Building Software for The Infinite Game

The Infinite Game

Simon Sinek, an author and speaker on business leadership, advocates for playing the infinite game in business. Finite games are played to win. These are things like Chess, Football, Cricket, and so on. Infinite games are played to continue playing. You need to use the right mindset for the right situation, and Sinek argues that Business is an infinite game, not a finite one. After all, what do you “win” in business? Where is the “end”? It doesn’t exist. You can only keep playing or not. Sinek is very critical of the finite mindset, and for good reason.

The technology industry, and American business as a whole, is rife with finite thinking. These companies are concerned about their next investment round or quarterly report. “Winning” is having a good investment round or beating your quarterly estimates. It’s shipping your project and marking it done. This finite mindset has its place in business, but it’s when things are dire. “Winning” is survival. If you’re a startup trying to get investment, you are laser focused on doing what’s needed to get that investment. Drive user aquisition and sales, no matter the cost. You are in an existential fight for survival, and thus have a finite goal.

The trap I see businesses and teams fall into quite often is not knowing when they’ve transitioned from a finite game to an infinite game and thus keep using a finite mindset to play an infinite game. This is the sickness at the heart of American business. We’re all playing the game like it’ll have a winner. This infects all levels of business, from CEOs to individual contributors.

My personal rule of thumb for recognizing when this transition has occurred is reaching profitability. Profitability indicates that you are self-sufficient. You are no longer reliant on investment capital to run the business. Your expenses to keep the business running are less than your income. You’ve won the fight for survival, now you need to keep playing.

Finite Mindset in Software Development

The Finite Mindset manifests in software development most commonly by overindexing on delivery versus quality. When you’re fighting for your life, delivering features is key, since each one could attract or retain customers (and thus investors). This is a process of rapid iteration and experimentation to find the right mix of features that your target customers will pay for. It’s natural that quality will suffer during this process, because quality isn’t the point. Who cares if the code is sloppy as long as customers (and thus investors) like it?

The answer to that question is: the team working on it five years from now. Each sacrifice in quality incurs technical debt and that debt will build up over time. Like financial debt, technical debt can completely cripple you. You may use a credit card to fund your way through an emergency, but eventually the banks will come calling for their payments. Software is much the same, as poor code quality can make the system brittle and difficult to modify. It can introduce weird edge cases and bugs that damage the customer experience. You will pay for those tradeoffs in one way or another. Thinking otherwise is a symptom of the finite mindset. You’re playing to win, not to keep playing.

Your customers will also notice this finite mindset in the features. You probably have some failed experiments in the product and some awkward or sharp edges in core features. For instance, maybe you don’t allow customers to rename a resource because you’re using the display name as the canonical identifier.

Making the Transition

Playing infinitely means building a sustainable organization system that balances delivery and quality. Once you’ve identified that you’re starting to play infinitely (that is, profitable or shortly thereafter), you should do two things: 1) polish core features and 2) pay off some of that technical debt.

Many companies reward larger features over smaller features, which builds products with many large pieces of functionality that kind-of sort-of work. Google, whose promotion process is contingent on large feature delivery, is infamous for this approach, producing a huge quantity of underwhelming products that no one will buy into and will eventually be deprecated. This only works because 80.2% of Google’s revenue is from advertising. Google’s core feature set as a company is advertising, not Gmail or even Search. Those are just vehicles by which to deliver the core feature. Their core product is extremely polished and effective. This is what you need to do as well.

Now that you’ve done that hard iteration process and found a feature set that works for a customer base, identify those core features and polish them to an unnatural shine. Identify any awkward issues that diminish your customers’ experience and fix them. As Ron Swanson puts it, “Don’t half-ass two things. Whole-ass one thing.”

The approach to clearing technical debt is well-understood, but many businesses hesitate to actually execute on it because of the aforementioned obsession with large feature delivery. The people who know your tech debt best are the engineers who built the software system. Allocate more time for them to work on this and let them decide the priority. You will probably want a high-allocation phase where major issues are fixed, then decrease allocation to a maintenance level.

By the time this transition is done, you’ll have a stable software system that delights customers and can continue making money into the immediate future.

Building for Infinity

Now, the true transition to playing the infinite game happens. At this point, your product teams should start looking at features that build on the core offering and you should be in a fairly stable technical state. The question becomes how to maintain this.

Many companies and teams will get a set of requirements and ask themselves, “What is the minimum amount of work needed to achieve these requirements?” This question sets you up for failure, because you’re looking for the bare minimum in terms of quality and feature set for every given deliverable. Over time, your product will thus be bare minimums built on top of bare minimums with an endless collection of technical debt and quirky behavior along the way. You are starting with a low bar and raising it just high enough to pass.

Instead, ask a different question: “What is the idealized solution for these requirements?” When answering this, dream big. Imagine you had all the money and time behind you to do this. What would you build? What would really delight customers? Go deep on requirements. Build the ideal architecture. Write it all down like you’re actually going to do it. Explore the edge cases in the features and the software design. Look around as many doors and corners as you can for anything waiting to get you.

Once that’s done and you have consensus on the idealized solution, start applying the constraints of reality to it. What features are high-cost and low-value? What features are low-cost and high-value? Where can you draw clean subdivisions of the product for incremental delivery? As you do this process, you’ll produce a roadmap for the next 1-2 years. You’ll have a clear vision of what you’re building and why, but it will be broken down into smaller steps and pieces. You can make conscious choices about the technical debt you’ll accept instead of letting it happen accidentally. Start with a high bar and gradually lower it until you can jump over it.

This may sound very waterfall-y and thus scare off any of you who are Agile™. It’s not, though. You aren’t committed to delivering this long-term vision, nor are you planning every little piece of it up front. The vision is just that, a vision. It’s a guiding light. A direction to unify everyone in the organization. It provides a critical reference point for making decisions.

If your environment changes or new business needs arise, you can adapt. This approach will leave you with clean places to cut off the product and software architecture. Just do the exercise again for your changed environment and keep going.

The key benefit of this approach is agency. Rather than let technical debt or shaky product decisions pile up accidentally, you are choosing what sacrifices to make. In a later post, I’ll go into how to build a decision-making framework that allows you to make such decisions wisely.