Team Gestalt and the 5 Dysfunctions

Patrick Lencioni's The Five Dysfunctions of a Team (here's the GetAbstract abstracted version) describes five Maslow-like pyramid levels of dysfunction of a team, from most basic to highest order: Trust, Fear of Conflict, Commitment, Accountability, and Results.

To build a strong team, a good leader needs to bring counterpoints to each of these dysfunctions and build a culture that allows the team to bond and Gestalt, or become greater than the sum of the parts.

Management Zen Experienced During Television Production
My first career was in television production.  Multi-camera studio shoots.  When the noon news went live, our cameras were up and going, whether we were ready or not.  Every production was an opportunity to Gestalt--become more than just the production plan.  Every nerve was firing and everyone's senses were on high alert.

The productions that went without a flaw received many kudos, but the productions where we had to deal with unforseen circumstances in some brilliant way--if we got out of them with flying colors--we celebrated.  It was those productions, when we were up against the clock, in adverse conditions, where something unexpected happened, where we really came together to create miracles.

If daily you have an opportunity to enter that Gestalt state, where everything is clicking at an optimal level, then you know how to recognize what the feeling is and what you're trying to get back to.  Conversely, if you deal with long development cycles where you only enter do-or-die mode every 18 months or so--then chances are you have felt the Gestalt state, but it has been so few and far between that you don't remember it.

I assert that we, as Leaders of teams, should be focusing on how to bring our teams into that Gestalt state as often as possible.  It doesn't mean you need to manufacture fire drills, but it does mean you need to get the team exercising the "end game" skills more often than just the end game.  The more opportunities for flexing the muscles that can bind the team together and make them click--the more times it'll actually happen.

Gestalt and the Five Dysfunctions
To bring your team to a place where they can Gestalt requires a solid foundation that the team operates on.  This is where the five dysfunctions serve as good milestones on the path toward a Gestalt state.

The first level of dysfunction is around trust.  James Kouzes and Barry Posner, authors of The Leadership Challenge (GetAbstract version), a seminal book on the five fundamentals of great leaders, write: "In almost every survey we've conducted, honesty [...] emerges as the single most important factor in the leader-constituent relationship." (p.32).

One of the outward manifestations of trust is the perception of a leader's honesty.  If a leader is exhibiting traits of honesty: genuineness, authenticity, and vulnerability, then the individuals interacting with that leader will report greater trust of that individual and their decisions.

Actions you can take: Repeated trustworthy behavior motivates.  Act in ways that are consistent with your ethical values; leaders go first, so be the first in on a risky item or controversial topic; show some vulnerability, and invite others to do so by example.  Then wash, rinse, repeat.

Fear of Conflict
The second level of dysfunction, once you get past trust, is calling bullshit.  You have to build a team ready to engage in constructive discord--a team willing to challenge each other in a way that is healthy and brings you to better solutions because you've identified pitfalls.

The problems people express today are the land mines you may hit on the road tomorrow.  Treat them seriously and engage the whole team in moving from acting like a patient--ouch, doctor, it hurts when I do that--to walking into your office as the doctor: "Here are the problems we've identified, and here are some ideas for how they could be resolved."

Conflict should be embraced courageously.  Meet it head on when it appears, with no after-the-fact passive-aggressiveness.  It also means giving personal feedback in private--some conflicts are inappropriate to air in front of the entire group.

Actions you can take: When your next big controversial issue comes up, don't shirk it, call it out right away and then reframe the problem in a positive context.  Instead of "Those designers are giving us horrible designs!" reframe and ask, "How can we be more clear about our customer needs and requirements?  How can we own this problem together as a team instead of making it an us versus them?"

Lack of clarity or buy-in prevents decisions from sticking, because individuals aren't clear on what is specifically being required of them.

Steve Roesler's edited version of the Tannenbaum and Schmidt leadership decision-making model: tell/sell/test/consult/join, is a useful approach to assuring commitment.

First, start with the actual perspective of the manager, yourself, who is coming to the team with an issue to resolve.  Then ask yourself where on the Tannenbaum/Schmidt model you can approach the team.  If you have an issue that the team truly has the ability to consider and not act on, then you can bring it to them as a join decision--where they can choose to take it on or not.  If you have an issue that they must take on, that's a tell.

I've observed this doesn't work: managers approach the team with a consult, but then devolve to a sell, and then further to a tell.  Those conversations leave most demotivated, with no clear commitment.

It's always better to sit down and make it clear exactly where you're at with an issue, "Hey folks, this is a tell right from the top, so get your gripes out now and then let's turn to discussing how to deal with this the most productively."

Actions you can take: Be candid, and honest, when an issue must be addressed, and call it that right away and move forward from there.  Look for other issues that truly are flexible and make sure to be clear to the team, "Hey, here's an issue we really can treat like a consult or a join..."  Otherwise, if you only ever call out your tells, your team may feel like those are the only times you're clear with communicating the priority and commitment level required for an issue.

Four questions drive accountability: What are we accountable for?  Who is accountable?  To whom are they accountable?  And what are the consequences?  Some answers get us above the line--being accountable for results not just activities; understanding that delegating responsibility doesn't absolve us from accountability; being accountable first to ourselves, our ethics, our morals, then wrangling the other stakeholders; and delivering consequences that are in-line with the behaviors we want to incent.

Below-the-line behavior is blame and excuses.  The focus needs to be on results.

As individuals move up and master the art of delegation, a false assumption is that delegated activity then transfers accountability.  Ultimately, the individual made responsible for something is accountable to you, and you are accountable for the task as it was given to you by your boss.  Two different parties holding parties below them accountable, usually with different expectations.

Actions you can take: When trying to gain commitment of the team, be clear and use explicit language on who is accountable for what and to whom.  Then discuss what consequences will result from which outcomes, both positive and negative.  Encourage a team culture where individuals feel safe to step-up and take accountability for results, especially mistakes, and then make sure you follow-up to do the same for positive results, too.

An individuals' career is ultimately their responsibility.  In the pursuit of advancing their status, it may erode the focus on collective results.  Ultimately, the team wins or loses together.  Having measurements and metrics that are focused (ex. 3 top issues, not 20) keeps the team clear on what results are expected.

In one of my first companies, I made the newbie management mistake of allowing every individual to work on their own pet projects, thinking each one could potentially be a goldmine.  Meanwhile, our only product that was out the door and making money was floundering due to sales leads that were going unattended to.  Having clear success measurements for results around the product and its sales, and holding the entire team accountable for that specific success, would have assured that all individuals would have turned their attention to the top priority and we would have had drastically better results.

Actions you can take: Whenever you have an assignment, specifically ask, "What will success look like here?  And how will we measure it?"  And have a board, even if its just a white board in the hallway, where you write the success measurement and its current status.  (Ie. Number of widgets upgraded: 1,000).

Finding Your Gestalt State
Once you've climbed and overcome the Five Dysfunctions of a Team pyramid, you're now in an optimal place for the team to reach their Gestalt state.  It will be brief interludes where you will really feel like everything's aligned, clicking, and you're meeting deadlines with flying colors.  Watch for it, see if you can call it out when it happens, and try to internalize what it looks like, and feels like, so you can encourage everyone to try to find that state again.  It's fleeting and impressive.  It will often happen when you end up with an emergency or hot issue that will require you to scramble.

Using transparent, open communication, with clear decision making and accountability, will get you to solving the problems ahead with greater alignment and quality of work--because you'll be able to spend more time on satisfying the customer need and less time on fixing team dynamics.




Originally written: Mon 28 Apr 2003
From: Andrew Coven
Subject: The origin of CodeHawgs

I was asked for some graphics and background of CodeHawgs. I thought I'd include a few more of you so you could take a break from your hectic lives and enjoy a fun historical moment.

Back in 1997 when InDesign 1.0 and its SDK were under construction, we thought it would be clever to come up with a fictional company that you could follow their pursuits as they tried to create a set of plug-ins to help a client integrate their workflow with InDesign.

The original name was CodeDawgs, a fun play on words, since "Who let the dogs out?" was often slurred "Who let the dawgs out?" and was still a popular song. It also was sort of fun to think we're "tearing up code like frothing dogs." Kind of some nice high-throughput connotation. We liked it. We were, after all, geeks, with low humor thresholds.

So I engaged my friend Elena on the Photoshop QE team to do a mockup of a dog for the logo:

In the meantime, we came up with a funny slogan, "Our code smells like roses!":
We started legal on the trademark search to make sure we weren't completely stepping on someone.

Well, this was particularly funny to us geeks with that kinda humor, because the original insult is, "You think you're so good, that your poop smells like roses?" So the phrase "Our code smells like roses!" was a cute play on words to indicate we didn't take ourselves too seriously, since of course our code was going to be crappy sometimes and we never would think we're pristine code writers and could learn nothing from our external developers.

A humility I hope carries through the group to this day.

So I asked Elena to do a mockup of the dog taking a dump and pooping out code, perhaps 0's and 1's? She was confused, she didn't understand what I wanted to see. So I explained to her, "Make it like the 'No bullshit!' bumper sticker!"

"Huh?" she said. "What's that?"

"You know, a bull taking a dump with an international 'NO' sign over it?"

"Huh?" she said again, "Show me!"

She hadn't seen one before, so I quickly drew one up in Photoshop and sent it to her.

Once she saw that, she understood. And the poopin dog was born:

You'll note, she hadn't yet gotten the memo on the trademark (tm) symbol. More on that below.

Legal then got back to me with the inital results of the trademark search. Bad news. There was a software consortium in Cupertino called "CodeDogs", and trademark law indicates spoken similarities are just as important, conflict-wise, as written similarities. So the argument that CodeDawgs was distinct from CodeDogs completely falls apart when spoken. And a software consortium certainly is in the same venue as a software application development company.

So then we talked and came up with a clever alteration--CodeHawgs! Even funnier, because it suggests we're hogging all the code! Again, a play on our, of course, humbler side.

We're nothing, if not humble.

Trademark searches on CodeHawgs came up in the clear. We were good to go! Although, the legal searches always ended with an interesting caveat: Do NOT use (tm) after any "CodeHawgs" icon or name listing. Why? Because, while we didn't want to conflict with any known trademark, there was no one in their right mind that was going to PAY the USD$7,000 to trademark it. I mean, we had budget, but not THAT much budget. It wasn't THAT important.

We DID however grab www.codehawgs.com and www.codehawgs.org. I had hoped that someday we would be able to publish sample code and integration suggestions on a very special, fun section of our adobe web site (such as partners.adobe.com/indesign/sdk/codehawgs or something like that) that the www.codehawgs.com/.org domains would redirect to.

If you do a whois on codehawgs.com you'll see its still owned by Adobe. Unused, but we still got it.

While they checked the trademark on "CodeHawgs" I asked them to also include the check for "Our code smells like roses!" They did find a few "smells like roses" references, but never related to computers--another green light! Again, we didn't care enough to actually pay the money to trademark it, so we can't use "Our code smells like roses!"(tm), but we can use it--good enough.

Back to the drawing board Elena went, converting the poopin dog to a poopin pig, with our fancy approved slogan:

Note the removal of the (tm)'s.

Our current director, being a geek at heart, got a great chuckle out of the whole thing as he amassed the correct budget to put this stuff on hats and jackets (which took over a year. See final note below.) In a moment of clarity, he said to me, "Andy, why don't you run this logo by HR before we imprint it on anything?"

"HR? Why would we need to run anything by HR?" I asked.

"Just do it, just to cross all our t's, dot all our i's."

"Ohh, all right."

Off to HR I went, sending the details of the fictional company and logo and the graphic for, what I thought for sure would undoubtedly be a flippant, quick, dismissive-like approval.

After the HR person was done being completely flabbergasted, and explained to me how engineers aren't allowed to do marketing FOR A REASON, she concluded with the final nail-in-the-coffin remark:

"Scatalogical humor is NEVER appropriate at ANY company."

Hmm. Maybe she just didn't get it?

Dismissed with a sound, spanking-like rejection, we pondered, "Now what do we do?" Fortunately, the movie The Matrix had just come out and we were quite smitten with it.

Of course! NeoPig! A stroke of genious:

An e-mail and a phone call to Elena, and slap that baby over a green background, to simulate how it'll look on the jackets, and the CodeHawg was truly born.
I've also included the final of the back-jacket art, symbolizing the arduous mountain-climbing-like task it was to get InDesign 1.0 out the door. Elena and I chose to make the person explicitly gender-neutral so that it could be perceived as a male or female, since this was a multi-gender, multi-cultural accomplishment:

The final note, the jackets, at $300/piece, were the last expensive "Shipping gifts" ever given out by Adobe. Right after we got those, the official "Shipping gifts policy" became $25 per person.

It took exactly 1.25 years, from the moment I started politicking to get the hats and jackets into the budget, to the day the team received these awards with Thank You notes from John and Chuck.

And now you know The Rest Of The Story.