PRODUCTHEAD: Empathy with engineering (or avoiding developer disengagement)
PRODUCTHEAD is a regular newsletter of product management goodness,
curated by Jock Busuttil.
street product (fade out) #
every PRODUCTHEAD edition is online for you to refer back to
Rather than focusing on engineering team productivity, examine the causes of their low / negative value work
When asked for development estimates, ask why they need the information and what they’ll do with the answer
Different development tasks need varying amounts of user story detail
Treat your developers with the same thoughtfulness as your users
A bit of difficult self-reflection this week. Are we actually helping our engineering team, or just reinforcing the stereotype of the ineffectual middle manager? Ouch.
Speak to you soon,
P.S. This edition of PRODUCTHEAD is kindly sponsored by Product-Led Alliance. Find out below about their free event on October 19, 2023.
Some engineers really resent product managers #
Despite it being our job to understand the needs of other groups of people, we sometimes find ourselves at odds with our team of engineers or developers. It doesn’t take much web searching to find a whole bunch of disgruntled engineers, resentful of their product managers or product owners.
“The vast majority of non-technical product managers I know are ignorant of the software we use. Their time is spent hounding developers on the status of tickets.”
“They create constant meetings devoted to asking me what I’m working on.”
“They can’t even prioritize things for me and I (or a senior developer) ends up doing that work.”
“At my last gig the Product Owner was also technical, so he would comment on PRs and also try to tell us how to do things. It was pretty annoying, although I’m sure it was well intentioned.”
“In general, PMs are terrible. A good manager enables their team. Terrible ones create barriers.”
“Right now I’m working with a good p.m. but do we really have to have meetings several times just about every day to update my status when my plate is overflowing? He’s not giving me enough time to get in the zone.”“Is it normal to resent product managers?”, various commenters on r/webdev, Reddit
“Overall, as an Engineer, I think Product Managers are 90% fluff. They are often not very knowledgeable about the industry, and they often do not have enough clout or political capital to tell upper management when they are on a wild goose chase. As a result they are often enablers of poorly-defined and consequently, poorly thought out products that are a nightmare to maintain and support that are not something the customer asked for.”“What do engineers think of product managers”, rmk on Hacker News
Where we’re going wrong #
It’s too easy to dismiss these as the rantings of a vocal minority. We can and do fall short of the mark. And when we do, we end up reinforcing the stereotype of being middle managers who add no value.
The main peeves engineers have with product managers are when we:
- are ignorant of the technology / product
- overreach the limits of our technical knowledge without any self-awareness
- push only process and add no value to the developers
- fail to provide the “why” to contextualise the “what” and “how”
- engage with the developers / engineers too much or too little
Oh snap. They’re talking about me #
Now I’ve made a whole bunch of mistakes over the years, and I’m mortified to say I’ve deserved these criticisms from teams I’ve worked with.
Partly to atone for my sins, I once wrote a short love-letter to The Development Team:
The really good developers can instinctively tell from a set of your software requirements where the complexity, performance bottlenecks, and other difficulties will arise in making the vision a reality. And that’s before they encounter a previously undiscovered bug in one of the many different building blocks of third-party software they’re relying on to assemble what you need, which necessitates them to either rethink the whole approach or undertake a massive development detour to work around the problem. They’re like car mechanics who can diagnose a leaking cylinder head gasket from the sound of a running engine alone and can strip down and fix the offending part by the end of the afternoon — but more so. Developers are miracle workers. They turn a product vision into reality and make it look easy.p.71, The Practitioner’s Guide To Product Management
It may have taken me a lot of trial and error to figure it out, but I’d like to think that I’ve transformed my relationships with engineering teams since those regretful early days.
What you do for your engineering team #
If you’re a product person at any level, part of your role is to put your engineering team in the best possible position to do their best possible work.
Sometimes this means stepping forward to provide the context.
Sometimes this means stepping back to let the team get on with it.
Sometimes this means shielding the team from C-level fickleness and unnecessary interference.
And sometimes this means delivering the message that work needs to stop and restart in a different direction.
Final thoughts #
Above all, respect your team and the difficult job they have to do. You should model the positive behaviours of transparency, accountability and trust that you would ideally want others to display.
When you do have a difference of opinion with your team, understand where your engineers and developers are coming from and, when you can, meet them half-way (and explain why not when you can’t).
what to think about this week
Productive developers spend more of their time and energy on high-leverage activities. Counter-productive developers spend more time and energy on low or negative-leverage activities. This skew is often only marginally within their control (and sometimes completely out of their control). It explains why the same developers in a different environment can be so much more (or less) productive.
[John Cutler / The Beautiful Mess]
I started this series with the issues of trying to estimate/predict a specific backlog item quarters away, not even weeks away. (Even weeks away is iffy because the entropy is the default state for the world.)
I used the example of my lunch: I know I will eat lunch. And even with my limited options, I do not know precisely what I will eat on a given day.
Product managers/owners often hear from our development team that all of our user stories are too short, insufficient, skimpy, lacking detail. Except when we hear that all of our user stories are long-winded, verbose, overspecifying how instead of what. What’s really happening?
[Rich Mironov / ProductTank Auckland]
In episode 08 of our podcast series “Spotify: A Product Story”, we share stories and lessons from building and open sourcing Backstage, our homegrown developer portal. Hear why a developer-friendly, market-based platform like Backstage could only have been developed at Spotify (where autonomy is prized, not top-down mandates) and why that ends up making Backstage such a flexible fit for other companies, too.
[Gustav Söderström / Spotify Engineering]
Job adverts present a chicken-and-egg problem: they all need you to have product management experience to secure a job, but you don’t yet have a product management job to gain that experience.
Don’t let this discourage you!
[I Manage Products]
Recently I was explaining to a client why I focus my efforts on finding “force multipliers”. These are what I call activities that allow us to extract multiple benefits from a single piece of work. You could think of it a little like a workplace fusion reaction, where the output ends up far greater than the input effort.
[I Manage Products]
When the vision and strategy are focused and clear, they allow product managers to prioritise and filter the possible options for their products more easily.
[I Manage Products]
can we help you?
Product People is a product management services company. We can help you through consultancy, training and coaching. Just contact us if you need our help!
Helping people build better products, more successfully, since 2012.
PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from dodgems, candyfloss and diesel fumes..
Read more from Jock
The Practitioner's Guide To Product Management
by Jock Busuttil
“This is a great book for Product Managers or those considering a career in Product Management.”— Lyndsay Denton