Alexander Bird Software • Blog

Learning to build useful, valuable software as part of a team.

The Natural Micromanager

I've been thinking about how we decide what to do next, and how we share that with others.

I've noticed that when deciding what to do next, folks tend to first develop some insight about the work, and then think of appropriate actions. It's tempting to share the actions (they're much more concrete). It's more helpful to share the insight you've had, and leave the actions up to the person who's going to be doing them. This applies to areas of technical leadership (on the topic of just in time design) and to people leadership (on the topic of delegation and micromanagement).

Here's an oversimiplified version of the process as I see it for an individual:

Block diagram showing me (the main block) reflecting on observations,
      direction from my leaders, my past experiences, and ideas from others to
      produce insights which lead to actions and then results

As the individual steps into leadership (technical leadership, people leadership, or informal peer-to-peer leadership), they're faced with the question of how to share their success with others. How can they equip others to do great things?

Often the process of converting observations, experience, ideas, and other inputs into actions is informal (sometimes not even put into words or structured thought). In general, it's easier to think about the problem and suggest actions than to think about the problem and share something that makes it easier for someone else to think about the problem.

So, in an effort to help one another, we share what we can: the list of actions that we would take if we were to do the work:

An extension of the previous block diagram, this time "doing" is
      replaced with "delegating" and I am passing "tasks to do" to a team mate.

This is unfortunate for at least two reasons:

  1. The team mate is closer to the action; their observations are more relavant than the leader's for this task. Actions based primarily on the leader's observations won't be quite right.
  2. The team mate continues to generate their own insights about the problem... but since they're acting primarily on the leader's instruction, there's no good outlet for their insight. It's frustrating to have good ideas and not be able to put them to use.

The challenge, as I see it, is to change the interface between the leader and the team member from delivering tasks to do to delivering advice and vision (intended outcomes). If the leader can share their insight about the problem, and frame a clear intended outcome (maybe with some advice about possible actions), then the person doing the work can start exercising their internal insight generation engine to produce their own action list. It yeilds better results, it's more rewarding, and it prepares them to lead.

A modified version of the previous diagram, this time I am sharing
      insights instead of tasks to do with my team mate, and they are producing
      better results and are not frustrated.

So what now? For me, I'm practicing sharing insights and intended outcomes instead of advice about specific actions. It's a major mindset shift. It's difficult to take my informal reflection process, interrupt it half way through, and share the midpoint result instead of the end result.

There's also an aspect of this that ties back to wanting to be in control: when I'm working solo, I can decide what I do. When I'm coaching others, I don't get to decide what gets done. To be a leader, I need to let go and trust my team mates. I'm trying to lean into that. It's a safe, healthy fear like what you get just before cliff jumping into water.

To me, it boils down to involving and trusting one another instead of bossing each other around and hoarding our knowledge. It's hard work to shift into healthier ways of working together, but I consider it a worthwhile pursuit.

Something to add? Continue the conversation on Twitter

Written 2022-04