We normally talk about the challenge of moving to a manager’s schedule in terms of our desire to write code. But writing code is just part of it. As an IC, you probably had some kind of schedule that worked well for you. When we move to being managers, it’s tempting to try and slot “management stuff” into that schedule.

This generally doesn’t work that well. It can work, if you have a small team, with no major problems, and a clear roadmap. Otherwise, it’s probably going to fall to bits.

Small Team

It seems obvious that a larger team is more work than a smaller team, although this is not always the case because of other variables like organization, and team challenges. But we can break the major team time commitments down into two pieces – managerial, and person.

Managerial Overhead

This is the “stuff” you need to do now you’re a manager. Manager meetings (what happens in these? You finally get to find out). Process stuff. This differs everywhere, but in general there is some stuff you now need to attend to that you never used to worry about as an IC. Usually this involves some amount of meetings, and some amount of non-meeting work. This is the stuff more like a “fixed cost” in economics – it doesn’t change that much with the size of your team.

Person Overhead

This is the per-person responsibilities. Obviously, 1:1s are a huge part of this. Performance Reviews (whenever they happen) will devour huge amounts of your time. Then there are things like vacation entitlements and expense reports.

People have a tendency to capture this by time in 1:1s, but it’s not just time in meetings – it’s also time preparing and following up.

This is more like a “variable” cost in economics. As you add one more person to your team, how much more time a week do you spend on them? Newer people, and more junior people will tend to need more of your time.

No Major Problems

As a manager, it’s your job to fix the problems on your team, and at least mitigate the problems created in the wider organization. Three examples: re-orgs, performance, and conflict.

Re-orgs

There are logistical problems caused by re-orgs – your team is different and now you have to get to know people again! Your mandate has changed and you need to make sure your work is aligned with it.

But there are also people problems caused by re-orgs. Even the best organized and well communicated re-org does not leave everyone happy. ICs may not have insight into what caused the need for the re-org – why that director left, or what challenges exactly the organization is re-aligning itself to face.

And we all know that many re-orgs are neither well organized nor well communicated. At The Conglomerate they used to re-org every year. Many people who I knew there (including myself) have something that is best described as “re-org trauma”.

Re-orgs make people panic. They deliberately create change – which creates uncertainty. Even if people don’t leave because of it (which they often do), trying to create some kind of semblance of order and stability on your team will take a while. And when people leave, you have to deal with that as well.

Performance

Performance problems take a huge amount of time to manage. Biggest is the time you spend figuring out expectations, setting clear expectations, communicating those expectations, and then evaluating the person against those expectations.

You’ll also have to consider this when you plan, when you communicate what the team is doing. And you’ll have to deal with the people who notice what’s happening, without actually admitting what is happening and why.

Unless you’re some kind of monster, you’ll probably spend a lot of time feeling terrible and uncertain, too.

Conflict

Well-managed conflict will make your team better. Conflict arises because people feel strongly about things and disagree. This is great! People feel strongly about things! They have different perspectives!

This is also exhausting.

You’ll need to spend time with each person, understand where they are coming from and why, ask them questions that challenge their thinking, and lay some groundwork for them to listen to each other. You probably also want to be present to moderate the discussion and make sure it’s productive.

Also, pro-tip: if you have conflict on an engineering team, one of the first places it will show up is in code reviews. Especially with quiet conflicts that went on without blowing up and haven’t been resolved, or aren’t fully resolved yet, you can expect to spend a lot of time on code review – making sure they are done promptly, respectfully, and thoroughly. You may also need to spend time educating people on what good code review looks like, and modelling that behavior yourself.

A Clear Roadmap

If your team has a clear mandate, and a thorough PM, you’ll have a nice roadmap that they ask you for feedback on when they need it. You’ll give that feedback, highlight things that seem like a lot of work for little gain, do some sprint planning, maybe run regular retrospectives depending on how Agile you are.

If you don’t have a clear roadmap, expect this to dominate your working (and waking) thoughts.

What are People Doing Now?

If you don’t have a clear roadmap, and that’s not because you randomly had a surprise re-org yesterday, there’s a good chance that what people are working on now is uncertain and undefined. Hopefully people are working on important things, but are they working on the most important things? Do they know what the important things are, or are they drifting?

Before you figure out where to go next, you’ll need to figure out where you are now. Starting with the big, multi-month multi-engineer projects.

What are People Doing Next?

Is there stuff already scheduled? Is there stuff already promised to users or other parts of the organization? Are there things, or parts of things owned by your team that are on fire?

What Could We be Doing as a Team?

This is the endless list in the backlog or the ideas that people generate. But most important is to filter it by asking the next question:

What Should We be Doing?

What are the big opportunities that could potentially drive growth? How do we measure the potential? How do we break it down and measure progress – what metrics do we measure against?

Where’s the Organization Going?

It’s always important to stay tuned into the wider organization and be aware of decisions and projects that might impact your team. But when the roadmap is less clear this is especially important and liable to take more time. If your team doesn’t have a sense of where you’re going, it’s unlikely anyone else does either, and so you’ll need to look out for implicit expectations, and decisions made without you.

Rebuilding Your Schedule

• Figure out your external commitments: what meetings do you need to attend?
• Schedule your internal commitments: team-meetings, and 1:1s.
  • Scheduling 1:1s all on the same day can be really helpful for noticing patterns, and avoiding context switching.
  • Make sure you pick a good day – e.g. if you always cut a build on Thursdays, Wednesdays and Thursdays are probably not good days for 1:1s. Friday would be better.
  • With 1:1s (well, with everything, but let’s start with 1:1s) the goal is to be effective rather than efficient. It can seem efficient to schedule all your 1:1s back to back, but it’s rarely effective. Either schedule more time than you need, or add breaks after each one. This gives you time to get more tea (or coffee!), write up your notes, deal with quick things.
• Figure out your priorities.
  • You might not be able to work on the “most important” thing immediately – either because you need to address:
    • Something more immediate.
    • Ground work for the most important thing.
    • Something that will build credibility to enable the most important thing.
  • I like to chose a “theme” for each week. At the end of the week, I measure myself by the progress on that theme.
• Figure out your tasks.
  • What needs to be done today? This week?
  • The kind of system that worked for me as an IC does not work for me as a manager.

This is part 1 of a series aimed at new engineering managers. For help and support, you can also ask for an invitation to the New-ish Eng Manager Slack.