Tribal Council Meeting

mymanagementexperiment.com

Creating the Tribal Council

I'm a geek that's been in the Software Development field for about 20 years and have worn many different hats. The manager hat is still quite new.  Fortunately, peers of mine recommended a book "Management 3.0" that has been my life jacket in rocky waters.

I've come to agree with the author Jurgen Appelo - that "Management is Too Important to Leave to the Managers".   I found myself wanting to share the work with colleagues in the team.  So I created a 15-minute "Daily Sync" with a few Senior Developers, QA and Scrum Masters.  The goal was to be as transparent as possible with topics like:

• organizational impediments
• upcoming decisions
• challenges the department was facing, etc,etc.

As time passed the meeting matured into a 15-minute Tribal Council meeting.  I was looking for ways to share the decision making of the department through the "council members".  I wanted a way to expose myself to a small group of individuals,  while learning how to manage the bumps in the road together.

Bumps along the way

One of these "bumps" resulted from my decision-making that was behind closed doors - with team members one-on-one.  An especially notable example was how I created a new team by reshuffling existing members.  I had been making team membership decisions in the past with some disruption, but as the department grew so did the discontent. Many developers wondered how these decisions were getting made, and what was the rationale.  Needless to say this was not particularly empowering for the team.

Finding Delegation Poker 

Not feeling good about the incident, I pulled the book "Management 3.0" and found myself looking at "Delegation Poker" as a possible way to involve the department in decision making that didn't totally disempower me, but empowered the team.

Here's a quick how-to video I created on Delegation Poker:

Delegation Poker at the Council Meeting

I immediately brought the tool into the council meeting and played the game with the scenario "Who gets to decide on team membership?".  I selected "Level 3 - Consult" while many council members selected 4,5 and 6.  This led to a healthy discussion about how these decisions get made and the impacts to the department and the individuals on the teams.  We all came out of this discussion with a better appreciation of the impact and moved into a "4 - Agree" level for this type of decision going forward.

Being Transparent about Council Decisions 

Having a large department, we see the Council meeting as a means to self-organize the department. We're still experimenting with ways to ensure high levels of transparency with the whole group, while balancing the need to have effective conversations with a small subset of individuals.

The council members are also responsible for gathering input before they make decisions to ensure proper representation of their vote.  We've also built a public JIRA workflow board with the discussion topics, comments and decisions that resulted.

We're stealing from Holacracy to define and roll out "Roles".  We're expecting that roles will clearly describe the accountabilities of the council members, along with the many other hats we all wear on the team. More to come on this later.

What I've learned so far

Small break-out chat’s with individuals can easily lead to mis-communication.  By exposing myself to a larger group (i.e. the council meeting) there is a consistent message and a shared understanding. Regardless of good intentions, making changes can be disempowering if transparency is lacking.

Last but not least, as a manager I find it important to experiment with leading practices.  It's clear that I can't "get it right" the first time.  It has helped having an attitude of experimentation that allows for learning to be an ongoing process.