Managing Systems
I find myself coming back to watch this talk by Richard Cook nearly every 3 months.
I highly recommend watching this video when you have the chance. It’s an entertaining talk and it’s shaped so much of how I think and operate complex systems.
In the video, Cook describes the properties of complex systems and talks about how all organizations and people typically act and react to system failures. He uses Rasmussen’s Risk Management in a Dynamic Society: A Modelling Problem.
This seems complex, but it’s actually quite simple, and I believe it’s the key to being a successful strategic thinker in systems and organizations. This model works in every system I can think of — applications and products, computing systems of limited resources, and people, teams and large-scale organizations.
Accident Boundaries and the Operating Point
In any system, there are failure or accident boundaries that a system cares about. For instance, in building a startup there are typically product, engineering, finance, marketing, people/HR, customer support and sales metrics that teams care about.
Within the accident boundaries there’s an operating point, which describes how balanced the system is and what it’s biased towards.
The operating point is constantly in motion and is often pushed close to a failure boundary. For instance, if a company is too aggressive in focusing on growth, it may push product teams to ship too early, thus crossing a Product Quality failure boundary. Once a team recognizes that the operating point has passed the Product Quality boundary of failure, it’ll apply a counter gradient to ensure this doesn’t happen again.
It’s often in the nature of reacting to crossing an accident boundary that teams push the counter gradient too far in the other direction. For instance, in the case when a team crosses a Product Quality boundary, they may be likely to push back against Growth/Sales much more than may be needed, and it puts the operating point closer to the growth boundary of failure. If the operating point crosses this boundary, then an organization may be in business trouble.
Like this, there are many pendulum swings of the operating point within a complex system of sensing and adapting.
The problem is we never truly know where an accident boundary is — we only know when we’ve crossed it. (i.e. the site is down, a great employee just left, we lost a big customer, etc.)
Marginal Boundaries
In order to improve the resiliency of a system it’s important to set up marginal boundaries — a signal, alert or safety measure to keep an operating point away from an accident boundary.
Setting up marginal boundaries is incredibly important for someone operating a system to sleep well at night — knowing there are things in place to prevent the operating point from crossing an accident boundary. Marginal boundaries also help you focus on a different part of the system without worrying about an accident boundary that has a good marginal boundary set up.
Normalization of Deviance
So why, after setting up marginal boundaries, do we seem to still see systems fail? Richard Cook describes that over time, the operating point will test the marginal boundaries. For instance, after a process or rule has been in place for a while, we forget the original reasoning for why it was set up. And we’ll decide we can do without a certain measure.
That means it becomes nearly guaranteed that when you’re not focusing on a part of the system, the operating point will find ways to push past the marginal boundaries and closer to the accident boundary. And only after an accident happens do we typically see a corrective action.
Systems are naturally poised to fail, and only over time, through continuous learning and improving the marginal boundaries, does a system become more and more resilient.
Crossing Accident Boundaries
Every organization I’ve been a part of (an organizational system) has crossed accident boundaries many, many times. Each time, the goal is to learn from it, sense and react, and push the operating point the other way. These are two of the biggest failures I’ve seen companies go through, and what there is to learn from them:
- Getting hacked (like the one I dealt with at Buffer). No one expects their systems to be vulnerable, and no one knows where the accident boundary is for keeping their systems secure. A small startup doesn’t expect its systems to be the target of a sophisticated, multi-vector attack. After an experience like that, and after learning the current state of web security, the operating point gets pushed far away from that boundary (a good thing). Best practices and monitoring get set up to improve the focus on security and ensure that boundary is never crossed again. Some of these processes may come to be viewed as a burden by those who haven’t experienced a hack before. The challenge is that no organization will ever truly know where the accident boundary for security is. So it’s important to sense and react when the operating point is close to a marginal boundary for security. It’s never a guarantee that things are completely safe, so it’s better to continue adding more and more monitoring and rules, enforce best practices and assume the worst. Though you still have to be mindful not to cross a productivity, usability and convenience accident boundary.
- Over-hiring and having to make layoffs. This is the mistake of not knowing where the economic boundary of failure is for the business, and not forecasting the hiring plan against growth well enough. Once a company recognizes it has crossed this boundary of failure, it has to put in counter gradients like layoffs, cutting back perks, etc. Those actions push the operating point away from the economic boundary of failure and closer to the accident boundary that makes the company not a great place to work, thus risking voluntary churn. That is something to be so mindful of, and it means keeping a close eye on the marginal boundary there (through regular team surveys, manager 1–1s, encouraging feedback, CEO AMAs, etc.). The lasting fix is setting up better marginal boundaries to ensure there is key oversight on the finance boundary, including hiring someone to own it, like a VP of Finance.
Trade-off thinking
I’ve found building an organization very similar to building complex web or mobile applications. Every day as an engineer, you’ll make hundreds of decisions among trade-offs. That’s similar with management and organizational strategy. Of course, the impact of failures is an order of magnitude worse — making mistakes that affect people’s lives is much worse than an app going down (in most cases).
Making trade-offs comes naturally to engineers who build systems. There’s rarely a situation where there’s a right and a wrong answer. Instead, you continually make decisions that have benefits and pitfalls. (Angular vs React… AWS vs GKE vs self-hosting, SQS vs RabbitMQ.)
Management is similar. There’s rarely a right and wrong answer. Building systems is great practice for management and trade-off thinking. It’s why I strive to ensure the Engineering Managers I work with (and myself) code. I believe coding brings a level of comfort in making trade-off decisions.
Monitoring and Alerts
A key concept I’ve taken away from building systems is monitoring and alerting. When I first started building web-app systems, the monitoring and alerting offering landscape was primitive. I would simply check Twitter or our support inbox to see if there was a trend, or check if we were down. I had several Twitter searches following a similar form to: “to:@ourapp down.”
Not a single hour of the day would go by that I wouldn’t check that Twitter search.
Discovering alerting through tools like AWS CloudWatch and PagerDuty was a non-linear step in my systems understanding. Now I had a way to assess and set up marginal boundaries of failure, and would receive a notification if any part of the system was off.
I’ve tried to take the same philosophies into management. I try to assess and predict the accident boundaries and set up marginal boundaries as oversight. I’ve on a few occasions had more than 10 people reporting to me — at that point it’s definitely not possible to give equal attention to each person, however I would try to encourage everyone to share regular thoughts with me in Slack, and I’d try to create a culture on my team of speaking up when something is off. I’d set up dashboards and alerts on quantifiable metrics (customer support ticket numbers, bug numbers, budgets). In our weekly exec meeting, we’d report and review those numbers. Much of the purpose of those weekly exec meetings was for us to come together and assess where exactly the operating point was within the company’s system of marginal boundaries.
I’ll never know where all the accident boundaries are, but when an accident does happen, I know it’s part of the ballgame and I’ll ensure we apply counter gradients and improve our marginal boundaries for the next time.
When you’re building a system, whether it’s growing a web-app, building a company, providing anesthesia to a patient, or even leading a nation, it’s literally a balancing act. I hope this post helps to describe the dynamics and give terms to an abstract but important concept.