Tribal Leadership: Is It a Game?

 

The book TRIBAL LEADERSHIP lays out 5 stages of culture. The 5 stages are basically stories that people tell themselves…and others.

 

 

 

 

Here are the 5 progressive stories:

  • Life Sucks
  • My Life Sucks
  • I’m Great!
  • We’re Great!
  • Life is Great!

What I have come to realize is that the content of this cultural self-talk is related to games.

Games have 4 properties:

  • A goal/set of goals
  • Rules
  • Ways to get feedback on progress
  • Opt in participation (you can opt-out)

My current belief is that the 4th property, “opt in participation”, is an absolutely huge factor. It is highly correlated with levels of joyfulness, satisfaction, feelings of well-being, and overall life quality.

When you are forced to play a game, it is almost never fun.

When you opt-in to play a game, things get interesting!

Here is a summary of what I think is going on with these stories. These five stages of TRIBAL LEADERSHIP are actually stories and related self-talk, and are actually about the ability to make choices, about game structure, and about control, progress, belonging and meaning:

 

TL Stage Your Story The GAME connection
Stage 1 Life sucks! I’m forced to play games I do not want to play and/or do not understand. I have no options. I have absolutely no sense of control.
Stage 2 My Life Sucks! Some people play enjoyable (opt-in) games, but I don’t. I’m forced to play and cannot opt out. I get it, yet I have a low sense of control and almost no sense of progress.
Stage 3 I’m Great! I’ve figured out how to win. Further, I now define MY game, and now you have to play it. You ARE playing it! I’m now in control & now making great progress!
Stage 4 We’re Great! I opt-in to play a bigger, cooperative, goal-seeking game, with others. I now have a sense of belonging.
Stage 5 Life is Great! I opt-in to play a bigger, cooperative goal-seeking game, with others. And this time, we play big and intend to change the world. I now have a sense of higher purpose.

 

Summary

In my book THE CULTURE GAME, I explain the concepts and facilities available to create a good-game structure at work, a game where the enjoyment is so great that the distinction between work and play is minimal.

My current belief is that we are not nearly focused enough on using know-how about game mechanics to debug the problems we face at home, and work and in the wider world.

Culture, as it turns out, is a game.

Jane McGonigal gets it right: Reality IS Broken. And Zappos CEO Tony Hsieh also gets it right in his book, DELIVERING HAPPINESS: we all want to experience a sense of control, a sense of progress, a sense of belonging, and a sense of higher purpose and meaning. Good games deliver substantial happiness. The 5 stages of culture as described in the book TRIBAL LEADERSHIP do appear to confirm this hypothesis.

 

The Relationship to Effective Agile Adoptions

Agile adoptions are typically implemented as a mandate. This is acceptable so long as leadership sets out the clear direction and stops short of mandating specific practices. My current hypothesis, which appears to be valid based on experience, is:

  • Mandates of practices in an Agile adoption amounts to a game without the essential opt-in feature
  • People have needs. The mandate quickly reduces the feelings of control, progress, and belonging that are basic human needs
  • Resentment and disengagement are the natural and predictable results;
  • Disengagement is death to any attempt at a rapid and lasting Agile adoption.

The solution? Check in on what people want, what people think and what people feel BEFORE embarking on the journey of Agile adoption in your company. Open Agile Adoption is one way to do that.

 

Resources

For a deeper dive into these concepts, you might consider taking a look at these resources:

Blog Post: How Games Deliver Happiness And Learning

Blog Post: Open Agile Adoption

Audio Book, absolutely free download: Tribal Leadership by Dave Logan and co-authors

***

 

 

 

 

 

 

 

 

Capitalize We

In digital terms, culture is an application platform consisting of a core operating system kernel and associated components, modules and low-level applications.  This implies We can hack culture by screwing with these cultural platform elements.

The operating system, components, modules and low-level applications of culture are actually our stories and narrative. Thoughts become things, and stories are highly organized, memetic compositions of related thoughts. Stories are culture-things with structure and content. Changing culture is an exercise in selectively hacking specific stories— the essential modules and components that constitute the core cultural platform.

(You can learn more about culture, story, and language here.)

Computer programs are written in a programming language. The programs are stored on digital media. Cultural programs– stories— are written in a natural language. The stories are stored in your head. The stories are the cultural software in your head. The language you use determines how the stories can be told.

Well understood stories get memorialized in writing– in language. Languages have a vocabulary, a syntax, and some rules and conventions. Modifying language is a way to make a change (to refactor) all the stories in that language.  To hack culture, hack the stories. The most efficient way to hack all the stories (at global scope) is to hack the language.

There is a rule in English that says We capitalize “I” and not “We”. This implies “I” is more significant than “We”. Anyone can chose to capitalize We. In so doing, “We” gets on an equal footing with “I” in sentences composed in the English language. By capitalizing We, the signal in writing is that “We” is at least as big, and as important, as significant, and as valuable as: “I”.

“We” is just one example. Anyone can choose to hack language and see what happens. If that language hack of yours comes into widespread usage, the language changes globally. As language goes, so goes story and narrative. As story goes, so goes the culture.

To hack your culture, hack your language.

Capitalize We.

 

Story and Language: Why Do You Care?

Language is the code of culture.

Stories and narratives are core, platform applications that execute the cultural operating system. Repeat:  The culture is the operating system, composed of the stories— the core applications. The language is the code used to create these core ‘applications’. If you have no stories, you do not have a culture.

Got that?

Dave Logan has all this covered in TRIBAL LEADERSHIP. You listen to the language- the code— of the stories you hear. That tells you the level of the culture. The level dictates what the culture can aspire to. What it can do.

What it is capable of doing. And being.

Example. You show up. People are talking in ‘We’ language and telling ‘We’ stories. That’s a tribe that can dominate their market space. That’s a tribe that can get to Stage 5 in the TRIBAL LEADERSHIP stage development model of culture. This Stage 4 tribe has the capacity to reach Stage 5 and be world-changing.

Another example. You show up and people are speaking ‘I’ language. The stories are all heroic in nature. He did this, she did that. I think this; I do that. Hear it? That’s Stage 3 culture. “I am great. (You are not.)

This culture can function in a minimal way. It cannot change the world.

To change the culture, change the stories people are telling. There are many ways to do this. It’s not a trivial task. I explain some specific techniques in THE CULTURE GAME book. When you change culture, you change the stories. This is an axiom that does not change.

The culture is the operating system.

The stories are the core components and core applications that make up the operating system. They encapsulate what the culture means. This operating system is composed of stories.

The language is the high-level (story) programming medium.

Last thing: recall that the best computer programmer is up to 10X better than the average. This is ALSO TRUE for those who ‘code’ stories.

Interested in culture? Wise up about story. There is no better place to start than the web site www.GetStoried.com. That site has a boatload of tips, techniques and specific guidance on how to leverage narrative. The individual responsible for that site has PLENTY to teach you.

Michael Margolis is a brilliant man who knows more about narrative than ANYONE I know.

Tell him Dan sent you, and that you want to know how to get a bigger story.

Nominalization

Everything is framed by language. Change the language and you are changing the game. This is as aspect of culture covered in my book, The Culture Game.

Naming things makes sense of the world, yet it can be bad for teams. Ironically, naming things reduces the flow of We. That is because the names are literally symbolic of things. Names create very real divisions.

Nominalization is one way we make sense of things. Nominalization assigns names  to things and reduces them to nouns. Nominalization is a linguistic device that allows you to turn a verb (and other word types) into nouns. It’s a trap that can limit perception and thinking at the level of We. Nominalization creates opportunities for division to occur. For example, this cannot be that if this is not(that).  I am describing the divisions: these divisions reduce the flow of We. Nominalization creates linguistic (and therefore very real) division inside the mind of groups.

On the other hand, anything that increases the flow of We is insanely great. Some specific, named socio-technologies that help do this include:

  • Kanban
  • Scrum
  • Core Protocols
  • Open Space
  • Facilitation
  • Coaching
  • Triads

There are others like these; I have a name for them as a group.

When I tell you the name, it is sure to reduce the flow of We in the community of readers. Why?

Because as soon as I divulge the name, then the discussions start, describing: how this is not that, how this is inferior to  that, how that is crap compared to this, and so on. Eventually, I have to tell you the name, so We can talk about it. There is no other way. I plan to wait until at least a few people comment on this post, to get the ball rolling. That is the signal I am waiting for. If I do not get any comments, that is my signal to wait. See also: semiotics.

Kanban and Scrum are Verbs, Not Nouns

Is it just me? The Kanban community folks appear to encourage and be fond of bashing Scrum. This is unfortunate since the Kanban and the Scrum are so closely related. These are not distant cousins but rather, brothers. They both encourage a generative flow of We.

Positioning Kanban as superior to Scrum and vice-versa is contributing to a sense of meaningless around the word Agile. Agile is beginning to mean “whoever had the biggest ego and yells loudest. Whoever can grab the socio-apparatus of the Agile community (The Scrum Alliance, Agile Alliance, the conferences etc) to steer them. Whoever can advocate their position even louder and more convincingly.”

Exhibit A is the artificial debate between which is better for Agile teams: Kanban or Scrum. Yes, Scrum fails in some organizations and does not  create much improvement in results. Kanban also suffers from these failures, typically in the same organizations.

In general, any failures of either are related to the culture in the implementing organization. In either case, Scrum and/or Kanban, the organizations doing the implementation need pain-killing drugs (commonly called a prescription) and a doctor (commonly called a coach). If they do not need a prescription or a doctor (to help them heal) they’d already be healthy, right?

 

Language is the Key

In the post The Flow of We I discuss nominalization, the act of changing verbs and adverbs (and other kinds of words) into nouns. Click the link to learn about it. We all do it all the time. It creates space to compare, contrast, disagree, and debate. Naming people, places and things is the primary way we make sense of the world we live in.

Scrum and Kanban are most useful to us in the English language when referred to as verbs, not nouns. We Scrum, and we Kanban. When we Kanban, We pay attention to the flow of work items through our group. We work with upstream and downstream partners to increase the flow of value. When We Kanban we increase the flow of We, by paying attention, as a group, to things that matter, like work items, classes of service, cycle times etc.

Likewise, we Scrum. When we Scrum, we first agree to some basic understandings, about roles and meetings and rules. Then We Scrum. When We Scrum, We open conversational space to discuss the actual details of requirements. We time-box most of these discussions. After We do some work, We reflect formally during a meeting We call “the Retrospective”. We also timebox this meeting.

Scrum is a verb. We Scrum. Kanban is a verb. We Kanban.

The Kanban community already realizes this, well below the level of collective awareness. What, you disagree, and do not think so? Guess again.

Check out this poster and slogan again, it says:

[Yes] … we Kanban. THAT is using the word Kanban as a VERB.

 

 

 

 

Post Script: 3 hours later, I already got three emails on this from folks out there. Moral of story: language matters.

 

 

 

 

 

 

Scrum Language: the term Scrum “Master”

Here is something I get a lot when doing Agile coaching: I hear comments about Scrum terms and words. One of them is ‘Scrum Master’.

‘Master’ associates with acquisition of complete knowledge or skill. However, ‘master’ also associates with:

 

 

  • One having authority over another
  • One that conquers
  • One having control, especially over a slave or animal, also the employer of a servant

People who know Scrum know that the Scrum Master is supposed to be a servant, a servant-leader.

And that is the problem. Language frames reality.

Here is a term that refers to a servant as a ‘master’. I understand that Jeff and Ken mean the other kind of master, the master of a skill called Scrum. However, not everyone hears it that way. I know because I get comments on this matter and questions, all the time from Agile coaching clients new to Scrum. They are hearing “authority over”, “control over a servant”, etc.

Language matters !

Are you getting these comments and questions about the term ‘Scrum Master’?

Let me know.