What engineering managers must un-learn

You got to where you are by very precisely instructing the computer to do something quite complicated and often nuanced. Maybe you spent years in school, or years of self-directed study to learn how to do this. You have been rewarded for demonstrating things like:

• Ingenuity
• Resourcefulness
• Grit, or persistence

Then you entered management. Did anyone teach you how to manage? Did anyone tell you what “great management” should look like?

All your years of software experience barely help you to excel at management.

In fact, some of the habits you were rewarded for as a programmer are actually hurting you. Today I’ll share some habits you should strongly consider un-learning.

Cage the “advice monster”

As a manager, your job is to create an environment for success. Very rarely is it necessary for you to solve someone else’s problems for them. Even if someone on your team asks you directly for advice, think twice before giving it.

Michael Bungay-Stanier, one of my favorite coaches and writers, coined the term “advice monster” in his book The Coaching Habit (which I love and constantly recommend). It’s a monster because it almost feels like it is controlling you, forcing you to take the gratifying dopamine hit of sharing your brilliant advice.

But every time you give advice, you take away an opportunity for growth. Instead of giving advice, ask better questions.

You can try Bungay-Stanier’s questions, or you can invent your own questions using the GROW model.

The bottom line: give less advice, ask more questions.

Stop engineering everything

In the late 1800s, a mechanical engineer named Frederick Winslow Taylor became obsessed with industrial efficiency, and in 1909 he published a book called The Principles of Scientific Management, which has been touted as “the most influential management book of the twentieth century.”

Taylor’s meticulous, empirical approach to eliminating waste in commercial engineering processes permanently altered the course of industrial history, but what Taylor left behind for us in the tech world is the terminally misled notion that everything you want to improve should be measured.

It is wrong to suppose that if you can’t measure it, you can’t manage it—a costly myth.

—W. Edwards Deming

So-called “Taylorism” glorifies the measurement of anything and everything in search of process efficiencies. That approach was revolutionary for the factory floor, but what about our jobs?

As an engineer, you love data, experimentation, and empirical objectivity. There is nothing more gratifying to an engineer than watching the dashboards as a change goes out and drops the p99 load time of a crucial page by 500%. That kind of feedback loop is intoxicating, and we are trained to create them.

But in teams, processes, and people, very little is actually measurable.

You can measure things, but the things you can measure aren’t the things you want to know, and in vanishingly few cases can you afford to design a controlled experiment where the thing you really want to know can be observed.

The common case is that you can’t measure what you want to measure, you can only measure a proxy and in order to meaningfully interpret even that, you either need to run an experiment that you probably don’t have the resources to run, or do statistics that you probably don’t have the expertise to do.

—Richard Marmorstein (@twitchard)

That isn’t to say that no metrics are useful or that you should give up and stop measuring things entirely. But when it comes to the operations of a team, turn to metrics as a last resort, and remember that they are proxies and are best considered in the aggregate, as a constellation of points informing a trend.

It’s more useful to make strong arguments with conviction based on experience. Weak leaders lean on metrics to shield them from criticism, which leads to low-morale teams that operate like a factory floor.

Resist the siren song of “scientific management.”

Don’t do it all yourself

As an individual contributor, you were highly rewarded for diving into any problem and figuring it out. Armed with your experience, ability to search the internet, and millions of StackOverflow pages to reference, you could overcome nearly any challenge.

Not only was your single-minded persistence and ingenuity rewarded, but it was rewarding. There is nothing more gratifying than going away by yourself and completely solving some vexing issue that everyone has been struggling with.

Unfortunately, that approach to leadership is not only ineffective, but it’s totally alienating. A manager who observes a problem, goes away by themselves and invents a solution, and then announces it victoriously to their team is called a dictator. You don’t want to be that kind of manager, do you?

People are unpredictable, illogical, and emotional. You are, too. The right way to approach team and process issues is, first and foremost, to achieve a complete understanding, and then co-create the solution.

Turn to your team and ask great questions. Share early drafts and workshop process changes before putting them into effect. Don’t assume that a promise to iterate will make everyone open to any experiment.

Consider how people feel. This means asking, yes, but also observing. Identify each team’s “meteorologist,” that one person who always knows what’s on everyone’s minds, and turn to them for insights often.

Be vocal about how you predict people will react to changes you want to make, and if it’s something you feel is necessary but unpopular, own that.

Your job is to co-create an optimal process with your team, not to descend from the mountain with the “perfect solution” etched on stone tablets.

Three questions

1. What part of your team’s work is over-engineered right now?

2. When someone brings you a problem, how many questions do you ask before trying to figure it out?

3. Who is your team’s “meteorologist?”

Comments