Field Notes: What a Four-Person Team Actually Looks Like

By Skip Marshall & Chuck Griess

We've been writing for a month about what's breaking in software delivery — the one-person myth, collapsing timelines, Scrum under pressure, the orchestration bottleneck. All of that has been diagnosed. This week, we want to show you something instead of arguing for it.

This is the first in what we're calling Field Notes: shorter, from-the-trenches pieces about what we're actually doing on the products we build and the teams we work with. Less theory, more \"here's what happened on a Tuesday.\"

We're going to tell you about a team. Four people. They replaced what had been an eight-person operation and shipped faster, with fewer incidents, at lower cost. But the interesting part isn't the headcount reduction — it'showthe four people worked. Because the structure of this team is something we keep coming back to, and we think it's a pattern worth examining closely.

Thanks for reading! Subscribe for free to receive new posts and support our work.

A quick note: the team we're describing here is real, but it's also a composite. We've drawn from multiple engagements and adjusted the details to protect the innocent — and a few of the guilty. The patterns are faithful. The specifics have been scrambled.

Skip: The call that started it

I was on a call with the founder of a growth-stage SaaS company — a non-technical CEO with a solid product that had been in market for about two years. Their problem was specific: they had an eight-person engineering team that was shipping slowly, missing deadlines, and producing work that frequently needed rework. The team had grown organically — a hire here, a contractor there, a scrum master bolted on when things felt chaotic. Everyone was busy. Not much was getting done.

The founder said something I've heard a dozen times: \"I'm spending more on engineering than ever, and I feel like we're going backwards.\"

When we dug in, the pattern was familiar. Eight people, but no clear ownership of outcomes. Three developers working on features that overlapped in ways nobody noticed until integration. A QA person who was always two sprints behind. A scrum master running ceremonies that the team tolerated but didn't value. Two contractors who'd been \"temporary\" for nine months and had context on critical systems that nobody else shared. Meetings everywhere. Decisions nowhere.

The founder didn't need more people. They needed a fundamentally different structure.

Chuck: What we actually built

When Skip brought me in to look at the engineering side, I spent the first week doing something that sounds simple but almost nobody does: I mapped what decisions were being made, by whom, and how.

Not the code. Not the architecture. The decisions.

What I found was revealing. The eight-person team was making roughly the same number of meaningful decisions per week as a team of four would — maybe fifteen to twenty real choices about scope, architecture, tradeoffs, and priorities. The rest of the time was consumed by coordination overhead: syncing people who didn't need to be synced, re-explaining context that should have been written down, and re-litigating decisions that had already been made but weren't documented anywhere.

So we proposed something that made the founder nervous: replace the eight-person team with four senior people, restructured around decisions rather than tasks.

Here's what the team looked like:

A senior full-stack engineerwho was comfortable using AI tools for the bulk of code generation, testing, and boilerplate. Not a junior developer with Copilot — a senior engineer with strong architectural judgment who used AI to handle the mechanical parts while focusing their own attention on the hard decisions: data model design, integration patterns, edge case handling.

A delivery leadwho owned intent and outcomes. This person's job wasn't managing a backlog or running standups. Their job was making sure every piece of work started with a clear answer to three questions: What are we building? Why? How will we know it worked? They also owned the post-ship question: did it actually work? This role is the connective tissue between the business goals and the engineering execution. On this team, the delivery lead spent about half their time talking to stakeholders and users, and half their time working with the engineer and designer to define scope and review outcomes.

A product designerwho doubled as the voice of the user. Not just mockups — lightweight research, prototype testing, and the person who said \"wait, this doesn't make sense from a user's perspective\" before it was too late. On a small team, the designer isn't a production line of screens. They're a thinking partner who keeps the product coherent.

A DevOps/infrastructure personwho made sure nothing shipped without observability and a rollback plan. Their job wasn't just \"keep the servers running\" — it was defining what \"safe to ship\" meant for every release, calibrating that safety bar to the actual risk of the change, and making sure the team had evidence (not just hope) that shipped code was working correctly in production. A copy tweak and a payment-flow overhaul don't deserve the same gate. This person owned that calibration.

Four people. Each one senior. Each one with clear ownership. No coordination tax from people who needed to be managed rather than unleashed.

Skip: What the founder noticed first

The first thing the founder noticed wasn't speed — though the speed came. It was clarity.

With eight people, every status update was a translation exercise. \"We're working on the notification system\" could mean six different things depending on who said it and which of the three overlapping notification efforts they were referring to. With four people, each with clear ownership, the founder could ask a simple question and get a simple answer. Not because the work was simpler, but because accountability was unambiguous.

The second thing they noticed was that decisions stuck. With the old team, a decision made in Monday's planning meeting would quietly dissolve by Wednesday because someone who wasn't in the room would make a different call, or because the rationale was never written down, and people filled in their own version. On the four-person team,every material decision was documented: what we decided, what we considered,and why we chose this path. Not a formal process. A few sentences in a shared place. But it meant that when someone — or an AI tool — encountered a question that had already been answered, the answer was there.

The founder told me, about six weeks in: \"For the first time, I actually understand what my engineering team is doing and why.\" That wasn't a technology improvement. It was a structural one.

Chuck: What I noticed from the engineering side

From my vantage point, the most striking difference was how much less rework the team produced. The old eight-person team had a rework rate that I'd estimate at 25-30% — a quarter of the work they did ended up getting partially or fully redone because of miscommunication, overlapping efforts, or decisions that weren't aligned. That's not unusual for a team that size. It's the hidden tax of coordination overhead.

The four-person team's rework rate dropped to something like 5%. Not because they were better engineers — some of the same people were involved. Because the structure eliminated the primary sources of rework.

When every piece of work starts with a clear statement of intent, you don't build the wrong thing. When decisions are documented, you don't relitigate them. When one engineer is responsible for the codebase instead of three, you don't get semantic conflicts from parallel work that diverged silently. When safety criteria are defined before you build, you don't scramble at the end to figure out whether it's safe to ship.

The AI tooling mattered, but not in the way most people think.It didn't replace the people.It replaced themechanical workthat had justified having eight people. With AI handling code generation, testing scaffolding, and boilerplate, one senior engineer could cover the territory that previously required three or four. But the decisions — architecture, scope, tradeoffs, integration design — still required human judgment. They just required fewer humans, because fewer humans meant less coordination overhead, which meant the decisions happened faster.

The counterintuitive result: a smaller team moved faster not primarily because they had better tools, but because they had fewer people to coordinate.

The tools were necessary but not sufficient. The structure was the multiplier.

What we both learned

We've applied variations of this structure on multiple products since, and a few patterns keep holding:

Writing down intent before starting work is the single highest-ROI practice.It takes thirty minutes. It saves days. Every time we skip it — because the work seems small, because we're in a rush, because \"everyone knows what we're doing\" — we pay for it. The cost of ambiguity scales with speed. When you're building slowly, you have time to course-correct. When AI-assisted delivery is moving fast, a misaligned assumption on Monday is three days of wasted work by Thursday.

Senior people in every seat is non-negotiable at this team size.A four-person team has no room for someone who needs to be managed. Every person needs to be capable of making good decisions autonomously, escalating the right things, and filling gaps without being asked. This isn't elitism — it's physics.

When there are only four of you, the cost of one person not pulling their weight isn't 12.5% (one out of eight). It's 25%.

The delivery lead role is the one most teams don't have and most need.It's not project management. It's not product management, exactly. It's the person who owns the question: \"Are we building the right thing, and how will we know?\" Most teams distribute this responsibility across everyone, which means nobody owns it. When nobody owns intent, everyone has their own version. That's where rework comes from.

Measuring outcomes after shippingchanges how the team thinks about the next piece of work.When you check — actually check, with data — whether your last release accomplished what it was supposed to, you learn things that no amount of sprint planning can teach you. Sometimes you learn the feature worked as intended. Sometimes you learn it didn't move the metric at all. Sometimes you learn something unexpected about how users actually behave. All of that is gold — but only if you have the discipline to look for it instead of immediately starting the next build.

The uncomfortable truth

This structure isn't for everyone, and we'd be dishonest if we didn't say so.

It requires senior people, which means higher individual salaries. It requires trust — from leadership, from stakeholders, from the team itself — because there's no process theater to hide behind. There are no ceremonies to make everyonefeelproductive. Either the team is shipping outcomes that matter, or they're not. The transparency is total and sometimes uncomfortable.

It also requires something most organizations resist: letting go of the idea that more people equals more output. We've had conversations with leaders who understood, intellectually, that their eight-person team was slower than a four-person team could be — and who still couldn't bring themselves to make the change, because headcount feels like commitment and reduction feels like retreat.

We get it. But the math is the math. And the results, when you get the structure right, are hard to argue with.

Next week, Skip's writing for the non-technical founders in the audience — the ones evaluating dev shops, signing contracts, and trying to figure out what \"good\" looks like when they don't have a technical background. Because if you can't tell the difference between a four-person team like this one and a eight-person mess billing you twice as much, your vendor will exploit that gap. Here's how to spot the difference.

If this resonated, subscribe. We're writing about what's actually changing in software delivery — no hype, no hand-waving, just what we're seeing with real teams on real products.