During the eight years I spent as an engineering manager, I regularly tracked how I spent my time. As a startup engineering manager, I was responsible for a wide range of duties, so keeping track of which areas I spent the most time on helped me plan and schedule appropriately.
For example, I knew that I typically spent about 1/3rd of my time helping my team solve technical problems or pairing with teammates. Knowing this, I reserved some free blocks of time for them. If my whole week were full of meetings and big-picture planning, I'd become a blocker for my team who needed my input on specific issues.
Since many prospective software engineering managers ask me about my job and what it entails, I decided to create this detailed look at how I spent my time. While every company and role is different, I hope this post gives you some first-hand insight into a day in the life of an engineering manager.
Note: If you're looking for some books to help you on your journey as a software engineering manager, here are some of my favorites.
First, a little bit about my roles as an engineering manager: my first management role was at Packback, a question and answer platform for college professors.
I joined the team when there were just four people in the company - it was essentially myself and the founders. In the intervening three years, I saw the company raise close to $5 million and grow to almost 30 people. My engineering team was pretty lean - there were five when I left in 2016 - but my role changed quite a bit over my years with the company.
After I left Packback to join The Graide Network, I started over as an engineering manager. Initially, my team was just a contractor and me, but over my four years at Graide, I hired three other engineers and took on more of the product management duties.
While my day-to-day work changed a lot over the years, as a software engineering manager, I was ultimately responsible for helping my team ship software that worked as expected on schedule and within budget.
The tricky word there is "helping." What does that mean exactly? Does it mean that an engineering manager writes code? Or do they just make sure everyone on their team is writing code?
The short answer is: it depends.
Generally, engineering managers write less code than the senior developers on their team, but they should write code some to keep their skills sharp. They also need to be good at helping their team members get "unstuck." Sometimes this means answering technical questions, and sometimes it means solving disputes between team members.
They're likely to play a role in training new engineers as well as evaluating candidates on a technical and interpersonal basis.
Being "good with people" is a tough label to nail down.
Many people assume that you have to be an extrovert to be an effective manager, but that's not necessarily true. Having empathy for your team and helping them through challenges - both technical and personal - is one of an engineering manager's primary mandates.
But, engineering managers have to "manage up" as well. This means they need to look out for their team's best interests when their boss asks them for feedback, and it means they might have to let a team member go if they're not getting the job done.
As I moved into my first management role, the most challenging part was adjusting my method for self-evaluation. Nickolas Means says it well in his fantastic piece on meta productivity for managers:
"Every so often, I have a day where I look up after the last meeting has ended and feel like I’ve gotten absolutely nothing done. I’ve been busy all day long: having conversations, reading documents, and checking in with peers and team members. I’m exhausted, but I’ve accomplished nothing." - Nickolas Means
It was relatively easy for me to tell how productive I had been as a software engineer. I usually made progress on shipping a feature or opened up a pull request, but as a manager, I had a really hard time telling whether my day was productive or not.
That's why I started tracking my time. While time spent on a task is not a perfect measurement of productivity, it helped me make sure I was investing enough time into each area of my job.
Engineering managers tend to have a wide range of responsibilities, and these responsibilities vary based on the employer's size and organizational structure. To help you see how an engineering manager spends their time, I broke my time down into four categories:
- Technical (35%)
- Managerial (35%)
- Recruiting (15%)
- Administrative (15%)
In this section, you'll see how I spent my time as an engineering manager. I'll offer a little bit about the specific tasks encompassed in each area and why it was an important part of my daily work.
While I tracked my time pretty rigidly for periods of my 8-year management career, I decided to round each category to a nice round number for the sake of simplicity. Exact hours spent on each task aren't the point here, but I found it helpful to know if one area spiked in one week or dropped sharply in another.
35% of my time.
Technical work includes writing code, code reviews, hunting down bugs, pairing with teammates, and reading software updates and best practices. As my teams grew, the amount of time I devoted to writing and reviewing code dwindled, but I do think it's important for engineering managers to spend at least some of their time elbows deep in the code.
35% of my time.
This includes direct people management, creating timelines, strategic planning, and meetings with technical and non-technical team members. Making sure my team was happy, advocating for them in business meetings, and helping our product team create technical specs were all part of my engineering manager duties at Packback.
At The Graide Network, I took a more strategic role by consulting with the founders on software choices and jumping in on important sales calls. Interestingly, while the tasks I took on were different, the time breakdown was pretty similar.
15% of my time.
Recruiting time included going to conferences, meetups, and coding bootcamps, writing blog posts, meeting with job candidates, and evaluating technical screenings.
While I spent more of my time on recruiting when I had an open engineering job, smart engineering managers are always hiring. The best candidates are usually the passive ones who rarely look for a job, so I spent a portion of my time getting in front of them each week.
15% of my time.
Finally, I spent a few hours per week reading and writing emails, answering questions in Slack, random conversations, and "other" day-to-day things to support my team. As the manager, I tried to keep these kinds of distractions away from my engineering team, but I'd schedule time with team members when necessary.
If an engineering manager's job is to make their team as productive as possible, it stands to reason that most of the administrative work will fall to them.
I don't think I can give you everything you need to know about being a good engineering manager in just one blog post (here are some good books on the topic though), so I'll just pick the three things that I focus on first.
Being a good manager is all about helping others achieve great things.
This means that as a manager, your impact is much less direct, and therefore, you can't spend all your time heads down in the code. It was frustrating for me to see my weekly accomplishments list shrink, but once I learned to accept that my team was getting more done without my individual contributions, I started to really enjoy the role.
Whether your team is working in one room or working remotely across the world, communication is one of your most crucial roles as a manager. In marketing, there's an idea that people must hear your message seven times before they internalize it, and I think this applies to team communication as well.
I'm not saying you should repeat everything seven times in the same meeting, but think about reiterating significant changes in one-on-ones, group settings, via email, and in passing. Change is scary, but the more people hear about something, the less scary it tends to be.
Finally, as the engineering manager, your role is to "vacuum up chaos:"
"Any room that you enter should have more certainty and a firmer plan by the time that you leave it. Good leaders can walk into a situation where people have lost track of their goals and get everyone aligned on a clear path forward."
Don't create or perpetuate drama, divide your team from the rest of the company, or pit team members against each other. Instead, be the one who absorbs uncertainty and stress so your team can get sh** done.
If you're an aspiring engineering manager or you're just wondering what your boss does all day, I hope this helps you. If you've got ideas about becoming a better engineering manager, find me on Twitter. I look forward to hearing what you think.