Q: Why does most offsourcing not work?
A: Because outsourcing comes with agency cost and offshoring exacerbates the weaknesses of most development teams
(Like this article? Read more Wednesday Wisdom!)
A few weeks ago I read one of these extremely annoying LinkedIn post. You know the ones: Every sentence is a separate paragraph and the post asks in itself valid questions, only to “reveal” in the comments that the poster actually has a business in helping you answer the very questions they posed.
In this particular post the following four questions were asked:
I need to hire offshore software developers for my startup.
Where should I hire them?
How do I trust them?
How do I make this work?
Right off the bat I would say that nobody needs to hire offshore software developers for their startup. Too many people confuse “need” with “want”, thereby moving the driver for their behavior outside of themselves. Here is a tip: Replace all uses of the word “need” by “want”; I guarantee you the entire situation becomes much clearer in an instant.
So you want to hire offshore software developers. My first question would be “Why?”, but I guess that in most cases the answer is: “It be cheaper bruh!”
It is true that the hourly rates of software developers vary greatly across the world, with northwest Europe and the US at the top. Stands to reason. But that is of course not the end of the story; the question is surely not what the hourly rate of your developers is, but what the total cost of development is to get what you want.
Too much outsourcing and offshoring is driven by penny pinching based on naïve mental models of software engineering like this one: “I got these requirements over here. It will take 10,000 hours to build this software with a team of local developers. Outsourced developers are better and offshored developers are cheaper. So instead of paying 10,000 x $65 I only have to pay 8,000 x $15! Plus I don’t have the cost of hiring! Just by offsourcing (outsourcing and offshoring) I can cut my costs by more than half a million dollars! W00t!” If you have $120,000 but not $650,000, it makes total sense to think that this is the way to go.
Unless you understand software engineering.
Many years ago I was consulting with a bank and after a few false starts they had assembled a great team building applications for their global transaction services business. That team had become successful by ignoring the corporate architects’ idiotic ideas and just writing working code using the best that technology had to offer at the time. Unfortunately, relentless cost cutting had eventually led the bank to outsource their IT to a handful of large IT companies. After a while, even more relentless cost cutting prompted them to consider offshoring most software development to a large IT company in southeast Asia.
After the contract was signed our new southeast Asian IT partner flew in a few engineers to learn about our systems. These folks were nothing short of amazing and to be honest we started to have some faith that this might actually work. Unfortunately, once the ink on the contract was dry and we had transferred our knowledge, we never saw these amazing people again. Instead, we now dealt with people that were, let’s put it mildly, less amazing.
Everything went downhill from there, with the exception of our level of frustration, which went uphill quite sharply. Eventually, people started grumbling about the quality of the people we were dealing with from our partner. I would be the first to say that they were not the best people I had ever seen, but I also was of the opinion that it was a little bit unfair because of the way we treated them. As I explained to the local executives: “It’s not just the level of the people and the geographic distance. Imagine we hire a team of crack software engineers and we put them in an office the next town over and then we treat them in exactly the same way as we treat our offshored engineers: We never talk to them, we never write down what we want, and we keep changing our minds about the requirements and the timeline. How well is that going to go?” This was before the era of easy and cheap video conferencing, so our communication was restricted to phone conference calls, which I learned to hate with a vengeance. At one point we hired an expert in cross-cultural communication and after a while she concluded that it was a miracle we got anything done.
I told the bank’s executives at the time the outsourcing and offshoring decisions were made that we are not ready for this. As I put it at the time: “Outsourcing works well for our company restaurant. And you know why? Because we know upfront what we want, we don’t change our mind about it, and when delivery happens we can check whether what we got is what we told them we wanted. Imagine we tell the catering company that we want three types of milk, two types of bread with five types of toppings, a salad bar, and a different hot snack every day. While the catering company is working on putting that together, we never revisit that plan. Then when the restaurant opens, we walk in and we check whether the milk, bread, toppings, salad bar, and hot snack are there. Presto! Outsourcing success! How different is our software engineering! We never know what we want, we don’t write it down, while development is going on we constantly change our minds, and when the software comes in, our testing sucks so much that we never know whether what we got meets what we need.”
Most software engineering works like the latter half of the previous paragraph, which is why we developed agile methodologies. One of the key components of agile is constant collaboration and communication between all stakeholders in the project, and for that to work it helps if all of these stakeholders are “close” to each other. Not just geographically (though that helps), but in all ways that ensures the required collaboration and communication is as easy as possible.
Offshoring introduces all sorts of distance: Geographic, time zone, language, you name it, and that distance makes it hard to collaborate. It’s not impossible, but it takes time and money to set that up, thereby eradicating some of the cost benefits of offshoring. I specifically want to draw some attention to cultural closeness, since that is often overlooked. Software is supposed to help people doing their work and it is important for the software developers to understand that work. A lot of software is thoroughly embedded in local business culture, practices and laws. If you get a software developer from the other side of the world, how likely are they to understand the details of the environment that they are coding for? This puts an even bigger emphasis on clarity of communication and completeness of the specification.
And then I am not even mentioning the issues of working with people from cultures where words have completely different meanings! I have worked with people from countries where “yes” could mean “yes”, “maybe”, or “no”, depending on the pronunciation. Nothing wrong with that, it’s all just culture, but it took me a while to figure that one out.
Offshored software development often fails for these exact reasons: It is hard to communicate clearly and concisely over large distances and most of our working and managerial styles rely on the availability of lots of effortless communication. It’s not impossible to overcome these problems, but it requires thoughtful efforts and discipline. And how good are we at that, exactly?
On top of that, outsourcing comes with agency costs. Put simply, these are the costs that derive from the fact that you are hiring someone to do a job for you and that someone has a different goal than you do. In an outsourcing situation, your goal typically is to get the job done as quickly and cheaply as possible, whereas their goal is to milk you for every loose lying dollar. In time & material contracts, there really is no incentive for the contractor to get the job done anytime soon, which often leads to enormous budget and timeline overruns. My experience with these types of contracts is that contractors are more than willing to engage in discussions about extensions to the original plans, new features, additions, whatnot, often enticing different groups in the customer organization to request those.
To combat this, many customers opt for fixed priced contracts. Great solution, but that comes with the problem that every deviation from the agreed-upon plan needs a time consuming negotiation and possibly a contract extension with a separate price tag. I have been in situations where even the most trivial changes, that technically speaking were super simple to implement, got bogged down in a contract negotiation hellscape.
The difference between these two approaches played out in full view between SpaceX and Boeing when developing a manned space flight solution. After years of being fleeced, NASA had awarded fixed price contracts to these two companies. Boeing, grown lazy and fat from years of (essentially) T&M contracts, struggled to develop a solution in a situation where they could no longer just pass the cost of their inefficiency to the taxpayer.
Here is a stunning story of agency cost: Many years ago, the Dutch postal service decided to outsource a large part of their core IT platform to a large Dutch IT company. Their account manager for this gig told me that on his first day in the contract, he met a fellow account manager from another provider of IT services in the elevator of the postal service HQ. “Congratulations on landing the contract”, my friend’s associate told him, “this cake is so big, we can all take a huge slice.” That is the essence of agency cost, right there!
So there you have it. If you want to hire offshore software developers for your startup that is all fine and dandy, but you need to be honest with yourself and figure out if you are able to make this a profitable and working proposition. I frequently get asked by lots of people who want an app to advise them and outsourcing/offshoring regularly comes up as a solution. Unfortunately, I rarely see good results; not because outsourced/offshore developers are worse; they are not (or at least, not necessarily). But just because managing a software development process is hard enough as it is, and is exponentially harder in an outsourced and/or offshored situation.
> I don’t give out cake, but if you subscribe to Wednesday Wisdom, you do get a free article every wake.
This typo appeals to my morbid humor.
Through my work with people from diverse cultural and educational backgrounds, I've often been surprised by how straightforward tasks can sometimes lead to unexpected results. Now, obviously much wiser (hahahaha!), I understand that everyone's perspective is unique. This means I need to take the time to explain my goals and expectations clearly, while also actively listening to my collaborators. It's important to understand when they disagree, don't understand, or see potential problems – but also to value their ideas.
In my experience, the biggest challenges with outsourcing services, tasks, or departments are twofold. First, there can be a disconnect regarding the desired outcome. Second, there's sometimes an expectation that once something is outsourced and paid for, it requires no further involvement. However, outsourcing doesn't mean handing something off and walking away. It's about building a working relationship that requires ongoing effort.
My experience doesn't come form IT, so I don't even want to imagine......
Thank Jos for sharing!