As a first-time manager, I wanted to be approachable to - well, basically everybody in general, but my direct reports in particular. I had the feeling that there was some management debt lingering around and most people were clearly under-managed and under-mentored, so the last thing I wanted to do is proceed as things had always been. With some coordinative tasks on my desk and considerable involvement in recruiting, I had not been coding for more than 50% of my time even before that. When I was promoted to a people management position, however, it became even less very quickly. Soon, I was fully in “management mode” and my only exposure to code was a code review here and there.

In Paul Graham’s terms, I switched from a maker’s schedule to a manager’s schedule, and it’s understandable why: As a manager, you typically face more interruptions, so that it is harder to free up several consecutive hours of quiet work and use them effectively. Because I wanted to be approachable, I took some pride in being open to interruption most of the time. After all, I wanted to be there for people. And as long as my tasks were rather superficial or short in duration - like reading small bits of code, reviewing candidate applications, scheduling meetings - this works, at least to some degree. However, writing good code does not fall into that category, so I wrote less and less.

Different mindset

For me, this change of schedule came with a change of mindset: Because I did not care very much about being interrupted and even expected those interruptions to happen, after a while, I implicitly assumed that others should feel the same. I caught myself thinking: “Ok, maybe it’s not ideal to just walk up to Paul and talk to him without asking him on Slack if he has time, but hey, does he know how many times I am interrupted every hour?” The subtle difference - which I had become somewhat unaware of by that time - is, of course: An interruption is usually much more expensive for a developer than for a manager. Generally, an interruption is very costly for anyone in maker mode.

As a manager of developers, becoming unaware of this difference is bad in at least two ways:

1. Once you think that disturbing developers out of their concentrated creator mode is ok, you will do it thoughtlessly and frequently, and thus cause a lot of time going to waste because the developer has to use this time for context switching.
2. Maybe not as visible, but even more of a shame is that you lose touch with what it’s like being a developer in an interruption-prone environment. If interruptions increase, developers will become more annoyed and frustrated. We, as managers, are supposed to care for them, make sure they are happy, and protect their productivity and focus. But if we forget what it is like being in maker mode, we will not understand them like we used to do, and we might not strive to improve things as passionately as we should.

The beauty of making something

Finally, if we allow ourselves to be a bit more self-centered: As a former software developer, abandoning all your maker time is simply a loss for yourself.

It’s a loss in quality of work life.

It’s a loss of enjoyment.

It’s a loss of mental exercise.

Whenever I get the chance to lose myself in code for more than an hour at a stretch, I start getting this beautiful feeling of being fully immersed in the problem at hand, which, after a while, I understand completely from every angle. At that point, all the next steps are so clear in my head that things seem to happen by themselves. Code gets rearranged. New functions are added. Old functions are slimmed down and have part of their functionality extracted to form yet another function. What started out blurry becomes crisp, and what started out clumsy becomes elegant. I run the code. I fix a small bug. I take the next small step towards the goal. I forget time. I forget the room around me and just feel hyper focused. Suddenly, three hours have passed and I don’t know how it happened, but my program works. I made it!

This feels brilliant, and sessions like this are the elixir of life to a software developer. They are his mental oxygen. I had this feeling even with something as simple as a small bookmarklet that extracted some data from a page, or with tiny diagraming scripts for a previous article. It does not take a full-fledged, giant codebase to produce that mental state (I might even say that joy comes easier from smaller codebases). We should not give these experiences up without thinking twice.

Responsibly reclaim some maker time

So how can we avoid giving them up? How can we continue being managers, but nevertheless enjoy some maker time here and there? Do we just get back to coding? One task every week? Possible, but depending on which task we pick, this can become dangerous.

Oren Ellenbogen (in Leading Snowflakes) justly warns us that we must not become a technical bottleneck for our team. If you tackle a task, it should not be mission critical, because you can never really know if you can actually finish it in the required time frame. If you pick a nice-to-have task without a hard deadline, you should be fine. Ideally, it could be something that does not only serve your personal enjoyment, but benefit the team productivity as a whole. Oren: “It can be experimenting with a new infrastructure, reducing Technical Debt or maybe creating a tool to cut down needless work.”

Of course, we still have to make sure that we actually manage to finish the task. If we wait until we have time, it might never happen, because there will always be this pile of applications to look through, or that report to write, or that meeting agenda to refine.

The solution is, unsurprisingly, to block dedicated maker time in our calendars in advance, so that we make a clearly visible commitment and stick to it. Pick a time of the day where you usually get few interruptions, and block a time slot of two (the bare minimum) to four hours. If you notice that you cannot get away from interruptions at your desk, then retreating to a meeting room and shutting the door might help.

Maker time variations

Besides writing code yourself, there are other ways of experiencing some maker time. Doing pair programming sessions with somebody on your team is a great way of staying somewhat involved in development, without having to fear breaking something, or getting lost in code regions that are new to you. I usually ask one of my reports for a 90 minute or two hour pairing session every week, and I think there are benefits on both sides:

• There is the obvious knowledge exchange that comes with every pair programming activity. As a long-term employee, I can sometimes provide some historical context that newcomers do not have. In return, they can show me how things are done now.
• Taking time to pair shows that you care about your people and want to experience first hand which day-to-day problems they face. If you have worked side by side, you will have a stronger relationship, and better mutual understanding.
• Working that closely with somebody, even if it is just once or twice a quarter, will enable you to give more meaningful feedback, and to have better discussions about the other’s working style.
• Putting yourself in a situation where your report is “superior” - in that he might know the code base and the problems at hand better than you - shows her that you are not just “the boss”, but that you are as fallible and imperfect as everyone else. Ask questions, have her explain, so that you can follow along until you can contribute yourself. In a way, you put yourself in a position of vulnerability, and, to quote the amazing Team Geek: “The more vulnerable you are, the stronger you appear.” Showing that you are vulnerable once in a while creates trust in your colleagues, and makes them more willing to share their thoughts and ideas with you.

Yet another way of treating yourself to some maker time does not have to do with writing code — but with writing natural language. Writing is great way to exercise your creativity, and takes even less time to get started than coding. Write blog posts or articles, either for your company, or your personal blog, or a technical news site, or some other medium. If you do not want to write publicly, that’s fine, too. Write down your thoughts on important and hard topics. Reflect on what you have written, take a break, and come back later. Try to refine and add to what you have written. Do this in regular intervals (at least once a week). This routine will help you come to clearer conclusions and gain better understanding of yourself and of what is happening around you. Plus, you might start to appreciate writing, and suddenly realize that you have just written a real article that’s ready to be published. (For a more thorough treatment of how writing can sharpen your thinking, have a look here.)

Conclusion

David Loftesness advises new engineering managers to say goodbye to coding, at least for a while. Similarly, Marcus Blankenship, taking the perspective of the company owner, tells us to put down the tools. That is probably fine until you have leveled up your management skills to the point where you are in some sort of comfort zone as a manager. At that point, however, I believe there is value in reclaiming some maker time for yourself, even if it is rather little.

I’ll be honest: I still interrupt people without previous notice. If I pass somebody’s desk, and their desk is far away from my desk, and I have been wanting to talk to this person for a while, and they are not wearing headphones — yes, then I will probably not return to my desk first and IM them to tell me when they have two minutes, but instead talk to them directly. However, experiencing some maker time of my own brought back my awareness both of its great value and of its fragility, so I do not disturb people out of it for no reason.