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

by Camille Fournier

This situation is why you start giving feedback early and often, and keep records of the feedback you’ve been delivering. Feedback, positive or negative, should be a conversation. If you avoid tackling negative feedback until it builds to a boiling point, you’re going to be met by a pile of excuses, and then what do you do?

It’s a short step from managing a person or two to managing a whole team, but managing a team is more than just doing the job of managing the individuals. At this point, your job has changed. In fact, at every step beyond this level you will probably experience a totally different set of requirements and challenges. The hardest thing to prepare for as you advance in your career is the idea that you’re going to start doing totally different things. As much as you may want to believe that management is a natural progression of the skills you develop as a senior engineer, it’s really a whole new set of skills and challenges.

he returned to our team and agreed to work with me. It turns out, being a good manager isn’t about having the most technical knowledge. The work of supporting people was far more important to management success.

Furthermore, if you truly wish to command the respect of an engineering team, they must see you as technically credible.

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.

Sadly, some companies don’t really have the role of “manager who has a little time to code” available. These companies split the management and technical tracks so cleanly that managers immediately start with large teams reporting directly to them. Thus the manager’s job becomes an administrative and people management position, and these managers end up grabbing technical time on nights and weekends, if ever. 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.

However, it’s unrealistic to expect that you can or should shield your team from everything.

Sometimes, in combining the roles of shield and mentor we end up in a parenting-style relationship with our team, and treat them like fragile children to be protected, nurtured, and chided as appropriate. You are not their parent.

Having a team that is constantly bickering and disagreeing is painful, and can be very dysfunctional. 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 set people up for votes that you know will fail instead of taking the responsibility as a manager of delivering that bad news yourself.

The goal is to identify problems that are causing the team to work less effectively together and resolve them, not to become the team’s therapist.

Many of us believe that the way to be liked is to be seen as nice — that niceness is itself the goal. Your goal as a manager, however, should not be to be nice, it should be to be kind.

But as a manager, you will have relationships that go deeper, and it’s more important to be kind. It’s kind to tell someone who isn’t ready for promotion that she isn’t ready, and back that up with the work she needs to do to get there. It’s unkind to lead that person on, saying “Maybe you could get promoted,” and then watch her fail.

One of the critical elements of creating functional teams is building teams that work well and happily together.

It’s incredibly hard for a manager to justify getting rid of someone who produces great work, even though she’s a drain on everyone around her — especially if this person is only irregularly a jerk.

The best way to avoid brilliant jerk syndrome is to simply not hire one.

The best thing you can do for your team, in the context of having a brilliant jerk, is to simply and openly refuse to tolerate bad behavior.

Keep the feedback neutral but to the point if you are going to deliver it in the moment, in public.

The third type of toxic individual is the person who simply doesn’t respect you as a manager, or who doesn’t respect her teammates.

Simply put, if your team member doesn’t respect you or her peers, why is she working there?

You’ll probably be asked for rough estimates as to when work will be done, even work that is planned and iterated on in an agile fashion.

As you approach deadlines, it is your job to say no

You will almost certainly have occasional deadlines, either goal dates that you’ve set or goal dates that came down from on high. The only way to achieve these goals is to cut scope at the end of the project.

There will be times when the engineering team will say that they can’t possibly implement a feature without doing some other technical work, and you will need to figure out when to push for a hack implementation and when to hold back for the right implementation.

Joining a small team as a manager is tough. It’s one thing to balance technical work when you’ve been promoted to manager from software engineer, but it’s another thing to come in new with a team to manage and new code to learn.

Finally, even if you don’t intend to write much code, I strongly advise you to keep at least a solid half-day once a week completely free from meetings or other obligations, and try to use this time at least partially on some creative pursuit.

Almost everyone who goes from a heavily hands-on technical role into management has a transition period where they question frequently whether they’ve made a mistake.

Becoming a great manager requires you to focus on the skills of management, and that requires giving up some of your technical focus. It’s a tradeoff, and one you’ll have to decide if you’re up to making.

When you have so many management duties that you have little time to code, you can start to feel like your day has been taken hostage by the whims of others.

It’s time — now — for you to figure out how to manage your time. Otherwise, you’ll find yourself with days gone by and little to show for them.

Managing your time comes down to one important thing: understanding the difference between importance and urgency.

This is why so many precise time-management tips encourage reading and responding to email at specific times of the day.

Hold people accountable to prepare in whatever way makes sense. Ask for agenda items up front. Any sort of standard meeting that involves a group of people, whether it’s planning, retrospective, or postmortem, should have a clear procedure and expected outcomes.

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.

happy team will feel energized and engaged. An unhappy or unmotivated team will feel drained or bored.

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.

How do you feel at the end of the day these days? If you’re like many new full-time managers, you probably feel quite drained.

The first several months of managing multiple teams can feel like a death march, even when your hours are not excessive.

It is your responsibility, as a manager, to build up the talent in your organization, and to help your people learn new skills they’ll need for the next stages of their careers.

In this modern era, frequency of code change is one of the leading indicators of a healthy engineering team.

bet if you honestly take a look at a team that isn’t releasing frequently, you’ll see cracks. The process of performing a release takes a long time. Engineers don’t feel ownership over their code quality, and they leave all of that work to a QA team, which creates a lot of back-and-forth communication delays.

The beauty of pushing for more frequent releases is that it often uncovers a host of interesting challenges.

Incident management, when it becomes merely reacting to incidents rather than working to reduce them, can turn into a task that diminishes your team’s ability to do what they do best.

Before you try to change everything to fit your vision, take the time to understand the company’s strengths and culture, and think about how you’re going to create a team that works well with this culture, not against it.

The trick is not to focus on what’s broken, but to identify existing strengths and cultivate them.

But impatience paired with laziness is wonderful when you direct it at processes and decisions. Impatience and laziness, applied to process, are the key elements to focus.

As you grow more into leadership positions, people will look to you for behavioral guidance. What you want to teach them is how to focus. To that end, there are two areas I encourage you to practice modeling, right now: figuring out what’s important, and going home.

So be impatient to figure out the nut of what’s important. As a leader, any time you see something being done that feels inefficient, question it: Why does this feel inefficient to me? What is the value in the thing we are doing? Can we deliver that value faster? Can we strip down this project into something simpler and get it done more quickly?

While managing multiple teams can be exhausting and daunting, managing managers adds a whole new level of complexity that is often a surprise.

This is a tough growth point. You’re going to be pulled in many directions, and figuring out how exactly to spend your time to maximize your leverage across your teams will be critical. In order to do this well, you’ll need to practice honing your instincts, and this practice will require you to follow through on things that you’re not sure are actually important, but you just sense are off.