Copyright © 2007 Jim and Michele McCarthy
The Core Commitments and The Core Protocols are a collection of codified best practices that came out of our teamwork laboratory, called BootCamp, compiled over a ten year period, and now in Version 3.
We didn’t create The Core.
Instead, we watched it grow. We did create the set of initial conditions under which The Core protocols, or something very much like them, would almost certainly emerge. Over the years, we have maintained healthy conditions for Core evolution. Along the way, we also pruned the tree from growing into a few false directions. And we added resources: our own money, time, focus, and stamina. We protected it. Took notes. Tried it out. Passed it out.
A proper credit also has to include the thousands of BootCamp students from around the world who contributed to The Core’s development over the years.
Crediting one person or segment of contributors exclusively would be inaccurate, however. The real story is both simpler and more complex.
The emergence of The Core was in some measure a result of our experiences in 1994-96. We were working for a commercial software company, leading a development team of approximately 150 people. We used a homegrown aphorism to help us try new ideas:
Team = Product
That’s the idea. Because of its many virtues, despite its deficits, and regardless of others who have had the same thought, this maxim became a bit of a mantra for us. During stressful times, when we were tempted to retreat from the overwhelming complexity of the project tasks; when the confusion and disorientation were really getting to us; when schedules were slipping and goals receding and prospects were looking pretty grim indeed. Then, just when we needed it most, someone in our group would invariably come up with a new idea, would provide a fresh point of view based on "Team = Product." "I get it," he might say, and then rattle off some new application of "Team = Product" that could apply to our situation. Occasionally, these ideas were profound; more often they weren’t. They were almost always useful, however.
The essence of the "Team = Product" philosophy is that the behavior of a team maps directly to the qualities of its product, and vice versa. If you want a product with certain characteristics, you must ensure that the team has those characteristics before the product’s development. We also realized that everyone has a product or provides a service. Everyone produces a concrete expression of his value system that carries that person’s virtues and vices out into the world.
What was our leadership team making? We moved through the hierarchical levels in our organization and answered two pertinent questions at each interesting point: Who is the team here? And what is its product?
Let’s call the team of frontline developers the Level I team. Level I makes the actual product. The managers of this team constitute the Level II team. Its product is the Level I team. When applying the "Team = Product" philosophy, the team on one level is the product of the team at the next higher level. If the Level II team sees an undesirable trait in the Level I team, it must be an expression of or reflection of Level II teamwork and the Level II team members. This pattern applies to teams at all levels, right up through the corporate ranks.
This idea may seem clever, obvious, fanciful, or just plain wrong-headed, but to us it was certainly helpful. Using this model, no one can hide from accountability. In our situation, even though we were bosses, we could not fault a team for lacking a virtue, unless and until we had personally demonstrated it. Nor could we expect any remedy that we weren’t personally modeling. On the one hand, this realization was depressing, because there really was no escape: Responsibility inevitably migrated upward and weighed heavily from time to time on our well-paid, if under-exercised, shoulders.
On the other hand, this realization offered an incredibly hopeful perspective as something more, something immediate, something completely within our control that was available to remedy any shortcomings of the team. If we saw something screwed up somewhere or noticed some good fruit dying on the vine, we could immediately find and fix the problem. To inspire other team members to go get that fruit before it died, we would gather and visibly devour tantalizing fruit that had gone unpicked in our own neck of the woods.
If we wanted any property to materialize on the Level I team, we would have to incorporate that property into our own behavior. This change in behavior was conceptually simple, but challenging to implement. In any case, keeping this basic framework in mind exposed many novel approaches to team problems. When we first applied this perspective, so many new possibilities opened up at such a rapid pace that we were unable to keep up with them. Although many little tests and a few big ones did yield the desired results, we saw so many new solutions to problems that had plagued us for years that we hardly knew where to begin.
We quickly realized that we couldn’t possibly conduct sufficient experiments to develop a full understanding of precisely how useful the formula was; to discover where it failed; or to see where the behavior it inspired might lead. We wanted to explore its dynamics and map its etiology in the systems we believed it governed-that is, check it out all the way. Unfortunately, the experimental opportunities in a commercial software development effort are necessarily limited. A major obstacle is the simple passage of calendar time. A large commercial software project can take months or years. The possibilities we were seeing appeared so valuable, however, that even a few months seemed far too long for each cycle if we were to learn everything possible. With millions of dollars at stake on a single development effort, radical experimentation seemed risky. The number of variables with which we could tinker was low. Together, the sluggishness of "real-world" calendar time and the responsibilities of prudent business practices worked against the idea of implementing the sustained, radical, and rapid experimentation that we envisioned. Still, we thought big breakthroughs in team dynamics were possible-breakthroughs that could make collaboration simpler and more effective for any team.
To study this material in depth, we had to complete a development cycle in a much shorter time. Life itself was too short to go through enough development cycles. Even a very busy, unusually stable, and highly focused development manager could-if she stayed with the task for a long time-expect to oversee 10 to 20 projects in one professional lifetime. Many of these projects would use essentially the same teams, reducing the diversity of team sources that would enrich the manager’s education and hasten experimental progress.
In early 1996, to accelerate the rate and breadth of our experiments, we went out on our own and established a laboratory devoted to the study and teaching of teamwork. The ultimate existence of The Core protocols became a virtual certainty when we decided how we would operate the new lab, which we named "BootCamp." The principal experiment conducted would be a recurrent product development simulation, lasting five days and nights with a new team each time. It would take place every month or so. The team members would complete four steps:
- Form a team.
- Envision a product.
- Agree on how it would be made.
- Design and build it.
At the end of the week, the teams would have to deliver their products on time, or stay longer to do so, or not, as they chose. We knew that we could successfully conduct such a product development effort, even leading it personally, if needed. We had done just that for many years, earning our living in a variety of environments. We had sufficient information, tips, techniques, and useful practices to transmit high value to most students. We could teach them practices that could ensure the successful outcome of their own product development efforts, now or later, simulated or not.
We had already gained, organized, and articulated considerable knowledge from our experiences in leading or otherwise contributing to dozens of project efforts, most of which proved quite successful. This body of knowledge would serve as the starting point for the first BootCamp teams. Even if we learned nothing during BootCamp, we still would have plenty to offer. BootCamp has allowed us to effectively compress a project development cycle into a five-day experience. In five days, students learn what would normally require a long development cycle. The intense BootCamp experience includes all of the failures and triumphs that occur with normal team formation; the creation of a team-shared vision; and the design, implementation, and delivery of a product. The days in each BootCamp are packed with accelerated team dynamics; what usually takes a year or more is created in a few long days and nights of exceptionally deep engagement.
The many new insights from BootCamp emerged at a vastly increased clip. The learning pace was accelerated by our experience of working intimately with hundreds of different project teams. We first helped to create the team, and then their products. We experienced complete development cycles with incredible frequency and velocity-6 times per month at peak periods.
Working with teams of every kind and composition, and working before and after BootCamp, we applied what we learned to our own teamwork. One additional factor led to the creation of The Core protocols, and originated in our standard assignment to the students. Each team would have to build a product in one week. But what product would the BootCamp teams make?
At one level, BootCamp is conceptually simple: We assemble a group of project team members. Sometimes the students are members of a preexisting team. Sometimes they represent as many backgrounds as possible: corporate executives, entrepreneurs, computer scientists, writers, editors, graphic artists, engineers, managers, program and project managers, producers, HR, technical support, administrative assistants, consultants, marketing managers and salespeople.
Often, there will be those who don’t work in a corporate environment in attendance: nurses, teachers, homebodies, and press members. We give each new team-in-waiting a single assignment:
Design, implement, and deliver a course that teaches you everything you need to know to deliver great products and services on time, every time.
This assignment has remained unchanged since the first BootCamp. It seemed to us that it would be useful to look at team dynamics from the real-time point of view of a team actually working in a state of effective teamwork. Teams exhibiting the most desirable teamwork were best able to solve the riddles of such teamwork. The decision to devote the BootCamp teams’ efforts to resolving the issues of bringing teams to the effective state they were enjoying was a productive innovation. Teams in a newly gained high-performance state produce extraordinary results. When they examine the conditions and elements of their own high performance, as it occurs, the quality of insight is substantial.
Almost every BootCamp team has experienced the following flash of insight: If teamwork itself could be made more efficient and direct, then the team members would be able to find the solutions to the big problems that vexed them. This knowledge could then be leveraged to enhance their other endeavors. High-performance teams typically acquire their reputations by accomplishing the specific goals they set for themselves. For example, a great basketball team wins many basketball games. The players are not remembered for their contributions to the art and science of team enhancement, but for putting balls through hoops. Achieving a team’s original goal is a task not directly related to explicitly uncovering the dynamics of team formation. In the case of the BootCamp teams, the presenting task became the discovery, refinement, and codification of practices that would always lead to the formation of great teams.
As one BootCamp led to the next, we began capturing the best practices employed by the teams, and we encoded these behaviors to make them easily transmissible. These lessons from the BootCamp experiences gradually evolved into The Core protocols. When a team applies The Core protocols consistently, it will produce superior results.
The booting process stimulated by The Core protocols can be ongoing, yielding more efficient and capable groups. The lesson that the booting process continues in a general way is reinforced vividly when we see every new BootCamp team learn more, do more, and add more to the richness and the reproducibility of the "multipersonal" patterns and protocols that lie at the heart of The Core.
And that’s our story-how we watched The Core protocols emerge.
Jim and Michele McCarthy left successful leadership positions at Microsoft to form an innovative teamwork laboratory. For the last 10 years they have rigorously studied and codified the best practices for teams to get into and maintain a state of shared vision. These best practices are called The Core Protocols. Jim is well-known for his humorous, inspirational and educational public speaking and the couple are co-authors of the books Dynamics of Software Development and Software for your Head. They also co-host a podcast focused on business issues called The McCarthy Show which some claim is addictive. They can also be heard on Microsoft’s MSDN web site.
Adapted from the article Booting the Core and used with permission.