Why distributed teams need more structure, not less: choosing a location, writing requirements that survive time zones, giving teams end-to-end ownership, and the false economy in the offshore decision.
Software requirements are a workaround for the ideal scenario, where developers sit with users and build solutions collaboratively. They exist because developers can’t access implicit domain knowledge, navigate organisational politics or extract business rules from hallway conversations. That makes them imperfect but necessary — and never more so than when the people who can answer questions are in another building, another country or another time zone. The further removed your developers are, the more likely things will go wrong, and the more you need software requirements to carry the weight that proximity used to carry for free.
Why distributed teams need more structure
Developers struggle when the people who can answer questions aren’t readily available. Remote developers struggle more, due to their lack of co-location and increased reliance on written communication. Add time zones, language barriers and asynchronous everything, and the gap widens further.
The standard response in many organisations is to apply local agile practices regardless: daily standups, real-time discussions, user stories as ‘placeholders for conversations’. This is well-intentioned but harmful. What remote development teams actually need is more structure and guidance, not less. There is nothing wrong with over-specifying what needs to be built, if that’s what the team and the situation require. Well-defined user stories, frequent backlog refinement and clear definitions of ‘ready’ and ‘done’ all help.
Remote teams working similar hours to the local business can act as an extension of the local workforce. Offshore teams working very different hours perform best when given responsibility for end-to-end work, avoiding part-finished work bouncing between distributed teams. Either way, the remote team must work with you rather than against you — accommodate their needs and avoid imposing local processes without assessing their suitability first.
That is the one principle every distance-related decision in this chapter comes back to. When you can’t tap someone on the shoulder for clarification, requirements have to be self-sufficient. The rest of the chapter is about what ‘self-sufficient’ means in practice — and about the decisions that determine whether a distributed team ever gets the chance to succeed.
Outsourcing and offshoring are not the same thing
Two distinct decisions hide behind the word ‘remote’, and they are easy to conflate. Outsourcing is when you rely on a third-party supplier to develop your software. Offshoring is when you locate your developers in a different country. You can do one without the other, both at once, or (without realising it) both when you thought you were doing one. The outsourcer may offshore their own development, in which case you have outsourced and offshored your software, and you may not even know it has happened.
When outsourcing makes sense. Anyone can hire a developer to build some software, but good software development is complex and costly, something many businesses are better off not doing themselves. Outsourcing your technical decisions and development makes sense when the specialist skills you need are missing internally, particularly if you need them quickly or the nature of your business is not technical. A strategic partner is well placed to advise on product and technical matters; agency outsourcing lets you scale development capability. The cost of engaging a supplier should be more than compensated by access to their expertise and the opportunity cost you avoid by not building that capability yourself. Long-lasting, mutually beneficial relationships can occur in both forms.
The distinction matters because the requirements challenge is driven by distance and asynchrony, not by who signs the cheques. A co-located outsourced team is an extension of your workforce; an offshore team eight hours away is a different proposition entirely. Most of what follows applies to any developer you can’t tap on the shoulder, but it bites hardest offshore; that is where the rest of the chapter concentrates.
Why offshore fails — and how it succeeds
Most offshore failures aren’t about technical ability. The developers are rarely the problem. They stem from three fundamental mismatches.
Communication assumptions. Local teams assume real-time conversations, hallway chats and quick clarifications. Offshore teams work asynchronously, across time zones, often in their second language. Requirements that work locally become ambiguous remotely.
Process incompatibility. Forcing ‘agile’ practices designed for co-located teams onto offshore developers is counterproductive. Daily standups at 6am their time, ‘placeholders for a conversation’ when the customer is eight hours away, and expecting developers to ‘just collaborate’ when separated by time and language — this isn’t agile, it’s negligent.
Hidden cost illusions. Lower hourly rates attract many organisations, but the hidden costs quickly accumulate: time zone coordination overhead, additional documentation, quality issues, longer release cycles and local staff hired to manage offshore staff. The economic case collapses if you’re not prepared for these realities.
Imagine working to tight deadlines as a non-native English speaker, relying on electronic communication, several time zones away, with limited access to the client or product owner. Then imagine receiving user stories described as ‘placeholders for conversations’ — except the customer is in another country and the conversations would happen in a language that isn’t your first. Talented offshore teams struggle not because they lack skill, but because their organisation imposes local practices without adaptation. Fix the process and the same teams deliver excellent results.
The offshore decision and its false economy
The decision to offshore isn’t just about cost. It’s about whether your organisation is genuinely ready for the challenges and committed to making it work.
Most offshoring is driven by budget holders seeking to reduce development costs, but the economic case is rarely what it first appears. Good-quality developers in a similar time zone, who speak the same language as you, will usually cost much the same as your local market already demands. So the saving isn’t made there. Lower development costs need compromises to happen — far-away time zones, junior bootcamp developers, language differences, cultural challenges or political instability. These are what produce the attractively low rates. Your economic case for offshoring therefore rests on being confident you can deliver on par with a locally sourced team despite those compromises. Otherwise you face hiring local staff to manage offshore staff, tolerating poorer quality and longer release cycles, feeling stressed throughout — all for a higher cost than expected. Organisations that offshore expecting ‘same service, lower cost’ are consistently disappointed.
Offshore works when you’ve already got your house in order locally. If your local teams write clear, complete requirements and developers rarely get blocked, you’ve got the foundation to succeed remotely. If you’re struggling with requirements locally, offshore will amplify those problems, not solve them. Vague tickets, frequent developer questions, regular rework and unclear acceptance criteria multiply with distance. Fix them locally first, then consider offshore. And projects that depend on constant real-time collaboration, where developers and stakeholders sketch solutions on a whiteboard several times a day, are poor candidates whatever your readiness, because that cadence simply can’t survive an eight-hour time difference.
Choosing a location
Not all offshore locations are equal. I favour Eastern Europe, particularly Poland or Romania. The technical calibre is very high, there is a good grasp of English, and working hours are similar to the UK. Perhaps most importantly, Eastern Europe seems to have a culture of excellent software craftsmanship. The trade-off is cost: Eastern European developers are no longer much cheaper than the local UK market, so if budget is the primary driver you are not saving much. If budget is not the primary driver, it is outstanding — and given the choice, I would still prefer to hire there remotely.
If you are looking for more significant cost savings, look to Southeast Asia — places like Vietnam and the Philippines, which have decent emerging offshore development industries. Favourable currency rates and lower costs should more than compensate for the increased challenges compared with their Eastern European counterparts. There are no guarantees, though, and further afield comes with higher risks of things going wrong. Better software requirements help close that gap. There are many Indian offshore development firms, but they would not be my first choice: large variations in quality, communication challenges and a cottage industry of brokers add complexity, and other locations typically offer a better experience. Mileage will vary.
Structuring requirements for distance
Structuring requirements for offshore teams isn’t about writing more — it’s about writing differently. The hardest mindset shift is to assume every question takes 12 to 24 hours to answer. That casual ‘quick question’ you’d ask a local developer over coffee becomes an email that arrives while they’re sleeping, gets answered while you’re sleeping, and turns a 30-second conversation into a two-day exchange. Every ambiguity that would be clarified verbally in minutes becomes a blocker that halts work for hours or days.
The remedy is to make the requirement self-sufficient. Each one should answer the obvious questions before a developer needs to ask them: why are we building this, what problem it solves, where it fits in the user journey, who is affected and how success is measured. ‘User can update their profile’ is not a requirement — it leaves unanswered which fields can change, what the validation rules are, whether changes take effect immediately, whether updating an email requires verification, and what happens if two people edit the same profile at once. Locally a developer interrupts you for the answers. Remotely they guess or get blocked. Neither outcome is good.
Make the implicit explicit, because the offshore developer doesn’t have your context. They don’t know your industry, haven’t attended your planning meetings and haven’t absorbed organisational knowledge through hallway conversations. State business rules plainly: ‘credit cards expire on the last day of the month shown’ rather than ‘handle card expiry’. Define your terms: ‘Priority 1 means it must deploy to production within 24 hours’ rather than assuming everyone shares your priority scheme. One team lost an entire week because a requirement said ‘validate email addresses’ without saying what ‘valid’ meant: the offshore developers implemented basic format checking, the local team expected domain and deliverability checks, and neither was wrong — the requirement was simply incomplete. Another implemented phone-number validation that rejected UK numbers, because ‘10-digit phone numbers only’ obviously meant US format to its author and nothing in the requirement said so. Everything you think is obvious probably isn’t.
None of this means over-specification. Over-specification tells developers how to code: font sizes, exact wording, implementation details that remove their autonomy and treat them as code typists. Appropriate detail tells them what to build and why, with enough context to make good decisions without interrupting your sleep. The difference between writing requirements and writing them for distance is one of completeness, not of control. For how to write a requirement so a developer can proceed unblocked, see Writing Requirements; use cases, which capture a behaviour end to end, earn their keep when the people building them are remote.
This is also where Definitions of ‘ready’ and ‘done’ stop being bureaucracy and start solving a real problem. When you can’t quickly clarify what’s expected, written criteria become essential: offshore teams know exactly what is required without having to ask, and local teams know exactly what they’re getting back without surprises. The criteria themselves are the same ones every team should use, set out in Reviewing Requirements; distance is what turns them from good practice into a precondition for work starting at all.
Detailed requirements for distributed teams are not ‘un-agile’, whatever a textbook reading of co-located practice might suggest. Jeff Sutherland, co-creator of Scrum, proposed ‘Enabling Specifications’ in 2012, narrating stories with detail specifically for distributed teams. It never formally entered Scrum, but the concept acknowledges that teams working across time zones and languages need more context than co-located ones. The problem isn’t detailed requirements. It’s imposing co-located agile practices, designed for the team a textbook describes, onto a distributed team that can’t get the information those practices assume.
Read more: Enabling Specifications
End-to-end ownership
Avoid splitting features between local and offshore teams. Don’t have a local team start a feature and an offshore team finish it, don’t assign the frontend offshore and the backend locally, and don’t create dependencies where half-finished work bounces between time zones waiting for the other team to do its part. Every handoff creates delay, confusion and lost context, and a cross-timezone handoff costs a day before anyone has done anything wrong.
Instead, give offshore teams complete features they own from start to finish: designing, building, testing and deploying whole user journeys, making the technical decisions within their domain. This serves two purposes. It’s more efficient, because there is no coordination overhead and no waiting on the other time zone. And it builds ownership and pride: teams care more about features they own completely than about work they merely contribute pieces to. Reduce handoffs and dependencies to the absolute minimum the work allows.
Managing the relationship
Meet in person, at least once. Budget for initial face-to-face meetings. Putting names to faces, building personal relationships and understanding each other’s working context pays dividends for years; it is what turns an offshore ‘vendor’ into teammates you’ve shared a meal with. I’ve seen one of the most successful offshore partnerships run with a development team in Gdansk, where the Technical Business Analyst and Product Owner travelled from London for in-person sessions once a month, and those monthly visits transformed the working relationship from ‘offshore vendor’ into genuine colleagues. Treat the travel budget as essential rather than a nice-to-have.
Work with the team, not against it. Respect their time zones rather than expecting 6am calls. Understand their constraints: internet reliability, local holidays. Adapt your processes to fit their reality, and ask them what they need to succeed. Asynchronous tools are now your primary communication method: detailed tickets, recorded demos, written summaries after every call. Not your backup. Document decisions immediately, before the meeting that produced them ends.
Avoid fixed-price, fixed-scope contracts. Outsourced suppliers routinely offer these when bidding, and you almost certainly want to decline. Software is never a known quantity, so a supplier locked into fixed scope will either charge you for every change, quietly reduce quality to stay profitable, or both. A fixed-cost, variable-scope arrangement removes that incentive and encourages the supplier to behave as a strategic partner rather than a vendor protecting a margin.
Treat ‘five developers for the price of four’ as a warning, not a discount. Suppliers offering extra developers ‘free’ are not handing you a deal. According to The Mythical Man-Month, adding people to a late project makes it later, so more developers does not mean better results — it is another false economy. The work the relationship demands is the real benefit: better planning, coordination and ongoing communication, well-defined user stories, frequent refinement and clear definitions of ‘ready’ and ‘done’. When you can’t rely on hallway conversations, you are forced to write better requirements, and those practices improve your local teams too.
Is it ethical to offshore?
International trade is here to stay, and that applies to services as much as to physical goods. Access to global talent and lower costs are compelling reasons to offshore, and choosing a location with a favourable exchange rate can have a material impact on individuals, families and whole communities, genuinely part of corporate social responsibility rather than charity. But remote workers may not enjoy the same legal rights and working conditions afforded to local staff, and you should not propagate basic human rights violations, knowingly or by looking the other way.
Be a good global citizen and do your due diligence: fair wages by local standards rather than poverty wages, employment rights respected, good working conditions, no human rights abuses. Visit the supplier and speak directly to their staff in person. Western buyers of offshore services hold real power to influence their suppliers for the good. Use it.
In closing
Offshore development succeeds when you adapt to its realities rather than expecting it to mimic co-located work. More complete requirements, asynchronous communication, end-to-end ownership and genuine partnership turn a distributed team from ‘cheap labour’ into valuable contributors. The developers aren’t the problem; the process mismatch is. Fix the process and offshore teams deliver excellent results.
When offshore development is layered onto a legacy replacement, where much of what the system does was never written down, the two hardest contexts in this book combine into something close to a perfect storm. That is the subject of Replacing Legacy Systems. Happy, productive development teams come in all shapes, sizes and locations — provided the requirements travel as far as the work does.