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:
The other inexperienced team members completed about 1 or less task each.
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:
- 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.
- 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?