I was buried deep in some side thread in an on-line forum, and someone asked me what a typical day was like for me. Nowadays, I'm a leadership role, with team-mates who report to me, so my day. or week, or year is a lot different than what it used to be when I programed every day.

Defining a typical day is pretty hard, since the day is very variable, but I thought I'd give it a shot. But, to get a full scope of my job, I can't stop at just a day. I'll start by looking at a typical day, but then I'm going to look at a typical sprint, and then a typical year.

What is a Typical Day?

I'm not sure I would call any day typical; unfortunately, but let's give it a shot.

8am – 10am

I get into my home office somewhere between 8am and 9am. I'll sign in and start going through my Slack notifications. A lot of messages to me or my team can build up and I try to spend an hour or two in the morning clearing out my queue. For non-urgent requests from the past, I may have used the slack reminder feature to remind me tomorrow (or next week), to come back to this thing I don't want to forget. These reminders show up in the morning, and I try to catch them and respond. These may be questions about our systems, or how they work. They are usually non-priority issues. It might be a casual conversation with someone else I didn't want to forget about.

Note that email is not the primary means of communication in my current environment. Eventually I'll get around to checking email, but it is usually company related newsletters or meeting invites and is relatively easily cleaned.

10am -11am

My meetings do not usually start before 10am, and some days are busier than others. My team does not have daily standups, but rather we do two in person standups per week, and Geekbot on the other days. Usually morning meetings are 1:1 discussion with someone. More details on those meetings when I talk about my sprint.

11am-12 noon

Around 11:00 we do a team deploy to prod. Production deploys are not automated, I believe due to some type of compliance. The company institutes a stakeholder review step, and in most cases I am the stakeholder. I have to review all the tickets completed by the team and approve them to be pushed to production. Thankfully our Dev and QA deploys are entirely automated.

12 noon to 1

Between 12 and 1 I have lunch. Most days. Some days my lunch stop is 3 minutes, other times I can relax for the full hour. Often this time slot overlaps with lunch and learn, town halls, or other educational team meetings.

1pm to 4pm

After lunch, the meetings will start up again. Some meetings are planned and recurring, and I'll talk more about that in the sprint section. A lot of ad hoc meetings rise to fill the time. It might be a sidebar with product owners to clarify requirements. It might be with a subset of my engineering team to talk about some issue. It might be an introductory meeting with another engineering team to discuss a new initiative we'll work on together. It might be a team review meeting to discuss the latest spike and RFC that will define what the team will build for the next few weeks or months.


My wife is a school teacher, so if the stars align I'll break for dinner when she gets home from work. This usually happens 2-3 times a week.


Sometimes after dinner, I'll be done for the day. Other times I'll check back-in to work.


In my time around meetings, some of it is research or education. Here are some of the things that may occur:

  • Team members often ask me questions to come out of 1:1s, for example I spent a few hours researching the expense policy for external classes, corporate travel, or recent return to office guidelines.
  • I'll also read and comment on new product briefs from our product team
  • Sometimes I'm reading and commenting on research spike from other teams we work with, if that work is relevant to my team.
  • Sometimes I'm reviewing management documents, such as guidelines on new procedures or other communications from upper management, and I have to figure out what is relevant to my team, and a way to communicate that.
  • When the team was hiring, I'd be spending time at least once a week to review resumes and give feedback to our recruiter.
  • Some of my time goes to planning team building activities. Team lunches, or other team building experiences such as escape rooms. Sometimes I'm working with a designer planning branded gifts for my team.
  • The company has sporadic training opportunities, including required courses and optional courses. I try to find time for stuff, especially if it is relevant to my job. Making myself better on my company's dime is a win-win.


I write a lot more than I expected in my current job. Here are a few things that may require documentation:

  • I might write an intake document to bring a new product brief to our team. This summarizes the information from our product owner, along with other tech details from other teams about how this initiative comes together. It will feed into the team's engineering research spike.
  • I may be crafting a new team procedure, such as documenting on call responsibilities, updating onboarding docs, creating Service Level Objectives (SLOs) and Indicators (SLIs), or creating key results related to objectives (OKRs).
  • I might be writing up my own product brief for a tech driven initiative. This allows me to sell it to my manager, and our product owners as a priority the team should take on.

To Summarize: My day is meetings, researching, and writing. I miss coding, which is primarily done in my spare time as part of this blog or writing.

What is a Typical Sprint?

It is a lot easier to tell you what my typical sprint will look like than a typical day. A sprint is a two-week development cycle, with a defined scope of work for the team and clear goals. Our sprints are done on a two-week cadence, so 10 working days.

Day 1

  • I start with a pre-planning meeting with my team's project manager and my manager. This is to take a look at the goals for the sprint, and choose the related tickets.
  • The full team also does retro from the last sprint. What went well, what didn't, and what can we do better? If you're a programmer you're probably used to this type of meeting.
  • Then we do sprint planning with the full team, where we communicate out the sprint goals for the team, talk about velocity, carry over, available points for each person, and choose tickets.
  • Day 1 coincides with our on-call person rotation, so we do on-call transition meeting to talk about issues from the last week, and double check on the schedule for the upcoming week. Sometimes work may come out of this meeting, such as documenting things for our runbook.

Day 2

This is a no meeting day across my org, so I catch up on a lot of the research and writing I mentioned above.

Day 3

  • This is one of the days we do in person standup. An agile ceremony where the team shares their status.
  • We also have a backlog refinement meeting, where the team will discuss and point tickets.
  • We also perform a sync with our product owners to talk about the ongoing work and long term roadmap. The team is invited, but optional on this one.

Day 4

This day contains a leadership meeting, which is just a status all ongoing work in our department.

Day 5

This day is a different leadership meeting that is a check-in on the org. Leadership is asking the people managers and project manager's about quality of life, any issues that need to be raised, or any other ongoing problems.

Day 6

  • My team, once again, does in person standup on day six.
  • We also have a sync with our designer, to talk about ongoing work, or more likely to jump in on future work.
  • There is another on call transition meeting, where we once again talk about issues of the last week and check the schedule for the previous week.
  • I also have a leadership meeting, focused on upcoming work to our division, and the various teams involved.

Day 7

This is the other no meeting day across our org, so once again I try to catch up on a lot of research and writing that I mentioned above.

Day 8

This is a repeat of Day 3, with in person standup, a sync with our product owners, and ticket backlog refinement.

Day 9

This is a leadership meeting all about my team, similar to the one on day 5, but instead of just the org it is focused on my team only.

Day 10

This is a repeat of day 5.

Then we go back to day 1, and repeat.

On days, where the team does not meet in person we use Geekbot for standup, and I do read through all the updates. I like this form of async status updates, because it allows the devs (and me) to get focus time.

One to One Meetings

Now you know that my two-week cadence contains a lot of meetings, but as you probably guessed this isn't 8 hours of a day of meetings. Thankfully! On any given day I'll have at least a single 1:1 with someone, let's talk about them.
  • My Dev Team: I might have a 1:1 with a team member who reports to me. I try to keep these focused on professional development and less about the current work status. There are plenty of avenues to find out about the work status, including JIRA boards, application deployments, standups (or GeekBot statuses), or any given ad hoc meeting if a problem does persist.
  • I also have 1:1 meetings with my project manager to discuss team stuff. We may be checking in the roadmap, or making a plan for our next product checkin, or chatting about how to organize the wiki, or about policies we may need to institute with the team.
  • There is also a 1:1 with my boss. More often than not this is a status meeting about ongoing team work, while also touching on company topics such as return to office, vacation, or other corporate policies. We may brainstorm on various issues going on with the team.
  • There is another 1:1 meeting with my product owner, to help plan for future projects, or clarify requirements around upcoming stuff. We do a lot of chatting async as needed, but it is nice to do so zoom to zoom when needed.
  • Although, less frequent I'll have a 1:1 with my manager's manager, which is often about team status. These are called skip level meetings.
  • Sometimes, I'll get together with our designer, which is often about ongoing projects. This is less consistent, but does happen.
  • I'm also active in the company's mentoring program. At any given time I have a mentee or two, along with a mentor of my own. Depending on the person, and how long our relationship has been, I meet with them anywhere from every 2 weeks to every other month. I appreciate these relationships with people who expose me to completely different jobs, or other aspects of the company.

Many to Many Meetings

I already spoke about recurring team meetings in my typical sprint, and dove deep into the type of 1:1s I have. But, there are some other meetings, that didn't quite fit into either of those categories.

  • The first is a manager status meeting with all of my manager's direct reports. This is primarily communication about company high level procedures, or a place to have open discussions about team feedback.
  • If I'm involved in any DE&I working groups or other extra-curricular activities, there will usually be a meeting around that.

The free time I collected around all these meetings is all about the research and writing I mentioned above.

Typical Year

I've been a manager for about a year and a half, and I'm starting to see some patterns. There are a bunch of meetings, or initiatives, that are routine, but not sprint focused.

On a monthly basis, we have team demos, both for other teams in our department, senior leadership, and the wider company. It is a great way to share what we're doing. I'm not usually the one giving these, but rather coordinating with the team so one of them can give the presentation.

On a quarterly basis, we'll perform ICE reviews of our roadmap with our product owners. ICE stands for Impact, Confidence, and Ease, and is a way of evaluating all the planned or upcoming projects to determine business priority.

Different Town Halls meetings happen routinely. This is where everyone gets together to listen to leadership talk about initiatives, outline a plan, and commend teams or developers who have been doing awesome. These can happen within my department, or within my org, or at any given leadership level of the company. There is usually at least one a month. For some of them, I may be presenting about my team, or submitting developers for spotlight callouts. This is part of my ad-hoc writing time around the other meetings.

Sometimes we do midyear reviews, and we always do end of year reviews. As part of this, I write up a manager review of every team member that reports to me. I may collect 360 feedback from other people they've worked with--on their team and external to the team. I combine all this info into a doc, that is hopefully informative, and actionable. Highlight their strengths and point out areas for improvement. These are hard to write, and it takes me up to two weeks per person around all my other work.

Out of year end reviews, will come a professional development plan. How can we make the team members better this year? What are they interested in learning about, or improving? These are primarily driven by the employee, but there do provide things to check up on throughout the year.

I may have to prepare promotion docs for my team members to present to my leadership. This includes collecting feedback from others in the org, writing information about how they excelled and making a case for how they were working at the next level. Once again, this is usually a couple of weeks to put this all together, summarizing each expectation at the next level and proving my teammate meets the criteria for the next level.

Near the end of the year there is something called a team calibration meeting. I evaluate each employee against the current expectations at their job role. I believe they use an approach called 4 box, so each employee, so on each expectation they get a 1-4. One means needs improvement; two means expectations; three means excelling; and four means doing freakin' amazing. The expectation is most people will land between 2 and 3 I hate to call this procedure stack ranking, because we are only evaluating employees against the expectations of their role. But, at the end each one has a number, which in essence could be used to compare them against each other.

With the rise of distributed workforces and so much work from home, I'll routinely have "virtual water cooler" group meetings with others in the org. This is the time to hang out, chat about the weekend, latest shows, sports, and sometimes play games.

Final Thoughts

I still like being me, so in my spare time above all of this, I still keep myself busy with non-recurring extracurricular activities. It might be contributing to the company blog or preparing an internal presentation.

I have been leading a team for about a year and a half, and sometimes I feel like I'm still figuring this out. I miss being knee deep in code and architecture every day, however, leading a team managerially has been a rewarding experience and it is nice to see the other side of the curtain.