Since 1996, it has been our goal to develop a recipe that would bring any team to a state of shared vision. After working with thousands of executives, managers and product developers from all over the world in our teamwork lab, we believe we have reached this goal. If you and your team follow our new recipe, it will lead you to the highly productive and previously chimerical state of multi-personal flow that we refer to as the "state of shared vision." The recipe (and the list of ingredients) is called The Core V3.0.
The recipe articulated in The Core is - like any recipe - repeatable at will, if you have the ingredients and, of course, the will. The recipe will succeed independently of our personal involvement. A book, licensable courseware, and various types of certification are available for those who are interested. Best of all, typically, establishing and maintaining a state of shared vision on a team costs less than 2% of a team's total time.
These encouraging results stem from the experience of shared vision. When multiple people share a vision, they are holding similar or identical imaginary objects in multiple minds simultaneously. Such a profound multi-personal capability can be used to augment or even replace other, more costly, less pleasurable techniques and tools commonly used in business environments today. It is likely that your team would benefit from being in a state of shared vision, if it's not in such a state already.
Actually, the emergence of The Core was inevitable, probably, from the moment in late 1994 that we had this one idea. We were still working for a commercial software company. We were leading a large development team. Maybe 150 people. And this little home-brew aphorism occurred to us, and was an idea we really latched onto, too. We used it to help us come up with new stuff to try whenever the inevitable project complexities arose and the usual management fog started to descend.
Team = Product
That's the idea. Whatever else its virtues (and they are many), and however many its deficits (and there are a few), and whoever else has thought the same thought (and there are probably some), this maxim became a bit of a mantra for us. During periods when we were stressing and fussing, or retreating from the overwhelming complexity of our tasks; when the confusion and disorientation of large scale product development began to really grab hold, as they always do at some point, someone would pop with a new idea, structuring a fresh point of view for us building on our formula. "I get it," she might say, and then, with reference to the saying, she would rattle off some new application of the "Team = Product" principle, something she saw as implicit in the equation that could apply to our situation. Occasionally, these ideas were profound; more often they weren't. But they were almost always useful. This team analysis technique consistently yielded fresh insight into whatever gnarly situation we were facing.
The basic idea of "Team = Product" is that the behavior of a team maps directly to the qualities of its product, and vice-versa. So, for example, if we wanted a product with certain characteristics, we would have to ensure that the team had those characteristics (or appropriate correlatives) before the product's development. Simple enough. An even more useful level of meaning in the "Team = Product" idea was revealed when we considered: hey, wait a minute: everybody around here has a product, or provides a service; everybody makes some kind of "product," everybody is making some concrete expression that embodies his value system, and carries his virtues and his vices, out into the world. This simply can't be helped.
One question quickly arose. We manager types, leader people: what was our "product"? What product was our leadership team actually making? Well, the mapping of the software development team to its product, software, so simple for us to do for others, required that we view both "product" and ourselves a bit differently if we wanted a map for ourselves. We had to move through the hierarchical levels in our organization and ferret out at each interesting point: who is the team here? And what is their product?
Let's simplify our discussion, for clarity's sake. Say that there were only managers and developers in the situation (which is a considerable simplification). We'll call the team of front-line developers the Level I team. Level I is the people that actually made - bit by gruesome bit - the computer software we sold. Then there was also a Level II team: that would be us, the managers.
The most useful definition of the Level II team's product, the product of the managers' effort, was actually the team itself on Level I. The product of the software development managers was the software development team; and the product of the team in Level I-land was the computer software products. In the world of Team = Product, the team on one level is the product of the team on the next. This meant that whatever we Level II folk saw as undesirable traits of the Level I team must be an expression, or reflect, or otherwise map to our own Level II teamwork and, indeed, to our little Level II selves. The Level I team characteristics merely pointed at their more fundamental correlatives of the Level II team. And so on, and so on, right on up through the corporate ranks. Now this may seem a clever point of view, or an obvious one, or merely a fanciful one, or just plain wrong-headed thinking, whatever suits your own perspective; but to us, it seemed mostly helpful.
Using this model, no one could hide from accountability. In our situation, even though we were ostensibly bosses, we could not honorably fault a team for lacking a virtue, unless and until we had exhausted ourselves demonstrating it personally. Nor could we expect from them any remedy that we weren't personally modeling to the extremities of our potential. On the one hand, this whole perspective was kind of depressing, because there really was no escape: responsibility just migrated upward and this weighed heavily from time to time on our well-paid if under-exercised shoulders; but it also was an incredibly hopeful perspective, on the other hand; finally, there was actually something more, something immediate, something completely within our domain of control, that we could do to remedy any shortcomings of the team, a team that did after all depend on us in many ways. Among other things, they depended on us, or at least they thought it would be fair, if from time to time, we made things better than they would be if we weren't there.
In any case, if we saw something was screwed up somewhere, or we noticed some good fruit was dying on the vine out in the fields of Level I, we could immediately find and fix in ourselves the type of problems we saw first elsewhere. To get them to go get the fruit, we could gather and visibly devour the Level II fruit that had been going unpicked in our neck of the woods. Why, if we wanted any property whatsoever to materialize on the Level I team, or, for that matter, via their own universe of Team = Product, in the products made by them, we would have to first incorporate that property into our own behavior.
This was conceptually simple, but characterologically challenging. Keeping this basic framework in mind will expose many novel approaches to team problems. In fact, at the time we first started working from this perspective, so many new possibilities opened up in our minds, and so quickly, that we were unable to keep up with them in any meaningful way. Although many little tests, and a few big ones, did yield the desired results, we saw so many more approaches to problems that we had been stuck on for years, that we could barely decide where to begin. Moreover, we quickly came to see that we couldn't possibly conduct sufficient experimentation to develop an understanding of precisely how useful the formula was, to discover where it failed, to see where the behavior it inspired might lead. We wanted to explore its dynamics, map its etiology in the systems we believed it governed. Check it out all the way.
But it is a fact that the experimental value of a commercial software development effort is necessarily limited. One big inhibition is the simple passage of calendar time. A large commercial software schedule can take months or years. But the possibilities we were seeing appeared so valuable that even a few months was far too long for each cycle, if we were to learn all we could. Also, with millions of dollars at stake on a single development effort in our environment, radical experimentation seemed a mite risky. The number of variables that could be tinkered with was, of rights, low. So the sluggishness of "real-world" calendar time, and the responsibilities of prudent business practices worked against the idea of the sustained, radical and rapid experimentation we envisioned. We thought big breakthroughs in team dynamics were possible, breakthroughs that could make collaboration simpler and more effective for any team. But it seemed obvious to us that to truly study this material, we had to be able to do a complete development cycle in a much shorter period of time. Life itself was too short to hold enough development cycles. Even a very busy, unusually stable, and highly focused manager could - if she stuck with the task for an extremely long time - expect to oversee between ten or twenty projects in her entire lifetime. And many of these projects would use mostly the same teams or team, reducing the diversity of team sources that would enrich her education and hasten experimental progress. So, in early 1996, to accelerate the rate and breadth of our experiments along this line, we struck out on our own and established a laboratory devoted to the study and teaching of teamwork.
And the ineluctability of The Core ratcheted up a bit more.
Probably, that The Core would exist became certain when we decided how we would operate the new lab (which we had named BootCamp). Especially with our first set of decisions: the principal experiment we would conduct would be a recurrent product development simulation, lasting five days and nights, a product development effort staffed with new teams each time. It would take place every month or so. The students who would attend as team members would spend their five days and nights:
1) Forming up as a team
2) Envisioning a product to make
3) Agreeing on everything about how it would be made
4) Designing and building it
On Friday, a hard deadline would hit: the teams would have to deliver their product on time, or stay longer to do so. Or not, as they chose.
This all made a great deal of sense. We knew we could successfully conduct a product development effort of that type, even leading it personally if needed. We had done just that (more or less) for many years, earning our livelihoods in a variety of environments. And we knew we had sufficient information (tips, techniques and useful practices, etc.) to be able 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. After all, we had already gained and (and even organized and articulated) much knowledge from our experiences in leading or otherwise contributing to dozens and dozens of development efforts, most of which were quite successful development efforts, too. This existing body of knowledge would serve as the starting point for the first BootCamp teams. Even if we ourselves learned nothing new during a BootCamp, we still would have plenty of value to offer. BootCamp has allowed us to effectively compress the essentials of a product development cycle into a 5-day experience. In five days, we have been able to gain the knowledge, or at least the hypotheses, that would normally require involvement in a drawn out development cycle.
The intense 5-day BootCamp period includes all the failures and triumphs that go into normal team formation; the oft-neglected creation of a team-shared vision, and the design, implementation and delivery of a product. The few days of each BootCamp are dense with accelerated team dynamics: what usually takes a team a year or more (if it ever happens at all, which it often doesn't) is created in a few long days and nights of deep, deep engagement. There were so many new and vivid insights from BootCamp, and they came at a vastly increased clip. Our learning pace was amped from working intimately with some fifty different BootCamp teams, first helping create the team and then helping create their products; from experiencing complete development cycles with nearly unspeakable frequency and velocity, one or two times a month at peak periods; from working with one team after another after another, teams of every kind and composition; from working with teams before and after BootCamp; from applying what we learned to our own teamwork. This is all well and good. But The Core was actually created due in large measure to one additional factor. The Core came from our recurrent assignment to the students. Each team would have to build some product in one week. What products would the BootCamp teams make?
In the case of Executive BootCamp, the course is conceptually simple. It goes like this: we assemble a group of executives. Sometimes they are a preexisting team. Sometimes, not. Then, we give this new team-in-waiting a single assignment:
Design, implement and deliver a course that teaches you everything you need to know to lead a corporation to greatness NOW.
This assignment has been essentially the same from the first to the most recent BootCamp. It seemed to us that it would be very useful to look at team dynamics from the real-time point of view of a team actually in a state of transcendently effective teamwork. Also, teams exhibiting the most desirable teamwork were likely best able to solve the riddles of such teamwork.
The decision to devote the BootCamp teams - while they were in a heretofore- rarefied state of high-performance - to resolving the issues of bringing teams to the state they were simultaneously enjoying, was a productive innovation. Teams in a newly gained high-performance state produce results that are extraordinary. When they are examining the conditions and elements of their own high performance, as it occurs, and while also building on what others similarly situated have found, the quality of insight is substantial.
Almost every BootCamp team has experienced an often-blazing period of team cognition around this idea: if teamwork itself could be made a significantly more efficient and direct process, then they would be able to find the solutions to the big problems that vexed them and filled their lives with struggle. This knowledge would be highly leverage-able.
After all, high-performance teams typically acquire the reputation of high performance by accomplishing their presenting task, the specific goal they had set for themselves. For example, a great basketball team wins many basketball games. They are not remembered for their contributions to the art and science of team enhancement, but for 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 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 the teams employed, and we encoded these to make them easily transmissible. The best practices and evolving learning from all BootCamp experiences gradually turned into The Core. When a team applies The Core consistently, that team will produce results superior to those it had previously produced.
Additionally, the "booting" process stimulated by The Core can be an ongoing one for teams, yielding ever more efficient and capable groups. That the booting process continues in a general way is especially vivid to us as we see every new BootCamp team learn more, do more, and add more to the richness and the reproducibility of the multi-personal patterns and protocols that are at the heart of The Core.
And that's the story of how we watched The Core emerge.