The context gap: another source of micromanagement

I'm being micromanaged to death. My boss keeps shifting the goalposts and then denies it later! If I try to do a good job, I'm "wasting time". If I don't, I should have taken more initiative. I can never win. I'm useless. I quit.

If any of that resonates, you have my utmost sympathies. But before you quit, I want you to try tweaking the order in which you do your work — it could help.

This post is aimed at Change Professionals — people tasked with designing and coordinating change to a product or process in order to solve a problem. In software development, these people have job titles like Business Analyst, Product Manager, UX Designer, Change Manager, or Solutions Architect. Very different jobs, very different deliverables, but the same core: designing and coordinating some aspect of change.

Change Professionals are assigned work via a brief — a description of the work, usually including a goal and some background. Sometimes it's a formal document, sometimes a few bullet points in Slack, sometimes just verbal.

Whatever form it takes, most people do the same thing when they receive one: they start work on their artefact. It's what everyone recognises as their job, and it's what everyone wants done as fast as possible. So you make decisions using your expertise — until you hit one you can't make. You don't have enough information, or a constraint in the brief doesn't mesh with reality. So you ask someone. You hand the decision to them.

That's where the trouble starts.

Micromanagement is when someone else repeatedly makes decisions you should be making — ignoring your expertise and stealing your autonomy. There are lots of reasons it happens, but I want to call out one that's prevalent, isn't really anyone's fault, and is something you can actually do something about.

The context gap doom loop

The context gap is the gap between what you know about the problem context, and everything you need to know about it, in order to make decisions using your expertise.

The big problem with context gaps is if you don't fill them, they grow. It works like this:

  1. To make your artefacts you need to make decisions.
  2. To make decisions, you need to understand the problem context.
  3. If you don't understand enough context to make the decision, someone else makes it for you.
  4. Because someone made the decision for you, the context gap is now a bit bigger.
    (Decisions are also problem context. They're a bit like requirements/constraints. Once they're made, you need to ensure they aren't contradicted by any future decisions. If you do want to make a contradictory change, you need to know why the decision was considered good in the first place. You need to know the problem context that the decision was based on).
  5. Now you're even less likely to be able to make future decisions.

Context gaps create a doom loop just by existing. The existence of a context gap means other people make decisions for you. People making decisions for you increases the context gap.

Actually it's more like a doom spiral. As more and more of your decisions are made by other people, more and more of your autonomy is taken away. Eventually your role is reduced to execution work. Other people make decisions and then tell you what to do. Put these bullet points in a slide deck. Add this into the speadsheet. Mockup my PowerPoint design in Figma.

While there's lots of reasons why micromanagement exists, a context gap is one you can resolve.

Filling the context gap

Instead of starting with artefacts, start by filling the context gap. I do this by writing my own brief-like document – I call it a Change Doc – that I then do my work from. It's a personal space for me to record and analyse problem context. Here's how I do it. If you're starting on a project, open a new document and follow along.

Change Docs have four parts:

1. The What (the goal)

Using the brief and any other information you've been given, write down what's meant to happen as a result of the project. Be specific about who it affects if you can. "Reduce customer attrition" is a start. "Reduce attrition of customers with revenue under $10k" is better. It helps a lot to have a clear understanding of who you are making decisions for.

2. The Why (the rationale)

Write down an argument for why the problem is worth solving. Answer things like:

The Why is where most of the problem context lives. Start with a draft now, but later on you'll update this to be a logical argument that supports the problem and all the effort that is going into solving it.

3. The Measures (what success looks like)

Write down what you could measure to know the goal was achieved? "We delivered it" isn't a measure. "Attrition of customers with revenue under $10k reduced by 10% within three months" is.

I once worked on a project to deliver an online form. Before starting, I asked what success looked like. The answer was, "people use it". Okay, sure — how many people did we hope would use it? Turns out one use per year was considered a success. One. What was going on? The question revealed the real goal: satisfy a compliance obligation, minimum effort required. With that extra context, I knew how much time to spend on this work (not much!).

Measures do two things: they tell you how to evaluate the work later, but more importantly they make the goal and problem context more specific.

4. Ideas (the proposed solution)

If the brief includes a solution, capture that too. Then ask yourself or the person who gave it to you, why that solution is a good idea. People who struggle to articulate why a problem matters often find it much easier to explain why their solution is great. The answer is usually the same thing, just approached from the other direction. And the gaps in their reasoning are gaps in the context.

What to do with the gaps

When you write these three/four sections – What, Why, Measures, Ideas – you'll almost certainly notice gaps. Things the brief didn't mention or glossed over. Evidence that the problem exists. Who made a particular call and why.

Make a note of these context gaps as you go, then afterwards, work through each gap you've noted and fill it. Many you can resolve quickly – a conversation with a colleague, a look at some data. Others might need a stakeholder meeting or a quick test. When you're setting meetings, frame it simply so you don't spook people: you just need “a bit more information” before you get started. Fill the context gap.

Final thoughts

Filling the gap at the start of the project is almost always faster than dealing with the fallout later – and it's just plain easier.

Having said that, you'll always have a bit of a gap as you work on a project. If you completely filled the context gap at the start, you would have spent too much time filling it, but there's a sweet spot for how wide the gap should be.

If you're being micromanaged, you likely need to be getting more context up front. If you can answer every question you can think of at the start, that's about right. If you are afraid of starting because there could be unknown unknowns, you're trying to fill too much.

Once you start work, keep your Change Doc (context document) updated. New context will emerge that you couldn't have anticipated. When it does, go back and check: does this change the Why? Does it affect the Measures? Does it reframe the What? Often a clearer understanding of the problem reveals that the original goal was slightly off – it focused on a symptom when the root cause could be fixed with far less effort.

And if your boss still tries to make decisions? That's fine. Ask them why. Get the context behind the decision, add it to your document, and keep going. The goal isn't to stop them from deciding – it's to make sure you understand enough that you don't need them to.