Team Tips – 11 {Myth busters}

One of the many, many, many things that one learns from the Core Protocols and the concepts in Software for Your Head by Jim & Michele McCarthy is that axioms we have been taught elsewhere about teamwork just aren't necessarily true. In other words, these “axioms” are more correctly  accepted wisdom, rules-of-thumb, even assumptions, that need to be verified and validated.

Just as once we thought the universe revolved around the earth – with really obvious evidence – we have learned that this knowledge, once taken to be fact, is actually wrong. Similarly, a lot of the accepted wisdom about the behaviours of successful teams, has not survived the living laboratory of teamwork we know as BootCamp. From teams' experiments in BootCamp we have captured essentials of great teamwork in the Core Commitments and the Protocols – the Core.

Some of these axiomatic falsehoods about teamwork we previously accepted from training or experience include:

• teams need to be led by an appointed leader
• teams need facilitation
• team decisions need consensus
• effort matters
• all team members have to work equally hard
• the best ideas come from the tenured members
• unsolicited feedback is useful
• emotions shouldn't be allowed
• conflicts should be set aside
• there is no “I” in “Team”
• etc. (I'd like to hear about your list)

But one of the bombshells concerns a myth of Project Management in an intellectual property development world.

Anyone who has worked on a project, or been taught classic project management thinking, knows about the scope, time, resources triangle. Given X resources on the team, to produce a Y scope of work, in Z time, we can visualize the triangle with sides X, Y, and Z. If one of these sides is to shorten or lengthen, then clearly the other sides must flex or else the triangle breaks and the project fails.

We can all think of many examples where that appears to be self-evident. If I decide I want a second story on my one floor bungalow in the middle of building the house, then the contractor will certainly tell me it will cost more money, more materials, more equipment, more builders – in short more resources.

So how can it be that teams using the Core and the experiences of BootCamp are successful with the Intentional Development Protocol which says:

There is not a rigid triad of time, resources, and scope as you may have been told in your project management class. The triangle is in fact an angle with an infinite space between the two lines. The infinite space is the “resources” space. Maximizing the human potential of your team, your resources, can overcome any deficiencies you feel in the time and scope domains. Your belief that you don’t have enough time or too much scope is the signal to you that you are not being receptive enough to what’s available to you.

And that statement is from Jim McCarthy (Bell Labs, Microsoft) who had previously promoted the classical triangle is his previous book The Dynamics of Software Development!

What gives? How can a finite team have indeterminate / unlimited / infinite resources?

One clue from the BootCamp experience is that in the realm of creative production one never knows when or from where the next good idea will appear. When the resource constraints are simply the minds available to the team, and the team knows how to best access these resources, that side of the triangle starts to bend, balloon, flex, wiggle, and expand, if not vanish.

If the team's focus is on delivering quality features for this milestone at this deadline, and the Simple Rules and Tools of the Core are familiar to them, then there is virtually no limit to whom, and when, they might ask for help in getting results.

Compare that to a team not having been to BootCamp, working the traditional paradigm of time, scope, and resources. The resources they perceive available to them are primarily, if not exclusively, the individuals on the team. They may or may not even ask each other for help on their own tasks. If they do ask for help, it is often restricted to non-significant issues - certainly nothing that is frightening to them: challenging egos, being vulnerable to appearing lacking in knowledge or capability, giving up on positions of power and influence from seniority or status, etc. They don't naturally ask for help quickly and easily from those outside the team, the department, the company, their locality, the world at large.

When this group gets into trouble with delivering quality on time, they do all the standard things: put in extra hours and effort, de-commit from scope by dropping features or the depth of features, ignoring quality, asking for more team members or different skill sets, changing timelines on task achievement or overall deadlines, focusing on "easy" stuff, not testing, not prototyping the end product, getting sick, spending more energy on working out options, excuses, blame, tossing the issues in the project manager's or boss's lap, etc.

The team that has been to BootCamp knows they don't need to do any of the above.

• They know they can ask anyone anywhere around the world for help. Just asking alone often provides the answer that was waiting to be found in their own minds.
• They make quick unanimous decisions about this new insight based on their shared vision of the outcome.
• They convert planning time into building prototype solutions to check the boss's and or the user's acceptance.
• They spend their energy on results – the results they agreed in advance they could produce.
• Their focus and energy dilates time – they get better work done faster.
• They are receptive to opportunities that appear spontaneously, perhaps are strange, unclear, yet somehow align with their vision and resolve an issue, add quality, provide a shortcut, help meet the deadline. This receptivity is key.

Impossible isn't it? And of course, the sun revolves around the earth – until one gets a new perspective. Then...

Myth busted.

Team Tips – 10 {A word with you ...}

There's a wonderful push across the world to translate the Core Protocols, from McCarthy Technologies, into a variety of languages by people who want to use this information locally with teams for whom English is not their first language.

As they look into this translation the following kinds of questions come up:

Sergej K. writes:

“I'd like to translate the Core into Czech to introduce it to our team and I need help. Will you tell me what the best alternative expression for "I'm in" would be? It's quite idiomatic ("I'm in what? In a team, in a state, in the room, in an agreement?"), what would you have used in English if you couldn't say "I'm in"? :) Are the words important?”

and, Algimantas S. writes:

“Is there a big difference between "I'm MAD, GLAD, SAD, AFRAID" and "I feel MAD, GLAD, SAD, AFRAID"? We use "I feel ..." version in Lithuanian version of The Core, because it is more natural.”

Algimantas S.again:

“I use "I connect/check-in" for Check-in and "I disconnect/logout" for Checkout. Lithuanian language doesn't have "I'm in" either.”

and, Annemarie H. asks:

“Will you help me to find the best french version of MAD SAD GLAD AFRAID ?”

These are in addition to efforts over the years to translate the Core into Spanish, Russian, even Marathi, and others I'm not aware of.

Considering that the Core Commitments and Protocols (the Core) are the distillation of the behaviours and procedures of thousands of successful teams since 1996 into condensed, rich algorithms it's no wonder that the precision of the wording gets a little tricky.

Add to that the quirks of modern North American English such as “I'm in” meaning I'm present, engaged, willing to participate, which is simpler and more comprehensive than “I dig it”, “I'm picking up what you're putting down”, “I'm down with that”, etc.

And then there is the complexity of the English language syntax itself as we've already discussed in the parsing of the phrase “Will you ....” (Team Tips - 9).

So it's probably fair to say that tossing the Core into the jaws of Google Translate won't do. As the British might say – I guess they are still the owners of English - “It's not on”, or “It's a non-starter”, or “It's not pukka”, or .... You get the point.

Since I have already appointed myself as “Professor Precision” in previous blogs regarding the use of words – sloppiness versus precision, and so on – what's to be done?

I could add to the confusion by recommending: “Huzzah chaps, best foot forward, carry on, hope for the best, ...”

But better,

is to do what Sergej, Algimantas, Annemarie, and lots of others have done and are doing: use the Core Protocols, particularly Ask for Help, to get suggestions. By engaging the global network of people using the Core, and digging into what the specific words and phrases of the Core Commitments and Protocols mean to each of us, we get enriched with the wisdom of others who are interested in the full meaning of what goes on when one uses the Core.

Are you pickin' up what I'm puttin' down?

Team Tips – 9 {Ramble on...}

It's a rainy day here, and I've pretty much caught up on work and administrivia, and since I've already fixed the hole where the rain gets in, my mind isn't kept from wandering...

This random? wandering includes the team challenges:

• maintaining momentum
• taking the Core Protocols literally
• mining the richness of the BootCamp learning
• why do bees buzz?

Maintaining momentum

As Vickie and I continue to work with groups that have attended the Simple Rules and Tools of Great Teams Immersion (aka BootCamp) inevitably individuals and teams find some aspect of the week long immersion into the delight of being useful – to themselves, and others – waning. Part of that might be running out of the adrenalin that typically is part of the experience. Sometimes it is physically demanding to stick at something. Perhaps we are experiencing enough personal change that our legacy behaviours and training start to push back. There can be disappointment that things didn't work as well on this part of the product as we remember it the last time. Or in the fun of trying many ideas we have lost track of a pattern for success – how we did it last time or how that felt. When we have reached the greener grass on the other side of the fence it can be difficult to remember how dry and withered the original side was.

Sometimes we just need to pause, take a collective deep breath, renew our support for each other, reconfirm our vision and alignments, and remember the wealth of possibility in front of us.

Taking the Core Protocols literally

If a particular Rule or Tool – Commitment or Protocol – is feeling like a burden, then we might be taking it too literally. Consider the problem of attempting to write down the paths to greatness. How I, or the next person, or the Core Protocols document, or the BootCamp Manual describe an experience will be highly variable. My view isn't automatically yours, your insights may not be mine, your words a different choice than in the document. If we are used to working with computing devices in black or white coding we have to remind ourselves that great teamwork is poetry, not bits and bytes. The algorithms of great team behaviour – the Protocols – are the result of years of refinement, including finding the best words. And if English isn't our first language, the difficulty is compounded. Take the example of “Will you ...” in Ask for Help. I've learned that this causes no end of confusion for translators. The intent isn't the future tense of the verb, but agreement to participate. Even the conditional “Would you” doesn't work.

The words are the best we have at the moment; the trick is to comprehend the intent and the spirit in the rules and tools, and keep practicing.

Mining the richness of the BootCamp learning

And if we digest each word in the Core, and read the BootCamp Manual many times, and think deeply about our week of immersion in the Simple Rules and Tools are we finished? I know for myself after 10 years of daily use and helping to instruct over 25 teams that I still learn something every time I read the words. And it is always fun to read some new book, a blog, a technique, a study that speaks to one single idea that is part of the thousands in the BootCamp experience as if that one alone was the answer. We live in a world looking for the seven habits, the four dashboard quadrants, the four agreements, the ten commandments, etc. Naturally authors and publishers are going to try to attract our attention to the silver bullets that make our lives wonderful. I just wonder how they would react to finding the wealth and depth and richness of BootCamp learning.

There is just so much there to explore, to try, and play with when one is dealing with the foundations of team communication and behaviour, the science of human systems dynamics.

Why do bees buzz?

Because they don't know the words. However, that doesn't stop them. I don't perceive that they analyze, I think they just get on with it. They do what works for them. When that flower doesn't work today they try another one. When a field or garden does provide pollen they repeat what works.

That's also what we have seen. Successful teams just get on with it. If this commitment or another helps, or this protocol or another adds value, then use it again. Or not. Try something else. Just get into the garden and smell the roses. And enjoy the honey.

Ramble on!

Team Tips - 8 {Stop the bus!}

The challenge for teams discussed in Team Tips - 3 was how to find members for a great team. But, sometimes, teams experience the opposite challenge:

How to DE-select members for a great team?

Some years ago Vickie and I assisted Toyota Technical Field Operations in the US with improving their processes towards providing more consistency and hence higher value. The boss, David J., was appreciative enough of our work to not only pay our invoice (always important), treat us with thoughtfulness and respect (a wonderful bonus), but to also provide a gift of a book (a special thank you).

The book was Good To Great by Jim Collins. Not only did this selection indicate his state of mind – the desire to transform his organization – it also became very important to me personally.

I've always been fascinated with this differentiation: Good vs. Great. While I'm fussy about precise definitions and clarity these terms are wide open. They can mean almost anything to anyone; however, they still easily allow us to distinguish companies, organizations, workgroups. Given a choice, we would at least want to work with Good ones, even better if we can find Great ones.

But what makes the difference between Good and Great organizations?

That is exactly the quest Jim Collins took on. One of the differentiators Collins and his research team found was this concept: Transformative executives

... first got the right people on the bus (and the wrong people off the bus) then figured out where to drive it.

The Simple Rules and Tools Great Teams Immersion (aka BootCamp) demonstrates the same principle: Have the team self select its members, then have them determine their shared vision of their future.

For me this is an instance where universal truths are determined by the connection of ideas from separate sources that provide us a fundamental insight.

Team Tips - 3 tackled the challenge of getting the right people on the team:

And just as the great teams work with a bias toward action instead of discussion, and incrementally building prototypes, and perfecting them, they can do the same thing in confirming new members. That is, work with them over a probationary period for everyone to confirm that the newly expanded team is functioning as well or better, and similarly the team is a good fit for the new member.

But what if someone isn't sure they're on the right bus, or decide it is the wrong bus for them? Or, the boss or the team decide someone should get off the bus? Just as being in a mediocre organization or workgroup isn't comfortable for some people, some aren't interested in being in workgroup striving for Great. And, a Shared Vision doesn't meet its potential if it is not truly shared.

Happily, the Core Protocols – the Simple Tools – provide lots of techniques to develop the desired synergy: Check In, Ask for Help, Personal Alignment, Investigate, Perfection Game, the Intentional Development Protocol for example. These all enable the high-bandwidth communication to explore ideas and develop a shared vision.

But this isn't mind control. We may just agree to disagree.

In the ideal situation, the team works with and supports the diversity of thought and dreams of each of its members. In fact that diversity – explicitly shared and explored – is the team's strength. All the intellectual diversity, aspirations, dreams, visions of greatness combine to produce a shared vision that is far beyond the sum or the multiplication of its parts. And each member's share of results towards that vision needs opportunity for hearing, investigating, support, and perfecting.

If one member of the team isn't aligned with that vision, then he or she needs room to explore that difference, work on their own, promote their alternative to the rest of the team. That may lead to a new product feature, a different development technique, a supporting element which still delivers team success.

Or not.

Perhaps that member is simply on the wrong bus. He or she then needs to take responsibility for themselves – part of the Core Commitments – to get off the bus. And the analogy works: this is not grabbing the steering wheel and yanking the bus off the road into the ditch. This is calmly, and with good intent, dealing with the difference which may lead to getting off. A quick stop, planned and controlled, that lets one off to catch a different vehicle.

And the team's responsibilities include being open to those differences, and where they aren't resolved, facing up to the fact that this is the wrong bus for that individual. If an adjustment can be made that makes the bus and its direction attractive to all, then make it. Otherwise, agree and accept that the bus needs to let someone off.

In the least ideal case, the boss has to recognize this situation and initiate the bus stopping. Here we can turn the slogan “The buck stops here” to “The bus stops here”. (Sorry; that really is bad!) The point is that we all have a responsibility to each other's success and well being, including helping them make a tough decision to leave us and join a different team.

This isn't about being right or wrong; it is about making a good decision. Having someone leave, then having to replace them and make up for lost opportunity is expensive in many ways. What a shame not to have, or use, the Simple Rules and Tools to get the best from each team member and make that bus trip Great.

How's your bus doing?

Team Tips - 7 {I, Robot}

Here's a challenge from some who have heard about, but not fully experienced, the Core Protocols in action:

Using protocols of behaviour turns us into robots.

Sure.

And the use of best practices in our work puts us in process hell, building quality into our results is expensive, rules inhibit creativity, great results require huge effort, and the earth is flat.

Just in case you haven't guessed yet, I have a bias. Yes, I am a fan of the Simple Rules and Tools for great teams – the Core Protocols from McCarthy Technologies.

And my bias is toward action, getting the best results with the least effort, being clear and explicit in communications, using standards of process to provide consistency of quality wherever possible, and promoting creativity and excellence.

If you have an uncontrollable urge to “roll your own” and be as free as bird with no constraints in developing and providing your particular product or service, then fill your boots.

I trust you won't be offended if I don't get into your car for the next trip across town, or get into the aircraft your company provides for travel. I'm just not that comfortable in blowing through stop signs and red lights because they are too constraining. Nor would I be thrilled if the pilots for my next flight didn't care to check the aircraft, do any pre-flight cockpit work, ignore air traffic control, and attempt the take-off from the taxiway with only fumes in the fuel tanks.

Yup; those dang protocols do inhibit things.

Like:

• using all the comfortable legacy behaviours that aren't productive and deliver low quality results
• having low bandwidth communication full of blather and unspoken assumptions
• spending more time on project management than on producing product
• getting tangled up in whining, complaining, and the Drama Triangle
• producing mediocre products or services so we don't achieve too much revenue

So if you are getting your very best results already, if you are sure there is nothing you can gain by trying a different approach, if you are completely, outrageously happy, financially secure, and have absolutely nothing else to offer the world, then please ignore the Core Protocols. Instead, please send me your own protocols.

The commitments from the Simple Rules and Tools include using the Tools – the Protocols – or something better. So I'm serious. If you have something better I need to know.

But in the meantime give the Simple Rules and Tools a try. How does any idea become a reality except by eventually trying it out and looking at the results?

Mainframe computers, became mini computers, became personal computers, became laptops, became hand held devices, etc. Computer assembly languages fostered compilers and interpreters, etc. Waterfall project management became more agile with – you know.

If you feel that protocols would turn you into a robot, then perhaps you need to be the one to show how they don't have to.

Of course you can also persist in ignoring the success of the Simple Rules and Tools, and sail your boat off the edge of the world.

Your call. :-)

Team Tips - 6 {Ouch - that hurts!}

Here's a team challenge from Christophe T:

I noticed we perform better as a team once we shared our fears, hopes, prides, etc. How can we go vulnerable to our team ?

Contrary to popular belief, and certainly my corporate training, we can't leave our emotions out of the workplace. As human beings it is not possible, as hard as we might try. Nor should we. Both Spocks in the latest Star Trek movie (2009) validate that learning.

We ask, for example, for people to leave their egos at the door as they enter the boardroom meeting. What we truly want is to reduce as much as possible the drama associated with our personal agendas. Irrational behaviour driven by extreme emotion often leads to behaviour well described by the Drama Triangle. In the Drama Triangle the roles of Persecutor, Victim, and Rescuer are assumed by those involved in the drama often moving between people as the emotional energy escalates. And that is not productive.

Nor is the emotion attached to grasping for our personal agendas, persisting to have things our way. This easily happens when each individual involved has their own vision of success as opposed to a shared vision among the members of a team. If I am stuck with “My way, or the highway” then we have a dictatorship instead of collaboration.

In fact we could say that without a shared vision a group of people is not a team; certainly not according to our definition in Team Tips - 1. More precisely we can say that such a group might have a common objective but no shared concept of what that actually looks like: what is the picture of the future once that shared vision is achieved.

Accordingly, to attempt to leave emotion out of the equation doesn't work. And you may have guessed already that we have observed that emotion plays an important role in team behaviour. For example, how did Christophe make the observation above? He knows that individuals on Great Teams use the Check In protocol – from the simple tools – to share their emotional state with their team.

Why do the best teams do this? 

• first: simply in order to provide that information – to make explicit what is implicit in my attitude at that moment
• second: to give the team some insight into what is driving my behaviours and actions
• third: to remove the energy from a dramatic scene of possible accusations and rebuttals inherent in the Drama Triangle
• finally: to declare to the team that in spite of, or along with, or because of that emotional energy, I am still ready to adhere to the Core Commitments and so be fully engaged in the team's activities.

OK?      Are you kidding? !!

At least that is often our instinctive reaction to such a foolish suggestion. I'm not about to be vulnerable to others that way, nor vulnerable in any other way, we say. I'm not interested in having the sharks smell my blood and attack.

But, I'm not talking about swimming with Great Whites. I'm talking about working with your associates, your team, who are all sharing their “vulnerabilities” to some degree as the level of trust between members grows.

If one is courageous enough to share emotion, to open the kimono, to expose his or her thoughts and then does get attacked – obviously or subtly – then, of course, that ends that, and a “team” allowing attacks should be left behind to feed on someone else. Sooner or later they will eat themselves.

Being vulnerable on a Great Team means being open to sharing and receiving information of any type, being willing to listen and learn, being willing to risk being wrong, being willing to change.

And that kind of vulnerability comes from great strength and power.