Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My team of 4 experienced developers works on a large, modular Windows application (approx. 200 KLoC). I have focused on the core codebase since the beginning of the project (3 years ago) and have gradually shifted to a semi-lead developer position, though I am not the team manager.

Our current iteration is a high-priority UI refresh requested by upper management, involving about 15 changes to the core codebase. When asked by the manager, I estimated that each of the 15 changes would take less than four hours for me to complete, a total of less than 7 work days. I then volunteered to perform the work. Instead, the manager decided to evenly divvy up all 15 tasks to all four developers.

In the three days since we started work, I have observed two things:

  1. The other inexperienced team members completed about 1 or less task each.

  2. Brook's Law in action: I spent about half of my time providing assistance (attempting to coach them on using the components). As a result, I only finished 2 tasks myself, instead of the expected 5 or 6.

I approached my manager with my concern that we were running late and again suggested that I complete the remaining tasks. My request was kindly refused, and the stated reasons to split the load evenly was twofold:

  1. Limit the truck/bus factor - ramping up other developers on these skills now, so that in the future any work can be given to anyone, not just me.
  2. To eliminate a "bottleneck" (me) and get work done faster.

To be clear, I have no problems with: a) investing the time teaching, b) people touching my code, or c) job security. In fact, I regularly suggest to the team leader that I train other devs on certain aspects of the core codebase to reduce risk.

In this iteration we also have a large collection of high-priority bug fixes targeted, so it would seem that more progress could be made if the workload were redistributed.

In Mythical-Man-Month, Brooks' suggests a "Surgical Team" where every team is comprised of a lead + sub-lead (the manager and me), and some minor roles. I feel as though we are naturally falling into this organization, but my manager is working against it. I feel that the bus factor is already taken care of (the manager is well-versed in the core code), and that the bottleneck doesn't actually exist (involving more devs won't make the work go faster). I think that in this regard, a Surgical Team is a Good Thing.

These are my feelings, but I'm not an experienced manager, nor have we had to deal with the bus factor (knock on wood). Was Brooks right? Have you worked in a "Surgical Team" where the bus factor came into play? Are there better techniques to manage distributing expertise?

Similar questions:

share|improve this question
1  
Consider it training in communicating your skills to the team. –  user1249 Aug 14 '12 at 8:30

4 Answers 4

up vote 3 down vote accepted

Actually, I would argue that you are following the "surgical team" model. Lucky!

Part of the point of said model is that the lower team members have an assistant role. When the team isn't doing heart surgery, then it is fine to move slower and give them a chance to practice some of their skills, or to cross train in responsibilities.

It is the job of the surgeon to examine and manage their team by looking for weak spots and resolving them, as well as being the top developer. You can't have a non surgeon (business manager) do this, because they don't understand the skills required, kind of like an apprentice to a master craftsman.

So, the manager is taking advantage of this opportunity to work on one of his other objectives. If during the course of it, some flaw is revealed in the team, he can deal with it before it becomes an issue. Say, by hiring another developer.

Or, the juniors might make a mistake. This is the perfect time for them to do so, since they have someone watching over their shoulder. Oscar Wilde said

Experience is simply the name we give our mistakes.

If these juniors never have an opportunity to make mistakes, then they will never improve. It won't just rob your team of experienced future developers, but in a sense, robs them of an opportunity they should have had.

share|improve this answer
    
Thanks for the answer. Already, this experience is definitely revealing two weaknesses of our team: 1) our core codebase is too large, and needs more modularization, and 2) when we do modularize more, other developers need to take the lead of the new components, instead of me. The larger issue, that isn't necessarily part of my original question, is that I have a far larger knowledge of the code than the manager (who is the "official" surgeon), so he isn't delegating effectively as he could imo. –  Kevin McCormick Aug 13 '12 at 21:38
    
@KevinMcCormick - It sounds you should allow your manager worry about these things. Adjust your estimates to now include helping your team members with their tasks. You hav e pleanty of justification for doing so. –  Ramhound Aug 14 '12 at 12:11
    
@Ramhound, definitely true, and I even already discussed that with the manager and he agreed to it in the future. Some of the imbalance in skills he wasn't aware of, and he offered to help. He does know that the project leans heavily on me, which we are both working to resolve. –  Kevin McCormick Aug 14 '12 at 12:23

You may not be a bottleneck now, but eventually you will be if you continue to do all the work yourself. Your manager realizes that it's important enough for you to learn to delegate to risk that your project be late--trust him. Once you learn to let go, your juniors will start learning and producing much much more under your guidance.

share|improve this answer
    
Thanks for the answer, I definitely do agree that one person doing all the work is a high risk and that the manager is aware of that. In this case, however, I am not doing all the work. The other team members are very productive when working on other tasks, such as fixing bugs and working on subcomponents - not the core system architecture. Would be somewhat similar to suggesting to someone on the Windows Media Player team at MS to make changes to the Windows kernel. –  Kevin McCormick Aug 13 '12 at 20:10
    
@KevinMcCormick - What if Media Player is being added to the Windows Kernel, valid excuse, for doing so. It sounds like you don't want the team members to become more familar with the core system architecture, and I can't see the reason for doing so, it would only help you in the long run. –  Ramhound Aug 14 '12 at 12:14
    
@Ramhound, yes of course in that case it would definitely be true. I do want others to take ownership of things I've written, make changes, and understand it (I regularly provide training and documentation). I just don't think the "everyone works on everything to the same degree" approach is effective vs some level of role assignment, since we all have different skillsets and expertise. –  Kevin McCormick Aug 14 '12 at 12:26

Our company used to work like you're suggesting. We had only two people who understood a critical part of code. Whenever a task came up in that part of the code, rather than spend a few weeks getting someone else up to speed, the task would be assigned to them because they could complete it in a couple days. This actually worked pretty well for a while.

What happened is eventually their plate became so full that even though they might be able to finish a task in 2 days, it would take weeks to move to the top of their list. Managers would have fierce verbal battles over whose task was more urgent. Urgent dependent tasks would lie undone.

Eventually managers got sick of waiting and started getting their own teams trained up. Yes, it was a lot slower for a while, but now our throughput is much better.

You may be in that first phase now where you can handle the work, but you have no way of predicting when you will move into the second phase. Here's a hint: it always happens at the most inconvenient time possible. Your manager is right to take the hit when you still have some breathing room.

Yes, it's frustrating to watch someone struggle with something you could do much more quickly and easily yourself. Try parenting a two year-old sometime. You do it because it helps the whole team improve. It's your manager's job to worry about the schedule. If you're worried about the undone high priority bugs, challenge yourself to see how fast you can fix them.

share|improve this answer
    
Thanks for the answer! I can definitely tell that "phase 2" is a real fear, given that we have another employee from another project who is a very visible bottleneck, and it caused major issues in the past. I'm not sure if our project has the same problems, so I'm guessing there is a little bit of a knee-jerk going on here. Regardless, I'm taking this as an opportunity to share some knowledge and maybe reveal some weaknesses in documentation, code modularity, etc. And yes, it is incredibly frustrating! It's comforting to hear someone else who feels the same way. –  Kevin McCormick Aug 13 '12 at 21:45

You are applying a constraint that may not be present or as significant to the degree you think it is. Specifically, you're worried about the time until completion. Your manager, on the other hand, does not appear as concerned by the perceived time constraints.

If you take the delivery time out of your question, you'll quickly start wondering why you're asking the question in the first place.

That's not to say that time is always available, and you did state this is a high priority request from upper management. But you are not privy to all of the conversations your boss has had with them. He may have negotiated for more time in order to have you spend that time training the other members of the team.

And while you feel the bus factor has already been addressed, your boss may be looking to the next request coming down the line that won't easily fit into 7 days of work by one of his star developers. It's far safer to train the team on a smaller iteration where the objective magnitude of risk is much smaller.

I have been a critical bottleneck before; and honestly, it's not a pleasant place to be. In my case, the VP of IT and I talked and we came up with a plan to permanently fix the issue. It hurt, but it hurt a lot less than had I been trucked.

It's easy to get into the mindset of everything needing to be knocked out as quickly as possible. A good manager spots the rare opportunities where a little delay (for cross-training / education) can pay significant dividends later on.

share|improve this answer
    
Thanks for the answer! I wish I could accept all of them. The time constraint is very real in this case, but as others have said, there is never a good time to make these types of time investments. Would be interested to hear how you resolved your situation. –  Kevin McCormick Aug 13 '12 at 21:39
3  
+1 Some bosses may be idiots, but many times your boss has a wider perspective and you just have to trust him. –  Phil Aug 13 '12 at 21:41
    
@Phil - It honestly sounds like in this case the boss might actually have a good perspective. Let him worry about the timeline, worry about being late, he provided the estimate after all. Worst case, crunch time happens, and you finish everything else yourself. –  Ramhound Aug 14 '12 at 12:16

Your Answer

 
discard

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.