The Case for Small Teams and Even Smaller Work

Big projects and big teams demand more meetings, and nobody needs another meeting.

Another thing you don't need - an aging product guy to tell you that more meetings don’t lead to better outcomes but it's 2024 and companies are still meeting obsessed. So, I guess old guys like me still need to keep reminding everyone why this it didn't work 20 years ago, and is still isn't working.

Meetings do not help make things, they often do the opposite. Formalized processes like Agile, with their emphasis on ceremonies and structured communication, inadvertently promote distraction, procrastination, and a culture of perpetual planning over actual doing.

Whether you call them meetings, events, or ceremonies, the time spent in these activities is time not spent actually solving problems, designing UI or writing code. This is particularly evident in practices like Scrum, which is philosophically well-meaning but in practice looks like endless games of calendar-Tetris and backlog Connect-4. (Cue the Scrum zealots with their "it would work if everybody just did what they said they were going to do" rhetoric).

Daily check-in meetings are for the isolated

The daily standup or scrum is a bandaid. It's a painkiller administered after the headache has already set in. It's a classic example of a meeting that is created to solve a problem that exists upstream. If your team is already working collaboratively—whether in small group or just through open and frequent communication—there’s little need to pause for a formal check-in. The daily team meeting is a relic of working in silos, where isolation is the norm and coordination is an afterthought. Instead of adding bandaids, go upstream and ask why the team needs this check-in. Stop working in isolation. Start together, and stay together (credit to John Cutler for this line).

Foster a culture where collaboration happens naturally throughout the day, rendering the daily standup obsolete.

Retros are for the disconnected

Retrospectives are another formalized process that can feel more like a box-ticking exercise than a tool for real improvement. In a team that works closely together, issues can be addressed as they arise—there’s no need to wait for a bi-weekly ritual. When something goes wrong, stop and address it immediately. This approach not only eliminates the need for regular retrospectives but also promotes continuous improvement in real time.

Reviews are performative

Demos are necessary and helpful, but 1-to-many reviews often devolve into the performative, where the focus is on presenting rather than learning. Watching an engineer show off their software doesn’t provide the same insights as observing a user interact with the product in real time. For the past few weeks I have been talking directly to customers, my favorite thing to do, and these conversations have surfaced more actionable insights than several months of roadmap and backlog grooming.

If you want to know how well your product works, put it in the hands of real users and watch them work. Record that customer integration. Anyone interested in the state of the project can see it firsthand. Record that and share that with your team. Better yet, release your software regularly and skip the formal review altogether.

Backlog management is professional procrastination

Humans learn by doing, not by planning. The practice of backlog grooming is intentional procrastination at best, and ego posturing at its worst. If you are talking to customers regularly, they will tell you what they value, and what they don't. That whizz-bang feature that the CEO is pushing hard to include in the next sprint turns out to be the least interesting thing to your customer. As Nate Walkingshaw says, the customer breaks the tie. Hosting meetings to move stuff around a backlog and debate the importance of a feature is a delightful way to postpone making choices.

Of the hundreds of highly functional teams I've interviewed, they find that maintaining a detailed backlog is less valuable than simply doing the things and learning as they go. The best way to do this is to replace your backlog with a list of questions that absolutely need to be answered by doing a thing. A backlog that stretches out for weeks or months doesn’t account for the inevitable learning that happens during development. Rather than speculative guessing, focus on a small, fixed-length “ready queue” that is constantly adjusted as work progresses. This keeps the team nimble and responsive, rather than bogged down by a list of tasks that may no longer be relevant.

Sprint or roadmap planning is an inquiry of the future, not a determination

Roadmaps are not a determination of the future, that's not possible given all the ambiguities about the market and the customer's evolution. Instead of making planning about what you want o happen, make it about what questions that need answers. This is called the inquiry-led approach and it has worked for teams like the NY Times and Mural.

Using the inquiry based approach, the traditional sprint planning process that can be streamlined, if not eliminated. Regular conversations with customers, paired with continuous feedback loops, should provide all the direction a team needs. This is the clarity I'm seeing every day when I speak to customers. They are telling me what they care about and what they don't. Combined with the data showing feature usage and adoption, the roadmap is nothing more than a series of questions, like "how can we deliver [requested outcome] to our customer?" or "how might we solve for the customer's need to [requested outcome]?"

If you’re relying heavily on something like Sprint Planning to get started, it might be a sign that your customer conversations need to be more robust. Dump the tickets, ignore the story points, and focus on the actual work at hand.

The power of small

The real point of this rant is the idea that smaller is better. Smaller teams mean fewer meetings. Less meetings mean more time to focus on the actual work. There’s less coordination needed, and decision-making can be faster and more effective. When work is broken down into the smallest possible elements, it becomes easier to identify and solve problems quickly. The result is a more responsive and focused team that spends its time building software rather than discussing how to build it.

The best processes are the ones that get out of the way, allowing teams to focus on what really matters: delivering value to users as quickly and efficiently as possible. Reduce the meeting load, increase productivity, and make better software in the process.