Engineering Leadership · Chapter 9 of 9
Running a capability centre or a satellite site
Why sites stall at delivery, the single test of how much authority you actually have, and the failure modes that are structural rather than cultural.
A large share of the engineering leadership jobs in India — and in Poland, Mexico, Vietnam and a dozen other places — are at a site owned by a company headquartered somewhere else. It is a genuinely different job from running a team at headquarters, it is barely written about, and the differences are structural rather than cultural.
The four stages, and where sites stop
Sites move through a recognisable progression: executing work defined elsewhere, then delivering features and whole services, then owning products end to end, and occasionally becoming a centre that originates new business.
Most stop at delivery, and the reason is not talent, cost, timezone or culture, though all four get blamed. It is that the disciplines that decide what to build — product management, design, user research — are still at headquarters. Engineering can execute anything and cannot decide anything, so a site can be genuinely excellent and permanently stuck.
The single test of which stage you are actually at
Can a decision be made here, overnight, without waiting for the other timezone?
Not ‘are we consulted’ — consultation is compatible with having no authority at all. Can it be decided, and will the decision stand.
If every non-trivial choice waits sixteen hours for someone else's morning, you are at the delivery stage whatever the organisation chart says. And the cost is not just latency: a team that cannot decide stops proposing, because proposing is expensive and being overruled is demoralising. That is how a site quietly becomes an order-taker while everyone involved is trying hard.
Which makes the leadership job mostly about acquiring decision rights, and only secondarily about running engineering well. Running engineering well is table stakes; it is not what moves the site.
How authority is actually acquired
Not by asking for it, and not by an organisational redesign proposed from the satellite. It moves in a predictable sequence, and understanding the sequence is most of the strategy:
- Deliver something visible and hard. Not more of the existing work — something the centre was worried about. Credibility is the currency and it is earned once.
- Then take ownership of something end to end, including its production operation and its on-call. Owning the pager is what converts a team into an owner, because whoever is woken up at three in the morning acquires the right to decide how the thing is built. This is the most reliable single lever available and it is frequently offered rather than fought for, because nobody at headquarters enjoys being on call for a system in another timezone.
- Then get one product or design person located here. A single product manager in the same timezone changes the site's stage more than fifty additional engineers, because it moves the decision rather than the execution. If you can only win one thing in a year, win this one.
- Then hire a senior person the centre respects — ideally someone who has worked at headquarters and moved. They carry credibility across, and they know which arguments land there.
- And be visibly good at the thing the centre finds hardest. Every organisation has a discipline it is weak at. A site that becomes the place that discipline lives acquires a reason to exist that is not cost.
The failure modes, and they are structural
Measured on cost per head. If the site's success metric is headcount cost, nobody can justify seniority, and a site of exclusively junior engineers cannot take ownership of anything — which confirms the belief that it should not. It is a closed loop and it must be broken deliberately, by changing the metric to something outcome-shaped before arguing about levels.
The follow-the-sun trap. Handing work over at the end of each day sounds efficient and is the single most reliable way to prevent ownership: nobody owns anything because everybody owns everything for eight hours. Real handover of context is far more expensive than people assume, and the model works only for genuinely stateless work such as incident triage.
Attrition that is really a career-path problem. High attrition at satellite sites is usually diagnosed as a market problem and is usually a ceiling problem. If the most senior technical person at the site is three levels below the most senior at headquarters, then everyone competent leaves when they hit that ceiling — and they leave to another company's site, at a higher level, doing the same work. The fix is levels, not salary.
Being the place where the unpleasant work goes. Maintenance, migrations, compliance remediation, and the legacy system nobody at headquarters will touch. Some of this is legitimate and reasonable; a site that gets only this cannot hire well and cannot retain, and the pattern establishes itself quietly one project at a time.
And a proximity effect nobody names. Promotion, interesting work and informal influence all flow toward the people the decision-makers see. This is not malice and it does not respond to good intentions; it responds only to written processes — calibrated promotion criteria, documented decisions, allocation that is reviewed rather than assumed.
Working across a large time difference
The practices that actually work are the same ones that make any distributed team function, applied with more discipline because the cost of failure is higher:
- Write things down, and treat the document as the decision. A meeting one half of the company cannot attend is not a decision-making forum. If it was decided in a call, it is not decided until it is written.
- Protect the overlap ruthlessly. Two or three hours of overlap is genuinely enough — if it is used for the things that need synchronous discussion, and not for status. Status in the overlap window is the most common waste of the scarcest resource the site has.
- Rotate the inconvenience. If the same people always take the late call, you have communicated the hierarchy more clearly than any organisation chart.
- Make the site's work visible in the centre's channels, not in its own. A demo recorded and posted where headquarters will see it does more for the site's standing than any amount of reporting.
- And insist on a whole capability, not a layer. A site that owns the whole of one thing coordinates rarely; a site that owns the backend of everything coordinates constantly, and every coordination costs a day. This is the same argument as the dependency hierarchy in programme management, and it applies with more force across a timezone.
What to ask before you take one of these jobs
These roles vary enormously and the interview is your only chance to find out which one it is. Five questions that reveal it:
- “What has this site decided in the last quarter that headquarters did not review?” The single most revealing question, and hesitation is the answer.
- “Where do the product managers for this work sit?”
- “What is the most senior technical level anyone here holds, and what is it at headquarters?” The gap is the ceiling you are hiring into.
- “Who is on call for what this site builds?”
- “What is the site measured on?” If the answer is cost or headcount, you now know what the job is — and if you take it anyway, you know that changing the metric is the first project.
A site at the delivery stage with a genuine intent to move is a good job and an unusually clear mandate. A site at the delivery stage with no such intent is a good job for two years and a ceiling after that. Both are worth taking; only one is worth staying in, and knowing which you are in is worth more than any amount of effort spent on the wrong one.
Check yourself