1. Home
  2. Blog
  3. Technology Resource Models for Software, Infrastructure and Digital Teams
Process & Resourcing

Technology Resource Models for Software, Infrastructure and Digital Teams

The choice between hiring, contracting, outsourcing to a managed provider or using an extended team model should follow how long the work lasts, how much organisational context it needs, and whether the capability is core to your business. Capability you compete on should generally be built internally; capability you merely need should generally be bought.

Start with core versus non-core

The capability your business competes on should sit inside it. If your product’s differentiator is how it handles a particular domain problem, the people who understand that problem should be employees, because the knowledge compounds and because handing it to a supplier means renting your own advantage.

Capability you need but do not compete on, infrastructure operations, standard integrations, routine maintenance, is a different category. Buying it from someone who does it at scale is usually better than building a small internal team that does it occasionally.

Model selection by work characteristics
Work characteristic Usual best fit
Core product capability, long-term Permanent hire
Specialist skill needed briefly Contractor
Defined deliverable, clear scope Project outsourcing
Ongoing operations, non-differentiating Managed service
Sustained capacity, your direction and process Extended team
Unpredictable, low volume Managed service or retained hours

Where each model breaks

Permanent hiring breaks on lead time and on demand that turns out to be temporary. It takes months to hire well, and a permanent team sized for a peak is expensive during the trough.

Contracting breaks on knowledge retention. Contractors deliver and leave, and what they knew leaves with them unless handover is enforced rather than hoped for.

Project outsourcing breaks on specification quality. A fixed-scope engagement is only as good as the definition of done, and vague requirements produce either disputes or a technically compliant result nobody wanted.

Extended teams break on coordination. A capable team working to your direction still needs your direction, and organisations that do not have the product ownership capacity to supply it get expensive idle capability.

Coordination is the cost people forget

Every boundary between organisations adds communication overhead, and the effect is not linear. Work split across an internal team, a managed provider and an offshore extended team requires someone whose actual job is keeping them aligned, and if nobody holds that role explicitly, it is absorbed badly by whoever is most senior.

Time zone spread is the specific multiplier. Some overlap in the working day is close to essential for anything requiring iteration; a fully non-overlapping arrangement works only for well-specified, independent workstreams.

  • Name a single person accountable for cross-boundary delivery
  • Require at least three hours of working-day overlap for iterative work
  • Standardise tooling and definitions of done across all parties
  • Give suppliers access to context, not just tickets
  • Review the boundary quarterly; work moves and the split ages

Deciding in practice

Ask four questions about the work. How long will it last? Does it require knowledge of our business that takes months to acquire? Is it something we compete on? Can we specify it well enough for someone outside to deliver it?

Long, context-heavy, core and hard to specify points strongly toward internal capability. Short, self-contained, non-core and specifiable points toward buying it. Most portfolios contain both, and the useful discipline is deciding deliberately per workstream rather than defaulting to one model for everything.

FAQ

Common questions

What is an extended team model?

A supplier provides people who work as part of your team, following your processes, priorities and tooling, rather than delivering an independently scoped project. It suits sustained capacity needs where you have the product ownership capacity to direct the work. It fails where the client cannot supply that direction consistently.

Should software development be outsourced?

Non-differentiating work with clear specifications outsources well. Work that defines your product's competitive advantage generally should not, because the knowledge compounds inside whoever does it and you end up renting your own advantage. Many organisations outsource surrounding work and keep the core internal, which is a reasonable split.

What is the most underestimated cost of distributed technology teams?

Coordination. Every organisational boundary adds communication overhead that grows faster than linearly with the number of parties, and time zone spread multiplies it. If nobody explicitly holds cross-boundary delivery accountability, it is absorbed informally by senior people whose time is the most expensive available.

Keep reading

Related articles

Working on something like this?

If this article covers a problem you are dealing with, tell us where you have got to and we will tell you what we would do next.