Goals and Process

When my daughter was here a week ago, she started a jigsaw puzzle. I've been puttering on it over the week since and I'll likely finish it this afternoon.

While I was puzzling, I remembered some professional development class I took years ago. We had an exercise where each table was given a set of jigsaw puzzle pieces and 5 minutes to work on it. After the 5 minutes was up, each team was given the picture for their puzzle and another 5 minutes. After the exercise, we discussed the lesson of how it was much easier to accomplish the purpose (completing the puzzle) when we knew what the goal was (the picture).

At my table, though, we were only 4 pieces short of completion at the 5-minute mark and it was obvious where they went. The picture was moot by the time we got it.

What was different? We had TWO very experienced puzzlers who had PROCESS for tackling the problem - highly compatible processes with a common understanding of the ARCHITECTURE. We tasked the other 3 people with sorting out specific piece traits that we identified. Then together we worked the initial structure of the puzzle. It helped that we had a similar vocabulary for describing the pieces (meta-language) so when we described a space we had, the other easily handed over the matching piece.

The lesson is not that process is better than a common goal. We had a goal. By looking at the pieces, we knew a lot about the final goal - dimensions, texture, and complexity level, for example. Process enabled us to (1) divide and conquer the work with minimal discussion and making best use of skill sets and (2) accomplish the bulk of the work with a less defined goal, allowing the goal to evolve.

I read a lot toward professional development, including process and team management. In my readings, I've noticed two major approaches - one lead directing a team or a team of equals taking the assignments round robin. A team with one lead is limited by that lead's blind spots and by the team's willingness to follow the lead's personality. The lead is also a frequent bottleneck. A team of equals is limited by the average skill level of the team and how well the team handles their knowledge base. It suffers from a lot of rework. In the puzzle exercise, two leads institutionalized the authority and prevented the bottleneck. It also allowed for growth and skill development in the rest of the team.

I wonder why I've never seen a team model with two leads. I wonder if architecture and process life cycle models would be more effective and more workable with a dual-lead approach.