Pros and cons of dedicated teams

One concept that’s been getting a lot of play in recent years is the idea of dedicated teams. In the context of software development and support activities, the concept boils down to this:

1. Any single team is assigned to just one development initiative or to the support of just one set of technical assets at a time; and
2. Any individual is assigned to just one team at a time.

With this model, you might dedicate Team A to ongoing enhancement and production support of the company’s call center systems. Team A does not do any work to support other business operations or other technical assets, such as contributing to the development of a loan underwriting system, or providing production support for the company’s enterprise service bus. In addition, if Stephan is a member of Team A, he is a full-time member of Team A. He is not assigned 75% to Team A, 15% to Team B, and 10% to Team C.

The dedicated team model is an alternative to a matrixed model of personnel assignment (or “resource allocation,” if you can tolerate speaking of humans as “resources”). With a matrixed model, teams are formed specifically to carry out particular initiatives (typically when the discrete project delivery mode is used), and disbanded at the conclusion of each initiative. Individuals may be assigned to more than one of these temporary teams at the same time, and expected to split their time among multiple initiatives.

Managers who are accustomed to thinking in terms of maximizing individual resource utilization often have difficulty understanding the potential advantages of the dedicated team model. I thought it might be helpful to summarize some of those advantages:

• Avoiding artificial dependencies between projects
• Reducing induced administrative overhead
• Reducing context-switching overhead
• Increasing domain knowledge
• Increasing team cohesion
• Improved visibility and clarity on progress

There are also potential disadvantages to be aware of, such as:

• Stagnation of technical skill sets
• Boredom and its associated morale problems
• Reduced opportunities to learn about other areas of the company’s business, with the risk of developing a narrow perspective on the work
• Missed value from deep specialists

The matrixed approach to personnel assignment seems like the obvious approach when one applies utilization thinking to the problem of software delivery, as opposed to throughput thinking. Utilization thinking focuses on keeping each individual resource as busy as possible all the time. Throughput thinking focuses on maximizing the delivery effectiveness of the end-to-end process. For more on these concepts, please see Utilization thinking vs. throughput thinking on this blog, or Measure throughput, not utilization by Johanna Rothman, or the write-up on the Strategos website (a consultancy), or any number of other sources.

The basic idea is that if an individual is waiting for some external dependency before he can continue his current task, he can stay busy by working on some other task in the meantime. While this does fill the individual’s time sheet completely, it overlooks the negative impact of context-switching overhead and the impact on those who may be waiting for him to complete the first task before they can continue their work.

With utilization thinking, the block may be removed at a time when the individual has become deeply involved with a second task in order to stay busy, and he cannot stop immediately. This causes waits and blocks to be extended when there are no technical hold-ups. With throughput thinking, the idea is that it is more important for the individual to be available immediately as soon as the block is removed than it is for him to stay busy at all times while waiting for its removal. When we look at the performance of the end-to-end process as a whole rather than at how busy each individual is at every moment, we find that throughput thinking tends to result in better delivery performance. The dedicated team model supports this in several ways.

Artificial dependencies between projects

The matrixed approach to personnel assignment creates artificial dependencies between projects. Even when there are no genuine dependencies, when individuals are dividing their time between two projects, there will be times when one of those projects must wait for the other. The dedicated team approach completely avoids this problem.

A company of appreciable size will have hundreds of initiatives in its portfolio in any given year. For purposes of illustration, let’s keep things simple and say we have 8 initiatives to carry out. We are running all 8 initiatives as discrete projects and starting them all at the same time (that is a related problem, but not in scope for this particular post), and we are using a matrixed approach to assigning people to the 8 projects. We’ll consider just a subset of all that to show how artificial dependencies arise.

Two of our people, Jan and Anna, are assigned part-time to several projects each, like this:

	Project A	Project B	Project C	Project D	Project E	Project F	Project G	Project H
Jan	50%	25%	15%	10%
Anna		5%		10%		10%		75%

Between the two of them, Jan and Anna are assigned to 6 of the 8 in-flight projects. We will say, for purposes of illustration, that none of these 8 projects has any technical dependencies on any of the other seven. From a purely technical perspective, they could all proceed independently of one another. This means that no dependencies are noted on the program-level Gantt chart or on any of the individual project Gantt charts.

I emphasize that point because the artificial dependencies are not visible to management. People assessing the dependencies among the various projects based on the merits of each project have no reason to think any dependencies exist. Management has no information by which to understand and manage the dependencies. The only reason any of these projects would block any of the others is because of the way people are assigned to them. As long as each individual person is fully utilized (busy all the time), management does not perceive a problem.

Let’s say the business priorities of the 8 projects line up with their alphabetical designations. Thus, the most important thing Jan can work on is Project A, and the most important thing Anna can work on is Project B. They both get started with their respective top priority tasks. Before long, Anna reaches an impasse because she needs the results of some task assigned to Jan on Project B. But Jan is not available to work on Project B just now because she is deeply involved with a task for Project A, which has a higher overall priority. We now have an artificial dependency between Projects A and B…and work on the portfolio has only just begun.

Because management measures people’s performance based on how busy they are, Anna finds something to occupy her time. She makes a start at a number of lower-priority tasks affecting three other projects. None of these tasks is completed, as she can only go far enough with each task to reach a point where she needs a result from some other team. Anna has six or more tasks officially in her “in progress” pile, and she is waiting for someone else before she can make progress on any of those tasks. Meanwhile, a number of other people working on other teams are waiting for Anna to complete one or more of the tasks in her pile. Soon, a large number of tasks are in various stages of completeness, and the people who started working on them are already forgetting what they have done so far and where they left off.

You can imagine the net effect of this sort of problem if we are talking about 200 initiatives and 1,500 technical staff. If the organization used the dedicated team model, then there would be no overlap between team members for Projects A and B, or any other two projects. No artificial dependencies could arise. The only dependencies to deal with would be legitimate ones.

Induced administrative overhead

Typically, each initiative has a set budget, and team members are expected to charge their time to the appropriate budget bucket so that management can track the financial burn for each initiative. With the matrixed model, each individual has to keep track of the amount of time he/she spent supporting the various projects to which he/she is assigned part-time. With the dedicated team model, management knows that every member of a given team is fully dedicated to the single initiative for which that team is responsible. Time tracking becomes much simpler. The cost of the overhead of a complicated time tracking procedure can have a significant impact on overall delivery effectiveness.

Some amount of administrative overhead will always be unavoidable. The problem here is induced (that is, created by the way we choose to work rather than by any genuine business need) and unnecessary administrative overhead. There is no need for people to spend time every day keeping track of how they spend time every day. If each individual is dedicated to just one project at a time, we already know how much time he/she spent on that project every day. Management can assume each person works a normal work day unless he/she reports a variance. The only remaining administrative overhead is for dealing with variances.

Context-switching overhead

The quantity of literature describing the issues with excessive context-switching is so vast that I can’t do it justice by citing a couple of hypertext links in a little blog post. Suffice it to say that the downside of context-switching is well-known and is not an open question. For a modest beginning in reading about it, you might start with articles like Is multitasking more efficient? on the American Psychological Association website, or Overcoming the performance declines of multitasking on the Human Performance Resource Center website, or Christine Rosen’s piece in The New Atlantis, The Myth of Multitasking.

Individuals, teams, and whole organizations will complete a long list of work items in less time by focusing on completing one or two at a time than they will by juggling many items concurrently. Jan and Anna lose a lot of time waiting for each other because they’re assigned to multiple projects at the same time. Even when they are actively working on a task, they lose time getting back to where they left off each time they resume a task they had put on hold. The matrixed approach to personnel assignment forces people to work in this manner. The dedicated team approach completely avoids the problem.

Development of domain knowledge

In organizations that use the matrixed approach to personnel assignment, individuals are typically assigned to tasks that match their skill set or job description. They don’t have a broad view of the project or projects to which they are contributing. Each task is assigned to them in isolation. For example, if Jan’s official role is database administrator, her work queue will look like a disconnected, random series of requests for new table columns, indexes, database instances, userids, and what-not. She will have no clear understanding of the business or technical context of any of these requests.

This prevents her from (a) learning about the business domain, and (b) applying her intelligence and creativity to suggest effective solutions to the problems people are trying to solve when they request her services. (This is sometimes called the “eighth waste” of Lean, above and beyond the canonical Seven Wastes: squandered human potential.)

From an organizational perspective, when all 1,500 technical staff are treated in this way, hardly anyone has an opportunity to become deeply familiar with the business domain. Everyone’s work just looks like an endless series of isolated, disconnected requests to perform trivial tasks that have no apparent context.

Every temporary team that is formed to carry out a new initiative is a team of beginners. There is no institutionalized domain knowledge that carries through from one project to the next.

With the dedicated team approach, a team learns the domain and the technology in the course of their first project together, and their knowledge continues to grow and deepen with each successive initiative they undertake. The initial learning curve for domain knowledge does not have to be repeated in every project. This saves considerable time and expense for the organization.

Increasing team cohesion

Software development of any scale larger than the most trivial is an example of a team-based product development activity. One of the critical success factors for any team-based product development activity is that the team learns to function smoothly and effectively together. This does not happen instantaneously or automatically just because management declares a group of people to be a “team.” It takes time, guidance, and effort.

There are a number of ways to look at this factor. One of the most popular is the Tuckman model, which suggests teams go through a series of stages on their way to becoming effective: Forming, Storming, Norming, and finally Performing. When the matrixed approach to personnel assignment is used, and temporary teams are formed for each initiative, the effect is to keep teams perpetually at the Forming, Storming, and Norming stages. At just about the time a team would settle into the Performing stage, the team is disbanded and the individual “resources” are assigned to new teams. The new teams start over again at the Forming stage.

When the dedicated team concept is combined with the closely-related stable team concept in which a team remains together for the long haul and is given one project after another, teams have a chance to reach the Performing stage and function smoothly through an arbitrary number of initiatives. In projects #2 and beyond, the team does not incur the overhead of passing through the Forming, Storming, and Norming stages. Consider the amount of waste that is avoided in an organization that has 20, 50, or 100 teams.

Improved visibility and clarity on progress

I mentioned previously that the artificial dependencies induced by the matrixed approach to personnel assignment are not visible to management because they don’t show up as “real” dependencies in Gantt charts or other project management tools. By using an approach to team formation that eliminates artificial dependencies, we enable the project management tools to reflect reality more clearly. This makes it easier for management to see the true status of initiatives and to detect potential delivery problems early enough to do something about them.

The matrixed approach muddies the waters so much that problems very often go undetected until late in a project. Of course, that isn’t the only cause of missed indications, but it is definitely one cause.

Downsides

We all know there’s no such thing as a magic bullet, so there must be downsides to the dedicated team model. It’s prudent to explore those before changing anything about the way an organization manages its teams.

In the opening section of this post, I list stagnation of technical skill sets as a potential downside of dedicated teams. Later in the post, I suggest that the dedicated team model helps ensure individual team members can see the big picture and can apply their skills more broadly than when their work is limited to a series of narrowly-focused, disconnected tasks. Okay, so which is it? Am I trying to have my cake and eat it, too, or is it one of those good news / bad news questions?

I hope the answer is that it is a good news / bad news question. The good news is that team members work with the same set of assets and the same technology stack long enough to gain deep familiarity with it. The bad news is that it is possible for people to stick with the same technologies too long, and start to get into a professional rut. We have to seek a balance between the advantages of teams consistently working in the same general area and the disadvantages of professional stagnation. In my experience, what this amounts to on a practical level is that a dedicated team does not remain together unchanged for an indefinite time. People have to switch out in order to stay in touch with different technologies and different areas of the company’s business.

Closely related to the issue of professional stagnation is the problem of boredom. Technical professionals are by nature curious, exploratory, creative, and enthusiastic. Once they have learned most of the “secrets” of a given problem domain or technology stack, they want to learn something new. There are business benefits to having them become deeply familiar with a domain and a set of technical assets, but if we ask them to remain in the same role for too long they are likely to leave the company. The cost of turnover is much higher than the cost of ramping up new team members. We can keep a team at the Performing stage for a few projects, and then it may be prudent to accept the cost of taking a new team through the formative stages in order to minimize turnover.

During the time that team members are learning one particular aspect of the business very well, they are not learning about all the other aspects of the business. By keeping an individual on a dedicated team too long, we might lead them to a narrow perspective on the business and on technology. They may start to lose the enterprise perspective on things. This is another sort of cost that can, over time, start to exceed the cost of ramping up a new team.

Finally, if the dedicated team model is implemented crudely, we can end up with expensive, rare, narrow-and-deep specialists in roles that do not exploit their unique skill sets. It depends on what the dedicated teams are dedicated to. For development projects, we need a cross-functional team that includes all skill sets necessary to complete the work. People sometimes interpret this to mean that a team has to have a full-time member who specializes in, literally, every type of task the project will require.

Using Jan the DBA as the example, this would mean that she was assigned full-time to a single application development team. In reality, her narrow-and-deep database skills may only be required by that team on occasion. Technical generalists are quite capable of handling routine database-related tasks like creating a table or adding an index. Jan might be having fun writing code and doing some testing or analysis, but she is unavailable to all the other projects in the shop that also occasionally require narrow-and-deep database skills. Cross-functional teams are ideal, but there are times when it isn’t practical to dedicate a specialist full-time to a development project.

This may apply to DBAs, network specialists, security specialists, or specialists in particular products like Siebel, SAP, WebSphere, or BizTalk. For specialized skills like those, it makes sense to establish dedicated teams around the technology itself rather than around specific development initiatives that use the technology. The technology-focused teams then function as service providers to multiple application teams. This can create dependencies between teams for reasons other than technical dependencies, but they are pragmatic trade-offs and not accidental, artificial dependencies.

Conclusion

The dedicated team model can result in better delivery performance than the matrixed model of personnel assignment, provided the potential downsides are understood and mitigated in some practical way. The single largest positive effect is the elimination of artificial dependencies between teams. A second powerful effect is to make the true status of initiatives more clearly visible to management. It has several other potential effects that can be positive, both from the perspective of overall delivery effectiveness and from the perspective of quality of working life for individual contributors.