The Case for Onshore Technology Teams

ARTICLE – Brian Duperrouzel shares 5 characteristics of projects that should work exclusively with onshore teams. (03:00)

Brian Duperrouzel shares 5 characteristics of projects that should work exclusively with onshore teams.

High cost labor markets have been offshoring technology jobs at scale going back to the Y2K problem. As the digital waves of change are forcing companies to shift their mindset from operational excellence to innovation, are technology leaders and their procurement department partners prepared to make the case for higher labor rate (but not necessarily labor cost) onshore technology teams?

While there will always be plenty of projects which make economic sense to shift offshore, or minimally use a blended onshore and offshore team, there are certain projects which companies should work exclusively with onshore teams. Five characteristics of these projects are:

Ambiguity: While business leaders may not like to admit it while asking their executive committees for funding, digital technology projects are often layered in ambiguity which requires the business and technology teams to be in the same room for frictionless communication. Successfully navigating through ambiguity, in an acceptable timeframe, is only happening with the right people in the room.

Flexibility: The final solution for a particular problem is often not discovered until the project is half way through its lifecycle. These are discovery driven projects, where the answer for one part of the solution is only findable after the answer of another part of the solution is realized. In agile speak, what’s in the second sprint is determined by the outcome of the first sprint. Onshore teams, due to proximity and frictionless communication are simply more flexible and can react to new discoveries much faster than their offshore counterparts.

Velocity: Certain projects require maximum development velocity to meet time to market constraints. While full onshore teams look expensive on a labor rate per hour basis, what buyers need to normalize is the development velocity they are buying at that labor rate. In some cases, 100% onshore teams can actually be cheaper than mixed onshore/offshore teams based on a higher realized development velocity. Put more simply, if the 100% onshore team produces 3x more product, for 2x the cost, in 1/2 the time, which model is better for your business? Sadly, many companies don’t measure their development velocity relative to their labor costs which masks the real cost per capability (or story point) delivered.

Optimal Team Size: Amazon’s Jeff Bezos’ two pizza rule is actually rooted in software research (W. Roetzheim and S. McConnell) which has shown that small teams are most effective on software development projects due to the reduced communication pathways required. If you are going for a high velocity, two pizza team that is flexible and gobbles up ambiguity, then both pizzas should be delivered to the same continent. I have seen frugal managers break up a small team of 4-8 people in two different countries, killing their velocity and flexibility for the sake of ‘cost savings’ that were not ultimately realized due to the extended project duration needed to make up for the reduced velocity.

Time to Market: Digital technology projects are often pressured by time to market constraints. The ultimate byproduct of a small, high velocity onshore team, which is flexible to change and can resolve ambiguity quickly, is a faster time to market.  Face to face communication saves lots of time.

You can’t cheat the project gods. Offshoring is a tradeoff, so understanding what you are trading off, which can be measured via development velocity metrics and time to market is critical to making the case for a full onshore team when the project requires.

An old mentor once coached me, “The cheapest manager pays the most…” but this quote from John Ruskin is more eloquent:

“It’s unwise to pay too much, but it’s worse to pay too little. When you pay too much, you lose a little money – that’s all. When you pay too little, you sometimes lose everything, because the thing you bought was incapable of doing the thing it was bought to do.”

Leave a Reply

%d bloggers like this: