A centre that isn't working rarely has a staffing problem. It has an unresolved question about who decides things, and that question was left open because everyone assumed the answer was obvious to everyone else.

The pattern is consistent enough to plan around. Engineers arrive, the first quarter goes well because the work is clear, and somewhere in month 5 a decision appears that nobody owns: a library choice, a hiring level, whether a defect blocks a release. The centre stalls waiting for an answer, and the client reads that as a capability problem. It isn't. Staff augmentation services and full centres both live or die on this, and the fix is boring: write the decision rights down before the second hire.

Who owns which decision

Split the list into 3 buckets: decisions that belong to the client, decisions that belong to the partner who employs the team, and decisions that need both. Most disputes come from the third bucket being left undefined rather than from either side overreaching. The same map applies whether you run a full centre or buy staff augmentation services for a handful of roles.

A decision map worth agreeing in writing

Read the third column as the real content. Every row drifts in a predictable direction, and knowing which direction is most of the management job.

When a local management layer earns its cost

Clients buying staff augmentation services for fewer than 8 engineers rarely need a local manager at all. Below roughly 8 people, a centre usually doesn't either, and adding one puts a translator between your engineering leadership and the engineers. Above 15 it usually does, because somebody on the ground has to handle the things that don't travel over a call: a person struggling without saying so, a team splitting into cliques, an office problem nobody mentions in a standup.

The middle range is a judgement call, and the honest version of it depends on how much management attention your own leadership can give. A client whose VP of Engineering has 4 hours a week for the centre needs a local lead sooner than one whose VP is there every morning.

The number that tells you it's working

Average engagement length across the teams we run is 3.5 years. It's the measure we'd point a client to before any productivity metric, because an engineer who stays 3 years has absorbed the system, the conventions and the reasons behind old decisions. That's the asset a centre exists to build, and it's the one that disappears fastest when management is absent.

What the client has to staff on its own side

2 roles, and neither is optional. Someone who owns the backlog the centre works from, with enough authority to reprioritise without a meeting. Someone who owns the relationship, handles the commercial conversation and notices when a pattern is forming.

Those two roles exist whether the arrangement is a full centre or staff augmentation services. They can be the same person in a small company. They cannot be nobody. An offshore development center with no named owner on the client side reverts to whatever the partner's account manager decides, and that's how a client ends up with an arrangement that looks like outsourcing without ever having chosen it.

Career paths come with the team

An engineer 2 years into a centre asks a fair question. What does the next step look like? Where the centre appears in the client's headcount plan, people can see the answer and plan around it. Where it doesn't, they work that out on their own and start looking, and the centre loses someone it had already trained.

Answering it doesn't require a formal ladder. It requires someone to have thought about whether the senior role, the lead role and the architect role can exist in that location at all. Say so either way. Ambiguity reads as a no.

Measuring it without counting tickets

An offshore development center gets measured badly more often than it gets run badly. Ticket throughput counts how work was sliced, not how much got done. 3 questions tell you more. Does the centre catch problems before your own team does? Can it make a decision in its own working day without waiting? Would you hire these people onto your own payroll if you could?

A no to the third question is worth taking seriously, because it usually means the hiring bar slipped somewhere and nobody said it out loud. Staff augmentation services can be audited against the same test, and it's a faster read than any dashboard.

Where to start

If the centre isn't running the way you want, go in this order. Decision rights, then the named owner on your side, then career visibility. Productivity complaints almost always resolve into one of those 3, and reorganising the work before fixing them just moves the problem somewhere less visible. The order holds for staff augmentation services too, where the same failures appear at smaller scale and get noticed later.

FAQ: running a centre day to day

Who runs performance reviews, us or the partner?

You do, on the technical substance, because you're the one directing the work. The partner should be in the room for anything touching compensation, role changes or an exit, since those carry local employment consequences the client isn't positioned to judge.

How often should leadership visit?

Once in the first quarter matters more than a regular cadence afterwards. The first visit converts a set of names into colleagues, and everything after that is cheaper. Teams that never meet their leadership in person stay formal with them for years.

What if the centre and the in-house team compete?

That's a scope problem wearing a culture costume. It happens when both groups can claim the same work. Give the centre a system it owns outright and the competition disappears, because ownership is what people were arguing about all along.

Can we run a centre without a local lead?

Up to a point, and the limit is attention, not headcount. If your own managers are present daily and the group is small, no lead is needed. Once nobody on the ground can answer a question about the group itself, you've passed the line.

How do we keep conventions consistent across locations?

Through code review. Documentation drifts; review doesn't. A written standard nobody enforces drifts within a quarter. Engineers from both locations reviewing each other's work keeps one codebase culture without anyone having to police it.

When does a centre stop making sense?

When the work it holds shrinks below the overhead of running it, or when the client's own roadmap no longer needs a permanent group in that location. Both are legitimate endings, and both are easier if the exit terms were written at the start.