Management patterns

Wiki home > management patterns.html

Management patterns

I have a very "systems" approach to work. Over time I've learned several management patterns to help me structure my work. Here are a few I've found most helpful.

Plan/Do/Check/Act (PDCA)

Also known as the "Deming cycle," Plan/Do/Check/Act describes the four steps to take when doing… anything:

  • Plan: create a plan (based on your understanding of the world)
  • Do: implement the plan
  • Check: compare actual reality vs. what you had planned
  • Act/Adjust: make changes based on what you learned when checking.

The core of PDCA is the "check" step. I'd argue this is actually the core of any improvement framework: uncovering your (invalid) assumptions through reflecting on reality.

"Deep reflection"

Deep reflection is a very thorough "check" approach to reviewing what you have done. To do a deep reflection, get take a blank sheet of paper, turn it sideways (landscape), and then split it into four columns:

  • Assumptions
  • Thinking
  • Actions
  • Outcomes

Then, write down one or more observable outcomes that you want to reflect on. For example, maybe you just completed a small project.

  1. What observable outcomes occurred?
  2. What actions led to those outcomes?
  3. What thinking led to those actions?
  4. What assumptions led to that thinking?

This technique can help greatly in uncovering unproductive assumptions.

RUN/GROW/TRANSFORM

When you are thinking about new work, work can be of three types:

  • Run: keeping things going more or less as-is, following existing patterns.
  • Grow: developing a new service or capability that is still fairly well-understood.
  • Transform: work needed to do something totally new.

The way I like to think about these categories is:

Run Outcomes known Methods known
Grow Outcomes known Methods unknown
Transform Outcomes unknown Methods unknown

These categories help you understand risks and how to manage the associated work.

Evolutionary vs. revolutionary approaches

When trying to change an organization, many managers attempt a "revolutionary" approach: we're going to switch to a new system; we're going to implement a completely new process; we're going to fundamentally restructure how we're organized.

There's a time and a place for revolutionary changes, but revolutionary changes often roll back later when management changes focus.

In contrast, evolutionary improvements–identifying smaller changes that emerge from the organization–are much slower to implement, but tend to "stick."

When considering how to make improvements, don't discount an evolutionary approach.

Improvement through expansion and contraction

When starting a new initiative, I often begin in the "expansion" phase: I am trying to brainstorm and come up with any possible idea. In the expansion phase, I'm trying to understand the playing field and what is possible. I don't know enough about the situation to know the best approach (or even a good approach); coming up with possibilities helps me be able to test ideas against one another.

There then comes a time when it's time for contraction: weeding through the ideas and possibilities for what is actually feasible right now, and what seems like the best approach given our current knowledge.

I have found it useful to call out when we're in each phase. People who are less excited about brainstorming are sometimes more willing to participate when they know that the contraction phase (of weeding) will come; people who are worried about the railroading of an idea are included in the expansion process and they can see participants listening to one another as the field eventually is winnowed.

This cycle can then continue after each "basecamp" or iteration of an implementation.

Cynefin framework

I've recently (as of 2020) been learning about the Cynefin framework. It describes five "domains" of work:

  • Simple: well known methods and outcomes. There can be "best practice." For example, a routine process like grocery check-out.
  • Complicated: clear outcomes but unclear methods. Experts are needed. For example, lawyers reviewing a contract.
  • Complex: a system with no clear linkage between inputs and outputs, where you need to use the "Disrupt and respond" approach. For example, a board of directors managing a church budget.
  • Chaotic: a system under duress, usually due to outside forces. The goal is to staunch the bleeding and keep things running to the extent possible. For example, airplane companies after 9/11.
  • Disorder: you're not sure which of the domains you're in.