The problem: I’m a new manager and I’m overwhelmed

A few months ago, I was given the opportunity to run a new team in a growing area of my organization. The company thought I was ready for a bigger leadership role, and I agreed. I think I have a good track record that prepared me well for this: I’ve been a successful tech lead, had a couple of direct reports, and created some great software. I was excited to grab this chance to lead a large team and set the technical direction for part of the business, so I gladly took the job.

But lately, I’ve begun to realize that instead of having a few hours of meetings a week, more than half of my time is booked before the week begins. I have regular 1-1s, touchbases with peers across tech, and meetings with the product team for planning, interviews, and strategy sessions, and the list goes on. I was excited to write some code for the new systems my team is building, and I’ve tried to, but the only time I can find is in the mornings before everyone arrives, or at night after I’ve eaten dinner. I’m totally stressed out trying to balance all of this, and my team is starting to complain that I am canceling my meetings so I can have more time to code. So, my question is: how do I learn to balance my days so I have time for all these meetings and management tasks, but also time to write code?

The solution: Think of management as real work

Let me ask you a question, before I begin. Do you believe that management is real work? Do you believe it is work that is just as valuable as coding, architecture, and other hands-on technical tasks?

We start with that because if you do not think that management is real work, you will continue to treat it like an unfortunate burden to be dealt with so you can get to the fun stuff. Which, sadly, is the attitude that many managers in tech seem to take. I say that this is sad because it causes not only suffering on the part of the manager, but a lot of damage to the team as well. Your team needs you to be there as a manager for them, and it is almost impossible to show up fully for a role that you don’t think is valuable. Management is work, and it is important that you put your management priorities front and center.

Great managers know that their value comes from the ways in which they create functioning teams, focused on the right work. When you can do that job well, you will almost always create greater value to the organization than you would as an engineer; yes, even a 10X engineer. If you shortchange your role as manager by fighting for code to write and technical work to deliver, it’s likely that you will end up, at best, totally stressed out, and at worst, slowing down your team.

Sometimes we managers feel that we have to keep writing code because otherwise things won’t get done. However, if your team isn’t getting enough work done, your job is not to do the work yourself. Your job as a manager is to figure out how to help the team get more done. It is incredibly hard to make the overall team stronger and spend half your time focused on doing the work yourself, especially when half your time is actually overtime. Yes, immersing yourself in the technical details may give you some insights into the day-to-day challenges of your team, but you can also get many of those insights by training your team to notice them, and helping your team know what to tell you.

Going hands-off is hard, even if you do value the work of management, because you no longer have a simple, easily measurable thing to look at. Experienced engineers get frequent strings of wins as they write code, fix bugs, and see new features come to life. The feedback loop as a manager is much, much slower. There’s no red-green-refactor for guiding humans. It’s okay to mourn the loss of that endorphin hit. You spent years getting good at the job of being an engineer, and now you have to do something that you probably aren’t as good at yet. It will get better, but it will not be the same.

All of that being said, getting away from writing code every day is not the same as having no technical responsibilities or tasks. When I wrote the job description for the engineering director position at my previous company, I included this bit:

The engineering director is not generally expected to write code on a day-to-day basis. However, the engineering director is responsible for their organization’s overall technical competence, guiding and growing that competence in the whole team as necessary via training and hiring. They should have a strong technical background and spend some of their time researching new technologies and staying abreast of trends in the tech industry. They will be expected to help debug and triage critical systems, and should understand the systems they oversee well enough to perform code reviews and help research problems as needed. They should contribute to the architecture and design efforts primarily by serving as the technically savvy voice that asks business and product questions of the engineers on their teams, ensuring that the code we are writing matches the product and business needs and can scale appropriately as those needs grow.

From the above description, you can see that although you might not be writing code, there are a lot of ways to stay hands-on that don’t require the sustained focus of writing large amounts of code!

Practical advice: Be useful in your contributions and expertise

As you transition to full-time management and away from technical contributions, you can still be involved with your team where it makes sense. Consider pitching in by:

Participating in code reviews. They are a good way to stay in practice, at least as a secondary reviewer. If you created systems when you were more hands-on, stay engaged with those systems because you will remember the details better than most, and you can help engineers working in those systems with code reviews and questions.

Getting hands on with debugging and production support. These are valuable hands-on exercises. Be sure that this is something in your skill set! If you weren’t a strong debugger before you went into management, jumping into incidents may be more annoying than helpful. However, participating in these exercises will force you to contend with some of the details of the systems and their integration into the larger architecture. For many people, debugging and production support tasks help with the challenge of keeping in touch with the systems, and provide valuable insight into the causes of frequent problems and the location of technical debt.

Volunteering for pair programming, and/or fixing minor bugs or features. This works well for the former developer who really loved to create new things. So often we diminish these small efforts as not worthwhile, but they are very good for keeping a manager in tune with the feeling of software development and showing their teams that they are willing and able to help out with the day-to-day in a valuable way.

Creating dedicated unscheduled time. Give yourself at least a solid half day once a week where you keep your calendar completely free from meetings or other obligations, and try to use this time on some creative pursuit of your own. Recently converted managers often call this their “coding time,” but there are many technical creative pursuits that don’t involve coding that would also be a good use of your time. I get a lot of value using that time to write talks and blog posts, and learn about new technologies. Don’t assume that you have to code, or force yourself to code when you have other ideas you’d like to pursue; this is time for you to think, not yet another obligation.

Keeping up with your own technical fluency. OK. So you’re hands-off, and feeling OK about it. But we’ve all heard of the Pointy-haired Boss—the one who may have once been technical but now seems completely oblivious. How do you avoid ending up in that situation if you’re rarely or never writing code?

The answer is: don’t leave technical work before you’re ready to go.

There is a risk to going hands-off because you will lose certain sensitivities and skills. That risk is greatly amplified if you did not spend enough time coding to get yourself deeply, fluently comfortable with at least one programming language prior to moving into a management role. I am a big advocate for spending the time it takes to gain mastery of programming before moving into management. For me, this took about 10 years, including my undergraduate and graduate degrees. You may do it faster than I did, but scrutinize yourself carefully in this regard. Do you have a language where you feel comfortable enough that if you were dropped into a good code base using that language, you could productively contribute to that code base with limited time spent getting up to speed in the basics of writing the language, using a standard development environment, and working in standard frameworks and libraries? Eventually, even the deepest knowledge will atrophy, but fluency working in a language (which includes comfort with its standard tools, libraries, and runtimes) is something that sticks with you for a long time.

Useful fluency also requires an ingrained understanding of what it means to work productively in such a language, hopefully on a team with other people building production software. Without this sense of the rhythms of building software, you are going to struggle with debugging team issues and keeping the teams producing quality software smoothly, which is one of the critical parts of the management job.

Editor’s note: You can find other articles in this series on Camille Fournier’s author page.