Happy product engineering orgs are all alike. Every unhappy product engineering org is unhappy in its own way.
(Apologies to Leo Tolstoy)
This is an early access article for Founder Members. It will be made available to other membership tiers over time. Enjoy your early access and let me know what you think about this article in the comments below.As promised, expanding access to all paid subscribers. Enjoy your early access. The article will be made free for all in a couple of weeks. If you can’t subscribe, all you need to do is wait a bit. If you can, I’d appreciate all the support I can get for my writing.
Cheers
Ah! Product Engineering — the volatile marriage of hackers and hustlers, the awkward cohabitation of Jovians and Saturnians, the Odd Couple of the professional world — many are your woes, colossal your misunderstandings, how unhappy your marriage!
But it needn’t be this way. Come, let me tell you a story.
We set the scene in a mid-sized product engineering org at a company whose product is quite scaled up. Now in a scaled up product it’s very hard to unlock new opportunities for growth and so the Product team would spend endless hours in the weeds of the data searching for an opportunity to extract just a little bit more value from their users. This naturally involved a lot of meetings with leadership and leaving each meeting with the exhortation to search more, to search harder and also to search in a different place.
In other words, the product team was very busy.
And in order to keep the engineers busy, the product team would bring to the backlog their most promising ideas — tweak this copy and we’ll see a 2% increase in conversions. Add this new type of discount code for a 1% hike in revenue. Add a hidden div with a photo of Laxmi, the Goddess of Wealth, to bless our payments pages… none of it moved any numbers.
All this time the Engineering Manager had been suggesting that the team might be better utilised paying off some technical debt. The payment pages were slow and the team had identified several bottlenecks that could improve the performance. Also, technical debt meant that the experience of working on these pages was very painful. Perhaps they might consider taking a sprint to rewrite parts of it in React?
A whole sprint?, asked the terrified PM. But, but that means that all these projects will be late. Request denied.
And so it went. The engineers would slave over one feature after another and nothing seemed to work. Along the way, two things happened concurrently. The EM started to run out of patience. And the PM started to run out of ideas.
At one sprint planning meeting the breaking was reached and crossed, left in the rear mirror. The EM finally put her foot down and said ‘enough is enough! we’re not working on your shitty ideas any more. The devs have suffered enough. Please go away for one sprint.’, The PM considered the steely determination on the EMs face, looked at the items on the backlog and seeing that he was now at the stage of seeking Divine Intervention, magnanimously agreed.
But the magnanimity was a mere show. Inside, the PM didn’t feel it. A whole sprint wasted on devs wanting to scratch their own itch instead of ‘doing what’s right for the business’! Oh, the waste! The sheer waste!
For the whole sprint the PM paced up and down, agitated, searching furiously for a way to save his job — because that’s how bad it had gotten. It was only with a great effort of the will that he restrained himself from popping in to the team every few hours to ask how it’s going. Besides, the EM was standing guard with a grim and determined look on her face. The PM inferred correctly that she was not a woman who would be putting up with any interruptions.
To distract himself, he started a long running TT match with the CTO.
The smiles on the faces of the team as they worked only served to increase the PMs irritation. ‘These nerds only care about one thing’, he fumed as he stalked off to the Cafe for another game of TT.
A week passes. Only another week to go to the end of the sprint. PM wakes up on Wednesday morning to a release notification. The new payment pages have rolled out to 10% of users. The data starts to trickle in. It’s obvious that nothing is broken, but there’s so little data that one can’t really infer anything more. The team rolls out to 50%.
PM wakes up on Thursday morning to find a healthy bump in revenue. Checking the results of the A/B he finds the new payment pages converting 30% better than the old ones. There must be some mistake! he says. This cannot be.
By the time Friday evening rolls around it is confirmed. The team is high-fiving and whooping it up in the office. The PM, feeling mighty sheepish, walks up to the team, swallows his pride and gives them all a heartfelt congratulations. The owner of the company walks by and says ‘I saw the reports this morning. Good job, PM’.
‘Thanks boss’, says the PM and then stops. And he feels something relax in his heart and he says ‘Actually this was the EMs project. She should get all the credit.’
And just like that, the team had crossed one of the two uncrossable chasms.
At the next planning meeting the PM sits down, rubs his hands gleefully and asks — so what technical debt should we pay down this sprint?
The CTO was waiting for him at the TT table.
A wise man once said -
The biggest determinant of execution success is a cohesiveness of thought from the top to the bottom of the organisation.
There is the famous story of JFK visiting Cape Canaveral, after having thrown NASA under the bus with a goal so audacious that from then onwards all such audacious goals would be called ‘moonshots’. There he met a janitor and he asked him ‘what do you do?’. Pat comes the reply — I’m sending a man to the moon.
This is a level of mission driven cohesion that puts lesser orgs to shame, where people say ‘I do frontend’ or ‘I represent the user in my org’. Does your org have the cohesion of thought and intent that NASA had? Can you get the Saturnians to thrive on Jupiter, and vice versa?
For Product and Engineering to be of one mind, two chasms have to be crossed. PMs have to cross the chasm of misunderstanding about the developers. And EMs have to feel the needs of the business in their bones.
For a family to be happy, it needs love. And love is the taking of another’s interests as our own. When the PMs and EMs take each others’ interests to be their own interests, then the Product Engineering team can be happy.
These are the two uncrossable chasms and they are crossed not through effort but through the intense longing for the chasm to not exist anymore.