I've watched this moment play out on several teams. A feature ships after months of work. There's a Slack thread with party emojis, a quick mention in the company standup, maybe a brief celebration. And within a week, nobody's talking about it anymore. Some people on the team seem energized regardless, already deep in the next problem. Others look deflated, anxious about finding the next milestone to feel good about.

Recently, I came across a conversation between Arthur Brooks (the happiness researcher whose book "From Strength to Strength" originally inspired this blog) and Codie Sánchez, a startup founder who helps people buy and build businesses. They were discussing what makes people genuinely fulfilled, and they landed on three things: progress, freedom, and ownership.

Simple ideas. But as I listened, I kept mapping their points to engineering teams and careers. The parallels were obvious and slightly uncomfortable, the way good insights tend to be.

Progress means loving the process

Brooks made an observation about diets that stuck with me. Between 80 and 95% of diets fail. Not because they don't work (they all work in the short term), but because once you arrive at your goal weight, the reward for hitting your target is never getting to eat what you like again. Congratulations on arriving. Now enjoy the rest of your life not making progress.

The psychology is clear: humans are wired to enjoy progress, not arrival. We love the journey, even when we convince ourselves it's the destination we're after.

I've seen this play out in engineering more times than I can count. A team spends months building something. The launch happens. Brief celebration. And then a kind of emptiness. What now? The teams that seem consistently fulfilled aren't the ones chasing the next big launch. They're the ones that genuinely enjoy the daily work of solving problems, designing systems, debugging the tricky stuff. They barely notice the transition between projects because they were already having a good time.

Brooks put it simply: "You need to love the playing more than the winning. That's what great athletes have in common."

I think about this in the context of engineering careers too. I've watched talented engineers optimize for the next title, the next salary band, the next impressive company name on their resume. And I've watched others who seemed to genuinely enjoy the craft of building software, regardless of the external markers. The second group, in my experience, tends to last longer, burn out less, and (paradoxically) often ends up more successful. They're playing because they love the game, not because they're desperate for the score.

This doesn't mean outcomes don't matter. Of course they do. You need goals and direction. But if the only thing that makes your work feel worthwhile is the moment of shipping, you're setting yourself up for a very specific kind of dissatisfaction: the kind where success never quite feels the way you thought it would.

Freedom needs constraints

Sánchez's husband is a former Navy SEAL, and he has a line I haven't been able to stop thinking about: "Freedom needs constraints."

Brooks added a metaphor from Chesterton: imagine a soccer field on top of a mountain, sheer cliffs on every side. Without fences, kids lie down, terrified of the edge. Build high fences, and they play joyfully. The constraints don't limit freedom. They enable it.

I've lived this in software engineering. The teams I've seen struggle most aren't the ones with too many rules. They're the ones with too few. No coding standards means every pull request becomes a debate about style. No architectural guidelines means every design review starts from first principles. No deployment process means every release is an adventure nobody asked for.

The best engineering teams I've worked in had strong opinions. Clear code conventions. Well-defined architectural boundaries. Deployment pipelines that enforced quality gates. These felt constraining at first. But once internalized, they were liberating. You stopped wasting energy on decisions that didn't matter and could focus entirely on the ones that did.

There's a reason frameworks like Rails became so popular. They made a thousand small decisions for you, and in doing so, freed you to focus on the problems only you could solve. That's freedom through constraints in practice.

The catch is that this only works when the constraints are voluntarily adopted, when the team understands why the fences exist and agrees they belong where they are. I wrote previously about a technical excellence initiative that struggled partly because we tried to introduce constraints without earning buy-in first. Mandated constraints without understanding feel like prison walls. Chosen constraints feel like infrastructure.

Ownership is stewardship, not control

Sánchez made a point about ownership that surprised me: "Anybody who's been an owner knows, you are not in control as an owner. You are the janitor and the CEO at all times."

That line hit home. Genuine ownership in engineering doesn't look like control. It looks like care. The engineer who owns a system doesn't just write the code and move on. They monitor it. They respond when it breaks. They know its quirks and limitations. They advocate for its improvement even when nobody's asking. They feel personal responsibility for its health.

The gap between "I completed my ticket" and "I own this system" is vast. The first is transactional: you did a task, it's done, you move on. The second is relational: you have an ongoing commitment, and that commitment shapes your decisions in ways that task completion never does.

I've noticed that teams with strong ownership cultures tend to produce better software. Not because ownership magically improves code quality, but because people who care about something invest differently. They write better tests because they'll be the ones debugging failures. They write better documentation because they know someone (possibly their future self) will need it. They push back on shortcuts because they'll live with the consequences.

But ownership, like freedom, has to be genuine. You can create conditions where it flourishes: clear responsibilities, autonomy within boundaries, trust that people will make good decisions. Or conditions where it withers: micromanagement, unclear boundaries, blame cultures. Calling someone a "system owner" in a Jira field does nothing if they have no authority to make decisions about that system.

The simple version

What strikes me about these three ideas is how simple they are. Love the process of building, not just the moment of shipping. Choose your constraints deliberately and commit to them. Care about the things you build as if they're yours, because in every meaningful sense, they are.

The most fulfilled engineers I've worked with aren't the ones with the most sophisticated career strategies or the flashiest tech stacks. They're the ones who found work they genuinely enjoy doing day to day, who operate within structures they helped create and believe in, and who feel genuine ownership over the systems and teams they're part of.

Brooks and Sánchez were talking about life and entrepreneurship. But these three principles don't need much translation to apply to how we build software and build teams. Progress, freedom, ownership. Three ideas that quietly determine whether engineering work feels fulfilling or just feels like work.

The game is the reward. Not the score on the board.