Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For about eight months I managed a development team doing a re-write of a web based application. During this time, I was focused on many aspects of the project that did not involve directly writing code, even though by trade that's what I started out as.

Recently the number of developers assigned to the project has dropped and I am now forced to drop back into a developer/management role. Since that time I have found that it's very difficult to focus on a feature and get it completed while at the same time trying to stay ahead of the other developers and make sure that we're keeping on track.

My questions is this: can you successfully keep managing a project when you are forced back into development?

share|improve this question
What are the expectations of the person(s) 'forcing' you back into development and what have you done to manage them? – JeffO Dec 12 '11 at 17:14
short answer is "you can't" something has to give ... – Jarrod Roberson Dec 12 '11 at 20:49
If I was in this position I would not try to "stay ahead of the other developers" I would pick tasks I know I could complete. As Mike points out, even if you are able to "stay ahead" of the people working 40 hours directly on the code for awhile, at some point you will fall behind, and thats alright. So assign yourself to fixing bugs that you feel are "showstoppers" since that certainly is a priority, and said project cannot be finished, without resolving those issue. Replace this task with anything that is a priority at the time. – Ramhound Dec 13 '11 at 14:20
up vote 6 down vote accepted

You know the saying "can't see the forest for the trees". When you're managing, your job is to tend the forest. When you're writing code, your job is to grow a tree. I've found that when I take my hands off code, I'm a better manager. I'm able to interact with my team and keep the pulse of the project. The second I drop down to writing code, that high level view has to go away or I won't be an effective coder.

I don't know a way around this, you can't manage a team and write code at the same time. One or the other of those tasks will suffer as a result.

share|improve this answer

I had a very similar problem. A management job that wasn't 100%-consuming, but if I tried to do development work with the rest of my time then I became a bottleneck, owing largely to not being able to focus on a single development task for more than a couple of hours at a time.

My advice is to stop doing that and start spending that spare time clearing the road for the other developers. Look at anything which costs development time and ask what you can do about it. Have a read of Continuous Delivery and see what you can do to improve your build and release process. Have a look at your unit and integration test coverage.

Just avoid working on tasks that are part of the iteration unless you're sure you can complete them smoothly without becoming a bottleneck. As long as you can point to an improvement in the amount of work being done, no one's going to care about the details of how you spent your time.

share|improve this answer
I agree...once your code becomes time-boxed, it's difficult to "de-prioritize" it to focus on team. I like your idea of working on infrastructure to enable the team rather than a single task. – Michael Brown Dec 12 '11 at 17:22

In my experience no - I have failed to manage whilst developing well and equally failed to do much by way of substantial development whilst managing.

I've also witnessed (in a former life) my "boss" having the same problem...

Fundamentally this is a variation on the problem described in the excellent article Makers's Schedule, Manager's Schedule - when you're developing you want to do nothing else 'til you get stuck or you're done at which point you want to go your manager for help/direction. Similarly if you're the manager then you're the point of contact for external interruptions (and indeed you should be working hard to avoid anyone interrupting the devs and getting them out of their groove). What this amounts to is that if you're managing you're, at least potentially, in a state of constant interruption from above and below - and that does for your ability to code at any sustained level as you can never clear the decks. If you do go the other way then you fail to manage your team well (give them too much leeway and interesting things will happen, and it won't be what you want...)

In the end I was able to find a comfortable position where I could deal with bugs and small bits of niggly stuff, where I could deal with stuff at an architectural level, where I was happy to discuss implementation detail (to vary degrees depending on the programmer) and could direct my devs whilst, for the most part, not interrupting them. External interruptions came to me so the rest of the devs got to do stuff. I worried about the big picture, they got to do the big pieces of work.

A further thought - it does seem to me that agile style methodologies with substantially self-organising teams and similar concepts might go some considerable distance towards making it more possible by removing some of the necessary overhead i.e. making it more possible to trust your team to do the right thing on their own more often than not. That still doesn't deal with external factors though.

share|improve this answer

No, unless you plan on doing your development outside of work hours, you can't do everything.

Do you all share with each other what you are working on each day as well as progress, that way you can all shift priorities as needed until you increase the number of developers.

share|improve this answer

Absolutely you can wear both hats at the same time, how effectively you can do so is largely a matter of time management.

Management is both a skill set and a job description. From that it encompasses various tasks that you perform. When I managed a team of 10, I was the "HR" manager as well as their technical team lead. I assigned work (yes, not agile...) dealt with small budgetary matters, general HR hire/fire/review/holiday/etc. stuff and the like.

Some of that work goes up with the number of people managed, and some is more fixed based on yes/no. The number of staff you have does not really impact how long you spend on your budget, but does impact how long it takes to perform their mid-year reviews and document them to HR satisfaction.

With a team of 10, I primarily oversaw, reviewed code, and was the person to bounce ideas off. With a team of only 5, however, there was much more time for actual coding.

To use a crude made-up formula as an analogy, my personal experience would be something like

Dev-Time-As-Percent = 100 - Fixed-Managerial-Overhead - (Staff-Count * 5)

Here I am presuming that each individual is 5% of my working time - averaged out. Some need more on some days, etc. The fixed part is the stuff I mentioned like budgets, which tends to be invariant - either I have to make one or I do not. The staff count is also an input to the numbers in the budget, but the staff count doesn't change the effort of creating the budget much.

What you do with that leftover time is up to you, and your boss! In my case, I mostly fixed bugs in order to keep my hands dirty in the code, and because my time did indeed vary, I was therefore not a bottleneck for larger features.

Any job, like bits on a hard disk, or furniture in a house, can expand to fill space (time) available. So it all goes back to time management. Do you get the management stuff done-done and can you then do other things? Or is the management stuff taking 100% of your time regardless of the size of team?

share|improve this answer
I'd love to agree, but its not about time management its about interruption management - or more strictly about being in the flow. If you can't shut the door (literally and figuratively) then its hard to develop well. If you do shut the door it will be about 5 minutes before the end of the world happens outside... You actually agree that you can't be a developer (not in the fullest sense of the word) because it seems you arrived at the same compromise I did – Murph Dec 13 '11 at 13:44
I used to shut my door frequently when I needed to (and at one point I actually had a physical door!) I was not a full-time developer, yes, so my tasks were by necessity more bite sized than others sure. – sdg Dec 13 '11 at 13:57
As soon as you shut the door you create the potential to stop others dead in their tracks - that's the fundamental problem – Murph Dec 13 '11 at 14:09

This can possibly work out well if the "team" shrinks to a small size, e.g. just you and another (experienced) developer, so there is not to manage anymore beyond that of a self-managed developer. Of course you still have to plan features, iterations, deadlines etc. but this doesn't conflict too much - if at all - with your role as a developer.

But if the number of developers is still to large to run without proper management, the little output you can produce on the side will hardly compensate the decline in their productivity.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.