Hard State vs Soft State Delivery

Why Micromanagement Fails

I was going to have a Wireshark Trace, but a literal Shark Eating Wires looks much cooler.

Having established what delivery means in my previous post, let's look at two fundamentally different ways of managing it. Understanding these approaches - and crucially, not mixing them - can transform how effectively your teams deliver.

Hard State vs Soft State

To explain these terms, let's start with a simple analogy. Imagine two ways of arranging to meet a friend:

Hard State: "I'll meet you at Starbucks at 2pm. If anything changes, I'll call you."

Soft State: "I'll try to get sometime in the afternoon - keep an eye on WhatsApp and I'll send you regular updates on timings as I go."

The first approach requires no mental overhead from your friend until something changes. The second keeps them checking their phone and thinking about the meeting.

The same patterns show up in management approaches:

Soft State Management

• Like UDP - constant updates needed to maintain state and no certainty that any update was received

• Continuous monitoring and adjustment

• Regular check-ins and course corrections

• The Manager owns and controls the connection and stays actively involved throughout

Hard State Management

• Like TCP/IP - clear handshakes and error signals

• Clear upfront agreements about deliverables

• The person delivering owns flagging any issues

• The manager can focus elsewhere unless alerted

A Tale of Two Organizations

Twenty years ago in a department of Cisco I was working with, I saw true soft state management in action. Team members worked on what they thought was most important, and managers circulated regularly, talking to people about priorities and adjusting course. It worked - Cisco was and is successful - but the drain on management attention was intense. Every manager needed deep context on every project to make good adjustments and anything they forgot to keep mentioning got dropped.

Contrast this with the company I worked for at the time, Data Connection, that was almost obsessed with delegated ownership and creating hard-state approaches. While it wasn’t perfect, the rigorous clarity of ownership, clear upfront agreements about deliverables, and focus on early issue raising meant that managers could focus on more strategic work, knowing their teams would alert them to problems.

The Micromanagement Trap

This brings us to micromanagement - the worst of both worlds. A micromanager tries to set up hard state agreements ("Deliver X by Friday") but then operates in soft state mode, constantly checking progress and suggesting adjustments - because the trust required for the hard state methods isn’t there.

This approach drains manager time and energy - they fundamentally get no gains from their team owning delivery, while simultaneously reducing team member agency and ownership and actually creating confusion about who owns delivery. People hate micromanagement in general, but I think this cuts to the heart of why.

Choosing Your Approach

I’ll be totally honest here - I’m very strongly in favour of hard-state delegated ownership, but I’ve genuinely seen soft-state management working successfully too. While both can work, they have different costs and benefits.

Hard State Benefits:

• Scales better (managers hold less state, teams hold less additional state)

• Builds ownership and trust

• Clear accountability

• Lower management overhead

Soft State Benefits:

• Good for highly uncertain or highly collaborative work

• Easier to identify issues and course-correct quickly

• Works well with very junior teams or where you correctly don’t trust the team yet

Looking at these side by side, it’s clear to me that Soft State is a place it’s fine to be temporarily, while you’re busy working to build with your team into a Hard State future.

Making Hard State Work

If you're moving towards hard state management:

1. Be explicit about expectations and what success looks like.

2. Welcome early warning of issues and never punish people for raising problems

3. Agree a cadence of check-ins where the people provide you with an explicit “Yes it’s good.” - much like keep-alive messages.

4. Trust that no news is good news (this is the hard one!) Resist the urge to "just check in". Remember: every time you ask for an update on something that's on track, you're teaching your team that you don’t really trust the hard state agreement. You're saying "Actually, I'm worrying about this even though you haven't flagged an issue."

Addendum: The Hidden Cost of Context Switching

There's another crucial benefit to hard state management that's often overlooked: it respects the different working patterns of managers and individual contributors (ICs).

A manager's day is naturally filled with context switches - they move from topic to topic, team to team, dealing with various issues as they arise. In fact, good managers become expert at rapidly switching context and maintaining multiple threads of work.

Individual contributors, on the other hand, often need long periods of uninterrupted focus to do their best work. A developer deep in solving a complex problem, a tester exploring a tricky edge case, or an architect designing a new system - these tasks require deep thought and concentration. Each interruption doesn't just cost the time of the interruption; it breaks the mental model they've built up, often requiring significant time to reconstruct their train of thought.

Hard state management respects this difference. When an IC hits an issue, they can choose when to surface it to their manager - perhaps finishing their current thought process first, or reaching a natural breaking point. The manager doesn't need to interrupt them for updates because they trust issues will be flagged appropriately.

Contrast this with soft state management or micromanagement, where the manager might interrupt at any time to "just check in." Even if these interruptions are well-intentioned, they're essentially prioritizing the manager's context switching convenience over the IC's need for focus time.

This is why "drive-by management" can be so destructive to team productivity, even when the individual interruptions seem minor. Hard state protocols protect your team's focus while ensuring important issues still get surfaced - just at times that work better for everyone.

---

This is the second post in a loosely connected series about delivery. Next time we'll look at how the language we use - especially the difference between "need" and "want" - shapes our ability to deliver effectively.