A strategy for lopsided teams

Here is a somewhat exaggerated and sanitized description of a situation I encountered on a coaching engagement.

The stated problem was that the software development teams in a certain department were taking too long to deliver and the results tended to have more defects than was deemed acceptable.

Situation:

The company had a policy of hiring the cheapest people they could find. That meant they hired people as analysts, testers, and programmers who lacked any training or experience in computer science or business information systems. The official policy was to “grow” the people internally.
The company had a policy of keeping each individual “resource” (that is, person) fully utilized (that is, busy) at all times.
The company had a policy of tracking each person’s hours against specific, assigned tasks. People were not allowed to do anything unless they could charge their time to a predefined task in the time tracking system.
The development teams in the department comprised about 20 people each, with 2 to 4 extremely senior team members and 16 to 18 extremely junior, many lacking even basic qualifications for an entry-level job (as of their hire date).
Charge-back for internal software development work was based on the fully-burdened hourly cost of each employee assigned to a project. The hourly cost for a senior person was far higher than that for a junior person. (The senior people were often contractors, or employees who had started as contractors rather than being “grown.”)
Internal customers competed with one another to have the senior team members assigned to their own projects, while also complaining loudly about the differential in hourly cost. They wanted to pay for the cheapest people and get the best people.
Each team typically had ~50 tasks in progress concurrently, spread out across the 20 team members. The more-challenging tasks were assigned to the few senior team members.
The junior team members followed extremely detailed “specifications” that spelled out every step they were to take in completing each task. The specifications were prepared by the senior team members. When things didn’t go as expected, the juniors lacked the experience or training to figure out what to do. They waited until the senior team member who had written the specification became available to help them.

My observations:

Because of #2, it was impossible to fulfill the goal to “grow” people internally, as stated in #1.
Because of #3, team members did not feel free to help each other. Because of #8, the only way a team could complete most of its assigned tasks was for the senior members to help the junior members.
Because of #2, senior team members were never officially available to help junior team members. Because of #3, they were not even allowed to help. Yet, they did so anyway, because they cared about the results their team produced. As a result, they often did not complete all their assigned tasks, or they worked overtime to do so.
Because of #2, senior team members would swoop in and pull each junior colleague out of the hole he/she had stumbled into without taking the time to explain or teach. This further guaranteed that the goal to “grow” people, as stated in #1, could never be achieved.
Because of #6, the lead time for any given task was much longer than necessary. The junior team members were assigned to several tasks concurrently. They started on, say, Task A, and Tasks B, C, D, and E were on hold. When they reached an impasse on Task A and no senior colleague was immediately available to help them, they set Task A aside and started on Task B. When they reached an impasse on Task B, they set it aside and started on Task C; and so on. A task that ought to take one week to complete was stretched out over four or five weeks, and most of that time the task was waiting; no one was adding value to the product. In most cases, an intervention by a senior team member only took 5 or 10 minutes, but they were dealing with so many issues at the same time that junior collagues had to wait hours or days for help.
Because senior team members often worked overtime to make up for the time they lost helping junior colleagues, or just to find some uninterrupted time to get their work done, they frequently came to work late. This further reduced their availability to help junior colleagues during normal working hours.

My recommendations:

Assign the senior team members to no tasks whatsoever. This would increase their availability to help junior team members to 100%. Since the primary value-add provided by the senior team members was to assist the juniors, and since the seniors were, in effect, the constraint in the process, increasing their availability to 100% would be tantamount to steps 2 and 3 in the Five Focusing Steps: Exploit the constraint, and Subordinate everything else to the constraint.
Reduce the number of concurrent tasks from ~50 to 1/2 the number of junior-level team members. This would increase throughput by reducing the amount of work in process, reducing thrashing by senior team members as they rushed from one problem to the next. They would still rush from one problem to the next, but there wouldn’t be as many concurrent problems. Also, when the junior team members had to put a task on hold, they would only have one task on hold at a time instead of four or five. This way, a task really could be completed in one week instead of five.
Assign each task to two junior team members, so that they could help each other. This would not eliminate the need for senior team members to step in, but it would reduce the occurrences of such interventions while allowing the junior members to teach each other whatever they could, gradually increasing their skills. In effect, this would be tantamount to step 4 in the Five Focusing Steps: Elevate the constraint (by reducing demand for the senior team members). It would also be a step toward realizing the goal to “grow” internal employees.
Increase the hourly rate charged for junior-level people to cover the fixed costs of the senior level people. Since senior people are not assigned to any tasks, there is no separate charge-back for their time. Since the senior team members will be involved in nearly every task anyway, it is fair to spread their costs across all projects. Now internal customers would pay the same rate for all work. This would reduce bickering and simplify the planning process. It would also eliminate the need to track each person’s hours against specific tasks, since everything would now have the same cost. Absent the need to track hours to tasks, team members could feel free to help each other as needed.
Shift the focus of metrics to track outcomes rather than activity. It is more important to achieve high end-to-end throughput than it is to worry about keeping everyone busy all the time. When we focus on throughput instead of utilization, people will be busy when they need to be busy.

Management response:

Since the senior team members are the only ones who actually get anything done, assigning them to no tasks would be stupid. Our customers would never stand for it.
Because it takes so painfully long for the teams to complete anything, we need to start all tasks as early as possible so they will have time to get them all done. Deferring tasks until later would be stupid. Our customers would never stand for it.
Junior team members are slow enough already. Having two of them working on a single task would just cost twice and much and probably take twice as long, since they would make twice as many mistakes. Throwing money away like that would be stupid. Our customers would never stand for it.
Our customers know exactly how much each employee costs per hour. That information is available to any manager who has access to the compensation system. Furthermore, the customers know the individual team members and they are aware of who possesses which skill sets. We can’t tell them to think of the team as a unit because they know all team members are not equal. They want to specify the individuals who are assigned to their projects. We can’t ask them to pay a higher hourly rate than the actual cost of the individuals assigned to their projects because they would think we were trying to make a profit at their expense. That would be stupid. Our customers would never stand for it.
Since our customers pay for team members by the hour, having team members less than 100% utilized would be stupid. Our customers would never stand for it.

As I see it, the main stumbling blocks to achieving this organization’s goals were:

Hiring policy. A policy of “growing” people internally is fine. However, it is necessary for entry-level hires to have at least a reasonable minimum level of training, especially if senior employees will not be given any time to mentor their new colleagues. Hiring a balance of entry-level and experienced people helps ensure teams aren’t lopsided, like the ones in this scenario, and that the organization enjoys a periodic infusion of ideas and experiences from other places. It also reduces the need to hire large numbers of contract programmers to compensate for the lack of skills of the employees.
Utilization thinking. It seems clear that when we focus on resource utilization, we can achieve local optimization at the expense of global optimization. In contrast, when we focus on throughput, we can achieve global optimization at the expense of keeping everyone busy all the time. There doesn’t appear to be any way to achieve both at the same time. To maximize business value, managers need to shift their thinking away from utilization thinking and toward throughput thinking. This was a deep problem in the organization in question.
Failure to separate the what from the how. At times, it seemed to me that the people in the development area were acting like helpless victims of their own customers. They did not take control of their own operations. In fact, the customers did not need to know exactly who would work on each specific task. They did not need to dictate how the teams would be structured and how the work would be assigned. The customers ought to focus on the what — the functionality the software had to support. The development teams ought to know how to deliver. Business stakeholders don’t know the best way to deliver software; it isn’t their specialty.