How Can I Avoid Turning Talented Workers Into Crappy Managers?
By: Osman, Ozzie
Tags: Engineering, Management, One Question, Coders, Leadership

Growing teams need managers, and who better to manage a team than someone who is already part of one? While that may be true, picking the right person to become a team manager can be a lot harder than it looks. While this piece will focus on engineers, the lessons within are applicable to all kinds of worker-to-leader transitions.

There’s some pretty great literature on making that transition, on being successful in a new managerial role, and on avoiding common mistakes. There are even some great reads on transitioning back and forth between engineering and management. Having advised startups on this, overseen engineers transitioning to management, and personally become a manager, I’ve read it all. But before any of that can happen, a company’s management needs to decide: Which engineers should they ask to become managers?

This is no simple task, as I’ve learned the hard way. Through failure, I’ve been able to take what I’ve learned and put it into a framework for successfully choosing potential managers. Before we talk about what works, let’s talk about what doesn’t.

Failed attempt #1: Choosing the technical wizard

Rosie (all names are composites of multiple employees) is the strongest engineer on the team. She can navigate any part of the stack. And when people have questions about the code base, they ask her for help — after all, she wrote most of it. Sometimes she’ll patiently answer, but sometimes, if it’s faster, she’ll just roll up her sleeves and do it herself.

Rosie is fast. She gets things done. I can always count on Rosie.

So as the team grows and needs a manager, I ask Rosie if she’s interested. She seems reluctant at first, but she wants to help her team. And she’s never backed off from a challenge. She takes a couple days to think it over, and eventually, she says yes.

She seems fine initially, riding a wave of excitement and renewed confidence. But over the next few weeks, I can sense her energy dropping. She’s less on top of things. Her enthusiasm and confidence fall and she seems agitated. The rest of the team notices she’s far less effective as a manager than she was as an engineer — and even worse, things don’t seem to improve over time. I’ve fallen victim to the classic trope of losing a top engineer and gaining a mediocre manager.

Over a series of conversations with Rosie, she acknowledges that things aren’t going well. I offer my support and my confidence that if she wants to, we can make this work. Instead, she asks if she can transition back into a purely technical role. I agree, but even after her transition, her enthusiasm never recovers, and a few months later she accepts a technical role at a different company.

Failed attempt #2: But they said they wanted the role!

Lesson learned: Before transitioning someone to management, I should ensure they actually want to be a manager. Easy fix, right? I start keeping my eyes open for someone who is both a top-performing engineer and has an explicit interest in management.

This leads me to Adam. He frequently asks me questions about what it takes to manage a team and inquires about management-related reading recommendations. When I ask him what his long-term goals are, he says, “I’d love to get into management, because I want to start my own company one day.”

So the next time I’m faced with a need for a manager, Adam seems like a perfect choice. Not only is he interested in management, but he is also a solid technical performer, and is generally well-liked by people on his team and elsewhere in the company.

And things start off great! But they don’t stay that way. In my skip-level one-on-ones with Adam’s direct reports, they don’t give him the glowing reviews I expected. “It’s okay,” I think to myself. “He’s just ramping up. Things will get better.”

But things don’t get better. They get worse. One of his reports puts it bluntly: “I feel like I’m just a means to his end. He doesn’t care about me. I’m starting to dread our interactions.” Adam is too focused on his own career and growth, and it shows. His conversations with his reports are mostly spent asking them for status updates and pushing commitments on them. He doesn’t take the time to listen to their needs and concerns.

As you can guess, that story doesn’t have a happy ending either. Adam departs the company, leaving behind a team with very low morale.

What went wrong? In a nutshell, my approaches toward finding a manager were too simplistic. Since then, I’ve been able to put together a framework for identifying management potential, which I’ll present shortly. But first, it’s helpful to understand the psychology of work and how it impacts the engineer-to-manager transition. To do that, we need to combine two theories of motivation.

In the book Drive, author Daniel Pink argues that knowledge workers (as opposed to manual workers) are intrinsically motivated by three broad categories:

Autonomy: the desire to be self-directed

the desire to be self-directed Purpose: the desire to do meaningful work

the desire to do meaningful work Mastery: the gain and application of skills

I believe this framework does a great job of explaining someone’s medium- and long-term satisfaction with their work (and aligns with a more macro theory of human motivation known as self-determination theory). But it’s still pretty general, and misses the more short-term, day-to-day motivations of workers. To help bridge the gap, we’ll need another framework: organizational psychologist Mihaly Csikszentmihalyi’s theory of flow.

A technical person transitioning into management needs to be able to bridge a pretty big chasm of new skill sets and day-to-day activities. Technical ability and interest in management are not enough to bridge that chasm.

Csikszentmihalyi explains that “flow” is experienced when one is in complete immersion in a task, sometimes described as being “in the zone.” If you’ve ever felt like you’ve lost track of time (and the rest of the world) while writing code, performing music, or playing a video game, that’s flow. Experiencing flow doesn’t just make people more productive, it makes them happier and more fulfilled in both the short and long term.

Let’s examine how autonomy, purpose, mastery, and flow can change when someone transitions from technical work to management:

Flow

Writing software provides plenty of opportunity for experiencing flow. Flow requires, among other things, clear goals and quick feedback to actions. This is much more likely to happen during the long blocks of focused work that an engineer has while writing malleable, deterministic software — especially if a team’s software development process is well-engineered. Managers, on the other hand, usually have a much more fragmented calendar, with various meetings and interruptions. The feedback loops are also longer, and ambiguity is usually higher. Losing this “flow” as a source of day-to-day energy can be very jolting for first-time managers, who can suddenly feel like they have no way to measure their success or impact in the short term.

Autonomy

A lot of people believe that by becoming managers, they will gain autonomy. They have more flexibility on how to spend their time and can make more impactful decisions. This is often not true. Management often comes with more responsibility, more obligations, less flexibility, and, hence, less autonomy. You spend more time in meetings and more time answering emails.

Mastery

The skill sets required to be a successful individual contributor who solves mostly technological problems and the skill sets required to be a successful manager who solves people and organizational problems can be very different. Anyone making a transition between those two roles will, at first, experience a marked decrease in their effectiveness.

Purpose

Ideally, individual contributors enjoy building products and solving technical problems. They get to spend most of their time doing just that, and they can concretely see their output. If they’re at a well-run company, their managers have also helped them connect their day-to-day work to some broader mission or impact. This provides them with a sense of purpose. New managers often experience a “purpose vacuum,” since it’s harder to connect their day-to-day work to progress with a larger goal that excites them. This can often lead to adverse behavior, like continuing to perform their old role instead of their new one and/or micromanagement of their team. Another risk is making their purpose solely about “helping their team.” It’s an inherent part of any manager’s job, but if it’s their only purpose, it might come at the expense of their broader satisfaction, or they might make decisions that are good for their team, but not for their company.

Putting that all together, a technical person transitioning into management needs to be able to bridge a pretty big chasm of new skill sets and day-to-day activities, while also finding a sense of meaning and fulfillment. Clearly, technical ability and interest in management are not enough to bridge that chasm. But, there are a set of abilities that I think can predict success for a new manager. I believe the following underlying characteristics are the best predictors of success:

Empathy

Being a manager involves a lot more interactions than writing software as an individual contributor. You have to interact with, understand the needs of, and influence different people with different goals, different personalities, and in different places in the chain of command (reports, peers, superiors). I don’t think someone can do that sustainably and successfully without being able to understand and share the feelings of others.

Systems thinking

Successful managers realize that everything is a system, with inputs, outputs, and internal states. Systems can be structured in different ways, but they are complex because they can have feedback loops, non-linear behavior, second-order effects, etc. It’s funny, but as engineers who spend our days building technical systems, we often lack “real-world” systems thinking. A person at work is a simple system. A team is a complex system that needs to be designed for resilience, sustainability, and self-improvement. Systems thinkers can recognize system patterns and leverage points in different contexts.

Conscientiousness

Conscientious people have a desire to do good work, and are self-motivated to perform well regardless of whether someone is watching over them or not. They are action-oriented, dutiful, and careful. This might sound like a vague catch-all for a bunch of positive behavior, but it’s actually a “big five” personality trait that many people believe is ingrained, hard to change, and testable. I used to call this drive or ambition, but I think unbridled drive or over-ambition can result in people who are self-serving or political — which are probably not the types of people you want managing your teams.

Values alignment

Every company or group of people has an implicit or explicit set of values that define what is most important, how decisions are made, and what behaviors get rewarded and punished. If someone’s answers to these questions are very different than the company’s, it will be hard for them to be successful as a manager — and in fact may take a huge toll on their morale and the morale of those around them — because they will have to navigate a lot of cognitive and emotional dissonance.

Technical

Any person should be in a good state technically before they transition to management, but how technical a manager needs to be is a whole separate topic/debate. Before I transition someone into management, I want them to exceed a threshold I call “technical escape velocity,” which means they have enough of a technical foundation and enough self-learning behaviors that their technical skills won’t atrophy if they’re not writing software full time.

Other

There are other, more concrete skills that are needed from managers — like the ability to multitask, the ability to prioritize well, and the ability to communicate clearly — but I believe these are all learnable.

You can see how these things all need to balance each other. For instance, unchecked empathy without systems thinking could result in a manager who doesn’t take action to rectify underperformance. Systems thinking without empathy can be ineffective because it is uninspiring, and can lead to a manager who overlooks the fact that people are an important part of any system. Conscientiousness without systems thinking could result in a “hero” manager who tries (and fails) to do everything themselves.

So, how do you spot these traits? Here are some things to look for:

Does the person have a track record of being successful on projects that involve coordinating across different people, teams, and goals? Or is their success mostly on work where they didn’t need to coordinate with others? (Empathy, conscientiousness, value alignment)

Do they think at a “higher level?” For instance, if they see a problem (especially a repeated one), are they likely to solve it themselves, or think about second-order sources of the problem (which are often at the team or company level) and propose fixes for those? Can they recognize and instill virtuous cycles — or break vicious cycles — for people, teams, and projects? Can they decide when to go with a longer-term, more foundational solution to a problem and when to just go with an easy fix? (Systems thinking)

Are they constantly learning from others and teaching/mentoring others? Do people go to them with questions beyond just asking them for context about code they’ve written in the past? (Empathy, conscientiousness)

Can they pitch their company/team well to others — for instance, candidates considering working with the company? (Values alignment, empathy)

People, teams, and companies are complex and often unpredictable. But by looking for empathy, conscientiousness, values alignment, and a minimum level of technical prowess, you can significantly increase your ability to identify potential managers.

It’s usually wise to gradually expose people to management to help them (and you) assess whether it’s a fit before making any formal transitions. For example, let the person mentor an intern or onboard a new hire. Let them lead a project or run a regular meeting. Additionally, don’t treat management as a “promotion.” Ensure that people have paths to grow into non-management roles if that’s better suited for their growth (the “dual ladder” approach). Only encourage a transition for someone who is genuinely interested in management, and even when they are, provide them with as much support as you can. It’s never an easy change, but when it succeeds, it can be a huge boon to both your team and your new manager’s career.