Problem & Context, even over Solution

Joel Gascoigne, Buffer‘s CEO, penned a really thoughtful piece on his ideal leadership style:

How I try to lead when making changes that affect people

Joel builds on Ben Horowitz’s description of the CEO as the owner of the information architecture in the company.

He captures the crux of the CEO’s challenges as a leader in this quote:

I naturally end up with a unique picture of the whole company, since I’m learning insights from all the different teams and areas. I see patterns across multiple areas, and this leads me to ideas for making changes that could make the whole company more effective.

That’s where the danger comes. I’m both in one of the best positions to notice and implement changes to how we work, and also I’m far removed enough that I might be missing some context about how my ideas for changes could have negative implications.

He then outlines his approach to dealing with this challenge:

  1. I try to have the communication architecture to put me in the best position to understand a lot of the context and to draw patterns between challenges in different areas.
  2. I aim to notice the challenges arising in areas, and spend time to reflect on them in a way that others might not have the viewpoint or time to do so.
  3. Once I start to find myself moving towards a solution for challenges, I stop myself.
  4. I then speak with people who will be affected by any potential changes to solve the challenge I’ve found.
  5. When I speak with people, I try to share all the context, without a solution.
  6. Sometimes I may have a hint of a solution in my mind, however I try to be fully open to a different solution being the optimal one, which I can only learn based on speaking with people.
  7. The goal and result of this method is that often I’m not even the one who comes up with solutions, and the changes we make are more fully embraced.

Steps 1 and 2 are the hallmarks of a good leader, but it’s in step 3 where great leaders get separated from the good. It takes tremendous discipline to stop yourself when you think you know the answer. And rather than issue an edict to execute your solution, loop in the affected people, describe the problem that you’re seeing and the big-picture context that they may be missing, and let them come up with the solution themselves.

 

Advertisements
Problem & Context, even over Solution

Turn the Ship Around (Book Review)

I first heard of David Marquet‘s

Turn the Ship Around

in an Agile conference four years ago, and I added it to my reading queue. For whatever reason, other books kept getting ahead of it (a relatively rare event in my reading queue), until it was mentioned in a book I recently finished causing it to jump back to the top of the queue.

The book chronicles David’s personal story, taking command of an under-performing nuclear submarine, the USS Santa Fe, and transforming it into a top-performing one. What makes this book a worthwhile topic for this blog, is the way David chose to go about doing that: by pushing power/control/decision-making down the chain-of-command – in a complete opposite direction to traditional Navy doctrine.

The biggest lesson learned, in my opinion, from David’s experience is best summarized in his own words:

“Control, we discovered, only works with a competent workforce that understands the organization’s purpose. Hence, as control is divested, both technical competence and organizational clarity need to be strengthened.”

Many books and articles make the case for why pushing control/power/decision making down the org (often times erroneously referred to as “empowerment”) is important. But the tight coupling between doing so, technical competence and organizational clarity was illuminating to me. Reflecting on past situations when I hesitated to delegate control, or did so and was disappointed with the outcome, I can almost always attribute the root cause for my hesitation or disappointment to one, or both, of these elements.

Even though the quote I shared above is taken from the book’s introduction, this is not one of those would-have-been-better-as-a-10-page-HBR-article books. The book adds colors and nuances to this high-level idea, and breaks it down to specific mechanisms that David use to push down control, improve technical competence and enhance the organizational clarity. Many of which can be adapted from a submarine-setting to a corporate-setting (environment that are worth a more in-depth comparing and contrasting).

 

Turn the Ship Around (Book Review)

A Leader’s Guide to Deciding

A good piece by Steven Sinofsky on decision making and the critical role that it plays in an executive’s job:

A Leader’s Guide to Deciding: What, When and How to Decide

In this post, Steven tries to put some structure on striking the right balance somewhere in between the two extreme ends of the decision making spectrum: being in the center of a command-and-control scheme and fully delegating any decision.

He argues that decision making gets complicated as the organization scale primarily due the number of stakeholders that are being affected by the decision. Based on his experience, typical responsibility assigning schemes (RACI and the likes) tend to slow things down and push responsibility around.

He identifies 3 key pieces to solving the challenge:

  1. “The most important thing an executive must do is keep the output and velocity of the team at the highest level, and focused on doing the right things” – if you understand that this is your #1 job as an executive, you will spend your time, on the right things.
  2. “The real challenge is in trying to define decisions, isolate important ones, and then figure out the stakeholders for that one instance” (as opposed to finding the solution.
  3. Being clear, up front, first of all with yourself, but then with everyone else involved on the role that you intend to play in the project:
    • Initiator (10% of time). Kicking off new projects.
    • Connector (60% of time). Connecting people to others so the work gets better.
    • Amplifier (10% of time). Amplifying the things that are working well or not so there is awareness of success and learning.
    • Editor (20% of time) Fixing or changing things while they are being done.

For each of those roles, he provides a few examples, the communication tools you should use, the granularity of the guidance you should provide, the time you should spend playing this role and the necessary mindset to drive an effective outcome.

As a final note, Steven touches on the exception to the rule: “Don’t ever be worried about deciding in the most top-down, non-empowered, toe-stepping manner when facing a true crisis. That’s what leadership is all about”. He ties this advice to Ben Horowitz’s distinction between a “wartime” and “peacetime” CEO, but in my mind, it goes deeper than that. What Steven is describing here, in his own words, are the “complex” and “chaotic” pieces of the Cynefin Model which I’ve covered at length here. It all connects in the end…

 

A Leader’s Guide to Deciding

Decomposing Leadership – The Executive’s Trinity

Stephen Bungay gave a great talk in Lean-Kanban UK 2014 about

The Executive’s Trinity

His thesis, an elaboration of a framework first put forth by John Adair suggests that the skill sets required of an executive can be grouped into three major buckets:

  1. Directing – dealing with concepts (intellectual) – authority, responsibility, and duty of direction
  2. Leading – dealing with people (moral) – getting people to achieve objectives
  3. Managing – dealing with things (physical) – organizing and controlling resources to achieve objectives

Bungay17027Pages3

Using this framework, he then articulates the gaps that exist in the standard paradigm around the executive skill sets: while “managing” (they way Bungay defines it) often gets discounted, “directing” and “leading” tend to be merged together under “leadership”, even though the skills that are required to do each well are rather different (as one is dealing with concepts while the other is dealing with people) – which often leads to training people in one but not the other.

I know this sounds a bit abstract, so let’s bring it down to earth with a real world example. You know you have a good framework when others are using it without even knowing it.

Ameet Ranadive,  a Product Manager at Twitter, wrote a nice post recently:

What It Means to Be a Product Leader

In it, he decomposes product leadership into three components: Operational Leadership, People Leadership, and Thought Leadership.

Sounds familiar? That’s because it is. Ameet’s narrative matches Stephen’s framework exactly: operational = managing,  people = leading , thought  = directing.

 

 

Decomposing Leadership – The Executive’s Trinity

Leading Without Coding

Aaron Schildkrout published a lovely piece recently:

Leading Without Coding 

It’s a little long, but completely worth it. It it, he reflects on his experience, as a non-technical co-founder, leading the engineering team at HowAboutWe and what made him an effective leader despite being “non-technical”.

His summarizes his experience through six pieces of advice:

  1. Know the stack
  2. Become an expert facilitator
  3. Run the smartest ship
  4. Master the data
  5. Hire great people and replace yourself
  6. Ready yourself, inside

It’s a wonderful read but I actually think that Aaron’s overall framing is too narrow.  If you’re bought into the thesis that management is a career change, not a promotion, then managing people that are better individual contributors than you is the norm. Therefore, this is a much broader manifesto on how you, as a leader/manager, should be spending your time, focus and energy, regardless of the type of team that you lead and your personal background.

Consequentially, my only qualm with this piece is that “replacing yourself with a more technical leader” should NOT be the end goal.

BONUS: in this piece Aaron also references a 7-piece series about product leadership that he’d previously written starting with Unblocked: A Guide to Making Things People Love.  I’m not going to cover it in depth in this blog because while the principles that start in piece are great, the process implementations themselves vary in quality and broader applicability.

 

 

Leading Without Coding

Book Review: Leadership Agility

Just finished reading Leadership Agility: Five Levels of Mastery for Anticipating and Initiating Change by Bill Joiner and Stephen Josephs.

It’s a fairly well-written leadership development book offering a very compelling framework for assessing your leadership level and identifying the competencies you need to develop in order to evolve your leadership to the next stage.

Even though the authors acknowledge that there’s more to leadership than anticipating and initiative change and therefore keep the focus on “leadership agility”, given how much of a leader’s role is anticipating and initiating change, I view this as a book about leadership, period.

The first part of the book provides an overview of the framework and a good high level illustration of it, by replaying the same dinner conversation, each time with a person at a different stage of leadership agility.

The third part focuses on assessing your own leadership agility and charting a path for improving it.

The second part is the heart of the book, consisting of five chapters mirroring the five leadership agility stages in the framework: Expert, Achiever, Catalyst, Co-Creator and Synergist. Each stage is described through two perspectives (supported by case studies/real-world examples):

  1. An outside-in perspective: covering how a leader at each level anticipates and initiate change at three different scales:
    1. Pivotal conversations
    2. Leading teams
    3. Leading organizational change
  2. An inside-out perspective: covering how a leader’s five key competencies develop at each stage:
    1. Awareness & intent
    2. Context setting agility:
      1. Situational awareness
      2. Sense of purpose
    3. Stakeholder agility:
      1. Stakeholder understanding
      2. Power style
    4. Creative agility:
      1. Reflective judgement
      2. Connective awareness
    5. Self-leadership agility:
      1. Self-awareness
      2. Developmental motivation

The first perspective is summarized in the book  neatly in the book in the following table:

leadershipagility01

leadershipagility02

The second, however, is not summarized anywhere, which is one of the book’s greatest drawbacks. The good news is that I thought that creating one will be a good way for me to get more value out of the book. It’s a bit of an eye-chart, so I suggest printing it out if you want to give it a more thorough read:

leadershipagility1

leadershipagility2

PDF Version of Cheat Sheet

Book Review: Leadership Agility