I’ve seen a similar pattern pop up in three different companies and I’m writing this to see if anyone else has seen it too. Each company is in a different industry. One is small, one is medium and one is massive. The leaders are frustrated with the lack of progress and the amount of friction in the system.
They are talking to me because they want someone to help them figure out what to do. They need an outsider to figure out where things are getting blocked. The symptoms are challenges prioritizing, friction between roles, and products or features that don’t resonate with customers.
There are a lot of ways you can prioritize what to build. In some organizations product makes the decisions and others are more democratic. RICE (Reach, Impact, Confidence, Effort) is a popular method for making decisions. Here is my favorite, we gave it the name GAS (Give a S#$t) score.
“Hold on a second. I’m like a two-out-of-ten on this. How strongly do you feel? I’m probably a six-out-of-ten, I replied after a couple moments of consideration. Cool, then let’s do it your way.” - Cap Watkins (Posted at a now-defunct blog)
When people, particularly engineers, talk about a need for prioritization frameworks I think it’s a front. I think what they are really saying is that I don’t trust your decision-making because it feels like you are just making it up and putting your own preferences above everyone else’s.
I’ve seen an engineering team go rogue on their product manager and cut them out of decisions. I’ve seen engineering and product teams have their own feature wish lists that are prioritized separately. They were trying to solve the problem of not trusting product decision. These are both terrible ways to solve any problem and I gave the people who did them lots of crap for it but I understand why they did it.
If everyone knows who the customer is and what we’re trying to achieve as a team, it shouldn’t be that hard to prioritize. It should make logical sense and with some debate people can get on board. They can do what Cap Watkins and his colleague did above. They can run an experiment and see what happens.
When people don’t know what they are trying to accomplish and why it matters one of three things happens: they get beaten into submission and blindly execute, they quit or they try to go their own way and drama ensues.
More than once, I’ve taken on leading a team of people who have been given the brand of being divas. They have the reputation of being insular, self-important, unwilling to compromise and difficult. When I dug in what I found was people who were deeply committed to their customers, wanted to make a good product, felt the organization didn’t value their craft and were always put in a position where they had to make concessions.
Engineering scales faster than product or UX, there are common ratios and expectations of when you need to add Engineering heads based on how much pizza you need. Product tends to be created and grow once they are swamped. It puts them in a position of being constantly behind and being blamed for slowdowns.
A common pattern I’ve seen for the last few years is that the further up the organization product, UX and engineering meet has a direct relationship between how well they work together. If a leader is holding them accountable for collective results you see a lot more collaboration.
If you want a team to work together better you need to create an environment and encourages good behaviors. Most people are having to overcome their environments and even act against their best interests related to bonuses to do what needs doing.
Image: A friend took this while we were climbing at Seneca Rocks, WV. There was a lot of “exposure” which apparently is climbing lingo for scary as shit.