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
This is not a software book. Simon Sinek is a leadership thinker and speaker, and Start With Why began as a TED talk before becoming one of the most-watched in history. The book is about marketing, business culture, and the psychology of why certain organisations inspire loyalty while others don’t. And yet, read it in 2026, and it feels like something else: a manual for the most consequential shift happening in software right now.
In my review of Thinking in Systems, I argued that the job was never the typing. The robotic welding arm doesn’t eliminate skilled workers; it changes what skill means. The developers who thrive are those who understand the whole system, not just their station within it. Start With Why is the logical next chapter of that argument. If systems thinking is the skill that persists when the WHAT is automated, purpose is the foundation that makes that skill worth anything.
Sinek’s central model is the Golden Circle: three concentric rings labelled WHY, HOW, and WHAT. Most organisations operate from the outside in: they know what they make, they can describe how they make it, and they never quite articulate why. The organisations that generate lasting loyalty work from the inside out. Belief first, and everything else follows from that.
When a Large Language Model (LLM) can generate a working codebase in an afternoon, the WHAT is no longer the hard problem. The hard problem is knowing what to build and why it matters. That is the question Start With Why was written to answer.
What Is Your Purpose?
Very few people or companies can clearly articulate WHY they do WHAT they do. When I say WHY, I don’t mean to make money — that’s a result. By WHY I mean what is your purpose, cause or belief? WHY does your company exist? And WHY should anyone care?
Most software teams can answer the WHAT without pausing for breath. We build APIs, we ship features, we maintain systems. The HOW comes almost as naturally: agile delivery, test-driven development, continuous integration. But WHY? That is where the sentence trails off.
It is not a question of intelligence or effort. It is structural. When the work arrives as tickets, the purpose is already pre-packaged: deliver the ticket. When the roadmap is measured in velocity, the purpose is already defined: move faster. Neither of those is a WHY. They are both WHATs dressed up as purpose.
AI tools compound this. When you can generate a working feature from a prompt in minutes, the pressure to keep producing is immense. The question of whether you should produce it gets quieter. Sinek’s challenge is to make that question louder. Not because productivity is the enemy, but because productivity in the wrong direction is expensive.
The Golden Circle
WHY is just a belief, HOWs are the actions we take to realize that belief, and WHATs are the results of those actions. When all three are in balance, trust is built and value is perceived.
Sinek’s model is worth understanding as a layered system, not a slogan. The WHY is the foundation: a belief that does not change based on market conditions or competitor moves. The HOWs are how that belief shows up in behaviour: hiring decisions, architectural choices, how a team handles a production incident. The WHATs are the visible output: the products, the code, the deliverables.
Most organisations build from the outside in. They decide what to build, figure out how to build it, and assume the WHY will emerge somewhere along the way. It rarely does. What emerges instead is a company with capable processes and competent output that cannot explain why anyone should choose it over any of its competitors.
The balance Sinek describes, with all three in alignment, is what produces trust. Not trust as a metric, but trust as the condition under which teams make good decisions without consulting a policy document first. It is also the foundation that psychological safety is built on. Teams that share a WHY do not need a framework to tell them how to behave under pressure.
They Buy the Why
It’s worth repeating: people don’t buy WHAT you do, they buy WHY you do it.
In software, this translates with uncomfortable directness. Users do not choose your product because it has more features. Clients do not hire your team because you listed more technologies on your profile. They choose you because something in how you present the problem, and why you believe it matters, matches something in how they experience it.
When AI can produce functional software on demand, the WHAT becomes a commodity faster than most engineers are comfortable acknowledging. A client can generate a working prototype from a prompt. What they cannot generate is confidence that it is solving the right problem, built by people who genuinely understand the stakes.
This is exactly why we published our own Why at RJJ Software. It is not a mission statement written by committee. It is a direct consequence of reading this book and asking the question honestly. The answer was compassion: for clients, for their customers, for the problems they are trying to solve. That did not change what we do, but it made it much clearer why we do it.
If You Can’t See It, They Don’t Know It
If we can’t easily assess a company’s WHY simply from looking at their products, services, marketing, and public statements, then odds are high that they don’t know it either. If they did, so would we.
This is the test. Not “do you have a WHY statement?” but “is your WHY legible in everything you produce?”
Donella Meadows made the same argument in Thinking in Systems, from a different direction: judge a system by its behaviour, not its stated intent. The frog that always catches flies has catching flies as its purpose, regardless of what it might claim. Sinek is saying the same thing about companies: what you consistently produce reveals what you actually believe.
For software teams, this is a useful lens for product decisions. If users cannot tell why your product exists from using it, if the feature set does not suggest a coherent belief about what problems matter, the absence of WHY shows up in the interface. It manifests as features that contradict each other, onboarding flows that assume the user already knows what they need, and support queues full of questions that a clear WHY would have pre-empted.
The Best Practice Trap
The idea that copying WHAT or HOW things are done at high-performing organisations will inherently work for you is just not true. Put simply, best practices are not always best.
This one lands differently depending on how many years you have spent in software. Early in a career, best practices feel like safety. There is a named pattern for this problem; you follow it. There is a framework the industry has converged on; you use it. The accumulated wisdom of more experienced developers has produced a set of defaults; you adopt them.
None of that is wrong, exactly. The danger is when best practice becomes a substitute for thinking. When the question “why are we doing this?” gets answered with “because that is how it is done,” the WHY has been outsourced to industry consensus.
AI coding tools will surface best practices constantly. They have been trained on the patterns that appear most frequently in public code, which makes them very good at producing the HOW and WHAT that the majority of teams have converged on. What they cannot tell you is whether that convergence is right for your context, your team, or your users. That judgement requires a WHY specific enough to discriminate.
Purpose Over Prescription
Great companies give their people a purpose or challenge around which to develop ideas rather than simply instruct them to make a better mousetrap.
There is a management pattern in software that mistakes specification for leadership: define the ticket, write the acceptance criteria, assign the story points, review the pull request. It produces teams that are very good at completing tasks and less practised at solving problems they have not been handed.
Sinek’s framing inverts this. The challenge is not “build a feature that does X.” The challenge is “we need our users to be able to achieve Y: work out the best path.” The first produces a delivery. The second produces ownership.
This distinction matters more as AI takes on more of the former. If the job is implementing a ticket, an AI assistant can do a significant portion of that work. If the job is understanding the problem deeply enough to know which ticket should not have been written in the first place, that requires something an AI cannot supply: genuine engagement with the WHY.
The View From the Bottom of the Tree
Some in management positions operate as if they are in a tree of monkeys. They make sure that everyone at the top of the tree looking down sees only smiles. But all too often, those at the bottom looking up only see arses.
When WHY is unclear, organisations compensate with hierarchy. Purpose gets replaced by structure, and structure gets optimised for whoever holds formal authority. Managers manage upward, reporting the metrics that make the tier above them comfortable, and the people doing the actual work develop a different view of the organisation.
This is not usually malice. It is what happens when there is no shared belief to anchor decisions to. Without a WHY, “are we doing the right thing?” gets replaced by “are we making the right people happy?” Those are different questions, and the second one produces the dynamic Sinek describes with such economy.
The antidote is not a restructure or a new performance framework. It is clarity of purpose, communicated consistently enough that people at every level understand what they are working toward, not just what they have been asked to work on.
Work On or Work Toward
Average companies give their people something to work ON. In contrast, the most innovative organisations give their people something to work TOWARD.
The distinction sounds subtle. It is not.
“Work on” is task-oriented: here is the problem, build the solution, mark the ticket done. “Work toward” is purpose-oriented: here is what we are trying to achieve, here is why it matters, figure out the best path and tell us what you find. The first produces delivery. The second produces the kind of ownership that leads to developers flagging problems before they become incidents, questioning requirements that do not serve users, and investing in the quality of their work because they are invested in the outcome.
In Thinking in Systems, Meadows describes intrinsic responsibility: the pilot in the front of the plane experiences the consequences of their decisions directly. Teams that work toward a WHY are intrinsically responsible in the same way. Teams that work on tickets are passengers.
Compete Against Yourself
When you compete against everyone else, no one wants to help you. But when you compete against yourself, everyone wants to help you.
In a market where AI tools are reducing the cost of building software, competing on output volume is increasingly difficult to sustain. If the measure of success is shipping features faster than the competition, you are in a race where the advantage erodes quickly and the finish line keeps moving.
Competing against yourself means measuring progress against your own trajectory: are you building a deeper understanding of your clients’ problems? Are you improving the quality of the judgements you bring to difficult decisions? Are you producing work that more closely reflects your WHY than what you produced a year ago? Those questions have no external benchmark, which means no competitor can answer them for you.
Sinek’s observation is that organisations oriented this way attract collaborators naturally. People want to contribute to something with a clear direction of its own, rather than something defined entirely by its relationship to everyone else.
You Don’t Invent Your Why
The WHY does not come from looking ahead at what you want to achieve and figuring out an appropriate strategy to get there. It is not born out of any market research. It does not come from extensive interviews with customers or even employees. It comes from looking in the completely opposite direction from where you are now. Finding WHY is a process of discovery, not invention.
This is the one that most founders and leaders resist. The instinct when building a business, a product, or a team, is to ask “what do we want to become?” and work backwards from the answer. Vision first, then strategy, then execution. Sinek’s claim is that this produces invented purpose, and invented purpose does not hold.
The WHY is already there, in the decisions you have already made, the work you have gravitated toward, the clients you have served best and why. Finding it means looking backwards with some honesty: what has been consistently true about how you approach problems, regardless of what the problem was? What would you do even if no one was paying you to do it?
For digital entrepreneurs, this is an uncomfortable question to sit with early. It is tempting to shape the answer around what the market rewards. But a WHY built to fit market conditions tends to collapse when those conditions change. A WHY built from what was always true about you tends to be the thing that survives.
Good Enough Is Real
A company doesn’t need to have the best products, they just need to be good or very good. Better or best is a relative comparison. Without first understanding WHY, the comparison itself is of no value to the decision maker.
Software engineers have a professional instinct toward quality that is, in the main, admirable. The problem comes when the pursuit of quality becomes an end in itself, disconnected from what quality is supposed to achieve. The best-engineered product that solves the wrong problem is still the wrong product. The architecturally perfect system that nobody uses is still a failure.
Sinek’s point is not that quality does not matter. It is that quality is downstream of WHY. If you understand why the product exists and who it is for, you know what “good enough” means in that context. You can make the tradeoffs that keep it moving without gold-plating the parts that do not serve users. You can ship something real rather than waiting for something perfect.
Sinek wrote this book to explain why Apple’s marketing worked when Dell’s did not. He was writing about advertising, consumer behaviour, and brand loyalty. What he was actually describing, and what becomes clearer every year, is the question that matters most in a world where the WHAT is increasingly cheap to produce.
An LLM can generate a codebase. It can draft a product roadmap. It can produce a reasonable approximation of most deliverables, given a detailed enough prompt. What it cannot do is tell you why the deliverable should exist, who it is really for, and whether you believe in it enough to stand behind it when it inevitably does not work the way you expected.
That is the WHY. And it has always been the job.
If you are working through what your WHY is, or thinking about how to build it into the way your team works, that is a conversation I have with clients regularly. Let’s talk.