During these work-from-home times, I’ve been doing a lot of video-based AMA’s (Ask Me Anything). It gives me a break from my writing, and I enjoy the questions. Every so often I get a question that really makes me think, and that happened recently, and is the subject of this article.
I had just answered some questions about the differences between feature teams and product teams, when one of the listeners asked me, “OK, I know we’re clearly a feature team, but if you could pick just one thing to change about how we work, what would it be?”
I had been asked this question in the past, in the context of an empowered product team, and my answer was qualitative user research in order to get the insights that innovation so often depends on. But that’s for a team that’s already empowered.
So after considering this question for a while, if I had to pick just one thing, it would be the concept of an empowered engineer.
Certainly, I’m not saying that’s all that’s required, as extraordinary products come from product teams. But I am suggesting I believe this is the single most important thing.
I could frame most of my writing and coaching around the concept of an empowered engineer.
I have said many times that the best single source for innovation is your engineers (because they’re working with the enabling technology every day, so they’re in the best position to see what’s just now possible).
The product vision is intended to attract and inspire these engineers.
The product strategy is intended to ensure these engineers are working on the most important problems.
The team objectives give the engineers clear statements of the problem to solve and the outcomes to strive for.
The product manager and product designer provide critical constraints regarding business viability and customer experience, respectively.
User research and data science provide the engineers with key insights.
And to be very clear, just letting your engineers decide how to code a solution is not what is meant by empowerment. Of course they need to decide how to implement.
Letting your engineers determine the architecture is also not what is meant by empowerment. Of course they also need to be able to decide the architecture.
Empowerment of an engineer means that you provide the engineers with the problem to solve, and the strategic context, and they are able to leverage technology to figure out the best solution to the problem.
An easy way to tell whether you have empowered engineers or not, is if the first time your engineers see a product idea is at sprint planning, you are clearly a feature team, and your engineers are not empowered in any meaningful sense.
I’ve long said that if you’re just using your engineers to code, you’re only getting about half their value.
Hopefully this is obvious, but a strong tech-powered product company would no sooner outsource their engineers, than they would outsource their CEO.
The best tech companies understand this. They all have dual-track career ladders for a reason. Their top engineers are generally compensated at the level of a vice-president.
The engineers are the easiest way to tell if the company has teams of missionaries or teams of mercenaries.
Note that I’m not suggesting that you put your engineers on a pedestal. They are ordinary people like the rest of us. But I am suggesting that you treat them like the first-class members of the product teams they need to be.
Often when I’m asked to talk to a company, the head of product will warn me – “we’re a sales-driven company” or “we’re a marketing-driven company” – but occasionally I’ll be warned “we’re an engineering-driven company.”
When a company is so-called “engineering-driven” it is usually very straightforward to transform the company into a world-class product company. That’s because they have already addressed the most important part.
Just consider the breakthrough innovations you use and love every day. Odds are that innovation originated from an empowered engineer.
If you do nothing else other than this, you will have meaningfully moved forward on your use of technology, and on giving yourself a real chance at continuous innovation.
