Tuesday, June 30, 2015

My leadership toolkit

A simple toolkit 

I've got a crappy memory.  To compensate I carry around index cards while away from my computer, and transcribe my notes onto my GTD (Get Things Done) text file.  It's archaic, but I've found pen and paper are far more natural and keep conversations fluid.

I take with me little "cheat sheets" of discoveries that have become a part of my leadership toolkit. Feel free to download the toolkit here.  They fit nicely on the back of index cards.  

Lead yourself

"Lead yourself, lead your superiors, lead your peers, and free your people to do the same. All else is trivia."  - Dee Hock (founder of Visa credit card association)

It's very easy to wear the hat of an expert especially when in a position of authority.  However, I've found it's not terribly empowering for my colleagues if I wear that hat too often.

I've taken the approach of learning with my team by sharing my cheat sheet.  The objective is for them to "lead themselves" instead of depending on the conventional role of the manager.  Depending on their varying levels of interest, I go into detail about each tool and give them copies upon request.

About the toolkit

The three gaps were described by Stephen Bungay in "Art Of Action" point out "Gaps" leaders face with Plans, Actions and Outcomes.  The red text below is how we incorrectly respond to a gap.  For example, when responding to the "Knowledge gap" we incorrectly respond by providing more information.

The green text is how we should respond.  For example, with the "Knowledge gap" we should provide clear direction in the form of "What and Why".

The 7 levels of delegation are described by this short 3 min video.    By having a model to describe how authority is being applied, it helps set expectations on how much influence we all have on the decision. 

Transactional Analysis was introduced to me by leadership guru "Greg Witz" during his leadership training course.  The diagram below speaks to how we can move into "Parent, Adult or Child" ego states when communicating with colleagues, friends and family.  

In short, when communicating with each other we move unconsciously into various ego states. The goal is to return the dialogue back to an "Adult to Adult" conversation.  This article speaks about transactional analysis in more detail.  At the risk of over-simplifying a simple example can be an interaction you may have with a "Withdrawn Child". The "Nurturing Parent" ego state could bring them back to the conversation into an Adult-to-Adult conversation.  To get a true sense of how this works I'd highly recommend signing up for a Witz leadership training workshop.

Dynamic Coaching is an approach to supporting your team depending on their various levels of them being "Willing and Able".  I've applied the ego states within each quadrant to help shape how you can approach your colleagues depending on where they are, and if they need support.

The last tool is an extension of Bungay's three gaps, speaking to how leaders can provide strategic intent to increase Alignment without sacrificing Autonomy.   It's often seen that Alignment to be in opposition to Autonomy.  Either "do as I say" or "do whatever you want".  Bungay's challenge this assumption.  

The below card shows how a leader can provide clear direction by focusing on the "What+Why". This frees your team to figure out the "how" by aligning with the leaders strategic intent.

Friday, June 26, 2015

Whispering Wednesdays


Moving to an Open Space

Our department recently moved to a large open space without cubicles.  We've been given large tables, chairs, whiteboards and a beautiful 8th floor view of the Toronto airport.

It's been an experiment in creating better face-to-face collaboration and increased productivity. For the most part we're happy with the move.

There have been occasions where individuals have wanted to have a quiet space to focus and get work done.  Our new office space was not conducive to a quiet and focused space.

Driving to work, I'd listened to Jason Fried in an interview on the CBC.

He spoke about how the modern workplace does not support getting work done. (Jason Fried is the co-founder of 37 signals and the author of the book "Rework").

Here's the interview if you are interested on "Why Work Doesn't Happen at Work":


In the interview he proposed the idea of just taking one day and treating the workplace like a Library.

We decided to experiment ourselves by creating a "Whispering Wednesday" on the first Wednesday of the 2 week sprint.

Experimenting with Whispering Wednesday's

I presented the idea to the team and they were willing to give it try.  We had a single simple rule:  Keep your voice down so that it would be loud enough for someone sitting beside or near you.

We even designated a "Librarian" that was given permission to shush the heck out of anyone that had forgotten the rule.  After the day had passed, it was hard to tell if the experiment was a success.  So we decided to ask the group if they'd like to try it again.  Survey Monkey came to the rescue: 

Having such a close tie in the results I decided to ask for more feedback in our 1:1's.  

For the most part, the teams for valued being able to speak openly and freely more than having quiet time.

However we all agreed to try it again, to accommodate individuals needing quiet and focused time.   There were still a few members that craved a quiet space.

So, for the next iteration we revised "Whispering Wednesday" to occur in a designated quiet room.  Instead of asking whether we'd like to try it again in two weeks, the question was asked "What kind of impact was Whispering Wednesday for you?"

As a result, we now occasionally run a Whispering Wednesday with a designated room... and have found a healthy balance between the needs of the few vs the large group.

What I've learned so far

Experimentation is crucial to a healthy workplace.   Equally as important is that we measure changes to see if they positively impacting our department.

And lastly, by measuring and sharing the results of experiments, the team is more willing to take risks as they are a clear part of the rationale behind the decision making.

Wednesday, June 24, 2015

The “hot seat” experiment


Difficult Conversations Workshop

Our development team recently attended a whole-day workshop about "Difficult Conversations". I setup the workshop because we were facing challenges when trying to voice concerns with each other and external departments.  The objective was to give the team tools to communicate effectively with various personality styles.

Asking a Difficult Question

A few days later, in our weekly department meeting I decided to stretch myself and give the department permission to ask me any difficult question they'd like.

To select the question, I stole techniques I learned from a recent "Spark the Change" conference I attended here in Toronto.  I took the following approach to help the team find the most important "difficult question".
  • Individuals were asked to quietly generate questions/topics (One per sticky)
  • The stickies were put up on whiteboard and grouped into similar areas of concern
  • Everyone went to the board and was allowed to "dot" a sticky with a vote
  • Individuals were allowed to vote 3 times for their favourite questions (3 dots)
Once everyone voted, the topic with the most "dots" was selected and I sat myself into in front of the team to address their "difficult question"

Here's the source material from Steve Rogalsky that introduces the science behind brainstorming and how "silent brainstorming" to allow all personality types contribute equally.


Employee Engagement and Retention

The selected topic was "How do you keep turnover low and how do you retain people?".  It was a relevant and topical question - as we just had an experienced member of the team resign. I sat down in front of the group and immediately felt awkward and uncomfortable.  Many long pauses as we tried to dig in.  It was not going smoothly.

I attempted to jumpstart the conversation with some facts on our current retention rates, how they compared historically in our department, how they compared to other companies.  I spoke to how "I felt good about where we stood" in light of a Developer's recent resignation.

Interestingly, someone from the group pointed out that I didn't answer the question.  The question remained, "how do you keep turnover low and keep good people?".  On top of which, half the room was not engaged in the conversation.  I had answers, but had no way of knowing if they were right answers.

I felt the value of the conversation diminishing.  I attempted to energize the group by speaking about the culture, changes recently made and how this was making for an engaging environment that would keep turnover low.   As I soon quickly realized that we weren't making progress, I decided to take on a different tactic.  I'd ask them what would make them quit... and what makes them stay.

Ask Them (anonymously)

Survey Monkey is a great tool to get anonymous feedback. In the end we decided to simply ask the department - "what's keeping you here?", and "what would cause you to leave?".  The following incomplete sentences were presented:

  1. Our work/life balance...
  2. Our technology stack...
  3. The work we do (i.e. user stories)...
  4. The product we are building ...
  5. Our codebase...
  6. Our culture...
  7. Our company's stability...
  8. My compensation...
  9. My advancement opportunity...
  10. My manager...
  11. My co-worker(s)...
  12. My squad/team...

The survey allowed them to select a value from 1-5 with the values reflecting how they'd complete the sentence:
  • (1) ..is bad enough to make me quit
  • (2) ..is not great
  • (3) ...is okay
  • (4) ...is good 
  • (5) ...is so great it keeps me here

What I learned from the experience

It was clear after going through this exercise that having the right answer is not as important as having the right question.  

The results of the survey were also very insightful.  It allowed us to see what behaviours we should continue to support and what issues to immediately address.

As painful as sitting in the hot seat was - I would gladly do it again.  By putting myself out there my team recognized that I was committed to being transparent and answering their concerns directly.

For future meetings, I would revise the large group discussion to a few smaller groups of 4-7 each. This may give the smaller groups opportunity to discuss more openly amongst themselves, and allow them to speak to me more comfortably.

The most important result was in finding the right question, and allowing the team to answer safely and anonymously.

Monday, June 22, 2015

Tribal Council Meeting


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.

Saturday, June 13, 2015

Where do I start?


An overview of 3 books that have provided me some practical tools to experiment and learn how to manage a contemporary software development team.

I've been a Software Developer for the better part of my 20 years of professional experience.  I've recently taken on the role of "Manager" and quite frankly have little experience with Management.

So in place of experience I've been experimenting. I'll describe some of the "tools" I've been geeking out over that I've lifted from the following three books:
They've been absolutely invaluable and a source of inspiration in my daily work.  I've been able to create a decent toolkit which allows me to continuously experiment to gain experience.  If you are in a similar position, I hope the following articles to get your started with your experimentation.

Tribal Leadership - by David Logan

Dave Logan describes how all we naturally form "tribes", how this occurs in the workplace, and the 5 stages of Tribal Culture.

Here's his TED talk on the subject:

A simple read on the concepts:

As well there's a great 21 day challenge you can take that takes you through practical exercises to gain insight about yourself:

Management 3.0 - by Jurgen Appelo

In his book Management 3.0, Jurgen Appelo provides tools that really engage your team and increase collaboration.

I had the pleasure of meeting Jurgen Appelo at a conference here in Toronto and thanked him for my favourite tool "Delegation Poker".  It's a great tool to have a non-confrontational dialogue about authority.  It's very similar to the game of "Planning Poker" (If you're an Agile Junkie):


Another favourite is the "Kudo Box" which is a great way for peers to recognize each others contributions:

Art of Action - by Stephen Bungay

This book is the absolute best kept secret that my colleague (Brian Kierstead) at work has called "The Calculus behind Agile". I stumbled across it when looking for how Spotify learned how to increase Alignment, without sacrificing on Autonomy.

Here's an article on Spotify's agile engineering culture:


We had the pleasure of talking to Simon Fawkes, a management consultant who describes the core concepts within the book:

The video does a great job describing the "3 gaps", our usual reactions and how we should approach three gaps.

To get you introduced to the concept of "strategic intent" heres a great RSA video by David Marquet: