# How I Plan With a Team of Ten Senior Engineers

By Antoine Debes, Principal Software Engineer · 2026-09-24

> Shape the problem, slice work for review, never let new scope in for free. How I plan now that implementation is no longer the bottleneck.

Ten senior engineers can build almost anything. The planning problem is not capacity. It is making sure all ten are building the same thing, in the same system, against a date that still means something.

Here is how I plan, and what changed once AI made implementation cheap.

## Shape the problem before anyone estimates

An estimate for a vague request is a guess dressed as a number. Before we size anything, three things are written down: what the business needs, what is out of scope, and what done looks like.

Non-goals do most of the work. "We are not migrating legacy records in this phase" settles an argument before it can start mid-build. Most estimates that go wrong were wrong at the start, because two people heard the same request and pictured different systems.

## Slice for review, not for effort

I break work into slices that can each be reviewed, tested and merged on their own. Not "backend first, then frontend", but thin vertical pieces: say, an intake flow that validates and stores one form type end to end before it handles all of them.

The reason is review. A slice a reviewer can hold in their head gets a real review; a two-thousand-line change gets a skim. That matters more now that a large change is cheap to generate and still expensive to check. Small slices also surface date risk in the first week, not the last.

## A short written plan for anything cross-cutting

Anything that touches several services, a data model, or another team's code gets a written plan before it gets tickets. One to three pages: context, goals and non-goals, the proposed design, the alternatives we rejected and why, and the risks. It is the mini design doc from [Google's design doc practice](https://www.industrialempathy.com/posts/design-docs-at-google/), not a ceremony.

A design problem found in a document costs an afternoon; found in a merged branch, it costs a sprint. If the solution is obvious, I skip the doc. Writing one for a trivial change is overhead, not rigor.

## The estimate describes a scope

My rule is simple. **We don't say no to features. We say no to free scope.** When a stakeholder asks for something new, the answer is almost always yes, and the date reopens with it. Both, together, every time.

An estimate is a commitment made under assumptions, and the biggest assumption is scope. Change the scope without reopening it and the estimate becomes a fiction that someone pays for: the team in overtime, the codebase in skipped tests, or the stakeholder in a surprise slip days before launch.

So I bring the cost immediately and offer the trade, not just the bill: "That's about three days, which moves us to the 14th, or we hold the date and move this to phase two." Nobody takes arithmetic personally.

## Name the unknowns on day one

Every plan carries its risks in writing, each with an owner. An integration nobody has tested against, an API whose limits we have not confirmed, a dependency on another team's release: each one gets a short, timeboxed spike or an explicit assumption the stakeholder agrees to.

A date that moves eight weeks out is a planning input. One that moves three days before launch is a crisis. Most of the difference is whether the risk was named early.

## Tickets written for people and agents

On my team, agents pull the ticket, read the design and open the pull request. That changes what planning is for. When implementation is cheap, the bottleneck moves to two places: the quality of the specification and the capacity to review what comes back.

A ticket is now an input to a machine as well as a note to a colleague. It needs acceptance criteria someone could write a test against, a concrete example of the expected behavior, the constraints that matter (which service owns the data, what must not change), and a definition of done. A gap a colleague would close by asking one question, an agent will fill with a confident guess.

It stays proportionate. Birgitta Böckeler's [review of spec-driven tooling](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html) shows how easily a small bug turns into pages of requirements. The goal is a clear ticket, not a longer one.

## One system, many opinions

Every senior engineer has a good opinion about how to build it. Without shared rules you get ten good systems stitched together badly. Three things keep it coherent.

- **Conventions written down.** Naming, structure, error handling, how we call external services. A convention that lives in someone's head gets reinvented in every pull request.
- **Clear ownership.** Every area of the system has an owner who is consulted before it changes shape.
- **Decisions recorded.** A short [architecture decision record](https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions) (context, decision, consequences) for anything we would otherwise re-argue in six months. Without the reason, the next person either follows a decision blindly or changes it blindly.

Planning is not predicting the future. It is making costs visible early enough that people can still choose differently.

Get the problem, the slices and the scope right, and a senior team is fast. Get them wrong, and cheap implementation only gets you to the wrong place sooner.