If you are considering management or just started, you are probably wondering: what does this job actually look like on a Tuesday? The answer is a mix of one-on-ones, stakeholder conversations, Slack fires, and the odd thirty-minute window where you try to do everything else. Here is an honest hour-by-hour walkthrough of what a typical EM day looks like - and why it is more satisfying than it sounds.
Morning: Triage and Preparation
Most EMs start the day by scanning Slack, email, and their project board. You are looking for anything that went sideways overnight: a production incident, a blocked deploy, an escalation from a stakeholder. This takes maybe thirty minutes, sometimes less. On a quiet morning, you catch up on threads you skimmed the day before. On a bad morning, triage eats your entire first hour.
Next you look at your calendar. A normal day has six to eight meetings with gaps of thirty to sixty minutes in between. You figure out which meetings actually need you, which ones you can skip, and whether there is a hard conversation coming up that you want to think about beforehand. Some EMs keep a running note of things to bring up in specific meetings so they don't forget when the time comes.
If there is a standup, you mostly listen. You are not there to report your own status. You are listening for blockers you can help remove, or for signs that somebody is stuck but not saying so. A standup where the manager talks the most is usually a standup that is not working.
One-on-Ones and People Work
If you have seven direct reports, you will probably have three or four one-on-ones scattered through the day, each around thirty minutes. The topics range wildly. One person wants to talk about a promotion timeline. Another is frustrated with a colleague. A third just wants to walk through a technical problem out loud. You switch modes constantly.
Good one-on-ones feel like real conversations. The person across from you drives the agenda and you ask questions, push back a little when needed, and occasionally share something you have noticed about their work. The worst thing you can do is turn it into a status report. They already posted their status in Jira. This is supposed to be the meeting where you actually talk about things that matter.
What happens between one-on-ones matters too. You promised to send someone a link to that blog post about system design interviews. You said you would introduce someone to a staff engineer on another team. You made a note to follow up on a piece of feedback next week. If you drop these, people stop trusting the one-on-one as a useful conversation. If you follow through, they start bringing you the real problems instead of the polished ones.
Stakeholder and Cross-Functional Meetings
The afternoon usually fills up with meetings outside your team. A sync with your PM about what is coming next sprint. A planning call with another EM whose team depends on yours. A progress review with your director where you give the honest version of where things stand.
In most of these, you are doing translation work. Your PM says 'we need this feature by Q2' and you convert that into engineering reality: scope, dependencies, who has capacity. Your engineers say 'this API is going to be a nightmare to maintain' and you convert that into something a product person can act on. You spend a lot of time restating the same information in different vocabularies for different audiences.
The relationships you build outside meetings matter more than the meetings themselves. A ten-second Slack message to your PM about a risk you spotted can prevent a week of misalignment. Grabbing five minutes with a peer EM to sort out a dependency saves a formal escalation. Most of the useful coordination happens informally, and that only works if people trust you enough to be direct.
The Work Between Meetings
Those thirty-minute gaps between meetings are where you try to do everything else. Performance review drafts. Hiring plans. A project proposal that is due Friday. A status update nobody will read but everyone expects. You open a doc, write two sentences, get a Slack ping, lose your train of thought, and start over.
A lot of EMs end up doing their real thinking outside work hours. Early mornings before Slack gets noisy, or evenings after the kids are in bed. This is not a healthy default and it leads to burnout if you let it become permanent. Be deliberate about protecting at least one or two longer blocks during the week. Some managers block out a 'no meetings' morning; others negotiate with their PM to keep Fridays lighter.
You also squeeze in some technical work during these gaps. Reviewing a PR, reading an RFC, checking dashboards to see if latency spiked after yesterday's deploy. You are not writing production code. But you need to stay close enough to the technical work that your team's decisions make sense to you, and that your engineers feel you understand what they are dealing with.
End of Day: Winding Down
Some EMs spend ten minutes at the end of the day writing down what happened. What went well, what needs follow-up, what caught them off guard. It sounds small but it adds up. A week of notes turns into a clear picture of patterns you would otherwise miss.
Prepping for tomorrow helps too. A quick look at your calendar so you are not blindsided by a difficult meeting first thing. A reminder about that feedback you wanted to give. A list of the two or three things you actually want to get done between all the conversations.
The part nobody warns you about is the emotional residue. A one-on-one where someone tells you they are thinking about leaving. A meeting where a stakeholder questions your team's competence. These stick with you. Going for a walk, talking it through with another manager, or just acknowledging that the conversation was hard - all of that matters if you want to keep doing this job without burning out.
Key Takeaways
- Six to eight meetings a day is normal - that is the job, not a distraction from it
- One-on-ones only work if you follow through on what you say you will do
- Most of your independent work happens in fragmented thirty-minute windows, so plan accordingly
- Stay close enough to the technical work to understand your team's decisions, but do not pretend you are still an IC
- Take ten minutes at the end of the day to write down what happened - it compounds over weeks
Frequently Asked Questions
- How do engineering managers handle the number of meetings?
- A few things that help: decline meetings where you are just a spectator, send a team member in your place when it is a good growth opportunity for them, batch similar meetings on the same day to protect focus time on other days, and push for written agendas so meetings end on time. Some EMs keep one day a week meeting-free for deep work. You will not eliminate meetings - they are how management gets done - but you can make each one count.
- How much time should an engineering manager spend coding?
- Most EMs spend somewhere around five to fifteen per cent of their time on technical work, and almost none of that is writing production code. It is mostly code reviews, reading technical proposals, and joining architecture discussions. If you are coding more than twenty per cent of the time, something else is probably getting dropped. If you never touch the technical side at all, you will lose context fast. The right balance depends on your team's maturity and how many direct reports you have.
- Is the daily schedule different for remote engineering managers?
- The work is the same but the rhythm is different. Remote EMs can usually arrange better focus blocks since nobody is tapping them on the shoulder. On the other hand, you lose the hallway conversations and lunch chats that build relationships. You end up doing more of that work deliberately - scheduled coffee chats, more detailed written updates, and more frequent async check-ins to make up for what you lose without a shared office.
Master the Daily EM Playbook
Templates and frameworks for the activities that fill your day - one-on-ones, delivery check-ins, stakeholder updates, and career conversations.
Learn More