The Power of a Systems Approach

What makes for a useful methodology or philosophy is its ability to predict future events accurately. Almost every approach can tell a good story by describing and explaining past events with selective perception and post-hoc analysis.

In trying to come up with a tagline for my website here, the result ends up being a bit buzzwordy: "empirically driven systems approach". My goal in this post is to elucidate exactly what that means, and why I use this approach to problem-solving. I don't use any specific framework or device but instead draw from many sources and my own experience. In this first post, I'll cover a few main tenets of my philosophy for problem-solving: systems thinking, considering secondary effects, and realist analysis.

Most broadly, systems thinking is about considering not only a specific problem in isolation but the environment that the problem lives in. To illustrate this, let's take an example where we have the larger context influencing our decision-making, then the same example, except this time with an outside influence.

Let's take an example that every software company has dealt with, hiring software engineers, specifically an early screening step. Many companies will take their cues from successful larger companies and do things such as ask questions you might find in Cracking the Coding Interview. It's easy to just copy from successful companies in this way, but based on the context of the company, this may screen out candidates that wouldn't be right for Google but would have been suitable for your company.

Another example would be hyper-focus on a specific task rather than the outcome it's supposed to contribute to. When teams get trapped into thinking about singular problems, they can become trapped into optimizing for the local maxima and lose focus on the goal they're working toward in the first place. Goodhart's law states that "When a measure becomes a target, it ceases to be a good measure." Turning a measure into a target, more broadly speaking, is focusing on a local maxima at the expense of the overall goal With systems thinking, we keep in mind the entire value flow from the end goal to the implementation, so we don't get stuck at optimizing for a step we derived from the goal, rather than the goal itself.

Understanding the context of a company's goals is easy enough, but systems thinking means we don't just think of a company in a vacuum. It has customers, competitors, state actors, and any number of other possible influences. Part of the challenge of systems thinking is separating the signal from the noise and not wasting time on immaterial influences. Let's think about some outside influences for our first example, employee screening. What other context might shape how a company does screening? Imagine a company that just blindly copies Google's interview process, but one that is generally a better fit for those kinds of programmers, as opposed to our first example. It seems this would be a good company to just wholesale copy a process, but what does it mean in a larger context? If you're trying to hire employees that would pass a Google interview, you're going to bias toward a specific kind of candidate, and that specific kind of candidate would probably rather be working for Google; that means at best you're going to end up with Google rejects. Given this outside context, it might be better to consider a different approach.

In the last section we looked at how the larger context can influence our decisions, but equally as important are how our decisions can influence our context. Systems thinking doesn't end at your decision or implementation, it extends to the effects those decisions make on other parts of the company or situation generally. Every decision made comes with a cost, and failure to understand this can lead to bigger problems than whatever the initial decision was trying to solve.

A very simple example of this is when someone from upper management calls for a new regular status meeting just to catch themselves up on something. This is great for the person calling the meeting; they have everyone involved in a project, ready to be called on on a weekly basis. For the company, though, what is the cost of having 5 or 10, or even more people joining a meeting for the sole purpose of telling someone from management something they could have found in documentation? It's a lot, and it's even more if you consider the cost of interruption and the discontent of an unproductive meeting.

Let's take marketing as another example. If you've worked at a company that wants to acquire users, you've almost certainly heard the phrase "conversion rate," and maybe seen some initiatives started to increase this number. It might be true in the context of the company's analysis of its sales numbers that increasing the conversion rate is best for the cash flow. However, a company that over-emphasizes this kind of short-term goal has the potential of giving the company a culture of higher time preference, signaling to its employees to choose the fast wins over the long-term health and development of the company. An over-emphasis on sales can also create resentment among product people who think more long-term, or apathy from developers who want to solve more interesting problems. Every decision has second-order effects, and with some thought, many can be anticipated ahead of time.

To solve a problem correctly, one must have an understanding of the situation as it is in reality. A realist analysis means putting pragmatism over idealism, understanding the goals and motivations of each of the parties involved, acknowledging constraints and limitations, and managing risks.

There is a place for idealism and improvement, but letting those into an initial analysis will cloud the result. I've seen companies fritter away months and years on projects and processes that had no chance of success, all because leadership couldn't cope with the reality of the situation, choosing to ignore the most critical part of the context rather than confront it.

Imagine you have a product that seems promising to start, but after 6 months the numbers don't look so good. On average, a new customer costs more to acquire than they bring in revenue, by a lot. By itself, this is not necessarily a cause for panic, but it's time to take a real assessment of the situation. Can anyone see a path to turning those numbers around by either cutting acquisition cost or increasing revenue per user? If the answer is no, then killing the product must be on the table; but many companies do not even bother asking this question, ignoring the reality of the situation.

That's about as concisely as I could describe my philosophy on the first go. It's not a framework or formula with steps to always achieve the right result, just tools I've picked up along the way. I continue to hone my skills by checking my predictions against reality, and updating my firmware if I made an inaccurate prediction that I could have made better.