HSD 4

In the review of our 2010 Human Systems Dynamics Certification course {ref. last blog post}, F. and I paused at the following spots and commented or shared insights:

• the domain of Complexity Sciences is - well - complex! Or at the very least, very busy and full to the brim. F. counted 13 different fields of study on the provided list of Complexity Sciences, and many we agreed we couldn't explain: "nK Landscapes", "Autopoiesis", "Self-Organized Criticality", etc. They aren't on my lips as I wake up each day!
• nonetheless; now we have taken the course, we are experts on the field of Complex Adaptive Systems! 😁
• combining Complexity Sciences and Social Sciences (more familiarity here - augmented by Twitter and FussBook - LOL) we get Human Systems Dynamics as the intersection. So if you are alive and interacting with other humans you are in the HSD game.
• Simple Rules (example in the previous post) are important initial conditions for every productive behaviour toward a desired result. F. added the insight that to “Attend to the part, the whole and the greater whole” (4^th. rule in the list for the HSD Institute) one also needs to attend to oneself. This is like the maxim I've used in our teamwork sessions: that in an in-flight emergency, one needs to secure their oxygen mask first before trying to help others. So in any situation where help is required or to be given, self-care is important (health, wellness, adequate sleep, minimal stress, etc.). Self-care is also recognized as an important virtue in the teamwork protocols - the Core - from McCarthy Technologies as described in my blogs Team Tips. And even more alignment of best practice occurs with the Personal Commitments which are the introduction to the Core. These are also the Simple Rules which govern the best in team behaviours, including my favourite: “Don't do anything dumb on purpose.” (The only discrepancy between the two bodies of knowledge is that HSD recommends six rules or less - to keep it simple. The Core has a longer list of Commitments.)
• then we got to the definition of a Complex Adaptive System, which is a biggee! F. was struck by the words “freedom to act”: do the values of, and accepted behaviours in, an organization really allow freedom among the individual agents? For example; if one acts outside of the framework then they don't belong in that system, or can be invited to leave the system, and therefore are restrained. (F. finds more unpredictable behaviours in government than in private companies because they are not as focused on the company's goals). Groups often don't share a vision and so act randomly; however, when functioning more as team they know each other better and listen better and act more uniformly. Perhaps the possibility of “freedom to act” depends on using rules to create the environment for freedom - like a country's constitution. We concluded that rules of behaviour on teams leads to greater freedom and creativity; like agreeing in advance to allow unpredictability. My attention was on “in unpredictable ways” (like recent elections). My memory is that it is the unforeseen variety of possible outcomes that makes the system complex. Also, the difference between “complicated” (like a modern, working, internal combustion engine) and “complex” is that complicated things can be designed, built, re-assembled, whereas complex things are unknowable as a whole. We can't build democratic election results. (We do know how to complain!)

We paused at that point and agreed to continue the review at our next meeting.

More to come.

Team Tips - 24 {Protocol Check - What do you think?}

Friday Brag (borrowed from my sweetheart Vickie)(steal from the best):

Highest number ever of page views of my blog of my last post “Team Tips - 23”. Yay!

You can now say: “You did that?”, and I can reply: “I did that!”

I also received some complimentary comments, and an offer of a reply to my Ask for Help. “All good” as they say locally.

I'm also receiving the highest volume of email spam, which probably means the evil bots are mining their way from the blog to my website and my supposedly “un-bot-able” email address. The offers of deposited funds, court action, lewd (I'm assuming) photos, follow-ups to fictitious requests for business proposals, fake billing, etc. are actually quite creative. One even claims that I've been caught speeding on a traffic camera - as if they existed here. If the spelling and grammar weren't so atrocious one could be tempted to pay attention to them. And if they didn't have the huge red warning flag of the attached zip file.

Following the line of the last post, it would be nice to scream “Protocol Check” at them.

But that isn't at all the point of Protocol Check.

While it would occasionally feel really good, and satisfying, and therapeutic to yell at someone who gets a Protocol wrong, or breaks a Commitment, that's not what Protocol Check is for. It's really a learning tool.

If I bury an Ask for Help inside a Perfection Game, or Check In angry about someone's behaviour without asking their intention, or just generally get the Protocol steps wrong, that's a great opportunity to gently, quietly, compassionately have a conversation with me about the Protocols in a spirit of shared learning.

It might go:

• Paul, Protocol Check.
• Oh? 
• I'm wondering what your intention was in that Perfection Game.
• Err .... I think I was looking for some information.
• OK; let's both look at the Core Protocols and see what it says about the Perfection Game. Were you really trying to Ask for Help?
• Hmmmm. Let's have a look. Maybe there is a better way than what I did.

In this kind of interaction both parties, adhering to the Commitments, are interested in discovering how the Protocols in question work, and the best way to use them.

For me, it is important that both parties are open to learning and teaching simultaneously. Alternatively, the risk is that one party becomes the “Protocol God” and rains fire and brimstone down on the transgressor.

Even when, as occurred in one of our BootCamps, a participant had the Protocols virtually memorized, and became Mr. Protocol Check. Happily, it all became fun: we had a Protocol Check dance, and phone ring tone imitating his specially exaggerated Protocol Check voice. But he followed “Rule Number 6” (Art of Possibility, Zander & Zander) and it was hilarious learning for all of us.

So while no one objected to my licence in writing about “screaming Protocol Check” last time, that's not how it is done.

Nevertheless, the ring tone may still be available.

Team Tips - 21 {Ouch, that hurts - Part 1}

You've been to the doctor, right?

There's always the moment when the doctor or nurse has to give you a needle, or draw blood, or otherwise inflict some unmentionable procedure on, or in (ew), some unmentionable part of your humanity.

That's when you hear the phrase:

This won't hurt a bit.

Just like when a “best friend”, or business associate, or the boss at performance evaluation time thinks you really need to hear some feedback, some constructive criticism. After all doesn't everyone want to improve? See their mistakes and learn from them? Make themselves a better person?

This won't hurt a bit. This is for your own good!

It's a wonderful idea if you are the “helper”: being a good friend, advising someone with your pearls of wisdom. But it's not so much fun being the “helpee”. Particularly when it is “inflicted help”. (I think every instance of feedback should be automatically matched in strength and duration with a return message; not as defensiveness or revenge. Just to return the favour.)

Ah, Reeves, you just don't want to hear criticism. You just don't want to be a better person. I'm, like, trying to help you here!

Hmmmm: right; wrong; wrong.

Right: I don't want to hear criticism. I may not respect the source; I may not like the intent; and I've already got my own imaginary critic whispering in my ear.
Wrong: I do want to be a better person. Returning as a dung beetle isn't at the top of my list (see previous post).
Wrong: You really aren't helping. If you really intended to help you would ask me how I would like to receive the “feedback” you have for me.

What I would like you to do, when I ask, for the topic of concern:

1. Tell me how I'm doing numerically, roughly, on a scale of 1 to 10. 
2. Tell me what you like and think I should keep doing 
3. Tell me what I should do differently, or add, to make the score a perfect 10, from your point of view. 

Now:

• I have a quick idea of how I'm doing: 10 out of 10 means I'm good for now; 1 out of 10 means you have lots of improvement ideas for me. 
• And I know what things you think I should continue doing. 
• And, best of all, I know what you think I should do more of, or do better, or add to my game. 
• The final component is that I can decide to use, or not, any of your suggestions. Nothing inflicted. 

In fact, this can be seen as a game. We could even call it, say, the Perfection Game. Crazy! 

It could be part of the Core Protocols. 

Oooops; Jim & Michele McCarthy already thought of that.

10 /10 from me.

Team Tips – 19 {Ask, and ye might receive.}

Back when I was a kid my parents made me have a bath every Saturday evening - whether I needed it or not. I'm not kidding! Imagine. 

So here's a blog post whether anyone needs it or not.

There's no evidence that anyone reads any of my posts, but absence of evidence is not evidence of absence - in this case. Maybe Google Analytics forgot about me, and didn't check to see if someone has been peeking. Maybe the feature that allows comments at the bottom isn't working, or is too complicated for people to bother, or requires a secret handshake and the root of minus one for identification.  Maybe there are so many people trying to tell me that they live just for my posts that they are swamping the internet. Or have died waiting.

It was been a while since my last article, (Me Mum is fine, by the way, in spite of all previous indications to the contrary): some 23 months and 13 days ago if you like hard data.

So for all you billions of fans out there, here's a poke to say I'm still here, still kicking, still training and consulting and helping people be their best. When they really want the help, that is.

I've made lots of offers with few takers. If we're talking evidence, the data that there have been few takers seems to reinforce the human condition that we all love to forge ahead independently without asking for help because that's the err, umm, adult? thing to do. Our mature egos balk at looking like, or admitting, there might be something we don't already know, or are proficient at, or with which we could use some assistance.

Of course, how do we know help is available, or that the helper really knows something we don't, or can actually explain it so we can learn something, or might actually be useful and not waste our time when we are busy struggling? How do we even know what we don't know?

Welllllll - we don't. Unless we ASK.

Asking for help - about anything - is still one of the best kept secrets for success in the world.

That's why it is the “secret sauce” in the Core Protocols. Why it is the primary behaviour to learn to develop and to be part of a great team.

And you don't have to wait for Saturday evenings to do it. It works anytime, all the time.

Team Tips – 18 {A little cheese with that WHINE?}

Got a phone call from “me Mum” the other day. She was sad. The reality of having to finally put the family home up for sale had just hit her.

After telling me how she felt, she apologized to me for “whining”.

I was struck that at her 95 years of age, having dealt with WW2 in England, emigrating to Canada with a newborn (me), having no friends or family in this part of her world, etc., etc. that this was the first time I could recall her “whining” (as she put it).

It made me think of all the stuff I see in Twitter, and on Fussbook, and in the news where folks are continually, relentlessly, indiscriminately moaning and complaining and fussing and wailing about the latest pin prick in their lives. That's what I call WHINING!

And my reaction to all that stuff is: Ya want a little cheese with that whine?

Sure, there's lots one can complain about, and no shortage of bad news. The talking heads are paid to provide it, lay on the drama, get the audience worked up, introduce a little anxiety, move us to DefCon 3.

But seriously folks. How about a little perspective? A little dose of proportion? See - now I'm whining!!

We live in a world of abundance. In spite of all humanities mistakes we're still here on this amazing space ship. The sun appearing every day is cause for celebration.

And there are tools in the Core Protocols to recognize the problems and see what can be done with them (like Perfection Game.) Of course it's a lot easier to point out the concerns than to figure out a remedy or solution, and many times we would just rather complain.

That's also where the Core Commitments help too. For example:
 1. I commit to engage when present .... (b) To always seek effective help.
 3. I will use teams, especially when undertaking difficult tasks.
 4. I will speak always and only when I believe it will improve the general results/effort ratio.
 5. I will offer and accept only rational, results-oriented behavior and communication.
 8. I will seek to move forward toward a particular goal, by biasing my behavior toward action.

So - surprise, surprise - we CAN make choices. We can choose to complain, AND choose to do whatever we can about it.

And I figure if me Mum can get on with it, then I'd better too!

Team Tips – 16 {An abundance of Angels}

When I was a District Manager of Customer Service at Xerox Canada one of my managers told me she had seen an Angel. The spiritual kind, the God's Helper kind.

Lizzie (almost her real name) was a professional, logical, coherent, mature adult who was a very “by the book” manager. I realized as she talked about her Angel experience that she was taking a big “career limiting” risk by sharing this with me, her corporate boss. Happily that meant that she trusted me enough not to judge her as crazy, or rat on her in to Human Resources.

I'm glad to say I listened quietly, kept my skepticism to myself, so she could share this secret. My task was to support her, not make things more difficult. In my mind I could conjure up some extenuating circumstances: her mother had just died, her husband was unusually introspective, she was stressed with a tough job.

Nonetheless, it was just plain weird in our cultural circle to admit to seeing Angels.

And I'm reminded of that situation when Vickie or I encounter some people's reactions to the Core Protocols or BootCamp.

We get:

• these concepts can't work, won't work, aren't feasible, won't be accepted
• the Core Protocols are too ... (insert negative adjective here)
• people won't use these Simple Rules and Tools
• people need to build their own
• there's no means to enforce compliance
• this is dictatorial
• people won't share emotions
• groups need facilitation
• we can't spend the time to come to BootCamp
• and several billion more

What's fascinating to discover, when a conversation is possible with an objector about any of these reactions, that the objector hasn't actually read the Core Protocols document, or has not attended a BootCamp, or seriously tried to investigate this material. Nor does the fact that thousands of people have found it helpful over the 15+ years that teams have been generating these ideas seem to make any difference to them. Or that an investment of five days is worth the value of changing one's life.

So what is preventing the level of understanding that all this might be genuine?

One possibility is fear.

When we talk about the potential for BootCamp to be a life changing experience and to effect your success for the balance of your life, that can be very scary. We know that some people don't really want to challenge their belief systems, or to deal with their true potential.

So when objectors deny the 15+ years of BootCamp success is possible, we just listen quietly, share the facts we have, and leave it at that.

If a world of abundance isn't what you want, if you don't want to realize your potential, or reach for the sky, then BootCamp is not for you.

You probably just aren't ready for a universe of possibility, or Angels either.

On April 21^st. Vickie Gray and I will conduct another Great Teams BootCamp. The details are at http://events.r20.constantcontact.com/register/event?oeidk=a07e6w31ovda52cdbb5

Team Tips – 13 {What's in a name?}

On April 21^st. Vickie Gray and I will conduct another Great Teams BootCamp. The details are here.

You'll notice right away we are calling this one a “Creating Time BootCamp”. Over the years since 2003 that we've attended, helped at, or held a Camp ourselves we've always debated with ourselves what we should call each session.

Jim & Michele McCarthy coined the original name of “BootCamp”. The common explanation for this choice is that over the week each attendee adopts new “software for their head” (taken from their book of the same name). So then everyone “boots new software” - using computer jargon. But this stuff isn't a computer Operating System. It's the commitments and protocols that make up the CoreProtocols that have emerged from teams being great. And adopting these best practices gives you a new way to operate in the world. Your own new mental operating system.

So if you're into software, or are in any tiny way computer literate, you get the idea.

But.... We've also had parents call us that wanted us to straighten out their teenagers. They hoped we were running a Marines style drill Bootcamp. And of course if you are leery of the military, or drill sergeants, or pushups in the rain, then the name BootCamp is not so exciting.

Then we got keen on “Results Camp” because the whole outcome of BootCamp is to generate a team that knows how to produce great results every time.

And I like “Great Teams Camp”. After all, the Core Protocols emerged from great teams in action and have been handed on to help others become a great team, and it's the team that produces the great results, and ...

Later, Vickie and I found out about Human Systems Dynamics, a whole discipline generated by the doctoral research of Glenda Eoyang. Glenda's certification course taught us about the importance of simple rules and tools. And bingo! We realized that the Core Protocols package was just that. The commitments were simple rules for teams to follow and the protocols were tools of behaviours for them to be great.

Now we had the name “Simple Rules and Tools Camps”.

Then we conducted a BootCamp where the team was astonished by the time-dilation effect. They were getting much more accomplished much faster than anticipated. That lead to Vickie's first book: Creating Time.

So as you are signing up for our next session above, you'll see it's a “Creating Time BootCamp”.

And when you get your manual once you've registered you'll see it's called the “BootCamp Manual”.

If this is all confusing, don't worry

Under the covers, it's still the same fabulous content. The week is your time to immerse yourself in the best understanding there is of what makes great team work. And you get to experience it to produce a great product. Yourself. Sweet!

A rose by any other name ...

Team Tips – 12 {Lean, mean, machine}

One part of my consulting and training life deals with IT Service Management. Those are the principles and practices associated with the view that an IT department is a provider of services to its business counterparts which improve the value and potential of business outcomes. Usually good IT Service Management is achieved by adopting best practices from a framework such as CobiT or the IT Infrastructure Library (ITIL).

In fact it was the need for teams of IT staff to adopt and adopt ITIL Service Management processes for their own use that made me realize that what I thought I knew about team building and team work was truly inadequate.

Let's get a group of people, toss them in a boardroom, and call them our process development team.  -Great idea! 

Let's use all the classic organizational methods to facilitate their working together, making decisions, building trust, becoming productive.  -Yes!

Except it very rarely works.

Similarly the Agile software development methods and Scrum in particular depend upon “self-organizing teams”. But the question remains: HOW do we build a self-organizing team?

Hold that thought.

A key element of the ITIL Framework is the principle of continual improvement drawing on W. Edward Deming's work which was foundational to the entire Quality Management world. In that context you might have heard of the Toyota Motor Corporation?

Toyota's focus on continuous improvement breaks down into three basic principles:¹

• Challenge: Having a long term vision of the challenges one needs to face to realize one's ambition (what we need to learn rather than what we want to do and then having the spirit to face that challenge). To do so, we have to challenge ourselves every day to see if we are achieving our goals.
• Kaizen: Good enough never is, no process can ever be thought perfect, so operations must be improved continuously, striving for innovation and evolution.
• Genchi Genbutsu: Going to the source to see the facts for oneself and make the right decisions, create consensus, and make sure goals are attained at the best possible speed.

Respect For People is less known outside of Toyota, and essentially involves two defining principles:²

• Respect: Taking every stakeholders' problems seriously, and making every effort to build mutual trust. Taking responsibility for other people reaching their objectives.
• Teamwork: This is about developing individuals through team problem-solving. The idea is to develop and engage people through their contribution to team performance. Shop floor teams, the whole site as team, and team Toyota at the outset.

Another call for team building and effective team work.

Hold that thought, too. Please.

The last thread in this tangle (for this post) is the growing interest in applying “Lean Manufacturing” principles (from companies such as Toyota) to IT organizations. This prompts IT groups to look at and study Six Sigma concepts, and “Lean IT” all of which centers around measuring defects in service delivery and reducing waste (muda).

Again from Wikipedia re: Lean Manufacturing, the original seven muda are:

• Transport (moving products that are not actually required to perform the processing)
• Inventory (all components, work in process and finished product not being processed)
• Motion (people or equipment moving or walking more than is required to perform the processing)
• Waiting (waiting for the next production step)
• Overproduction (production ahead of demand)
• Over Processing (resulting from poor tool or product design creating activity)
• Defects (the effort involved in inspecting for and fixing defects)

• Later an eighth waste was defined by Womack et al. (2003); it was described as manufacturing goods or services that do not meet customer demand or specifications. Many others have added the "waste of unused human talent" to the original seven wastes.

Anyone with any experience in an IT operation of any size will recognize most, if not all, of these problems occurring in managing the IT infrastructure, in group interaction, with programming bugs, and poor communication with the business customers. So I get asked if I can help here too.

Now what?

Behind the first door we have the need for self-organizing teams. Behind the second door the requirement to be continually improving. Behind the third, the quest to reduce waste in our organizations.

What if we could address all three of these issues? What if we could open all these doors and not get eaten by the tiger?

Nah! Can't be done! Rubbish!

Well ...

Check out the Core Protocols as a means to building self-organizing teams, dealing with all the questions of waste, and continually improving your results and satisfaction. And more.

When people start to notice your results with these simple rules and tools, and you become famous because your team is a Lean, Mean, Machine, just tell them you're a genius ... because you were smart enough to try the Core Protocols.

1 From: http://en.wikipedia.org/wiki/Lean_manufacturing

2 Also from: http://en.wikipedia.org/wiki/Lean_manufacturing

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.