What does the day-to-day of a software engineering manager look like?

As an engineer on the outside looking in, it often looks like a manager shows up to stand ups and 1–1s but otherwise is in a lot of meetings. Here’s what you sign up for as an engineering manager.

How I Describe Software Engineering Team Management

Professional Decision Maker

In my first month as an engineering manager, my manager and mentor asked me what we should do to solve a particular problem. I wrote up a one pager doc with options and pros and cons then shared it with my manager. She said “Okay, this is great, but what is your recommendation”

I said “the right thing to do would be…” and gave a list of reasons about what implementation would be better.

She stopped me. She said “Neither of these solutions is ‘right’. Both of these solutions would technically work. But why would we do one over the other?”

I did not understand.

Then she asked me “What about the timelines, the business? What needs to be done in 6 months?”

That question is when it clicked. I was still thinking like an engineer. While I had provided information and thought through implementation I had not made a decision in consideration of the larger team direction. While either would solve the problem, what delivered what the greater org actually needed? That is the kind of decision making I had to learn as an engineering manager.

Shit Storm Umbrella

There are times when something is happening that disturbs the team. Sometimes these are people related: Layoffs, key team members leaving. But more often, it is rapid and unexpected changes in priorities from leadership that change the team direction. Sometimes this looks like a re-org. Other times this looks like a directive “your team owns XYZ problem now. Solve it”

A shit storm umbrella manager tells the team the facts. They address and dispel relevant rumors. They build trust with their team. Critically, the manager keeps engineers focused. They clarify priorities by asking leadership “what is my team’s priority” and “what is expected of the team” then share this with the team.

The “API” for the team

You are the key interface for your team. When your team needs help, they come to you. When stakeholders need something from your team, they come to you. You represent your team. You set the culture and the expectations inside and outside the team.

I ensure the right people are doing the right thing at the right time.

I address this here

Engineering Manager Day to Day Breakdown

To answer “what does an engineering manager do day to day”, I made two key assumptions. First, let’s assume that the people manager works a standard 40-hour week. This is not always the case. One of my manager peers once said “If you figure out how to do this job in less than 50 hours a week, tell me the secret.” Second, let’s assume your software engineering team is 10 people. I am going with the 2-pizza team model of 8–10 people per team and 10 makes math easier.

Task Breakdown

Here’s the breakdown of tasks typically on my to do list. Fellow engineering managers, What would you add to this list?

People management

• 1–1s
• Prepping for performance reviews
• Adhoc questions, check-ins
• Skills training

Project management

• Prioritization
• Chasing down requirements
• Project planning
• Design reviews
• Stakeholder management
• Attending team rituals (retro, demo, standup etc)
• Generally unblocking the team

Overall Team Management

• Setting Vision
• Roadmapping
• Resource Management
• Stakeholder management
• Team Building
• Interviewing
• 1–1s with peers and managers

How does this work break down in hours?

In an average week, I spend 20 hours in physical meetings.

• 5 hours in 1–1’s with my team
• 2 hours in 1–1s with peers and manager.
• 3 hours in Team Rituals
• 10 hours in planning, alignment, and stakeholder management. That’s ~5 hours a week per project.

Very few of the tasks I listed happen successfully in a silo. Engineering managers must collaborate with their stakeholders such as product and (if applicable) UX partners in order to manage a team. collaboration requires communication. When used correctly, meetings are an effective communication tool.

What am I doing when I am not in meetings

These are rough estimates and vary week to week.

4 hours preparing for meetings

Productive meetings must be planned and prepared. Prior to a meeting, I will set an agenda. If someone else owns the agenda, I will clarify what that agenda is and then understand what is my part to contribute. Meeting prep time is spent clarifying requirements, auditing progress, reviewing designs, and developing my own opinions and questions on the problem and approach, writing these out in some shareable way.

Note: even if the meetings I am prepping for did not exist, I should and would still do this work. It is important to know what your team is doing and how.

2 hrs preparing for 1–1s

I take a similar philosophy here. 1–1s are best done with some preparation. I review what a person has done, write up talking points, prepare to address any talking points my engineers may have flagged in advance and review last week’s talking points. I follow up on any action items I had committed to in the last session.

1–1 prep takes much more time if that 1–1 is a performance review, goal setting exercise or gap analysis. I usually take up to 2 hours per person for an in depth session like that. I do a session like this with each member of the team around twice a year.

4 hours a week for overall team management

Not every event categorized as ‘team management’ is required week over week. But each week, some combination of them does occur. This time is usually spent. What I spend most time on most frequently are activities that help me answer the question ‘what is your team spending time on and are you spending it appropriately’. These questions usually come from stakeholders and the leadership team. What I do to prepare to answer these questions is write documents, read and contribute to other people’s documents and synthesize information. I identify problems that need to be escalated. This requires putting together communications to provide context and put together a specific ask.

Sometimes I run team retros or team building events which take time to prepare for. Sometimes 1–1’s, retros and team building reveal gaps in the team which I need to address. For example, I recently identified that the team had a skills gap in using writing as a problem solving tool. Sometimes, a skills gap is best addressed by other members of the team. In this case, I was the best person, so I prepared a “lunch and learn” session.

One of my favorite mantras as a manager is “Brace for Change”. When a moment of change happens in the organization, the team manager should evaluate the potential impact to the team. When events happen in the organization, I learn what and why the changes are happening then I prepare to address them. Some good examples, which all happened in the last year, include:

• Cultural changes such as all meetings and slack history being deleted
• Introduction of new collaboration tools
• Changes to compensation structure
• Changes to Performance management
• Changes to Talent Review
• Team leadership changes

5 hours a week to slack messages

This is about one hour a day. In person, this hour would probably go to ad hoc communications throughout the day. I answer questions, ask questions, check in on how people’s days are going, check in on threads and generally keep an eye out for issues that might require my attention.

That comes to 35 Total hours. The last 5 hours would be a lunch hour — or miscellaneous other issues. There is always more work to do.

There is always more work to do

The nature of the job is change. As a manager, you respond, make decisions and keep your team functioning. Each day something changes, which means each day there is something new to do.