Team Tips - 23 {Protocol Check - on myself}

I've been thinking about my last post of Team Tips - Team Tips 22 {Ouch, that hurts - Part 2} - and that no one responded to my challenge.

And how that is actually a good thing. Weird, eh?

I know that 20+ folks looked at the blog page, and so it is reasonable that some even read it. But not one comment.

Now, absence of evidence is not evidence of absence (or more precisely, is not evidence - period.) Someone out there may be busy pondering my questions, researching articles, sharpening their cyber pencils, drafting an essay, getting copy editor revisions, and so on. Or not!

However, no response is perfectly reasonable, because I broke the rules.

The Perfection Game is one of the Core Protocols. I like the choice “Protocols” because it implies following a procedure, a set of steps. In other words, doing it - the Protocol - properly. After all, if you want to do things well, then once you have a successful method follow it! At least until a better procedure shows up.

So I shouldn't have hidden an Ask for Help inside a pretend Perfection Game. Sure, I presented it as “an example” to skirt the fact that you didn't actually ask me to Perfect your reading of the post. But a donkey having been through the car wash is still a donkey.

I should have just Asked for Help directly.

All of you who didn't comment - all 100% - congrats! You could have gleefully screamed “Protocol Check!!” and pointed out the error of my ways. You could have asked me for an intention check to clarify my purpose, and then with that clarification from me then gleefully screamed “Protocol Check!!”. Or you could have ignored my inappropriate behaviour and walked away, as the evidence might indicate you did.

The point of having these atoms of proven successful group behaviour - the Protocols - is that everyone in the group knows them, how to use them, what to do if they suspect improper use. All of which set up the best known initial conditions for successful teamwork. If you would rather use your own version of the Protocols, or not use them at all, be my guest. Let me know how that is working for you.

In the meantime, let me Ask for Help properly:

• Will you use the Comments area to note some [employee] performance examples for which the Perfection Game doesn't seem to work; and
• when using the Perfection Game as your performance management method, a simple scheme to allocate merit increase money if it must be based on job performance?
  

Management 11

A very special person is lining up his first management assignment. 

He's been poking at the idea for some time, even tried for an opening in his organization a while ago. Another opportunity has now come along and we've been talking about it: what the current situation is, is he interested, is he ready, what are the implications, etc., etc.

These conversations are wonderful for me because I love sharing what I've learned and the results. I'm a strong believer in the pilot's adage: Learn from the mistakes of others, because you won't live long enough to make them all yourself.

So after an ask for help from him to prepare for this new opening, I've been thinking about how best to be helpful. How do I usefully condense 20+ years of management learning and experience? It suddenly occurred to me that I had posted thoughts on management before, and they might be useful. So the list below is an index of management topics from which anyone can pick and choose items of interest.

Management

• Management 1: The prospective manager dilemma
• Management 2: Precision of terms
• Management 3: My manager is a bozo
• Management 4: Some definitions, to have the correct discussion
• Management 5: My manager is my best customer?
• Management 6: Managing my manager!?
• Management 7: Jobs vs. Roles
• Management 8: Fun with role play
• Management 9: Management training?
• Management 10: Coaching and mentoring and asking for help

And just in case you thought you would see more on "leadership" in these, there are lots of posts on Leadership starting with:

• Leadership 1: Leadership can come from anywhere

through to 

• Leadership 13: Smart leadership

(If you want to scan through all the Leadership posts, just look in the Archive list (middle right), select an arrowhead beside a date to find the desired topic. (Google organizes by date instead of topic.))

Now the fun begins! What does he find most interesting? What did I leave out? Do these posts help him get results?
Stand by!

Team Tips - 22 {Ouch, that hurts - Part 2}

(For the folks just switching from a code window)

BEGIN

IF: you've read “Ouch, that hurts - Part 1”

THEN: jump to END

ELSE: read “Ouch, that hurts - Part 1”

END

So now you know how the Perfection Game works. It's one of the Core Protocols. It could be called the Perfection Protocol, but that could be problematic because we are only human and as much as I would like to improve I'm not counting on getting to complete perfection. I'm such a slacker.

Besides, it really is fun as a game: Do something, Perfect it (Caps meaning Perfection Game steps), do it again, Perfect it, etc. Kids love it. I'm glad I'm a kid.

When I wasn't a kid, I had this very serious corporate manager job being a very serious corporate manager and eventually became a very serious corporate manager of very serious corporate managers. One of the duties of being a very serious corporate manager was to evaluate employee performance, following a very serious corporate policy and filling in very serious corporate forms describing and scoring all manner of employee performance and behaviours.

I'm sure you know what I'm referring to:

• describe the employee's performance over the previous period
• highlight job responsibilities done well, or requiring improvement, for all 99 job duties
• from the following exhaustive sets of descriptors, choose characteristics that best describe the employee's attributes, and those requiring more focus
• etc., etc.
• provide an overall summary score out of 5

All of this is, at best, a well intentioned effort to provide guidance to the manager and to standardize a process that ensures the employee gets some information on their performance in a scheduled, repetitive manner.

But, at worst, it becomes a way to find enough sugar to cover the medicine of enough negative concerns to keep the final score centered on a bell curve. If everyone is regularly at a 4 or 5 out of 5 then they are over performing in their job, ready for promotion, and candidates for salary increases (when there is merit increase money available.) And as a boss, you didn't do it right.

That becomes a mess.

It is stressful for the manager, stressful for the employee, each jockeying for position. Feedback becomes a negative experience even though it should include amplification information as well as dampening. The score keeping becomes a case of “1 aw-shit cancels out 10 attaboys”.

Alternatively, imagine how pleasant and useful the Perfection Game plays out:

Boss:
"Continue doing this, stop doing that, add these things, and I'll be happy."
You: (Realizing the boss doesn't have his facts right, or missed some of your best moves)
"You didn't mention the amazing thing I did 6 months ago; do you still want more of that?
(Realizing the boss is asking for you to do something you are currently doing)
"I can certainly do that." 
(Realizing that you don't understand what is wanted) 
"Happy to give it my best shot; how would it look when I do it?" (Collecting requirements and a definition of “done”.)

As the boss, I don't have to wrestle my way through negative feedback, finding the right words, trying not to hurt feelings, struggling with cultural or maturity differences, etc., etc.

And if the employee follows all the Perfection Game steps and decides to ignore my suggestions, then I am already prepared for the next round - rinse and repeat - until one of you has had enough and you part company.

Now that you have read this far, here's some Perfection for You (provided as an example since you didn't actually ask for it):

• 8/10
• I like that you persisted, put up with my quirky humour, and got to this point
• For a 10, use the Comments area to note some employee performance examples for which the Perfection Game doesn't seem to work; and/or, when using the Perfection Game as your performance management method, a simple scheme to allocate merit increase money if it must be based on job performance.

(Back to your code window - I hear the boss coming!)

Blog History {Who'd a thunk?}

Since I just released a new version of my website, I was poking around making sure all the links worked which led me to my Blog - this one - and a shock.
 
I've made 60 posts since the first one in 2008!

Some I think aren't too bad and some are just horrible. Either way it was fun to scan through them, and that made me wonder if there was an easy way to compile a summary list.

I haven't found an easy way to do that, but I did find that Google can report the ones that were most popular - at least the top ten. They are in order below.

The astute observer will note that interest in 2011 is no guarantee of readership in 2012 and 2013. As for the desert from 2008 on - the less said the better.

The blog layout options don't make it easy to pick out interesting titles either because you actually have to select the month in the Archive list on the right to see them - not so user friendly.

That's why I've added the opening paragraphs in the list so you at least get that.
If you have some improvement thoughts, or any requests, let me know. The good news from my passion for improvement and reading is that it is great fun to post ideas in the big cyberspace library in the sky.

Here's the top ten:

Effort vs. Results on a Great Team from April, 2011

There's another interesting and important exchange underway in the Core Protocols Group forum (http://tech.groups.yahoo.com/group/TheCoreProtocols). This one is about the relative merits of effort versus results. [Note: this forum is now the Facebook Group "The Booted"]

Agile vs. ITIL from March, 2011

A little while ago an associate in the Agile Coaching community, Yves Hanoulle, asked me about the contention often raised that Agile software development practices don't mesh with the ITIL Framework.

Team Tips – 12 {Lean, mean, machine} from January, 2013

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).

Team Tips – 16 {An abundance ofAngels} from April, 2013

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.

Team Tips – 10 {A word with you ...} from October, 2012

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.

Team Tips – 13 {What's in a name?} from February, 2013

On April 21st. 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.

Team Tips - 7 {I, Robot} from March, 2012

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.

Software for Your Head #4 from March, 2011

Finishing the project team kickoff meeting story from Software for Your Head by Jim & Michele McCarthy.

Team Tips - 4 {Is this for me?} from November, 2011

Another challenge for teams comes from Jose R.:
“Can everybody work in teams?”

Team Tips - 5 {Trust me!} from November, 2011

We're having a snow day; first of the season.
So it's a good time to tackle this challenge for teams from Jose R.:
"How can you recover trust inside a team that has lost it?"

Team Tips – 15 {Our soufflé fell!}

I had another post lined up for Team Tips - 15 but then this gem popped up this morning on Twitter:

from @LeaderChat

BEST BUY: We Ended ROWE/Work From Home Because It Defines Leadership as 100% Delegation.... ow.ly/jrDjp By @kris_dunn

I was intrigued because a Results-Only Work Environment (ROWE) is a kindred spirit with the learnings and experiences gained from the immersion in the CORE Protocols at BootCamp.

So I followed the url above to Kris Dunn's post:

[the hr Capitalist]

http://www.hrcapitalist.com/2013/03/best-buy-we-ended-rowework-from-home-because-it-defines-leadership-as-100-delegation.html

March 21, 2013

BEST BUY: We Ended ROWE/Work From Home Because It Defines Leadership as 100% Delegation....

Kris ends his post with:

Take a look and soak - it's an interesting conversation. My gut tells me that the delegation angle is window dressing, and when times are bad, people want butts (plural!) in seats.

In this way he leaves the door open for debate on the reported statements on ROWE by the CEO of Best Buy, Hubert Joly, and connects us to the related post by the creators of ROWE:

Cali & Jody Blog

http://www.gorowe.com/blog/2013/03/18/beyond-telework/rowe-creators-set-the-record-straight-best-buy-ceo-doesn-t-understand-rowe/

ROWE Creators Set the Record Straight: Best Buy CEO Doesn't Understand ROWE

It’s disheartening to us that Best Buy's CEO, Hubert Joly, complains of his ideas being “misconstrued” and then in the same breath completely misconstrues another important idea. That idea is Results-Only Work Environment, which up until a few weeks ago was the innovative work culture of Best Buy’s corporate offices.

Jody Thompson continues to explain some myths about ROWE which you should read for the full story. To summarize, they are:

Myth #1 - ROWE is delegation

Myth #2 - If you can see people at the office, you know they’re working!

Myth #3 - ROWE is a one-size-fits-all program

And Jody ends with:

Either Joly truly doesn't understand what ROWE is or he doesn't know how to lead in a ROWE. Either way, he just doesn’t get it.

Fascinating, Captain!

Taking these posts at face value, and assuming Hubert Joly is a smart person with good intent, we have a conundrum.

• Perhaps he is misinformed about ROWE, or it's mechanics, or how it has been implemented at Best Buy
• Perhaps he has a bad speechwriter / press agent, or can't read
• Perhaps he has been misquoted, or might plead the Nixon-ism: “Those statements are not longer operative”

Given his quoted remarks it's clear he doesn't understand delegation. When he says no one should delegate the task of building a brick wall to him (because they wouldn't like the result) he seems to not understand that

• delegation of responsibility is only viable when the “delegatee” can produce the desired result, OR
• (and he should surely understand this as the CEO) when the “delegatee” can further delegate the task to a bona-fide bricklayer

Does Best Buy regularly designate responsibility for, say, accounting audits to their facilities people, or IT services to their logistics experts?

And Mr. Joly needs some assistance with the concepts of leadership. His description of possible leadership styles as “coaching, motivating or directing” are more accurately descriptions of parent-managing.

But we started with the belief that Hubert Joly is a smart person with good intent. Hmmm. Reductio ad absurdem?

He at least needs some help. A good executive coach might work with him on his integrity so that he can honestly say: "I don't like our implementation of the ROWE concepts. It hasn't worked out like I wanted here at Best Buy. We are changing direction and asking all HQ employees to work in the office." (BTW: that's leadership - at least in the traditional organization)

Perhaps even: "Butts in seats is good enough for Yahoo so it's good enough for us."

Whichever way you look at it, the chef shouldn't blame the recipe when he doesn't follow it.

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 - 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 - 4 {Is this for me?}

Another challenge for teams comes from Jose R.:

“Can everybody work in teams?”

I am so very tempted to reply with a sarcastic answer, except that wouldn't be helpful, and this is a really tough challenge.

Some people I have observed over the years just don't seem suited to work with others at all. I leave it to psychologists to analyze and guess why. But most of us have encountered those who simply like to work independently or even have a difficult time making conversation with one other person, let alone a team.

In fact, some people, like myself, chose to work in fields like computer science to reduce the amount of time needed to deal with other humans, their emotional states, their foibles, etc., and maximize their time dealing with the pure, rational, logic of computing.

And some, like myself (again! ?), find themselves so disappointed and de-motivated working in organizational groups where there is no clear vision, objective, approach, sharing of ideas, focus on results, etc. that they can't function effectively. In those kinds of organizations I am un-employable (and have the severance packages to show for it.)

So if we view the challenge as “Can teams provide a work environment for everyone?” we can see why team building, team work, team success is difficult for lots of organizations and anyone who is stuck on those teams.

For those teams that can demonstrate success through the delivery of great results on time every time*, we can revert back to the original question and ask: “Can anyone at all become part of that team?”

And unless the product or service that your organization delivers to its customers can be built by one person only, never interacting with anyone else, we need to address this challenge.

What we have found in our work with teams using the Simple Rules and Tools of Great Teams* is that no, not everyone will want to be part of a given team's shared vision, and adopt the rules and tools to deliver great results. Some just aren't ready to step out of their comfort zone, give up their previously learned models and behaviours for mediocre results, accept the responsibility and accountability to be their best. This isn't a judgemental statement; it's just fact.

We all become ready to be our best in our own time, at our own pace. Unfortunately, in my opinion, some run out of time before they get to a decision.

What we have also found so far is that the best way to know if one IS ready to be part of a team is to attend the team building session known as BootCamp from McCarthy Technologies. There one is immersed in the Simple Rules and Tools of Great Teams and can discover for themselves if they are ready, and what it means to be part of a great team. As covered in the previous posts, this also allows the boss to recognize which people are creating which team, and for an existing team to determine their members.

Another choice is to join a great team for a probationary period to see if one is up to the challenge. An important team work practice is prototyping: building versions of the required product or service to be “perfected” (using the Perfection Game tool). Similarly, a probationary period for a new member is a use of prototyping.

Being part of a team isn't about group hugs or being in constant agreement with the rest of the team. Sometimes independent behaviour by a team member is the best choice for the team in a particular situation. Further, if the team's shared vision isn't shared by someone, then it is best that they leave the team – to possibly form their own team.

So if you are one of those extremely rare people who never needs to work with anyone else, you don't have to concern yourself with team work. Happily for the rest of us there are really excellent options.

Click here for your own copy of the Core Protocols – the Simple Rules and Tools of Great Teams.

To add your team challenges to the list please add a comment below or message me @ReevesResults on Twitter.

Team Tips - 3 {Who gets to play?}

The next challenge for teams I have chosen is from Ben N.:

New member ?

“How to select members for a great team?”

The smartest way we have seen people get selected for a team is to have all potential team members attend the team building workshop: Simple Rules and Tools for Great Teams. This session is also known as BootCamp by the originators of the event, Jim and Michele McCarthy, and is based on their book Software for Your Head.

By inviting potential team members to participate in this workshop the boss* is setting some initial conditions which help define the basis for the team. (* see Team Tips - 1)

1. The workshop is NOT mandatory. Accordingly, the people who attend are only those who want to be there; hence, want to be part of the team
2. By participating in the session attendees are immersed in the Core Protocols – the Simple Rules and Tools. This helps everyone involved get to experience and practice these foundational behaviours for great teamwork, and some will invest energy in this learning and thrive in it, and some may choose not to
3. During the session, the team members develop a Shared Vision for that team. If someone doesn't wish to share that vision they are free to follow their own dream and so move out of the original team
4. The team members that find that the Core Protocols as used by the team deliver on the promise of high band-with communication, fast decision making, the development of trust, a focus on results of high quality, etc. become their own self organized team. Any attendees who don't are again free to not participate, possibly forming their own team working in other ways

The boss gets the result: a self organized team, following Simple Rules and Tools that are repeatable in any situation, scaleable for any size of group, reliably working to produce the best results on time every time. Any attendee who chooses not to be part of this, effectively self-selects themselves off the team.

Our experience with this approach is that:

   a) bosses have used the session to “do the hiring”. That is the immersion becomes the hiring process, and the check for personality chemistry, and the probation period, and any other scrutiny one wishes for in a hiring process. (And the cost of a “normal” personnel search, interview and hire, and possible failure after three months of probation more than pays for the session.)

   b) or alternatively, they have seen after the session who should be, or remain, “on the bus” [Good to Great, Harper Collins, Jim Collins] and can identify those who don't wish to work on the team using the Core Protocols. (Again this saves considerable energy and cost dealing with employees who have turned out not to be a good fit.)

Team

The quick answer then is: Have the team select their own members.

If the team already exists, then they are the best people to determine who will fit well on that team, who can aspire to the team's shared vision, will use the team's commitments to responsible behaviour, and follow the team's protocols for information sharing, decision making, self improvement, development of great products or services, etc.

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.

Great teams learn to let ideas go, and similarly can accept that their world isn't perfect for everyone. Sometimes the shiniest, prettiest, smartest new hire just shouldn't be on this team. The Core Protocols provide the tools to deal with that.

Again, the underlying premise in all these answers is that the team is using the Simple Rules – the Core Commitments in the Core Protocols – and the Tools – the Protocols themselves for their day to day operation. This is simply the smartest approach for any team that we have found.

So here is the “catch”. If what I am suggesting doesn't seem workable in your situation, then you need to use the Simple Rules and Tools for Great Teams (or something better).

To add your questions to the list add a comment below or tweet me @ReevesResults.

Team Tips – 2 {Where's the Boss?}

Assuming you've read the previous post – Team Tips - 1 – you know the definitions I'm using for “teams”, “boss”, etc. and can guess that I will be relying on the Simple Rules and Tools for Great Teams – the Core Protocols – in my answers.

Indeed, the underlying premise in all these answers is that the team is using the Simple Rules – the Core Commitments in the Core Protocols – and the Tools – the Protocols themselves, for their day to day operation. This is simply the smartest approach for any team that we have found.

So here is the “catch”. If what I am suggesting doesn't seem workable in your situation, then the organization needs to use the Core Commitments and Protocols (or something better).

Let's start with one of the most complicated situations Vickie and I have had to work on with a team, the question Jose R. asked:

“Does the boss belong to the team, or he just must work for it?” (I believe for the last part Jose meant “or does the team just work for the boss?”)

(Remember: “boss” as used here is defined in the prior post Team Tips - 1).

Boss

The simplest rule is NOT to have the boss be part of the team. The team works for the boss, and delivers the product or service the boss requires, in the timeframe the boss requires, with the quality the boss requires. And in large enough organizations the boss is on his or her own team with other bosses of other teams.

Team

In fact the teams working for a boss ARE THE PRODUCTS of the boss, and the teams across the organization are the products of the team of bosses. In the purest arrangement the bosses don't produce any final product or service for sale to their retail customers – their teams do.

And to get even more precise, the boss sets the initial conditions for the team – what must be produced and delivered by the team, and when, and within what constraints (resources, values, legislation, policies, etc.). The most experienced and mature teams can take responsibility for deciding what can be produced and delivered against a given deadline, or alternatively, what deadline they can meet for a given product requirement.

All of this works smoothly when there is a high level of trust and a high level of communication both ways between the team and the boss. And, of course, individual commitment and responsibility from each team member. (We'll explore trust and commitment more in future posts.) These elements are all comprehended and provided for in the Core Protocols.

But the situation gets trickier when the organization is smaller and, for example, the owners of the business are the bosses AND are also contributors to the team and its products.

In this special case the boss or bosses have to operate in two modes: explicitly as the boss, and explicitly as a team member. The modes have to be crystal clear at each moment in each transaction between all parties – that is why I emphasize “explicitly”.

In all cases, the boss's job is to have the team produce a result on time that is great in the opinion of the team and the boss. The boss does not have to be concerned with how that is done, what tools or methods are used, etc. as long as the initial conditions – the non-negotiable items – are met. If the result exceeds expectation or is finished early – fantastic. If there is any doubt that this will happen, the team should be reworking their methods, their focus on deadlines, their quality, etc., without expecting the boss to intervene or rescue them, unless they specifically ask the boss for help.

Similarly, in daily operation, the team relies on the merit of the best ideas from any team member at any time to proceed to producing the team result. The boss as a team member cannot have any special standing or influence, otherwise the other team members will eventually stand back and wait for the boss to propose all ideas and make all the decisions, and the huge opportunity for individual leadership, innovation, and energy is lost.

Accordingly, as the boss the business owner states the end result required or the deadline, then steps aside to let the team get on with it. As a team member, the owner acts as an equal with all the other team members to determine how best to produce a high quality result, or when the result will be completed as appropriate.

To be crystal clear about what mode the business owner is in – boss or team member – he or she may use a special name, put on a particular hat, etc. or simply say: “As the boss I need...” or “As a team member I propose...”

Needless to say, this special case can add a layer of extra effort and confusion, and so we recommend the simplest scenario for teams that are just getting accustomed to using the Core Protocols for team building and operation. But if there is no choice, we have a number of ways of accomplishing the special case.

If you already are knowledgeable about the Simple Rules and Tools of Great Teams – the Core Protocols – then you can see how this boss / team model works.

If not, then you will probably have many more questions on how this model can possibly work! So please send in your questions via the comments section below or @ReevesResults on Twitter.

Leadership 13

You can't beat having your own coach, soul-mate, and historian right at your finger tips. And it's wonderful when she – Vickie Gray, www.adaptivecoach.com – throws a wrench into my half baked thinking about Servant-Leadership with one comment.

Like: I think servant-leadership is attempting to solve an issue with authority.

Ooops! Another solution for symptoms – not the cause?

Let's continue the investigation on Servant-Leadership then and see what we can find.

From http://en.wikipedia.org/wiki/Robert_K._Greenleaf

"Larry Spears ( in the “Ten Characteristics of the Servant-Leader” ) distills Greenleaf’s (1977/2002) instrumental means into ten characteristics: listening, empathy, healing, awareness, persuasion, conceptualization, foresight, stewardship, commitment to the growth of people, and building community (pp. 3-6). It is important to note that these characteristics are not simply traits or skills possessed by the leader; a century of research has rejected what Bass and Stogdill (1990) referred to as an “approach [that] tended to treat personality variables in an atomistic fashion, suggesting that each trait acts singly to determine the effects of leadership” (p. 87).

"Rather, servant-leadership is an ethical perspective on leadership that identifies key moral behaviors that leaders must continuously demonstrate in order to make progress on Greenleaf’s (1977/2002) “best test.” The “best test,” which gives us the ethical ends for action, combined with Spears’ distillation of traits that identified the means, create a powerful framework for a review of the literature that furthers the conceptual framework for servant-leadership.

"That person is sharply different from one who is leader first... The difference manifests itself in the care taken by the servant first to make sure that other people's highest priority needs are being served. The best test, and the most difficult to administer, is this: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?"

As Vickie and I discussed the evolution of leadership thinking that got Greenleaf and Spears to the servant-leader concept and traits, the question became: What prompted all this?

If we take the idea at face value, it all seems quite nice, and perhaps too idealistic. I know I haven't encountered one of these animals personally. Mohandas Ghandi is the best candidate I can think of.

But if we consider the historical context of leaders, rulers, kings, princes, generals, etc. behaving in their own best interests, using their position to exercise power, and that leading to excesses of manipulation, subjugation, even slavery, the need for a kinder, gentler approach becomes clear.

Even in the lightest case of employees working for a domineering boss, the concept and traits of servant-leadership become appealing.

But not necessarily for everyone.

• Some are very content to be led, directed, told what to do.
  
• Some are looking for strong leadership in the form of an appealing vision – a picture of the future.
  
• Some want a clear course of action laid out in a mission statement.
  
• Some want the bounded responsibilities of specific tasks that don't include tactical or strategic thinking.
  
• Some want a well defined “day job” that lets them have a life of their own outside of work.
• Some don't want the boss asking them their opinion.

The point that Vickie and I got to was: In reaction to absolute power corrupting absolutely (or less disturbing versions of that), servant-leadership makes sense.

But the servant-leader traits listed should be part of any leaders behaviours because it simply just makes sense. They are the smart things to do. They get the best results.

And for more reasons than we might recognize on the surface.

From: http://www.greenleaf.org/whatissl/MargaretWheatley.html
Margaret Wheatley gave a talk on “The Work of the Servant Leader” at the 1999 conference. In her talk, which was published in Focus on Leadership, she said:

"There are many patterns, many beliefs, out there about leadership, about people, about motivation, about human development. The essential truth I’m discovering right now is that when we are together, more becomes possible. When we are together, joy is available. In the midst of a world that is insane, that will continue to surprise us with new outrages…in the midst of that future, the gift is each other. We have lived with a belief system that has not told us that. We have lived with a belief that has said, ‘We’re in it for ourselves. It’s a dog-eat-dog world out there. Only the strong survive and you can’t trust anybody.’ That’s the belief that’s operating in most organizations if you scratch the surface. The belief that called you to be a servant-leader, I believe, is the belief of who we are as a species. We have need for each other. We have a desire for each other, and, more and more, I believe that if the real work is to stay together, then we are not only the best resource to move into this future—we are the only resource….We need to learn how to be together: that is the essential work of the servant-leader."

I like letting Margaret Wheatley have the last word.