A snapshot of my day as an engineering manager at a start up
I manage a team of 4 people responsible for 5 different web products, both internal and B2B. Inspired by a question from Out of Office Hours, here’s what a typical day might look like for me.
9:30am — Specific product stand up
I have 2 stand ups each day. The first is for one of our products. We have representatives from big data, computer vision, and web teams, and it is led by our VP of Product.
In a stand up meeting, everyone gives an update on what they did yesterday, what they will do today, and if they have any blockers. Ideally a stand up meeting with be very short — 1–5 minutes, so we table any discussions that arise until after the meeting. These quick meetings keep everyone on the same page and informed about what people are working on, so the product manager doesn’t need to constantly ask for updates. It also shares knowledge; if I find out someone is working on something I know about or have a question about, I can ask. We also get a business update from our VP of Product, which I enjoy hearing because I like to know if we have any new clients or feedback. Development shouldn’t happen in a bubble.
I like having stand up meetings in the morning because it makes me think about what I want to accomplish for the day.
10:00am — Web products stand up
I have another stand up meeting with everyone on my team, plus the product manager that works with us on everything besides the product from the 9:30am meeting.
10:15am — 1:1 meeting
I try to schedule meetings for the people I manage in clusters to minimize the number of times they get interrupted throughout the day, so either right after stand up or towards the end of the day. I asked each person how often they want to meet, so every week I have 2 1:1s and every 2 weeks I have 4. I talk to everyone every day, but it’s important to also have an official scheduled time on the calendar that they know is just for them. Afterwards, I take a few minutes to take notes about what we talked about, and if there are any follow up actions to take. I might do some of the follow up things I need to do if they’re quick.
Not always, but sometimes I might have other meetings during the day varying from:
- Product specific meeting: Talk about a new and upcoming product, talk about a new feature on an existing product, give updates, brainstorm with our UI team about the design of something
- Showcase: Our larger team has a meeting every 2 weeks to share what each of the individual teams has been working on
Times between meetings — Work
I’m usually working on multiple things, so depending on the amount of time I have until the next meeting or lunch and priorities, I will do any of the following:
- Overall management tasks: Write an annual review for someone, think about and compose goals for the next review period, follow up on items from a 1:1 meeting, follow up to make sure someone has booked travel for a conference, if we are hiring, write a job description or review candidates…
- Overall team tasks: Examples of things I’ve done in this category: Suggest and finalize a set of eslint rules so linting on all projects is a consistent experience, set up and test new things with devops team, write documentation for our git flow and deployment processes, hold a live session of how to review a PR for someone new to the process and document best practices, create Jira tickets for things such as: upgrade to Yarn in all projects, test new version of npm on all projects…
- Product specific tasks: Check our analytics for user insights, ask internal users for their thoughts on a new UI or feature we’re building, message our Product Manager about questions or clarifications about a new product feature or task, talk to PM about user feedback or requests, break out larger features into smaller tasks…
- Clean up tickets or assign tickets on Jira: I loosely manage our work queue for our products (I compare quarterly goals to other smaller tickets that pop up that might need to be done quickly, and also ask people what they have an interest in — maybe there is a ticket that will allow them to develop a new skill, or this feature they find interesting, or maybe they need a break from working on a long ticket) and assign tickets to the people I manage, or ask them to work on something. I close duplicate tickets and fill out the description on some once I find out about more requirements.
- Review PRs: We only have people for 1 person to focus on each project (except 1 has 2 people), and we like to have at least 1–2 people review every pull request, so I am generally added to all of them. I try not to become a blocker in merging tickets, so I usually prioritize this. I also remind people to review things when I see the queue building and I want us to release something soon.
- Actually work on a ticket: I’m generally working on 1 or 2 tickets at a time, because I still want to keep learning myself. I tend to take tickets for things that are a priority (right now we’re trying to push out a new app and have 1 person dedicated to it, so I am taking a lot of tickets to help with it), or less of a priority but quicker to do (I usually get distracted with my other tasks so it would take me a lot longer to work on a big feature).
- And finally, most importantly as a manager, answer questions: The people I manage can have questions ranging from:
“I’m stuck on something, can I show you what I tried (and maybe you will have a suggestion of how to solve it?)”
(help with an error/bug or rubber ducking)
“I’m thinking about doing it this way, can I explain it to you how I’m thinking about doing it ?”
(code structure and implementation)
“I just added this thing. How do you think it looks? I was thinking about doing it this way or this other way.”
(design related or design second opinion)
“I’m working on this ticket and what does this part mean? Should I do this?”
“I finished this, what should I do next?”
“What/how should I do this?”
(if it is a newer person, how to do a task, where to start, generally point them in the right direction)
Before I started managing, my day looked similar, except focused just on the specific product and ticket I was working on. I generally did a lot of the same things: reviewing tickets, scoping out new features, talking with other teams such as product, UI, and big data to clarify requirements and ways to implement something, working with my team when I had a question, sharing knowledge about developing, reviewing PRs, doing research and googling error messages, and of course, actually coding.