Taking Work to the Team
Every once and a while I have to work with someone who has the idea that productivity would increase if we had teams that floated from project to project. Worse, float individuals from project to project based on the particular skills they have. "It's the professional services model," they tell me. If you happen to work for a professional services firm, this would make good sense. Looking at the evolution of productivity since the industrial revolution reveals the professional services model as a niche approach to managing productive workflows.
A hundred and fifty years ago, if you wanted a horse drawn wagon and didn't have the skill to build one yourself, you might go to "Smith and Sons Wagon Makers" and work out a deal. You brought the work to the team. In this case, the team is Mr. Smith and his sons. They'd take your order, put it in the queue, and when your order came up they would build your wagon from scratch.
Just over a hundred years ago, Henry Ford figured out a more efficient way to bring work to the team with the invention of the "assembly line." This brought better quality, product consistency, lower costs, and faster delivery of the successor to the horse drawn wagon. The assembly line also brought greater specialization to the team members.
A modern day example of bringing the work to a team who's members are extremely specialized is the Formula One pit crew. Twenty plus team members who's sole objective is to service a race car in the shortest amount of time. The example video shows an amazing blend of team coordination and years of technical evolution to enable the pit crew to complete the task in under two seconds. It's the end result of a century of scientific management, also known as "Taylorism."
However, the assembly line and scientific management breaks down when working to improve the productivity of knowledge workers. It doesn't even serve as a particularly good metaphor for knowledge work. What does "bringing work to the team" look like when searching for ways to improve software development and delivery, for example? Software developers and quality engineers don't sit at an assembly line work station. Knowledge work, in particular software development, is also creative work. There is only one way a wheel can be attached to an axle if an automobile is going to function properly. But there can be many ways to create software that functions in a particular way. Among software developers and engineers, they may be able to tell which approach is better or more efficient or more robust. Assuming good QA, the the end user probably won't. A mis-aligned wheel on a car is readily apparent to anyone who knows how to drive.
What is common when taking work to a team is a shared understanding of the process behind the workflow and the need for well-defined coordination among team members. Who does what when and why. The race car pit crew demonstrates this in under two seconds.
There is, in my view, a metaphor that does serve the team of knowledge workers well. That's the jazz ensemble. Here is a team of highly specialized individuals who have come together to combine their understanding of music theory and individual creativity to produce some amazing music. But this doesn't happen by accident and it isn't something that can be scheduled. The musicians have to have complete trust in each other's abilities and this takes time to establish. The "sound" each ensemble creates is dependent on who's playing. The talent isn't interchangeable with other ensembles. Even when it goes well, when an ensemble member is replaced there is a period of time where the trust needs to be re-established. And it's likely that changing the member composition is going to change the ensemble's "sound." But it will still be jazz.
Keeping knowledge work teams together and taking work to the team allows for a number of desirable characteristics to emerge that are critical to high performing teams.
Clear and persistent understanding of each other's capabilities
Shared understanding of the work involved
Trust in each other's commitment to the goal
The speed at which a knowledge work team gels into a high performance team is significantly influenced by the tactics employed by management.
Be clear with the team what process they are expected to follow (e.g. Scrum, SAFe, etc.) and where in the process they have full creative discretion. A jazz ensemble has full discretion over what they play. But if you've hired them, they also need to know where and when they're expected to play. That's the deal.
Minimize changes to the team's composition. Like musicians, talent between teams isn't seamlessly interchangeable. Replacing a team member will require a period of time for trust among team members to be re-established and until it is, performance will decline. How long this takes is dependent on how disruptive the change to the team's composition has been. Did they lose a leader or a junior member? Did they lose a highly specialized set of skills and product knowledge or something more general and common?
The team is best evaluated by the quality of their output, regardless of how they put it all together. Resist the urge to pull out the scientific management stop watch and magnifying glass.
