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
tl;dr
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
hello
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,
Jock
P.S. This edition of PRODUCTHEAD is kindly sponsored by Product-Led Alliance. Find out below about their free event on October 19, 2023.
✉️ Contact us if you want to sponsor an edition ✉️
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
The ultimate guide to developer counter-productivity
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.
Where all that time and effort really goes
[John Cutler / The Beautiful Mess]
Summary for How to predict when the team will finish a specific backlog item
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.
Practical tips for any team struggling with prediction/estimation
[Johanna Rothman]
My stories aren’t long enough… except when they are too long
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?
[VIDEO] Helping the team to unpack true user needs
[Rich Mironov / ProductTank Auckland]
A Product Story: The lessons of Backstage and Spotify’s autonomous culture
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.
Fixing the problem of “rumour-driven development”
[Gustav Söderström / Spotify Engineering]
recent posts
Getting your first job as a product manager
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!
Practical tips for breaking into a career in product management
[I Manage Products]
Force multipliers
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.
Getting more out than you put in
[I Manage Products]
How to sharpen up your vision and strategy
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.
Use these straightforward questions and worked examples
[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
Jock Busuttil is a product management and leadership coach, product leader and author. He has spent over two decades working with technology companies to improve their product management practices, from startups to multinationals. In 2012 Jock founded Product People Limited, which provides product management consultancy, coaching and training. Its clients include BBC, University of Cambridge, Ometria, Prolific and the UK’s Ministry of Justice and Government Digital Service (GDS). Jock holds a master’s degree in Classics from the University of Cambridge. He is the author of the popular book The Practitioner’s Guide To Product Management, which was published in January 2015 by Grand Central Publishing in the US and Piatkus in the UK. He writes the blog I Manage Products and weekly product management newsletter PRODUCTHEAD. You can find him on Mastodon, Twitter and LinkedIn.
Leave a Reply