Introduction

Maybe you are an Engineering Manager who recently did the transition to the management track or you are an Engineering Manager wishing to come back to coding again. Then this article might be interesting to you.
As an Engineering Manager, your priorities shift a bit and that was rough for me in the first weeks. With barely any time to code, seemingly endless meetings, and our corporate re-organization I was seeking to find a way to come back to code contribution. Luckily, I can say I found a way to balance my day between being a manager for my team and still writing some code. This practice is what I want to share with you in this blog post.

The Switch

Let's start at the beginning. You get the message from your manager, hop into the call, and just a few weeks later you are the leader of a team full of Engineers. In my case, I was lucky to switch from individual contributor to manager within the same team. So I could skip the step of getting to know everyone on the team.

The first few days, I had the feeling, I got it. I've heard of all the rumors around "You not gonna find time to contribute anymore", "You will be stuck in meetings", and "Your calendar will fill up quickly". For the moment, I could keep on working as an engineer as before but with just a few meetings more. Fast I got proven wrong. More and more regular meetings, coordination, and syncs sneaked up on me and I found myself in the "meeting hell".

And now? Well, my instinct as an engineer kicked in and I was looking for solutions to my problem. Internally, we keep track of great learning resources that help you onboard to the new role. I stumbled over the book from Oren Ellenbog - Leading Snowflakes. Especially in the first chapter, he explains a great technique for implementing a Maker's and a Manager's schedule.

Implement a schedule

Implementing such a schedule means blocking time in your calendar to do focus work. Work that I normally did as a Software Engineer. Dig deep into the code to find the bugs. Well, if you tried to fix a bug within 30 minutes of looking into the code, you will know that doesn't work.

To contribute effectively, I have the feeling it's best to have at least a minimum of two uninterrupted hours. The longer this dedicated focus period, the more substantial your contribution will be. But be aware you cannot block a whole day for coding. Your team needs your input at some point in the day. So don't go above 50% of your daily working hours.

In our engineering organization, we have the goal to contribute individually at least 30% of our working hours as Engineering Manager. This requirement translates to twelve hours a week for a full-time position. I reduced the hours to eight - 20% of my working time - to establish this habit first.

Usually, you can identify empty spots in your calendar that may need one meeting to move to a different time to make room for the Maker's blocker. As you will see below in my calendar, I allocate my Maker's time towards the end of my day so that I can even extend my effort working on code if I am close to finishing up a feature. This practice is also a tip I can recommend to you, try not to schedule other meetings right after your Maker's time, because otherwise you keep looking at the clock when you want to focus on the problem you want to solve in the code.

On top of implementing two different schedules, I also added a blocker to plan my day. Ideally, this is done at the start of your day. For me, it is 9 AM every morning until we start our daily at 9:30 AM. At this time I set up myself ready for the day. Going through my to-do list, prioritize tasks, go through the meetings I will have today, and recap the last day (filling out my decision log - Chapter 2). While it may appear nonessential at first glance, in reality, it's probably the most important time of the day.

Now, that you have an idea of the free time blocks, we can move along and translate these into our calendars. A suggestion is to use color coding for the different types of blockers. I chose to go for my favorite color yellow to distinguish them from the default meetings in blue and my beloved lunch blockers in red.

Here is an example week of my calendar:

Execute it in reality

A typical day starts with the preparation for the day. I take a look at my calendar to see if I have a meeting marathon this day or if it is quite empty. An empty calendar is an indicator that I might find some time working things off my to-do list. This to-do list consists of tasks that pile up over time with or without due dates. These tasks are meant to be done during your Manager's time. That means these tasks can suffer interruption and disturbance. Accordingly, I schedule tasks for the day and keep in mind prioritization.
In case, I see a Maker's blocker in my calendar I take a look at our team's prepared backlog. I try to find tickets I can finish up in one single time slot. Small bugs or features usually work best. But it could be also something not code-related. For example what I am doing right now, writing a blog post where I zone out from my surroundings and try to get into a flow.
These are suggestions I try to stick to. Of course, there are days when I invest a portion of my Maker's time to finish up to-dos of my to-do list. And vice versa, there is nothing wrong with using free time slots to do some coding.

Preparation

Let's pick an example day: Wednesday (third column from the picture above):

• I see that I have a little sync meeting in the morning but mostly I have free time. That means I can do a couple of little things or even a big one from my to-do list.
• In the afternoon, I see a Maker's block which means looking in the backlog and picking one of the bugs or small features. I would rather go for more complex bugs in this slot since I have the rest of the day to work on it.
• I also see that there is a meeting happening during my Maker's time. Check on the importance of your person being there and you have two options:
  • Decline the meeting
  • Move your Maker's time to a different time slot in the week.

DO NOT DELETE YOUR MAKERS TIME!
In this example, I was able to decline the meeting, because I didn't need to be there. Additionally, if needed, I could catch up by watching the recording of the meeting later.

Execution

OK, let's check what happened in reality:

Right after the daily, the company seems to be waking up and the first messages come in. Mostly, I will get some tasks from the stand-up meeting that I can put on my to-do list. In case the tasks are quick wins, I like doing them immediately. Quick wins for me are tasks that I can do within 15 minutes. Therefore, I tend to not document those tasks on my to-do list. By the time you put a task on the list, it could already be completed.

In the morning, I have a block with no meetings, therefore I start working on the first things I put on my to-do list for today. I don't need focus time for that since it is about syncing with another Engineering Manager in my organization. Ping-ponging messages back and forth doesn't require any focus time.

Suddenly, an Engineer from my team asks for an opinion on a technical solution so I jump on a call with him. Since it is Manager's schedule there is not a real interruption for me on the ongoing task. After the call with my Engineer, I finalized the sync with the Engineering Manager in our documentation tool and can call it a done task.

Next up is the scheduled meeting. I had nearly 10 minutes until it started. Normally, I pick up the next coffee (important keep to the machine running ☕️), talk to some colleagues in the office, or check on some messages in Slack. These time fillers are usually what I do when I have just a few spare minutes before the next meeting.
The meeting proceeded as scheduled. By the time it ended, it was almost lunchtime. Therefore, I selected the next task from my to-do list. Despite the lunch interruption, I managed to complete the task afterward.

The more intriguing part comes in the afternoon, just before the Maker's time starts. In my scenario, there were no meetings immediately preceding the time slot. However, if you do have a meeting, it's essential to treat your Maker's time as though it were an essential meeting with your manager. Aim to conclude the meeting promptly, allowing your Maker's time to start without delay. Failure to do so may lead to your Maker's time being de-prioritized, and in the long run, being disregarded

With the prepared story at hand, I can now roll up my sleeves (depending on the time of the year, I actually roll up my sleeves 🤓). A tip inside Leading Snowflakes is to visualize your focus time with your peers. Tell your teammates what this time is about and how they can reach you. Maybe a specific status in the messenger or even a red light at your desk.

If there are still some colleagues ignoring it and trying to schedule meetings in these blockers you can also put the blockers on private and hide the name of the appointment from them. Out of my experience, I had no problems postponing discussions or inquiries so far.

The rest is "business as usual" for an engineer: Working on the ticket, wrapping it up toward the end of the Maker's time, and getting it ready for review. In case you are not able to finish up the ticket you can work on it in the next Maker's time or spare some time in between meetings.
For me, the best way is to code in Maker's time until they reach the state to be ready for review. Once I receive review feedback from my teammates I can also incorporate it during my Manager's time. Of course, this practice cannot be applied to every feature since some topics need some deeper focus.

Conclusion

Adding the practice of Maker's and Manager's schedules to your daily routine helps balance your management efforts with the need to contribute to your team's code base regularly. I found that this method supports you with light guardrails throughout your day. Especially, when you do a recent transition from being an individual contributor to a management role, it can be challenging with all the demanding tasks coming towards you. Setting specific schedules helps me fulfill my role as a manager for my team, as well as being on top of the recent technical topics in our team since I am contributing to the code base.
In the end, every circumstance needs different approaches. This method works for me and can be used as a blueprint to get started with your own Maker's and Manager's schedule. I hope you enjoyed reading this article and I can only recommend taking a look at the other great posts on this blog.

Thank you for reading, have a great day! 🍻👋
Tom

Resources

• Oren Ellenbog - Leading Snowflakes

Published by...

Tom Gehder

Visit author page