Instilling Harmony Between Product & Engineering Strategy
This article is a summary narrative version of a panel talk I recently gave at CTO Craft Con about instilling harmony between Product & Engineering strategies.
I think it’s important to first acknowledge that every organisation is, to some extent, unique. Not everyone will perhaps agree with this statement and there are certainly organisational patterns that we can spot but as Technology Leaders a big part of our role is to remain alive to what is going on in the organisation, the industry and in the wider Technology landscape in order to adapt and respond. Being curious, asking questions and responding to change are, in my opinion, some of the essential traits of a good leader. That being said, patterns do emerge and being able to spot or anticipate them can help remediate or even prevent unnecessary tension.
Let’s begin by exploring a few examples of where tension can arise between Product & Engineering. I’ve seen first hand, and heard about, situations where Product people…
- Constantly trip over themselves with upfront discovery activities
- Spend time prototyping something that has technical feasibility challenges
- Can’t get out as many A/B tests as they have planned
- Get frustrated with the need to pay down Tech Debt
- Don’t see the pace of delivery that they would like
- Are eager to buy software that does 80% of what they need right now
- Aren’t given space to think about accessibility by design
As well as situations where Engineering people…
- Feel like they’re always a bottleneck that nobody understands
- Get frustrated when purchased software doesn’t integrate as cleanly as they’d like
- Are asked to implement more A/B tests than they feel are valuable
- Don’t understand, or buy into, why a particular task has been thrown over the fence
- Are drowning in Tech Debt that slows them down and is difficult to maintain
- Aren’t given the space to think about security by design
The above points are just a few examples and can be symptomatic of a team that isn’t setting itself up for success.
So what can a team do to help alleviate some of these pain points?
First and foremost, make sure that there is a common goal across the organisation that the teams are working towards. Whether it’s the team or the divisional strategies, everyone needs to be moving in the same direction. This is one of the reasons why I always insist that if you’re in a Squad, your objectives ARE the Squads objectives, you don’t have your own individual set or a set that comes from your functional discipline. I talk more about this in my article Organisational Alignment — Establishing A Strong Product Culture.
Next, try to avoid thinking of the Product Strategy and the Engineering Strategies as two entirely separate things. Think of them as two halves of a whole. They are distinct, and it’s important to have the balance of both, but at the same time, it is better to think of them as a single joined-up Product Engineering Strategy in order to create real harmony and clarity of thought.
Consider, also, the balance of the team. Typically, you will want a ratio of ~1:3 Product Managers/Designers to Product Engineers to keep the team running at the same pace and prevent the Product Manager/Designer from trying to get ahead on discovery activities. Discovery is a team activity. The Engineers should be as involved at this stage as any other role, in part to go on the journey of understanding the user and in part because there’s more than likely technical discovery that needs to take place in parallel.
Make sure you have the right people in the right roles with the right expectations set. Align descriptions across peers and make things easier by being more specific and calling the disciplines Product Management, Product Design and Product Engineering. It helps set the right tone, creates a network of peers and with the right role profiles will help prevent the placement of what I would describe as Corporate IT Developers into Product Engineering roles. There’s nothing wrong with Corporate IT Developers but you wouldn’t get a house builder to build a boat, it’s a different skill set. I discuss this more in my post Product Engineering versus Corporate IT.
When it comes to buy versus build decisions, have an open and honest conversation about where the team can best add value. People, money and time are a three-legged stool that needs to be balanced to avoid toppling over. Focus the team’s time on building the value-add differentiator. The team should ask themselves what is it they are uniquely positioned to build. The other stuff, where commoditised, can be bought.
Above all these things though, a team needs to have strong empathy for the roles that the other team members are performing. I strongly encourage teams to walk a mile in each other’s shoes. Spend an hour a month pairing up for knowledge sharing. Talk about the role, the skills, the career path, the challenges, the highs and the lows.
A final thought, some tension and pressure can be healthy. You don’t want everyone to agree all the time or try to drive your strategy through consensus, this will likely result in it either stalling or not quite meeting the true needs of anyone. One of the most important skills of a leader is to know when to disagree and commit.
Thanks to all the other panel members for making it such a great discussion.
Check out more from my series of Product Management articles, Leadership articles or my practical guides on building and operating effective Product Engineering Squads.
All thoughts are my own.
