I wrote a piece this week about what motivates people to become managers (tldr mostly org dysfunction), and Julian Dunn replied with some typically insightful tweets:
(I originally titled this article “Julian Dunn and the Case of the Bad Manager”, lol)
God, YES. This is something that has been on my queue of “topics to write about” for so long, and I haven’t because it’s just too big (and sometimes I tell myself, optimistically, it’s just too obvious?).
Julian’s point is that the reason so many bad managers persist is because it’s perceived as a promotion. Which means going back to engineering after managing is, ipso facto, a demotion. Which is really fucking hard to swallow. For anyone.
I touched on this briefly in an earlier post, the Pendulum or the Ladder, when I wrote,
“If management isn’t a promotion, then returning to hands-on work isn’t a demotion, either. Right?”
There are a few separate points here which are worth unfurling separately.
- Management is widely seen as a promotion
- Management really does grant you some formal powers over your peers, which contributes to perceived hierarchy
- Humans are hierarchical mammals, exquisitely sensitive to any loss of status — we hates it
- But this is a cultural choice, not destiny. And we can change it.
Management is seen as a promotion
The notion that management is a promotion is deeply ingrained into our culture. It’s in language, pop culture, business books, any and all sources of career advice. If you became a manager and told your mom about it, she probably congratulated you and told you how proud she was. If you go out on a job interview, you’re expected to reach for the same rung or a higher one — or eyebrows will raise.
That’s a lot of cultural baggage to lean against. But I believe this is an idea whose time has come.
Any technical company should work hard to center and celebrate the work being done to build the product and make customers happy. Management is overhead, to be brutally frank about it, and we should not design organizations that would lead any rational, ambitious person to aspire to be overhead, should we?
The surest path to acclaim and glory (and promotions and raises) should be found through contributing. Not managing. Not being overhead.
… Because it mostly is a promotion, honestly
It is absolutely true that when you become a manager, you acquire new powers. As a tool of the org, you are granted certain powers to act on behalf of the organization, in exchange for being held accountable for certain outcomes.
These explicit powers often include hiring and firing decisions, access to privileged
information, and making and meeting budgets.
But most of your powers aren’t formal at all. Most of your power comes from people listening more closely to what you say, giving your opinions more weight, and (consciously or subconsciously) just trying to please you, because they know you hold some influence over their career outcomes. It comes from the fact that so much information flows through managers. And finally, it comes from relationships — the strength of your personal relationships and mutual trust with other people throughout the org.
So how is this not a promotion? Well, it is a promotion at most companies, to be perfectly honest. But it does not have to be a promotion, if you acknowledge that these privileges and powers are accepted only by sacrificing other privileges and powers, and if you structurally allocate power to other roles. For example, you should acquire managerial powers only at the expense of technical decision-making powers.
I believe that the healthiest companies are ones where managerial powers are limited, enumerated, and minimal, with robust powers explicitly reserved for technical ICs. (much like the Constitution provides for Congress and the States, respectively.)
But it shouldn’t be. “Management” is a support role
Here are some of the reasons why we should invert the hierarchy and embrace management as a service role, a support position.
- Tech is a creative industry. Hierarchical leadership is a relic, a holdover from the days of manual labor. Hierarchy kills creativity, which leads to worse business outcomes.
- Bad managers are a huge problem in tech. Just like Julian says, the wrong people are doing the job, for the wrong reasons, because they can’t to take the hit to the ego (and paycheck) of the demotion. This leads to unhappy teams and ultimately loss of talent.
- I firmly believe that the engineer-manager pendulum is the way to build great technical leaders. The great line managers are never more than a few years removed from hands on work themselves, the great tech leads have always done a stint or two as a people manager. The promotion myth therefore both starves us of powerful technical leadership.and leaves us saddled with unhappy managers who have dwindling relevant skills, year after year.
- The ladder is a trap. There are an order of magnitude fewer jobs for each rung you ascend. Meanwhile, the higher you climb the farther removed you are from the work most find meaningful (building things, making customers happy). The perception that you are a failure if you do anything but climb higher therefore traps a great many people in a cycle of intense anxiety and unhappiness.
- Management is only one of many forms leadership can take. Yes, you have formal powers delegated to you on behalf of the org, but formal authority is the weakest form of power, and you should resort to using it rarely. Good leaders lead by influence and persuasion, weak leaders with “because I said so.”
Most engineers become managers to cope with org fuckery
Many people (like me!) become managers because they want access to the powers it gives them. As I argued in my last article, this is usually because they are frustrated with some organizational fuckery and it seems the only plausible way to fix or work around said fuckery is by becoming a manager.
Earlier this year I was having a 1×1 with one of our engineers, Martin Holman, who has been a
manager before and had expressed interest in doing it again. So, I asked him, was he still interested?
He thought for a moment, and replied, “You know, I thought I wanted to be a manager again, I really did. But I think what I actually wanted was a seat at the table — to know what was going on, to have a say in what work I do. But I don’t feel out of the loop here. So it turns out I don’t feel any need to become a manager.”
Not only did that warm my heart, it answered a question I didn’t know I had. I think they would be a good manager, and should they change their mind again in the future, I will completely support them changing their mind again (minds change! it’s what they do!) — but I hope it is never because they feel that technical contributors are left out of the loop, or don’t have a say in what they do.
That’s what I’d call organizational fuckery.
A roadmap for changing your company culture
If “management is not a promotion” is a cultural value you would like to embrace at your company, here are some concrete actions you should take.
- Make sure the pay bands for engineers and managers are equal, or even pay engineers more than managers of the same rank. (Slack does this, or used to.)
- Have IC (individual contributor) levels for engineers that track management levels, all the way up to VP.
- Look for ways to give high-level ICs information and opportunities for company impact that are on par with their people-manager counterparts.
- Technical contributors should own and be accountable for technical strategy and decision-making, not managers.
- Demystify management. Break it down into its constituent skills (giving feedback, running meetings, planning and budgeting, mentoring, running programs) and encourage everyone to develop those leadership skills.
- Offer any management roles that may open up to internal transfers before considering external candidates.
- Offer training and support for first-time managers who are undergoing that first career change. Offer engineers the same leadership coaching opportunities as managers.
- Explicitly encourage managers to swing back to IC roles after two or three years. Support them through a generous grace period while refreshing their technical skills.
- Watch your language. Loaded terms are everywhere, whether hierarchical (referring to people as being “above” others), or authoritarian (talking about bosses, managers). While it’s impossible to strip it from our vocabulary, it’s worth being thoughtful in how you represent reality, and using neutral phrases like “I support two teams” whenever possible.
- Be explicit; repeat yourself. Say over and over that management is not a promotion, it is a change of career. Say it internally and externally, in your interview processes and recruiting messages. Educate your recruiting staff too (and be stern about it).
This isn’t a thing you can do once and be done with it; it’s an ongoing effort you must commit to. Managers tend to accrue power over time, like a gravitational force. In order to counterbalance this drift, managers need to consciously push power out to others. They must use their role as “information router” to inform and empower people to own decisions, instead of hoarding it for themselves.
“Management is not a promotion” is my favorite bat signal
“Management is not a promotion, it’s a change of career.” I say this over and over again, even though it’s more aspirational than accurate.
Yet I say it anyway, because it’s a bat signal. It’s how the people I want to work with can find their way to me. And it repels the people I don’t want to work with just as efficiently.
When we recently posted our first-ever job req for an engineering manager, I included this under the list of optional skills:
- You have worked as an engineering director or higher before, and decided to return to line management. Why? Because we value people who don’t blindly climb hierarchies just because they’re there. We value people who know themselves and what they find fulfilling in work and in life, and who can handle the hit to the ego that it takes to move “down” in pursuit of that fulfillment. Also, it would be interesting to talk about how you have solved org problems at other companies.
I cannot tell you how many amazing candidates zeroed in on that paragraph and came running. People who had been VPs before, been CTO, been director. People who were not only interested in becoming a line manager again, but were hungry to go back, to be closer to the people doing the work.
Something I heard them say again and again was, “People look at me like I’m crazy for wanting this,” “I have never had anyone see this as a strength.”
These were candidates who were acutely attuned to power dynamics, had exceptional self-knowledge, and who had seen and done so much to make organizations successful at multiple levels. What a set of superpowers!
Humans HAAAAAATE losing status.
We hate it. We hate it so bad. Even when we tell ourselves it’s what we wanted, even when we know it’s best for us, even when all the stars align. Something inside of us kicks and screams and feels excruciatingly attuned to the ripple effects of any status loss for a long time.
Like all such powerful irrational feelings, it’s evolution’s fault. Once upon a time it helped us survive and procreate. Now it’s just a nuisance, something to be worked around and minimized.
Where someone sits on the org chart should not determine that person’s ability to drive change, nor should their preference for tech problems or people problems. We need to see the work that engineers, managers, directors, VPs, and CxOs do as equally valuable and equally capable of prestige. We need to flip the org chart upside down, and treat “management” roles like the support systems they should be.
The work done by a database engineer is different from the work done by a VP marketing, or a director of database engineering. It is not inherently better or worse, easier or harder, more or less deserving of praise and admiration. It is simply different.
And we will have the best chance finding the work that brings the most meaning and joy to our lives if we can drain the hierarchical residue out of our perception of these roles, by flattening pay structures, equalizing power dynamics, and making sure everyone has the tools they need to do their job with as little hierarchical bullshit as possible.
 Martin said I could tell this story and use his name. I actually try to avoid talking about people, conversations, or anecdotes from Honeycomb as a more or less blanket rule, because I don’t want people to be perpetually on edge wondering if I am talking about them. (So if you’re wondering if I’m talking about you: I’m not. Unless I asked first.)
 Raise your hand if you’ve worked at a company where a DB engineer had a far greater impact on the bottom line some quarters than any of the VPs did.