Be Nice to Engineering
I recently got a note from a former engineering partner asking about “what a good form of collaboration between product and engineering leadership would look like”.
Of course I asked about the why behind the question, and the response was eye-opening:
“I somehow always find myself working for orgs where me asking the connection to business outcomes question is faced with criticism for me stepping out of line”
Woah. What?!?
We’ve of course all been part of teams and projects where engineering was sidelined into a purely delivery role vs planning and learning, but it’s always jarring to hear directly from someone dealing with these shenanigans to the point where they wonder if their expectations are out of whack. While I’ve seen product leaders keep engineering out of the loop on strategy many times, it always comes back to bite you.
In my view, there are 3 things an engineering leader is ultimately accountable for, and each of them requires them to have deep business context:
talent pipelining
pattern matching
outcome mapping
No amount of strategy perfection matters without the ability to actually build and ship product, which is why talent is job #1. And the disproportionate makeup of most product teams is developers (followed by smaller ratios of PMs, Designers, Researchers, Analysts, etc). But it’s not just about creating a pipeline and closing candidates - engineering leaders have to ensure that the makeup of the team evolves with the needs of the org - examples include creating career ladders, introducing management hierarchy, and up-leveling promising people. And each of these hinges on the engineering leader being able to translate the broader business context into something digestible - otherwise, you risk folks being misaligned and just end up adding new talent for marginal gains.
The 2nd key asset a seasoned engineering leader brings is the ability to pattern match. For example, when there’s a service outage, is it a one-off black swan event or a sign of a system that’s going to have recurring issues? Or when the UI starts lagging with the latest release, is it a bug or the compounding effect of 1% latency hits over the last n releases? That judgement call on whether the org’s focus needs to be shifted or not based on day-to-day inputs is the experience that engineering leaders are hired for; but the pattern matching has to be blended with business context to make the right decisions. Maybe the outage was truly unpredictable, but re-earning customer trust might require spending cycles on system hardening work. Or maybe performance really has slowly but surely degraded, but maintaining delivery velocity and a feature gap vs competitors is the right prioritization. Product teams are idea factories, and engineering leaders need to have a clear pulse on shifting strategy and tactics in order to greenlight, end-of-life, de-risk, and prop up. Basically, without business context, the trade-offs calls start to become more wrong than right over time.
Lastly, true customer value and business impact (i.e. outcomes) are what product development is all about - but if you look at what any team is working on in a given day (organizing JIRA tickets, answering support questions, etc) it’s very hard to see how the dots connect. And for the leadership team of the company, everything comes down to a handful of key levers (revenue growth, market share, customer retention, product adoption, operating margins) - so the onus falls on engineering leadership to tie work on the ground to company objectives (this is why an engineering operations team usually gets pulled into the rollout of a framework like OKRs). But if engineering leaders don’t have business context, they won’t be able to pull a steel thread through all the layers of work happening in the org.
Any way you slice it, if you work in product development, it just makes business sense (short- and long- term) to be nice to engineering.
I’d love to hear from readers about their adventures keeping engineering in the loop - please chime in via comments👇. And if you enjoyed this post, please consider subscribing.
further reading / references
I recently did an audio episode on the 5 C’s of why we cascade
if you’re interested in hearing about about product (vs engineering) leaders are accountable for, check out The Product Paradox
if you’re a leader dealing with how to align your org on shifting strategy without creating thrash, this pendulum analogy might help
a lot of the issues I highlighted in Implementing Product Strategy are exacerbated by not making engineering a true partner
childish drawing / interpretation
Have 💯 been there. Awesome write up.