Does Fred Brooks' "Surgical Team" effectively handle the bus factor?

Question

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:

• How to increase the bus factor and specialize at the same time?
• https://softwareengineering.stackexchange.com/questions/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.