The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change

by Camille Fournier

Unfortunately, I’ve come to see that there are people who have never in their careers had a good manager. Friends of mine talk about their best managers as managing them with “benign neglect.” The engineer just kind of knows what to work on, and the manager just leaves them alone entirely.

For most people, good 1-1s are not status meetings. If you are a manager reporting up to senior management, you may use your 1-1 to discuss the status of critical projects, or projects that are still in the nascent stage where there’s not necessarily a lot written down yet. If you’re an individual contributor, though, a 1-1 as a status meeting is repetitive and probably boring. If your 1-1 is a dreadful obligation for delivering a boring status report, try using email or chat for that purpose instead to free up the time, and bringing some topics of your own to the 1-1.

Your manager should be the person who shows you the larger picture of how your work fits into the team’s goals, and helps you feel a sense of purpose in the day-to-day work. The most mundane work can turn into a source of pride when you understand how it contributes to the overall success of the company.

As you become more senior, the amount of personal feedback you get, both good and bad, is likely to decrease. You are operating at a higher level, and your manager is operating at a very high level. Expect the type of feedback to change somewhat from personal feedback to team- or strategy-related input. It’s even more important as you become more senior that you feel comfortable driving your 1-1s and bringing topics for discussion or feedback to your manager, because she is otherwise unlikely to spend a lot of time on this outside of performance reviews.

This is a job. Your manager will be stressed out sometimes. She’ll be imperfect. She will say dumb things, or do things that feel unfair or harmful to you. She’ll give you work that you don’t want to do, and get annoyed when you complain about doing it. Her job is to do the best thing for the company and the team. It is not to do whatever it takes to make you happy all the time.

Strong managers know how to play the game at their company. They can get you promoted; they can get you attention and feedback from important people. Strong managers have strong networks, and they can get you jobs even after you stop working for them.

There’s a difference between a strong manager and a manager that you like as a friend, or even one you respect as an engineer. Plenty of great engineers make ineffective managers because they don’t know or want to deal with the politics of leadership in their companies. A strong engineer may make a great mentor-manager to someone early in his career, but a terrible advocate-manager for someone who is more senior.

The alpha geek is usually an excellent, effective engineer who goes into management either because she was pushed into it or because she believes that the smartest person on the team should be the manager. She tends to undermine the people who work for her by belittling their mistakes and, at her worst, redoing the work of her teammates without warning. Sometimes the alpha geek will take credit for all of the work that a team does rather than acknowledging the strength of the team members.

If you’re ever in the position to promote people to management, be very, very careful in giving your alpha geeks team management positions, and keep a close eye on the impact they have in that role. The alpha geek culture can be very harmful to collaboration and can deeply undermine those who feel unable to fight back. Alpha geeks who believe that their value comes from knowing more than others can also hide information in order to maintain their edge, which makes everyone on the team less effective.

Emotional labor is a way to think about traditionally feminine “soft skills” — that is, skills that address the emotional needs of people and teams. Because the outcome can be hard to quantitatively measure, emotional labor is often dismissed as less important work than writing software. It’s assumed to be something that should just be provided without financial recognition.

He said, “Your thesis was one of the most lucid and clear theses I’ve read in many years. Thank you!” I was certainly gratified but also very surprised by his words. I had assumed that he, being a world-class mathematician, would “know all about it,” and just “watch” how my thesis would turn out. In fact, as he explained, he was able to do that, but only because I had taken the trouble to explain the basic ideas of the problem space and the motivations behind my ideas. I have never forgotten this lesson. Since then, after many years working in software and in large organizations, I have come to appreciate those comments even more.

We think our management “gets” what we do as technologists. Just “read the code, man!” The software we live and breathe every day ought to seem obvious to anyone working in technology, right? But it is not. Technology managers hire the best people (hopefully), who solve very difficult problems. But they don’t “get” it all. I’ve always been surprised how grateful senior technical managers have been when I can explain some very basic modern ideas (e.g., what’s this NoSQL stuff all about, and why should I care?) to them in a nonthreatening and noncondescending way.

You do set the standards for culture on your team, which is good and bad. It’s good when they take after your best aspects, and it’s bad when you realize that your team is also mirroring your faults.

Unfortunately, sometimes you will mis-hire a person. Having a clear set of expected goals for your new hires that you believe is achievable in the first 90 days will help you catch mis-hires quickly, and make it clear to you and to them that you need to correct the situation. Create a set of realistic milestones based on your prior hires, the current state of your technology and project, and the level of the person coming in.

Empathetic leaders can sometimes allow themselves to get sucked into an unhealthy closeness with their direct reports. If you start focusing a lot of energy on hearing reports’ complaints and commiserating, you’re quite possibly making the problem worse. You don’t have to have a to-do list, but problems in the workplace need to be either dealt with or put aside by mutual agreement. There is very little value to repeatedly focusing on drama.

A word of caution, though; if you treat a struggling engineer or project as a massive failure on the part of the individual or manager, she is going to feel that blame and criticism, and instead of giving you more information in the future, she’ll keep hiding it from you as a way of avoiding blame until it’s too late. Hiding important information intentionally is a failure, and getting stuck on a problem or making a mistake is often just an opportunity for learning.

Would you pore over the details of some project that is going smoothly, searching for any minor error?

Similarly, if someone has recently been promoted, you may want to prepare her for the fact that she will be reviewed based on higher standards.

A person who has never shown reasonable performance, and who has been with a company long enough for you to observe performance, probably doesn’t actually have potential, at least within that company. It doesn’t matter how good his school was, how articulate she is, how tall he is…if the employee has been with a company for a while with little to show for it, all that potential you are imagining is simply that — a figment of your imagination (or your biases).

Famous BigCo hires engineers out of college at level E2 (level E1 is reserved for interns). Famous BigCo has a policy that an engineer who shows no sign of advancing past level E2 after two years at that level doesn’t have a future at the company. It has this policy for levels E2–E4, but at E5, you can stay forever.

Some people will be happy cruising as senior engineers or managers at a certain level for their whole careers, and if you’re both satisfied with the work, there’s nothing wrong with that. Others, like your employee, want to progress but for whatever reason don’t seem to be able to do it on your team. You owe it to your employee to be clear that this is the case. This is what is meant by “coaching out.” Make the situation clear to him. You have told him repeatedly what the next level looks like, and he has not been able to show that he can work at that level, so you don’t think that your team is the right place for him to grow his career. You aren’t firing him, but you are telling him that he needs to move on if he wants to progress.

In particular, leaders in this role are capable of identifying the most high-value projects and keeping their team focused on these projects. As part of keeping the team focused, the engineering lead will partner closely with the product lead to manage project scope and ensure the technical deliverables are met. In addition to focusing the team, they are capable of identifying headcount needs for the team and planning and recruiting to fill these needs.

Furthermore, if you truly wish to command the respect of an engineering team, they must see you as technically credible. Without technical credibility you face an uphill battle, and even though you may be able to get into a position of leadership in one company, your options will be limited. Don’t underestimate the value of your technical skills as you work to become a successful engineering manager.

However, at this level, if you don’t stay in the code, you risk making yourself technically obsolete too early in your career. You may be on a management career path, but that doesn’t mean that you should wash your hands of technical responsibilities. In fact, I mention specifically in my engineering lead job description that I expect managers at this level to implement small features and bug fixes.

If your company is like this, my advice is to stay technical until you feel that you have truly mastered what you want to learn for writing code and designing systems, and then decide if you want to switch careers into management. It’s hard to make up lost time when you stop writing code, and if you do it too early in your career, you may never achieve sufficient technical savvy to get beyond the role of middle management.

Appropriate context is what helps teams make good decisions about how and where to focus their energy. As the manager, it’s not your job to make all of those decisions by yourself.

But there is such a thing as artificial harmony, and conflict-avoidant managers tend to favor harmony above functional working relationships. Creating a safe environment for disagreement to work itself out is far better than pretending that all disagreement does not exist.

Don’t rely exclusively on consensus or voting. Consensus can appear morally authoritative, but that assumes that everyone involved in the voting process is impartial, has an equal stake in the various outcomes, and has equal knowledge of the context. These conditions are rarely met on teams where each person has different levels of expertise and different roles.

Conflict avoidance often arises from fear.

One of the major changes at this level compared to the previous level is that your boss will expect you to be mature enough to manage yourself and your teams independently. This means that your manager trusts you to proactively deal with all those important but not urgent things before they become urgent, and especially before they become urgent for your manager. No one will tell you how to manage your calendar to give yourself the time to do this. I’ve seen managers fail at this point because they just could not juggle all the different tasks in an organized fashion.

If your team needs a manager more than they need an engineer, you have to accept that being that manager means that you by definition can’t be that engineer. I know some people manage both, but you need to decide, if you’re going to suck at one, which one that will be.

Handle Simple and Infrequent Tasks Yourself If it’s faster to do something yourself than it would be to explain it to someone else and it rarely needs to be done, roll up your sleeves and do it, even if you deem the task beneath you. This can be anything from booking the occasional conference ticket for your team to running the script that generates quarterly reports.

Saying no to your boss rarely looks like a simple “no” when you’re a manager. Instead, it looks like the “yes, and” technique of improvisational comedy. “Yes, we can do that project, and all we will need to do is delay the start of this other project that is currently on the roadmap.” Responding with positivity while still articulating the boundaries of reality will get you into the major leagues of senior leadership.

Sometimes you’ll hear ideas that seem very ill-considered. “Help me say yes” means you ask questions and dig in on the elements that seem so questionable to you. Often, this line of questioning helps people come to the realization themselves that their plan isn’t a good idea, but sometimes they’ll surprise you with their line of thinking. Either way, curious interrogation of ideas can help you say no and teach at the same time.

Some suggested prompts to provide the person you are holding the skip-level 1-1 with include: What do you like best/worst about the project you are working on? Who on your team has been doing really well recently? Do you have any feedback about your manager — what’s going well, what isn’t? What changes do you think we could make to the product? Are there any opportunities you think we might be missing? How do you think the organization is doing overall? Anything we could be doing better/more/less? Are there any areas of the business strategy you don’t understand? What’s keeping you from doing your best work right now? How happy (or not) are you working at the company? What could we do to make working at the company more fun?

First-time managers are tricky because if they truly don’t have the willingness to learn and aptitude to become solid managers, they’re a big problem. Making the wrong person a manager is a mistake, but keeping her in that position once you’ve realize she’s wrong for it is a critical error.

Culture fit is so important in managers because they shape their teams to their culture, and they hire new people based on their cultural ideas. If you hire a manager who doesn’t fit in culturally with the team she’s managing, one of two things is likely to happen: the manager will fail and you’ll have to fire her, or most of the team will quit and then you may still have to fire her.

The point of Schrödinger’s experiment was to show that the act of observing changes the outcome, or rather, causes an outcome to happen. Likewise, you can’t go into a team and not change the behavior of that team by being around them, sitting in their meetings, and watching their standups. Your presence changes the team’s behavior and may hide the problem you’re trying to find, in the same way that a log statement can cause a concurrency issue to be magically erased, at least for some time.

Read the code. Occasionally taking the time to read some of the code in your systems can help remind you what it looks like. Sometimes, it also shows you places where things have gotten ugly and need attention. Looking over code reviews and pull requests can give you insight into changes that are happening.

You’re capable of making hard decisions without perfect information and willing to face the consequences of those decisions.

I’ll leave you with some advice my own VP of Engineering once gave me: “Wanting to be a CTO (or VP of Engineering) is like wanting to be married. Remember that it’s not just the title, it’s also the company and the people that matter.” Titles are definitely not everything.

You’ll also need to repeat information when you’re communicating up. When you want your boss to act on something, expect that you’ll need to tell him the same thing three times before he actually listens. The first two times, the issue may still resolve itself, but the third time, it’s a sign that something bigger needs to happen. You may be surprised to find that you start acting the same way toward your team. Many problems will get raised to you and then resolved on their own, so you may decide you need a degree of sustained struggle from your team before it’s time to step in. I’m not recommending that you adopt the “three-times rule” as a policy, but it does tend to happen, whether you plan for it or not.

A very common clash occurs between people who are extremely analytically driven and those who are more creatively or intuitively focused. Another is between the people who prefer to embrace agility and change (and, yes, sometimes disorder) and those who push for more long-term planning, deadlines, and budgets. You have to figure out how to understand and trust everyone’s styles across the spectrum.

The final element of this first-team trust and respect is the cone of silence. Disagreements that happen in the context of the leadership team don’t exist to the wider team. Once a decision is made, we commit to that decision and put on a united front in front of our engineering teams and anyone else in the company. It’s easier said than done — I’ve struggled frequently with hiding my own disagreements with my peers. Letting go when you don’t get your way, especially when you don’t feel that your objections have been heard, is hard, and it will have to happen from time to time. At this level especially, you must decide whether you want to fall in line or quit. The middle ground, openly disagreeing with your peers, does nothing but make the situation worse for everyone.

You’re no longer one of the team. Your first team is comprised of your peers at the leadership/executive level, and your reporting structure has now become your second team. If you shift your mindset successfully, you will probably start to detach socially a little bit from the overall organization. When there’s a happy hour, you go for a drink and then leave the team to socialize. Closing down the bar with your whole organization will tend to have bad consequences for everyone, so I strongly advise that you avoid doing that with any regularity. Socializing heavily with your team outside of working hours is a thing of the past.

Transparency that may have been harmless or even possibly helpful at lower levels of management can become incredibly damaging to the stability of your team at this level.

Pretending to lack structure tends to create hidden power structures resulting from the nature of human communication and the challenges of trying to scale that communication.

Consider your breakpoint levels. It is common for companies to have certain levels that they consider “up or out.” These are early-career roles where a lack of advancement means that the person has not achieved the maturity or independence needed to remain at the company. This policy tends to get translated into your ladder as an implicit or explicit breakpoint level. What is the lowest level at which people can sit forever, never getting promoted but also not underperforming? This is your breakpoint level. For many companies, it’s somewhere around senior engineer. Someone who’s made it this far is a solid team member, but he may stay at this level indefinitely by his own choice. It’s good to have a notion of where this is. You may even want to use it as the point at which your ladder levels get harder to achieve. Expect your team to cluster around this level, with fewer people above or below it.