Project Anatomy: Why Smart Teams Ship and Nothing Happens

TL;DR: A team of brilliant engineers, a cloud-native stack, and a CEO who wants everything shipped yesterday. Yet nothing meaningful ships. The technology isn’t the problem. Nobody owns the project as a whole - and ownership requires more than a name on a Jira board.

Disclaimer: The scenario described in this post is a composite. It doesn’t reflect any specific company I’ve worked for - past or present. The patterns, however, are real and drawn from over a decade of building software across different organisations.

The Scene #

Imagine this - and I suspect you don’t have to try very hard.

A startup with serious funding. Backend, AI, and frontend teams each staffed with genuinely talented engineers. Kubernetes, CI/CD, the works. No sprints, no velocity tracking - because “we move too fast for that.” A CEO whose ideas arrive faster than the CI pipeline.

Features get built. Deployments happen daily. And yet, at the end of every quarter, the honest answer to “did we move the needle?” is: we’re not sure.

I’ve seen this setup more than once. The instinct is to blame the process - or the lack of one. But the real issue runs deeper. Nobody owns the project. Not the CEO, not the teams, not any individual engineer. And when nobody owns it, everyone half-owns it, which is functionally the same as nobody.

What “Ownership” Actually Means #

Ownership isn’t a calendar invite or a title. It’s five concrete things being in place simultaneously. Pull any one of them out, and you get the scenario above: smart people, great tooling, disappointing outcomes.

Here’s what’s missing - gap by gap.

Gap 1: Nobody Owns the Intent #

The CEO knows what they want built. The engineers know how to build it. But nobody has written down - clearly, and shared - why it matters and what success looks like.

Marty Cagan, in INSPIRED, calls this the difference between a feature factory and a product team. A feature factory receives instructions and ships output. A product team understands the problem they’re solving and owns the outcome.

In practice, this looks like: the CEO says “build the export feature”, the team builds the export feature, users don’t use it, nobody knows why. Because nobody asked: what user behaviour are we trying to change, and how will we know if we did?

The missing piece is always the same - nobody wrote down, in plain language:

1. What problem are we solving?
2. For whom?
3. How do we measure success?

Without that document, the CEO’s vision and the engineer’s implementation drift apart from day one.

Gap 2: Nobody Owns the Cross-Team Contract #

Separate backend, AI, and frontend teams with no shared sprint and no shared goal will locally optimise and globally fail. Every time.

There’s a rule that’s older than most of the frameworks we use: Conway’s Law. Organisations produce systems that mirror their communication structures. If your backend, AI, and frontend teams don’t talk, your backend, AI, and frontend services won’t integrate cleanly either. The architecture is always a reflection of the org chart - whether you designed it that way or not.

Team Topologies by Skelton and Pais takes this further: the way you draw team boundaries is a deliberate architectural decision, not an HR one. Siloed component teams - organised around technical layers - produce siloed systems with no clean integration layer. The friction you feel at deployment time was baked in at org-design time.

The real fix isn’t a better meeting cadence. It’s recognising that backend, AI, and frontend teams are the wrong cut. They’re component teams organised around technology, not around what the user needs. The alternative is feature teams: cross-functional groups that own a slice of the product end-to-end, from database to UI. A feature team doesn’t need a cross-team sync to align on the API contract - the backend and frontend engineers sit next to each other and own the same outcome. Team Topologies calls this a stream-aligned team: a group organised around a flow of work rather than a technical specialty.

That’s a harder change than scheduling a meeting. If you can’t re-org today, here’s a pragmatic stopgap: a weekly 30-minute cross-team sync with one agenda item only - what are the integration risks this week? Not status updates. Not progress reports. Just: where are the seams, and are they holding? But be honest with yourself - that’s a band-aid on a topology problem, not a solution.

Gap 3: Nobody Owns the Rhythm #

“No sprints, no velocity tracking” is sometimes a genuine philosophy. More often it’s what happens when nobody wanted to have the conversation about cadence.

A rhythm isn’t about story points. It’s about creating predictable moments where the team syncs, adjusts, and commits. Without it, work expands to fill all available time, priorities shift mid-flight with no anchor, and “done” becomes a permanent future state. You start noticing the symptoms in small ways: engineers aren’t sure what to work on next Monday, the CEO asks for a status update because there’s no natural place to get one, and nobody can say with confidence what shipped last week versus what’s still in progress.

You don’t have to do Scrum. I’ve worked in setups with two-week cycles that had no ceremonies except a Monday kickoff and a Friday demo. That was enough. The point is: something creates the heartbeat. Without a heartbeat, you can’t tell whether the patient is healthy or not.

Gap 4: Nobody Owns the Decision Boundary #

When the CEO is the de facto decision-maker on every feature, ticket, and architectural choice, two things happen. First, the CEO becomes the bottleneck. Second - and this is the one that kills teams slowly - engineers stop making decisions. They wait. They escalate. They optimise for not being wrong rather than for being useful.

EMPOWERED frames it as the difference between missionaries and mercenaries:

• Missionaries understand the mission and act on it.
• Mercenaries execute instructions and collect their fee.

You cannot hire missionaries and then treat them like mercenaries.

The decision boundary isn’t something you write down in a document. It’s something leadership demonstrates. The first time a team makes an imperfect-but-reasonable call and leadership backs it publicly, the boundary expands. Engineers learn: we are trusted to decide things here. The first time leadership reverses a decision without explanation, the boundary collapses - and it takes far longer to rebuild than it did to destroy.

No process fixes this. It’s a leadership behaviour. The question to ask isn’t “what’s in our RACI¹?” - it’s “when did we last back a team decision we privately disagreed with?”

Gap 5: Nobody Owns the Definition of Done #

This is the one that hides longest.

Features ship. The deployment succeeds. The ticket closes. And then: nothing. No one checks whether the feature was adopted. No one measures the metric it was supposed to move. The next request is already in the queue.

INSPIRED puts it plainly: shipping is not winning. Shipping is a bet. Winning is when the bet pays off. If you never check whether the bet paid off, you’re not building a product - you’re just writing code and hoping.

Outcome-based done looks like this: we shipped the export feature. Two weeks later, we check: how many users triggered it? Did it reduce support tickets about data access? If yes - win. If no - learning. Either way, the loop closes.

Without this, every feature is a question you asked and never waited to hear the answer to.

Putting It Together #

Some of these gaps close with a conversation. Others - like team topology - require real structural change. But all of them start the same way: by asking the question nobody has asked yet.

If you’re wondering where to start: intent first. Everything else depends on it. You can’t evaluate your team structure, your rhythm, or your definition of done without knowing what you’re trying to achieve. Once intent is clear, decision boundaries tend to become obvious - leadership can delegate when the destination is shared. Rhythm and cross-team contracts follow naturally from there. Definition of done comes last, because you need all four other pieces before you can meaningfully close the loop.

Five questions worth running through before the first line of code:

1. Intent - Can anyone on the team articulate, in two sentences, what problem we’re solving and how we’ll know we succeeded?
2. Team structure - Are teams organised around user outcomes, or around technical layers?
3. Rhythm - Is there a recurring moment, however lightweight, where we check direction and adjust?
4. Decision boundary - When did leadership last back a team decision they privately disagreed with?
5. Definition of done - Does “done” include checking whether it actually worked?

If any answer is “no,” “unclear,” or uncomfortable silence - that’s the first thing to fix. Not the backlog. Not the sprint structure. Not the CI pipeline. The gap.

The Uncomfortable Conclusion #

A demanding CEO is a gift most teams don’t appreciate until they’ve worked under an indifferent one. The issue was never the pressure. It was that nobody built the structure to make that pressure productive.

The engineers weren’t failing because they lacked skill. They were failing because the system they worked inside made ownership structurally impossible. Every incentive pointed toward executing the next request, not questioning whether it was the right one. The CEO’s energy had nowhere to land except directly in the backlog - bypassing strategy, skipping discovery, collapsing the distance between idea and ticket.

I’ve also seen what happens when these gaps close. A team went from monthly “what did we even build?” conversations to weekly demos where the product owner watched real users interact with the feature. Nothing about the talent changed. Nothing about the stack changed. What changed was that someone wrote down the intent, drew the team boundary around the outcome instead of the technology, and gave engineers permission to make calls without escalating every decision to the top. The same pressure that had been producing chaos started producing focus.

Fix the system, and a demanding CEO becomes your biggest advantage. Leave it broken, and no amount of talent, tooling, or process improvement will change the outcome.