Need to Outsource? Do This Instead.
Source: https://www.flickr.com/photos/ofernandezberrios/2719742541
“We’re unhappy with the engineers we’ve hired to build the product. That’s why we’re calling you guys. We want you to fix it.”
This was a frequent request back when I led a software consulting agency. Every week or so, from 2000 to 2011, I got a call or an email from someone whose company was facing imminent financial disaster unless they could salvage their failing software project.
I would ask if I could chat with the current engineering team.
“Well, the engineers are actually based in [India|China|Ukraine|Russia],” they would say. “We’ll have to schedule a call at a time when our business hours overlap.”
The unfortunate thing for our engineering peers abroad is that the caller inevitably believed the failure of his/her project represented some fundamental lack of quality in the engineering capability of their remote team. But that wasn’t really it at all! These were often good engineers. The problem was one of process and organization, as it so often is.
The caller had fallen into the trap of improperly offshoring development of their core product, usually for cost reasons, without having the slightest idea what they were doing. In the end, it was always more expensive.
“Let’s set up a call with these folks,” I’d say calmly. “But… I want to talk with them privately, without you on the line. No offense.” I’d smile to myself as I said this.
After a nervous pause, they’d say, “Well… alright.”
“Don’t worry,” I assured. “I just want to make sure they feel open to speaking freely with me about what’s going on at their end.”
Outsourcing & Offshoring
I really don’t know why startups and small companies hire offshore teams to build the first version of their product. But it happens all the time. I suspect it is related to a myth that offshore technical resources automatically save you money.
Bluntly, that couldn’t be further from the truth — and I’ll tell you exactly why below. But no matter how many projects fail on this pivotal dimension, people keep doing it.
The practice of leveraging technical resources offshore probably evolved out of IT outsourcing in general. In the mid-1980s companies began outsourcing their IT operations to other companies that specialized in it. This made some sense, since it is a good idea to focus your employees on your core value proposition, and not spread your resources too thin.
Gradually, this outsourcing trend evolved into offshoring, as outsourcing giants like IBM located more and more of their data centers and engineering staff outside of the United States and Western Europe.
Eventually, even companies that maintained their own internal IT staff, without outsourcing that function, still set up engineering operations abroad. Presumably, the logic in this decision was that it seemed cost-prohibitive to house technical talent at headquarters.
This hard-t0-dislodge “cost of talent” bias among managers completely misses the fact that delays between work steps in a process, not actual work time, accounts for the lion’s share of costs in product development [Reinertsen 2009]. And physical distance between team members executing those steps affects delays in production far more than any other factor.
By the time I entered the technology field in late 1999, it was entirely common for most software engineering teams inside companies to be working with product and marketing folks in San Francisco from halfway around the world. Startups founded by former employees of these companies simply internalized this habit.
Cross-functional, Colocated, Dedicated Teams
In my book, Startup Patterns, I try to drive home the importance of teams that are small, co-located, cross-functional, and dedicated to one project at a time.
Cross-functional teams create better products than teams organized into functional silos. The feedback loops are tighter, and there is less rework and fewer miscommunications. Further, there are fewer delays from partially completed work items sitting in a queue waiting for the next functional silo to pick them up.
Dedicated teams avoid the costs of context switching. We don’t really multitask. Working on more than one project at a time has been shown over and over to incur immense “switching costs” on teams and individuals, dragging down development speed overall. Trying to do multiple tasks at once only slows you down more!
And nothing tightens feedback loops and improves cross-functional coordination better than being in the same room with your teammates.
“Two outta three ain’t bad”
I frequently run into organizations that, for a variety of reasons, struggle to form their product organization into truly cross-functional, co-located, and dedicated teams. There are a variety of legitimate reasons they give for this, including inheriting a functional group (usually, engineers) from a merger or acquisition, who happen to be across the world.
But what I tell them is this, “If you can’t get all three of these in place, you’d certainly better have two.” For example:
Not dedicated?
A cross-functional, colocated team can afford to work on multiple projects simultaneously, because their proximity to each other makes fast informal communication easier. But it really only works if there is a process in place for work by team members who are on the same project to be synchronized with regular cadences. Daily stand-ups, regular planning, and review meetings can help. A large visual control board somewhere in the office (or online) that shows everyone’s work in an obvious way also helps.
Not co-located?
A cross-functional, distributed team can work well if it is dedicated to one project at a time. These teams leverage modern communications tools (favorites like Slack, Trello, Google Docs, and Google Hangouts) to conquer the physical distance between them. Again, regular synchronized check-ins are critical.
[UPDATE: This post was written pre-COVID. Now, with co-location difficult or impossible, you have to choose the other two options: dedicated and cross-functional. Skipping either will lead to failure.]
Not cross-functional?
A co-located team working together on a single project (dedicated) can sometimes operate in functional silos. There are actually many startups that look this way. It’s certainly not ideal. But the fact that everyone is in the same building makes it a little easier to overcome organic social and behavioral boundaries that form around functional silos. Of the above “two-outta-three” options, this one is probably the least advantageous, and there is not a lot of justification for it. If everyone is in the building and working together on the same project, why not just be cross-functional as well?
If you have a big team and you need divide them along some boundary, you should avoid functional splits. You want people who are working on the same project to be sitting as close together as possible.
Instead, teams that are geographically remote from one another should be organized to work together on a component of the larger system. The interface boundary between components should mirror the geographical separation of the teams.
Let’s look in more detail at why this is the case.
Conway’s Law
Mel Conway’s theorem about systems, originally printed in the April 1968 edition of Datamation magazine, was coined “Conway’s Law” by the legendary Fred Brooks who cited it in his seminal engineering management book “Mythical Man-Month” — which you all have no doubt all read, right?
Put simply, Conway’s Law reads as follows:
“Organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations.”
Let that sink in a minute.
Think about the “communication structures” of your organization. How might those structures affect the end design of systems, particularly information or software systems. Ring true? Check out the original paper (linked above) if you still need convincing.
Component Teams, Not Functional silos
In software engineering, we’ve learned that separation of software into services is a critical enabler of what makes platforms and APIs so powerful. The best systems tend to be organized into independent semi-autonomous components that communicate asynchronously over internet protocols.
These components can be developed along independent timelines and product roadmaps, with new versions of each deployed completely separately from one another.
As it happens, companies that build this way have learned that organizing our product teams similarly around components leads to better outcomes. No longer do you find product management in SF, design in NY, and engineering in Hyderabad. Instead, you find the cross-functional team responsible for search APIs, for example, working together in one office, and the cross-functional team responsible for the mobile app in another office. And that component separation of product teams aligns perfectly with the patterns Conway recognized almost 50 years ago.
