Dedicated development teams

A team that owns an area and reviews its own work, rather than one attached to yours.

A dedicated team owns an area of work rather than a queue of tickets. It has its own review, its own standards and enough people to be self-sufficient, and it reports against outcomes rather than against task completion.

This is the right shape when there is a whole area to own and when hiring three or four people into a tight market would take a year. It asks more of you at the start, because an area cannot be owned without a clear definition of what it includes and who decides, and it asks considerably less of you afterwards.

What makes it work

A boundary somebody can draw

An area with a describable edge: a product surface, a service, a domain. If the boundary cannot be stated, the team will spend its time negotiating scope rather than building, and you will conclude that dedicated teams do not work.

A single person who decides

Someone on your side who can answer questions and make calls without assembling a committee. Distributed teams do not fail on skill; they fail on waiting.

Outcomes rather than task lists

A team that owns an area should be measured on what the area does, not on how many tickets closed. Measuring the second produces the second.

Enough people to review themselves

This is the point of the model. If every change still has to be reviewed by your team, you have augmentation with extra structure and more overhead.

What we set up first

• The boundary of the area, written down, including what is explicitly outside it.
• The named decision-maker on your side and what they can decide without escalating.
• The overlap window, published and treated as real.
• How work arrives and how it is prioritised, since an owned area still needs direction.
• What the team is accountable for, stated as outcomes rather than as throughput.
• How and when we review whether the arrangement is working, including the option to stop.

What the levels actually mean

Job titles are not comparable between companies, so it is more useful to describe levels by what somebody can be left to own without supervision. These are the boundaries we use, and every technology page states what each level looks like in that specific technology.

Junior

Delivers defined pieces of work inside an existing structure, with the approach decided for them. Reviews catch the things experience teaches. Valuable where there is strong direction and capacity to teach, and a poor investment where there is neither.

Mid-level

Owns a feature end to end, including its tests, its failure states and its data access. Can be given a problem rather than a solution. Still benefits from review on decisions that will be expensive to reverse.

Senior

Owns the shape of an area. Makes the decisions that are costly to change later and can justify them against the alternatives. Raises the level of the people reviewing alongside them, which is the part most often left out of the definition.

Staff

Owns cross-cutting concerns: the contracts between areas, the standards others build against, the migration path off whatever the system has outgrown. Measured by what other teams stop having to decide.

Years of experience correlate with these far less than people expect. Somebody who has spent six years maintaining one application carries less transferable judgement than somebody who has spent three across three very different ones. When a CV and a level disagree, the interview should settle it.

The most reliable seniority signal we know is what somebody has removed. Mid-level developers describe what they added. Senior ones describe a store they deleted, an abstraction they collapsed, a dependency they took out. The ability to make a system smaller is harder to fake than any amount of technical vocabulary.

How it differs from outsourcing a project

A fixed-scope project is a contract about a deliverable. It suits work where the requirements are genuinely known in advance, which is rarer than it is claimed to be, and it creates an incentive to argue about scope when they turn out not to be. A dedicated team is an ongoing capability that adapts as the understanding changes, which is how most software actually develops.

Frequently asked questions

How big is a dedicated team?

Small enough that everyone knows what the others are doing and large enough to review its own work, which in practice usually means three to five people including a senior engineer who can make architectural decisions. Smaller than that and it is really augmentation.

Who manages the team?

We handle the day-to-day and you own the direction. The arrangement that does not work is one where nobody on your side is accountable for what the team is pointed at, which produces a team that is busy and not useful.

How is this different from augmentation?

Augmented developers work to your direction and your review. A dedicated team owns an area and reviews itself. The practical trigger for the switch is when the people you would add exceed what your reviewers can absorb.

What if we want to bring the area in-house later?

That is a legitimate outcome and it should be planned rather than improvised. Documentation, handover and a transition period are agreed in the engagement. A supplier who makes leaving difficult is telling you something.

Can the team work on several areas?

It can and it usually should not. A team spread across three areas owns none of them, and the accountability that makes the model work disappears. If there are three areas, the honest answer is either three teams or a narrower scope.

How do we know it is working?

Agree that at the start, in terms of what the area should do rather than how much the team produces. We review it on a set cadence, and the review includes the option to stop. An arrangement nobody re-examines tends to continue past the point where it made sense.