Thinking in Systems

Take the bathtub. The tub itself represents a stock of water. Water flows in through the faucet and flows out through the drain.

In some software engineering systems we want to maximize stock, like developer knowledge within our team. If knowledge starts draining out and your bathtub runs dry, you’re going to have a bad time.

In other systems we want to minimize stock, as with customer requests. The flow to production is how we minimize lead time.

But most of the time we want to balance the stock. For instance, I don’t want an engineer on my team to feel overwhelmed and uncertain of priorities. So I’m careful. Rather than dumping the entire product roadmap on them, I selectively feed them pieces of the plan.

Resilience often requires a whole system view, which many of us don’t have or neglect to think about.

Instead, we focus on local factors that sometimes look like resilience – factors like stability and productivity.

Being local, we can see the effect of our changes earlier. Feedback loops are tighter. Conversely, feedback loops in resilient systems often lag and sometimes only manifest themselves in extreme cases.

All systems in the world interconnect. Complexity is essentially infinite.

But we need to have productive and pragmatic conversations, which require us to draw boundaries.

When we draw boundaries, we’re effectively saying, “For the purposes of this discussion…”

Framing systems as interconnected and boundaries as arbitrary human constructs can help software engineers focus on building solutions that deliver customer value. Here’s an example:

You’re building a 3rd party API integration. You diagram the system. Here’s the boundary where their system ends and ours begins.

Drawing this boundary can create both a useful but potentially problematic “us vs. them” mentality that ultimately your customer doesn’t really care about. Your customer just wants a working integration.

Reinforcing feedback loops come in two forms: virtuous cycles and vicious cycles.

Sometimes it just depends which side of the coin you’re on. Compounding interest is great for investors, not so great for debtors.

In software engineering, I focus heavily on the virtuous cycle of deploying frequently. By deploying frequently, we decrease risk and increase joy, which in turn make us want to deploy more frequently.

When faced with a complex system that’s not functioning correctly, look at the rules. Who controls the rules? What incentives drive their behavior?

Your perception of a malfunctioning system may drastically differ from the opinion of a rule maker.