This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: Continual Professional Development
Simon Sinek’s “The Infinite Game” keeps showing up in the conversations I have with technology leaders. The book argues that most of us are playing the wrong game; treating leadership like a finite competition with winners and losers, when the actual game we are in has no finish line. The shift in mindset has obvious consequences for how teams are built, how decisions are made, and how technology organisations adapt when the rules of the field keep changing. This post is my CPD review, focused on the parts of the book that have changed how I think about my own work.
The Importance of a Cause Greater Than the Product
The distinction between a finite and an infinite mindset is the engine of the whole book. A finite mindset chases short-term wins (the promotion, the quarterly target, the share-price bump); an infinite mindset is anchored to something the company would still be working towards even if those near-term wins disappeared. Sinek illustrates the difference with the publishing and music industries: both could have defined themselves by what they were actually for, which was spreading ideas and sharing music. Both instead defined themselves by the products they sold. iTunes and Spotify ended up being built by other people.
Publishers saw themselves in the book business instead of the spreading-ideas business and thus missed the opportunity to capitalize on new technology to advance their cause. They could have invented Amazon or the digital e-reader. Had the music industry defined themselves as the sharers of music rather than sellers of records, tapes and CDs they would have had an easier time in a world of digital streaming. By defining themselves by a cause greater than the products they sold, they could have invented services like iTunes or Spotify. But they didn’t… and now they are paying the price for it.
The lesson translates directly to technology leadership. The teams I have worked with that survive the disruption of their own market are not the ones with the best roadmap or the most current stack. They are the ones whose leaders can articulate a reason for the company that is independent of any particular feature, product, or technology choice. If your reason for being is “we sell .NET integration tooling,” a shift in the underlying platform can erase the company. If your reason for being is “we make life easier for the engineers building integrations,” the shift is just a change of tools.
Cultivating a Circle of Safety for Team Success
Psychological safety is what makes the rest of the book actionable. Without it, the team cannot raise problems before they become incidents, cannot challenge a senior person who is heading in the wrong direction, and cannot admit when they have personally got something wrong. Toxic individuals erode it by competing inside the team instead of with the outside world. Leaders erode it by accident every time they reward visible internal competition. Sinek calls the alternative the Circle of Safety: the environment in which honesty and admission have no penalty attached.
Toxic team members are often more interested in their own performance and career trajectories than they are with helping the whole team rise. And though they may crush it in the near term, the manner in which they achieve their results often contribute to a toxic environment in which others will struggle to thrive. Indeed, in performance-obsessed cultures, these tendencies are often exacerbated by leaders who encourage internal competition as a way to further drive performance. A Circle of Safety is a necessary condition for trust to exist. It describes an environment in which people feel psychologically safe to be vulnerable around their colleagues. Safe to admit mistakes, and, of course, ask for help with the confidence that others will support them instead of using that information against them.
This matches what I have written elsewhere about psychological safety in development teams. The single most reliable predictor I have seen of whether a team will catch a problem early is whether the team feels safe enough to flag it. That feeling is created by the leader, in front of the team, repeatedly. There is no shortcut.
💡 Reminder
The idea of both psychological safety and a circle of safety feeds directly into my ideas around Communities of Practice, which I wrote about recently.
Leadership as Enabling, Not Controlling
Sinek’s framing of leadership responsibility is one of the cleanest single-sentence reframes in the book. Leaders are responsible for the people who are responsible for the results, not the results directly. That sounds like a semantic distinction; it changes how a leader spends their day. The leader who is responsible for the results manages outputs. The leader who is responsible for the people creates the conditions in which their team can produce those outputs themselves.
Leaders are not responsible for the results, leaders are responsible for the people who are responsible for the results. And the best way to drive performance in an organization is to create an environment in which information can flow freely, mistakes can be highlighted and help can be offered and received. In short, an environment in which people feel safe among their own. This is the responsibility of a leader.
In technology specifically, this means resisting the urge to manage by output count when the engineers are blocked by something the leader could remove. The most common version of this I see is leaders chasing velocity while ignoring the build pipeline that takes ninety minutes. Velocity is the symptom. The build pipeline is the constraint. The leader who fixes the constraint earns the velocity for free.
💡 Tip
I’ve written about how the leader’s main role is to remove blockers rather than supervise the work, in my notes from Extreme Ownership.
Finding Worthy Rivals to Drive Improvement
Sinek’s reframing of competition is one of the parts of the book that took me longest to absorb. The infinite game is not played without rivals. It is played with rivals chosen carefully. A worthy rival is whoever, by being better at a specific thing than you are, gives you something concrete to improve towards. They do not have to be morally aligned with you. They do not have to be in the same market segment. They just have to be doing the thing well enough that you have something to learn from.
Having a rival worthy of comparison does not mean that their cause is moral, ethical or serves the greater good. It just means they excel at certain things and reveal to us where we can make improvements. The very manner in which they play the game can challenge us, inspire us or force us to improve. Who we choose to be our Worthy Rivals is entirely up to us. And it is in the best interest of the Infinite Game to keep options open.
In my own work, the most useful worthy rivals have not been competitors in the strict sense. They have been individual practitioners and small teams who do one specific thing better than I do, and whose work I can study without ego getting in the way. Anthropic’s documentation team. The Hugo core developers. The maintainers of the libraries I depend on. The point is not to copy them. The point is to know they exist, take them seriously, and let their standard set mine.
Adapting to the Unpredictable Future
This is the part of the book that lands hardest for technology leaders, because we are the ones whose assumptions go stale fastest. Sinek’s line that “what got us here won’t get us there” applies more directly to our work than to almost any other discipline. The stack that scaled the company to its current size is not necessarily the stack that gets it to the next size. The team that wrote the original system may not be the team that maintains it well. The architectural decisions that were right in 2018 are not automatically right in 2025.
What got us here won’t get us there, and knowing who our Worthy Rivals are is the best way to help us improve and adapt before it’s too late.
None of this means you change everything every year. It means you stay willing to challenge the decisions that have served you well, because the conditions under which they made sense are no longer the conditions you operate in. Most of the technical-debt crises I have seen at clients started as good decisions that nobody revisited.
Living with an Infinite Mindset
Sinek is fundamentally a values writer, and the closing chapters of the book are unsubtle about that. The choice he is asking the reader to make is which kind of player you want to be. The finite player’s measure is how much they got, by when, ahead of whom. The infinite player’s measure is what they were part of, and whether what they were part of will outlast them.
If we choose to live our lives with a finite mindset, it means we make our primary purpose to get richer or promoted faster than others. To live our lives with an infinite mindset means that we are driven to advance a cause bigger than ourselves.
As a technology leader, that choice has practical consequences. The infinite-minded version of the work is willing to invest in things that will pay off after the next funding round, the next quarter, the next contract. It is willing to be slower in the short term to be sustainable in the longer one. It is willing to spend on the build pipeline, the developer experience, the documentation, and the team’s psychological safety, because those are where the compounding happens.
I recently discussed this framing with Bojan Magušić on The Modern .NET Show, in the context of Azure Security. The argument we ended up at was that security in particular only makes sense as an infinite game. Treating it as a finite one (the audit passed, ship it) is how the breach gets built. You can listen to that episode here: The Infinite Game Meets Azure Security with Bojan Magušić.
If you’d like practical guidance on applying an infinite mindset to your technology organisation, let’s talk.