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?
Similar questions:
Best Answer
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
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.