The Case for "Eventually Consistent" Management

People often panic when two managers give slightly different answers. The instinctive reaction is "something is wrong" or "we're disjointed." But in distributed systems, we accept temporary mismatches as a necessary trade-off for speed—a concept known as eventual consistency. Instead of treating every management inconsistency as a failure, what if we viewed leadership teams like distributed databases that sometimes just experience latency before reaching a unified state?

Examples

The simplest examples come when someone asks me or my manager the same question (e.g. status of a project). We might give two different answers if we haven't synced yet, but that's fine because we will eventually be consistent. A momentary mismatch in answers isn't necessarily dysfunction; it's often just latency. Adopting an eventually consistent mindset lets us keep moving forward even knowing that occasionally we won't all have the same current information.

For example, an engineer asks you: "Are we prioritizing X or Y this quarter?" They ask your manager the same question. They get two answers that are directionally aligned but not identical. Both answers may be correct given the information available at that moment. Neither response is malicious or incompetent. The system is temporarily inconsistent, but still healthy. When in doubt, explicit communication reduces the error rate: 'This is my current understanding, but I need to sync with [peer] to confirm.'

Where does this approach not work? Anywhere you really need to provide accurate answers without speculation or later clarification. (In other words, you need strong consistency.) Two situations that come to mind for me are any customers or internal executives (more than a layer or two above my manager). In those cases, I prefer to get synced on the accurate information to avoid sending people off with the wrong understanding.

Origin in distributed computing

The Wikipedia definition is a good starting point:

Eventual consistency is a consistency model used in distributed computing to achieve high availability. An eventually consistent system ensures that if no new updates are made to a given data item, eventually all read accesses to that item will return the last updated value.

I first learned about eventual consistency in my last job working at DataStax. Our system was built with the distributed database Apache Cassandra which has tunable consistency levels for reads and writes:

Consistency level (CL) determines how many replicas must acknowledge a read or write for it to be considered successful. Higher levels (more replicas in agreement) yield stronger consistency guarantees at the cost of latency, whereas lower levels favor speed and availability at the risk of stale data.

This is a helpful Reddit post from a couple years ago with several good examples: What is eventual consistency good for?

Note: I wrote this post but credit to ChatGPT for good suggestions for illustrating this metaphor.