Empowered Engineers FAQ

In my last article I spoke about the concept of an empowered engineer, which I consider the single most important concept for companies that want to move from feature teams to product teams.

Overall my sense was that most people understood the points, and many told me they could personally relate as they have seen the power of an empowered engineer first-hand.   

However, I did get several questions, and the topic did generate some conversation on social media, and some of the questions and opinions out there are frankly disturbing.  So, I thought it would be good to get these thoughts on the table, and confront them head on.

The reason this is important is because I believe that some of these opinions are at the core of why product management has such a poor reputation in so many companies.  

More generally, many people over the years have expressed frustration and confusion as to why so many strong product companies require (or at least very strongly prefer) product manager candidates that have a technology background.  I think this dialog helps to explain why these companies feel so strongly about a technology degree.

“My engineers are not interested in anything but coding.”

This is by far the most common excuse from people that don’t believe in empowered engineers.  I have heard it countless times, mostly when I ask a product manager or product designer why their engineers aren’t participating in the product discovery work.

The first thing I should acknowledge is that occasionally this is true, and I’ll come back to this situation later.  But in my experience this is the exception.

Whenever I hear this, I insist on speaking to the engineers directly.  Much more often than not, this is not what the engineers say at all.  In fact, the most common complaint I hear from the engineers is that they are not included until it’s too late, and they are forced to deal with the consequences.  

What’s usually going on is that the product manager doesn’t want the engineers to be included because he would rather the engineers spend their time coding.  So in this case the issue is an over-zealous product manager, either hearing what he wants to hear, or not caring enough to even ask.

However, sometimes the engineers do tell me they don’t really care much about discovery – they prefer to code, and are fine building “whatever.”  In this case, I ask the last time any of the engineers were able to personally visit with a customer?  And the answer is usually between a very long time ago, and never.

But as I said above, sometimes not even a single one of the engineers has any desire to do anything other than code.  In this case, my discussion moves to the CTO/VP Engineering, and I explain that they have mercenaries and not missionaries, and why they need to raise their bar on hiring engineers.  At a minimum, they need at least one true tech lead on each product team, and discovery is one of the big responsibilities of the tech lead.

“If I give my engineers this kind of power, all they will want to do is over-engineer and play with new technologies.”

If this is true (and not just another reason to keep the engineers focused on coding), then this is describing an empowered engineer but without motivation or focus.

An empowered engineer depends on having a visceral understanding of the customer’s pain.  Strong engineers hate to see customers that are struggling or unhappy.  They take it personally.

This is why it is so powerful to bring engineers to see customers directly.  They should be shown the good, the bad, and the ugly.

“Our best engineers only want to work on what they consider hard technical problems.”

This might be the same issue as above, or it may be these strong engineers are doing exactly the right thing because they are empowered engineers and they do understand the business.  For example, fault tolerance and site availability are very hard technical problems, but they are primarily business and customer problems.  Same with zero-downtime initiatives.  Same with continuous delivery.  Same with dealing with scale during times of rapid growth.

“My engineers are clueless about our customers.”

As I said above, this may be true, but if it is, this is squarely the fault of the product manager, and should be corrected immediately.

“I took a programming class in college.  I can serve this role, so my engineers can focus on delivery.”

You may be thinking nobody would really be arrogant or clueless enough to think or say this, but multiple people did.  I’m not sure what to do with people that think like this, other than try very hard not to hire them.

“If this is what my engineers are supposed to be doing, then what is my role?”

This is a remarkably common sentiment, especially from PM’s of feature teams.  The empowered engineer concept is just so far from their current reality that they have a hard time wrapping their heads around this concept.  That’s because it highlights the need for a very different type of product manager.  I point these people to the difference between feature teams and product teams.

“Of course I agree with empowered engineers.  As product manager, my job is to clearly define the problem to solve, and the measure of success, and then get out of the way.”

I’ve seen this opinion floating around on the fringes for years.  But hopefully everyone can see how ridiculous this is.  In fact, if you have a product strategy, then this has already been done for you by your manager.  And how long would it take your manager to realize that she can move your headcount to get another engineer or designer and not lose a thing?

Of course, someone who really thinks this is very likely at a company that doesn’t have a true product strategy, and is almost certainly a feature team product manager, which as I’ve said and this clearly illustrates, is really a project manager.

“Do you think it’s possible to be an empowered engineer if our company uses SAFe?”

Only a couple people asked me this.  And I’m pretty sure they already knew the answer.  I’m sorry but I don’t see how, as the models are polar opposites in terms of the role of engineers.  But hopefully this concept gives you a better understanding of why processes like SAFe are not used at true tech-powered companies that depend on innovation.

“Does this mean that product designers and product managers are not important?”

I find it hard to believe that anyone that’s been reading my writing over the past many years could think this, but some did.  As I said in the opening of The Most Important Thing: “Certainly, I’m not saying [an empowered engineer is] all that’s required, as extraordinary products come from product teams.”

If you’re still confused about the concept of an empowered engineer, I am hoping that at least one of these other articles will resonate with you: Customer Inspired; Technology Enabled, The Role of Technology and Empowered Product Teams.