Purpose Is Everything
How to Set a North Star and Then Actually Deliver on It
Purpose Is Everything
How to Set a North Star and Then Actually Deliver on It
Maryland part of the Appalachain Trail
I once worked at a company whose mission statement was printed on the back of every employee’s badge. I wore that badge every day for two years. I couldn’t tell you what it said. Not because I have a bad memory, but because the mission statement had nothing to do with my day to day work. It was a sentence assembled by committee, approved by legal, and printed in a font so small it was clearly designed not to be read. It mentioned “delivering world-class solutions” and “empowering stakeholders.” It could have been the mission statement of a hospital, a defense contractor, or a mid-range hotel chain, and nobody would have noticed the swap.
This is what happens when purpose is just a slogan on the wall instead of something people actually follow.
Still, the real purpose, the kind of team a manager can refer to when deciding what to build next, is the most valuable thing a manager can give. It’s more important than process, tools, or even extra people. Purpose means having a clear, honest answer to why the team exists and how to know if you’re succeeding.
So how do you find that answer, make it stick, and most importantly, close the gap between your north star and the work your team actually delivers?
Mission Statements, North Stars, and the Space Between
To be clear, a mission statement isn’t a bad thing. It’s just different from a north star, and it has its own value.
A mission statement tells the world who you are. It’s outward-facing. It communicates identity, ambition, and the reason the company exists at all. A good mission statement gives customers, investors, and new hires a reason to care. It belongs on the website, in the pitch deck, on the badge. It serves a real purpose, and I’m not here to trash it.
A north star guides your team on what to do next. It’s focused on the team and how you work. When two smart people disagree about what to build, the north star helps you decide. The mission statement explains why the company matters. The north star helps you choose what to work on today.
Most companies have the first and most teams lack the second. They have a mission statement that says something about “transforming the future of X,” and then their engineering teams make priority decisions based on whoever talked loudest in the last meeting. The mission is real, but it’s too high-altitude to settle a sprint planning argument. You need something closer to the ground.
I love the Amazon Leadership Principles as they bridge the gap between mission and daily work. For example, “Customer Obsession” helps decide product direction, “Bias for Action” guides when to move forward without all the information, and “Disagree and Commit” means the team moves forward together after a decision. These principles work because Amazon uses them in everyday decisions.
But you don’t have to be Amazon or have a long list of principles. You just need one or two clear priorities that help break ties, and the discipline to use them when needed. I’ve seen small teams do this better than big companies because their leaders actually say things like “we care about reliability more than features” and follow through, or my favorite, “you can be frugal with time and money,” meaning that latency and speed need to be taken into account and not just cost.
Your Team Needs a North Star, Not a Mission Statement
Here’s my test: if your north star doesn’t help you decide what not to build, it’s just a wish, not a real guide.
Saying “build great software” is just a wish. Every team wants that, but it doesn’t help you decide what to prioritize, what to skip, or how to choose between two good ideas in the same sprint.
“Ship reliable features that reduce customer support tickets” is a real north star. It shows that reliability is more important than new features. It means customer pain points guide your work. If a feature looks great in a demo but causes lots of support tickets, it’s a failure. This north star helps the team decide: if the product manager wants a flashy dashboard but the engineer wants to fix a buggy integration that causes 30% of support tickets, the north star helps you choose.
A good north star should do three things:
First, it should make trade-offs clear. Every team has to balance speed and quality, new features and technical debt, or what customers ask for versus what they really need. Your north star should make these choices obvious. You’ll still have debates, but they’ll be about how to serve the purpose, not what the purpose is.
Second, it should be measurable, at least in a basic way. You don’t need fancy dashboards, but you should be able to look back at the end of a quarter and honestly ask, “Did we get closer to this goal or not?” If you can’t answer that, your north star is too vague.
Third, your north star should still matter even as AI changes how work gets done. Many people miss this. If your north star is about human productivity or lines of code, it won’t mean much when AI can write code faster than people can review it. Your purpose should focus on outcomes like customer impact, system reliability, team skills, or market position, things that stay important even as technology changes.
The Gap
Ideas are cheap. Execution is everything — John Doerr
Here’s what most people don’t admit: setting a north star is easy. Actually delivering on it is where things get tough.
I’ve seen teams spend a whole day at a strategy offsite, come back with a clear vision document, and then return to their usual work on Monday. The north star ended up in a Notion page, which was quickly forgotten. Three months later, when someone asked about the strategy, nobody had an answer.
The gap between intention and execution isn’t about laziness or lack of skill. It happens when teams don’t connect big ideas to daily work. The vision might say “reduce customer churn by improving reliability,” but on Monday, there are 47 Jira tickets and the CEO wants a demo by Friday. The North Star is high up, but the work is on the ground. No one built a bridge between them.
It’s the manager’s job to build that bridge, and it’s the hardest part of the role.
The Telescope
I use something I call the telescope roadmap to connect purpose to delivery.
The lens is the north star—your purpose. It doesn’t change every quarter, though it might shift over a year or two as the business evolves. During any planning period, it stays the same. Everything the team does should connect to this lens. If something doesn’t fit, either the work or the north star needs to change.
The far view (loosely, next six months). This is directional. We know we want to tackle the platform migration, the reporting overhaul, and the international expansion. We haven’t spec’ed any of it. We don’t know the exact shape. But we know it’s coming, and we know why it’s coming, because it connects to the north star. This is the horizon that gives the team context. It answers the question: “Why are we doing this sprint’s work instead of something else?”
The close view looks at the next three months. Here, things get specific: clear deliverables, assigned owners, and written specs for major features. You don’t need every ticket planned to the hour, but you should know what you’re shipping by June. This gives the team focus and answers, “What does success look like this quarter?”
The time is always now or the present view. This is where the work actually happens. The specs are being reviewed. The agent output being evaluated. The decisions are being made in the three weekly syncs. This is the horizon that gives the team traction. It answers: “What am I doing today, and why does it matter?”
The telescope only works if all four elements are aligned. If the weekly work doesn’t connect to the quarterly goals, you have drift. If the quarterly goals don’t connect to the six-month direction, you have churn. If the six-month direction doesn’t connect to the north star, you end up with busy work that feels productive but isn’t.
Every quarter, as a team we check the alignment. We look at what we shipped, we look at the north star, and we ask: did the work we did move the needle? If yes, keep going. If no, something is misaligned, either the work or the star, and we need to fix it.
Actually Delivering: The Boring Part That Matters
Purpose without execution is philosophy. Here’s how I close the gap between the north star and the sprint board.
Connect every spec to the north star, in writing. Every spec my team writes has a section at the top; two or three sentences that connect the feature to the team’s purpose. Not a paragraph of corporate justification. Just a clear line from “we’re building this” to “because it serves this goal.” This sounds small. It isn’t. When an engineer is reviewing an agent’s output at 4 PM on a Thursday and wondering whether a particular edge case matters, that “why” section is the thing that tells them whether to spend the extra hour or move on. Context changes decisions.
Some people call this “working backwards,” starting with the customer outcome and working towards the implementation. I just call it common sense that almost nobody practices. The “why” comes before the “what.” When you flip that order, when you start with the implementation and then try to justify it after the fact, you end up building things that are technically interesting but don’t serve anyone.
Make the north star visible in your team’s routines. In every quarterly planning session, the first slide—or the first paragraph of the document, since I prefer documents—restates the north star. It’s not because anyone forgot, but because starting with purpose keeps the planning focused. In retros, I ask: “Did the work we did this sprint move us closer to the north star?” Sometimes the answer is no, and that’s okay. Maintenance sprints and tech debt work are necessary. But the team should know when they’re investing in infrastructure versus investing in purpose. Both are valid, but they shouldn’t be confused.
Use AI to keep yourself honest. At the end of each quarter, I put our shipped features, decision logs, and sprint summaries into an AI and ask: “Based on our stated goal of [north star], how well did this quarter’s work align? Where did we drift? What work was completed that doesn’t connect to the stated purpose?” It’s like holding up a mirror. Sometimes, it shows you things you’d rather not see. Last quarter, the AI pointed out that 35% of our shipped work was tied to a stakeholder request that had nothing to do with our main priorities. We’d been pulled off course by a loud voice in a meeting and didn’t even notice.
Say yes more than most people are comfortable with. This is contrarian, and I know it. The standard management advice is “learn to say no.” Protect the team. Guard the backlog. Be the shield. And there’s a version of that advice that’s correct: don’t let random requests derail work that’s connected to your purpose.
But I’ve found that saying yes, often and early, is what builds the momentum that makes a north star real. When a stakeholder brings a request that connects to the purpose, even loosely, my default is yes. When an engineer proposes an experiment that might improve a metric we care about, my default is yes. When the team sees an opportunity that wasn’t in the quarterly plan but clearly serves the north star, my default is yes.
Here’s why. The teams I’ve seen fail at purpose-driven delivery didn’t fail because they said yes too much. They failed because they said no to everything that wasn’t pre-approved, and then the north star became a prison instead of a compass. The plan became the point, and the purpose got lost behind it. People stopped bringing ideas because the answer was always “that’s not in the sprint.”
A north star should make you more willing to say yes to the right things, not less willing to say yes to anything. The star isn’t a filter that blocks work. It’s a lens that shows you which work matters. When someone brings you something that serves the purpose, you should be eager to say yes, because that’s exactly the kind of initiative a purpose-driven team needs.
The “no” should be reserved for work that genuinely doesn’t connect, and when you do say no, the north star gives you language: “That’s an interesting idea, but it doesn’t connect to what we’re trying to achieve this quarter. If the situation changes, let’s revisit it.” That’s not a shield. It’s a compass reading. And most reasonable people, when they can see the compass, understand the direction.
There’s a useful distinction between reversible and irreversible decisions. Most of what a team decides in a given week is reversible. You try something, it doesn’t work, you roll it back. The cost is a few days. The cost of saying no to the experiment that would have changed everything is the future you never got to see. Bias towards action on reversible decisions. Save the caution for the irreversible ones.
Ownership Is the Multiplier
Of all the values I’ve seen teams adopt, ownership is the one that connects purpose to delivery most directly.
I don’t mean ownership in the corporate sense, where it shows up on a performance review rubric next to “takes initiative.” I mean the version where the person responsible for a piece of the system cares about the outcome, not just the task. They don’t throw code over the wall and move on. They don’t close the ticket and forget about it. They check whether the feature actually worked. They look at the support tickets that come in after launch. They monitor the error rates. They own the result, not just the action.
In the AI era, ownership matters more than it ever has. When an agent writes the code, the engineer's ownership isn't of the code itself; it's of the outcome. Did the agent-produced feature actually reduce the metric we were targeting? Did it introduce regressions? Is the customer experience better or worse? If the engineer doesn't own those questions, nobody does, because the agent certainly won't.
This is why teams should define ownership in terms of outcomes rather than artifacts. You don't own the payments module. You own the reliability of the payments experience. The module is just the current implementation. If an agent rewrites the module tomorrow, you still own the reliability. That shift, from artifact ownership to outcome ownership, is what makes purpose-driven teams work. It means the north star isn't just a planning tool; it's a definition of who's responsible for what.
Challenge the North Star Constantly
Here's another contrarian take: you should be actively trying to break your own north star. Not once a year at an offsite. Constantly.
The standard advice is to set a direction and commit to it. Stay the course. Don't get distracted. And in a slower-moving industry, that's fine. But AI is not a slower-moving industry. The pace of innovation right now is unlike anything I've seen in my career. Tools that didn't exist six months ago are reshaping how teams build software. Capabilities that were theoretical in January are shipping in production by June. A north star you set in Q1 might be pointing at a problem that AI solved by Q3.
If you're not regularly challenging your purpose, you're not being disciplined. You're being stubborn. And there's a big difference.
Ask your team, every quarter: "Is this still the right star?" Not as a philosophical exercise. As a real question with real stakes. Last year, we spent a quarter focused on reducing deployment friction because it was our biggest bottleneck. By the end of that quarter, agent-assisted deployment workflows had cut the problem in half without us doing anything. The friction wasn't gone, but it wasn't the highest-leverage thing to focus on. If we'd stayed the course out of commitment to the original plan, we'd have spent Q3 polishing a problem that was already shrinking while a bigger opportunity sat untouched.
When this happens, the worst thing you can do is cling to the old purpose out of sunk-cost loyalty. "We committed to reducing churn, so we have to keep focusing on churn" sounds principled. But if the data shows that churn stabilized and the real threat is competitors beating you on a capability you don't have, your principled focus has become a blind spot.
The best teams I've worked with treat this as a feature, not a bug. The principles stay stable, but the strategies they produce evolve constantly. "We care about reliability" meant one thing when the team was running a monolith and something different when they were orchestrating agents across five microservices. The purpose persisted. The interpretation evolved. That's not inconsistency. That's intelligence.
The cadence I use is the quarterly planning session. Not weekly, because weekly course corrections create chaos. Not yearly, because yearly is negligent when AI is reshaping your industry on a monthly basis. Quarterly gives you enough distance to see trends, enough frequency to catch problems, and enough rhythm for the team to expect and welcome recalibration.
The question to ask is: "If we were starting this team from scratch today, with everything we know now, would we pick the same north star?" If yes, keep going. If no, have the courage to change it, and be transparent about why. A team can handle a north star that evolves. What they can't handle is a manager who pretends the old star still applies, even though everyone can see it doesn't. Changing direction isn't failure. Refusing to change direction when the evidence demands it, that's failure.
The Compound Effect
I'll close with this.
The teams I've seen that ship consistently, that deliver quarter after quarter, that don't burn out their people or drown in process, all have one thing in common. It's not that they have the best engineers, though some of them do. It's not that they use the best tools, though most of them use good ones. It's that every person on the team can answer two questions without hesitating:
Why does this team exist?
How do I know if we're winning?
That's purpose, and that's measurement. The north star and the compass. When both are clear, everything else, the specs, the reviews, the agent orchestration, the quarterly planning, the difficult conversations about what to cut, becomes navigable. Not easy. Navigable. You still have to sail the ship. But at least you know where you're going.
When they're unclear, teams default to busyness. They ship features nobody asked for. They optimize metrics that don't matter. They have sprints that feel productive but don't move the needle. They work hard and go nowhere, which is the most demoralizing outcome there is.
Purpose is not a nice-to-have. It's the load-bearing wall. Knock it out, and everything eventually collapses, no matter how good the individual pieces look.
I write about engineering management and AI at the intersection where both get interesting. Follow me on Medium: @joshmcdonald
By Joshua McDonald on March 19, 2026.
Exported from Medium on August 26, 2026.
Reader discussion