Programming and Managing : Can you do both?

I have been getting quite a few emails recently asking me to post about certain topics. So today I start answering them.

Brendan Barber asks “I am a software development manager for a global recruitment firm. I was wondering if you have any blogs about how to juggle team leadership / management with programming tasks. I am finding it increasingly difficult to perform both the technical and the management aspects together. The nature of programming tends to require large blocks of focused time whereas management is sometimes the opposite especially when dealing with operational issues that have mostly have a lifespan of minutes. an it be done, should it be done, and if so how have you approached this?”

It is fair to say that trying to program and manage is not for everyone. In fact a large percentage of programmers are not suitable to management roles and most rightly see management as something which would require them to give up all morals and learn to speak a different language (e.g. say ‘pro active’ every other word). This is partly due to the fact that management (on the whole) positions get filled by people who understand social structures and a lot of programmers (especially some of the most talented ones) do not fall into this bracket.

But given that you are a programmer who now has management responsibilities how do you handle both?

As a starting point you firstly have to realize that as a programmer and as a manager you are never going to be as productive a programmer as you would be if you were dedicated to just programming. This seems obvious but I am not just talking about splitting your time. If you have a 50/50 split between programming and management that 50% does not equal 50% programming output. If you are just starting out trying to manage together you will be lucky to be getting 20% of your normal output.

What I hope in this article is to show you that it is possible to do both and to improve your efficiency of both and that the roles can be very complimentary.

Learn to refocus

Programming effectively is all about focus. If you are not ‘in the zone’ then your productivity tends to go through the floor because without focus it is easy for your mind to wander and get distracted by almost anything (email, RSS, YouTube, Dilbert, etc). For most programmers focus can take time to get back so each time you get distracted you lose time having to refocus.

For a programmer who also wants to manage the ability to refocus immediately and pickup were you last left off is absolutely fundamental. If you imagine a typical refocus time of 15 minutes and you get distracted by management issues 10 times in one day then you have immediately lost nearly 3 hours of work.

Improving your ability to refocus on your work is something that takes time and is not something easy to teach. But below I have listed a few tips on actions you can take to make it easier to manage.

Set out a strict daily timetable of when you try and program and when you perform your management tasks, by doing this you have a clear idea of what you should be doing at any point of the day and stops you switching tasks each time you get interrupted.
Use note taking software to keep track of your current thoughts. If you are thinking through a typical programming problem start writing them down. If you get distracted you can more easily understand what you were last doing.
If you are a typical programmer that spends the whole day with headphones on you have to change this habit fast. Although you can remove the headphones as required this means you are not learning to cope with distraction.
Make sure you have auto-save enabled in whatever development environment you have. If you have to bring up other ‘management’ tools at the same time you are likely to have your dev environment crash on you at some point. (Microsoft Project has been my main culprit in the past.)
If you have a meeting booked in an hour’s time try to fill that time with management tasks, programming is best done in longer blocks of time therefore always perform your management tasks during times of the day that you know your time is going to be split up most and programming tasks during those that will be split up least.
Become disconnected

Programmers tend to be extremely passionate about the work they do. In a dedicated programmer this is exactly what you want. As a manager you cannot view your own work in the same way. Managers need to make broader decisions than a typical programmer and this means taking in information from a range of sources and it is counterproductive to view your own work personally. Not only will it likely skew the decision but also be seen by your staff as favoritism to yourself.

In a similar vein it is often the case that programmer likes to think they are better than everyone else (you grow out of it as you get older) but as a manager you have to be objective about your own abilities and about those who work under you. Understanding your strengths as a programmer can help you focus on what tasks are best applied to yourself and to the rest of the team.

As a programmer/manager you must always take the following into account when assigning yourself tasks.
According to your schedule do any of your tasks put yourself in a position that you can delay other team members.
How difficult would it be for another team member to take over this task if you find you have less programming time because of other management responsibilities.
Are you creating any other dependencies that could be alleviated by not doing the work yourself
Are you taking the task because it’s the most interesting? (not a good idea)
It may seem that the list stops you from doing any work but in reality you cannot always remove yourself from the critical path and it may not always be the right thing to do. The aim as with any other part of management to create contingences for every situation so that when things go wrong (they will) that you have already thought through what the course of action should be.

The good news

The great news is that programmers can make some of the best managers. Here is my list of reasons why you would want to do both.

You have the ability to understand what your technical team members are telling you.
When scheduling tasks you can tell if your team members are telling you porky pies about how long something is going to take.
Building a schedule is still a nasty task but at least it may resemble reality (for at least a few days)
You can confuse other managers by talking technical (my personal favorite)
You tend to get respect from your team members rather than abuse.
I would like to hear from everyone on their experiences of either becoming a manager or your observations on the difference between technical and non-technical managers.

Management Programming