Can you successfully keep managing when you are forced back into development?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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?

Answer 6

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.