Entirely in-house, co-located development teams are growing increasingly uncommon. Companies are realizing that a good phone/internet connection is a highly efficient substitute for a cubical, and good developers in the area are never available when you need them. This has led to a huge surge in remote work and distributed contractors, but some companies manage this process better than others. Here are a few issues that I see almost everyone get wrong.
Mistake #1: Shopping for Cost, not Quality
I frequently see the concept of a remote team conflated with the idea of cheap outsourcing (of textile/automobile fame). And yet the markets are fundamentally different: Manufacturers are taking advantage of an arbitrage opportunity where physical labor is geographically restricted and thereby trapped in its own low-cost market, to be repackaged and resold as high-value goods in high-cost markets. Knowledge work does not share that geographic restriction, and thus does not present the same opportunity for cost arbitrage.
The 1970s “cheap outsourcing” attitude towards remote development looks like this: If you can overcome the distance barrier by working with a developer in India or Eastern Europe, you’ll receive some kind of discount per unit of quality work and be able to leverage that in your more expensive market (the US or Europe).
I’m sorry to say that this is not the case. Today’s technology makes distance a non-issue in the majority of development projects, so shopping abroad for low-cost labor basically just translates to shopping for low-cost labor, which you can find at home (hint: look for someone who is inexperienced or unskilled).
There is great development talent abroad. But if you have this outsourcing mentality, you are probably shopping for cost when you should be looking for quality. The major caveat is that the talent won’t be dramatically less expensive than it is at home – the market for technology is global, and doesn’t really care where you are.
Now I’m not saying there aren’t opportunities to save money, and I’m downplaying the challenges of work at a distance to make a point. But the next time you find yourself wondering if that $15/hour developer in Pakistan is going to put out work like the $150/hour senior developer in California, here’s your answer: He won’t. (While the $100/hour engineer in Islamabad may well beat out both.)
Mistake #2: Underestimating Communication Barriers
In preparation for this post I calculated the word count of all emails that I exchanged with a recent client regarding a fairly standard Minimum Viable Product build. I removed all meaningless content (e.g. datestamps, reply summaries, etc) and signatures so only unique product-related communication remained. Together we accumulated over 50,000 words of email over the roughly three months of the project, in addition to hours of regularly scheduled calls. That is either a long novella or a short book, depending on how you look at it.
Just for some context we are both highly educated, native English speakers. And you can safely assume we were being as concise as possible (no room for fluff in discussing complex systems).
People often assume a significant hourly cost discount is worth a little communication barrier, but I’d argue this is the number one cause of all product development failures in remote work. It will end up costing you more money over the long run than any amount you will save up front. And this isn’t just language proficiency; communication even in your native tongue is a skill that is honed over time. I rank the ability to communicate higher than technical proficiency every single time.
Mistake #3: Scope Creep, Scope Creep, Scope Creep
The challenge in many contracted development projects (i.e. the people building it do not have a vested stake in the product) is that you are going to get what you ask for, which is never exactly what you want. Custom applications always change based on early usage and user feedback, which means that you need to work with someone who understands how to adapt and anticipate requirements throughout the life of the project, not just while creating the initial spec sheet.
But there is a limit to this flexibility. In web applications, features beget features and one minor tweak can quickly morph into hours or additional work for a developer, either from unanticipated complexity or unforeseen additional features that become necessary during implementation (these are commonly misrepresented as “bugs” that need to be fixed).
This cycle of scope creep can be extremely demoralizing to a development team, who is unlikely to bill the extra hours either because it is a fixed-price job and they can’t, or because they don’t want to blindside clients with unforeseen costs. And outside of internalized financial burdens, a moving goalpost in any complex project kills motivation and throws off development time lines (both for your project and other projects the team is working on).
It is impossible to avoid scope creep in all cases (which is why you hear about it so frequently), but the key as a product manager is to identify when it happens and adjust the project triangle accordingly.