Product & Technology can be a delicate ecosystem
I’ve come across many organisations that struggle with consistent high-quality technical delivery. There are lots of reasons why this delivery may not be at the level an organisation would like, for example: a lack of alignment in overarching business strategy and/or goals, a lack of buy-in from senior leadership on ways of working, or a mismatch of net resources relative to ambition. I believe, however, that one of the biggest challenges to consistently high-quality technical delivery, is keeping an organisation’s Product & Technology capability in equilibrium.
To elaborate, all of the core disciplines in Product & Technology need to be kept in sync, much like the type of ecosystem that we might find in, say, a tropical rainforest or giant vivarium. This balance is important, not simply in the ratio of the roles themselves, but also in their capability level. If this isn’t constantly monitored and levelled out, the ecosystem will begin to fail, people will leave, causing destabilisation and an ongoing domino effect of failure over time, which clearly nobody wants. We want the trees, the moss, the ants, and the natural spring to all be in harmony, enriching each other as they grow. Of course, they are expected to expire, but provided the balance is right, they will prepare the environment around them for the next generation to come through, setting them up for success.
Though I suspect it varies a lot from one organisation to another, in my experience Product & Technology are often seen as one large delivery function, rather than the highly granular set of interdependent cross-functional disciplines that it comprises of in practice. It becomes obvious when you start to break it down. Although, simply separating “Product & Technology” into its two component titles doesn’t go far enough, in fact in some instances it’s just plain wrong and unhelpful to do so. There are, to some extent, Product professionals and Technology professionals, but Product Engineers will span across both and many Product Managers and Product Designers have strong technical knowledge and skills too. In practice it’s lots of different disciplines and highly varied roles, each focused on honing a complimentary craft that they bring to the table, but critically, they all have to work together.
Often overlooked when thinking about a Product & Technology function is this holistic balance of capability; the skills and experience that any one individual might have relative to another. For example, pairing a highly experienced Product Manager with a team of graduate Software Engineers will have some advantages if done intentionally, but in most instances, it’s probably going to create a lot of issues and is unlikely to result in well-paced high-quality delivery.
In my next few paragraphs let’s go with extreme examples to emphasise the point, although please don’t be offended if I play ever-so-slightly into some stereotypes! 🫣
Is Product Management stronger than your other disciplines?
Product people thrive on getting new experiences into customers’ hands, experimenting and generally generating new value. If they can’t do that because the other disciplines can’t keep up with the pace of the backlog, then they’re going to get frustrated. Product Managers can do a certain amount of independent competitor and market analysis, as well as refine the backlog and make sure everything is as slick as possible for when it can be picked up within the team. They can also support wider hiring and upskilling. However, if they can’t ship quickly, and this isn’t resolved with some expediency, they’re probably going to get bored and ultimately leave in pursuit of roles where they can have a greater impact.
Is Design stronger than your other disciplines?
There’s only so much you can tweak a single design. We’re talking about a highly creative role here, it’s near impossible for people in this area not to start thinking about future designs and getting ahead of the team, which is not a bad thing but can be riddled with pitfalls. Designers will only be able to get so far by validating prototypes through low-fidelity user testing, if they’re not able to validate their work by receiving real-world insights they’re likely to design for the wrong conditions and take the team down a route that may not drive value, or at least as much of it. They’re also going to potentially miss-set a bunch of expectations by generating designs that the wider team is unable to deliver against which, in turn, is likely going to be demotivating for them and those around them. If left unchecked, good Designers are likely also going to leave under these conditions.
Is Engineering stronger than your other disciplines?
Software Engineers will build stuff, but… will it be valuable stuff? Engineers, without strong Product counterparts, might spend a bunch of time and money building and rebuilding things that don’t add any notable incremental value. Engineering can happily create a backlog of paying down technical debt, refactoring code, updating libraries, investigating new technologies and improving features that they’re interested in. It rarely takes long for someone to spot that your most expensive function isn’t delivering a sufficient ROI though. If they’re true Product Engineers, they’ll likely realise they’re not delivering customer or business value too, and yep, they’re also going to leave.
I have, of course, oversimplified the examples above to make my point. Any one of these disciplines could be broken down further — if you’re frontend engineering capability and your backend engineering capability is out of sync, it’s going to cause very similar issues.
So what do you do? Here are a few tips:
- Routinely talk about holistic capability and personal development not just at an individual or discipline level, but at a directorate/divisional level. Discuss the gaps/shortfalls and the impact this is having, as well as how the different disciplines can better support each other in the pursuit of balance.
- Try to avoid spreading your best people out in the hope that they will upskill those around them. In my experience this tends to lead to slowing down delivery, burn-out and limited upskilling (and yes, you guessed it, people leaving again). Instead, when building out teams start small, focus on a single team at a time and bring it into a steady state of balanced capability, then protect it before moving on to the next one.
- Talk about capability with teams openly — this might be through an ongoing employee engagement survey, although better would be an informal discussion at something like an All Hands meeting (you can always have a mechanism for people to share their sentiments anonymously in advance if you feel it’s needed).
- Invest in training — whether that’s simply giving ‘permission’ for people to carve out personal development time or actually paying for courses. Above all else, we want to encourage continual learning behaviours.
Beyond capability, good organisational design will also go a long way. Ensuring you have well-formed teams with a solid ratio of, say, 1 product person to every 3 software engineers is a good place to start. Thinking about the Squad operating model and the balance of roles is another — a Product Manager, a Product Designer, an Engineering Lead with 3–5 Engineers. Read more about what my view on good organisational design looks like in my blog post on Roles in a Product Engineering Squad.
Writing about all this is easy of course, doing it in practice is hard. I believe Product & Technology to be a delicate ecosystem and in order to flourish it needs continual care, monitoring of role ratios and capability, with sustained investment over time.
Check out more from my series of Leadership articles or my practical guides on building and operating effective Product Engineering Squads.
All thoughts are my own.
