Kill the Specter Over Outsourcing and Remote Dev Teams

I’ve had the pleasure of working with remote developer and engineering teams for most of my professional career, starting out at Johnson & Johnson back in the mid-90’s.

It wasn’t a “thing” quite yet but over the next decade an increasing amount of work was sent overseas and the general feeling and sense was one of negativity and even fear.

I can remember one watercooler conversation (an actual, physical watercooler… crazy, I know…) and I could hear some of the older software developers whine and complain about how “outsourcing” was “killing” the industry and how the quality of work was, if not immediately deemed terrible and unusable, just plain “bad”.

The mass media began picking up on this dynamic and I remember the absolute FUD (fear, uncertainty, and doubt) that was being liberally programmed into the public about how outsourcing any work abroad was disloyal and un-American. Eastern Europe, India, and especially anything remotely associated with Russia was on the engineering blacklist.

Yup. This actually happened… still does, I’m told.

And that never quite sat well with me.

One of my first “developer friend” that I ever had (i.e. a friend who was a developer) was a guy named Venkat from Bangalore, India which is now recognized as the Silicon Valley of India and effectively the “IT Capital of India” – he was a skilled, motivated, and driven software engineer who inspired me with his work ethic and commitment to excellence.

I met Venkat at Dell, Inc. and he was one of the 40 or so outsourced developers that I was tasked with working with and what I quickly began to recognize was how unfairly they were treated based on the fear that they would eventually take over our jobs and we’d be out on the street.

Seriously! This was the cultural temperature in the room and it trained an entire software generation to generally distrust and even condemn the entire practice of using remote talent. In fact, the very word “outsourcing” became an anathema in engineering circles.

And the problem is that that generation is still active in the field, but now they are all working as managers, senior leaders, or even (startup) business owners and operators. And many of them still hold an incredibly negative posture for any work that is outsourced.

What you’ll hear them say, in a number of different ways, is:

The quality of work from a remote developer will never be as good as a home-grown, American-made one. #murica

idiots of IT hiring

This nationalistic stance is appalling; it’s a perspective that does nothing but evangelize the lie that the best talent is obviously (and only available) state-side and that building your development staff with anyone-but-American is not just frowned upon but even demonized.

And it’s definitely not true in today’s modern economy! I have too many friends now (thanks to Open Source!) who aren’t from the US and who are just as talented and skilled as anyone else out there.

In fact, now that skill and talent-parity has been effectively reached, there are infinitely-more upsides that companies of all sizes should consider when building out their technical teams!

The first and most obvious benefit is cost – you can find the talent you need at a fraction of the cost. Again, large enterprise companies are now reaping the unbelievable benefits of fully-scaled out remote teams and, on the flip-side of the spectrum, more and more startups are intentionally building remote and distributed-first companies intentionally!

Heck, this is what I’m doing with mine!

The present reality is that a fully remote and/or distributed team can be just as effective as a domestic, IRL team, full-stop. The question isn’t about whether or not it can work (it obviously can!) but whether you have built a culture / organizational environment and have the right leadership that understands and respects a global and readily-available workforce.

And it has to start with the leadership who builds and establishes a culture of openness and acceptance and who continues to hire folks who also believe and agree with those principles and value systems.

Of course, there are a ton of challenges when you work with remote teams, just like there are a ton of challenges working with a team that isn’t remote. In fact, the number of issues and problems that can crop up with a fully-remote and distributed team aren’t better or worse than a centralized one – they are just different.

And you get to decide the problem sets and the solutions (or resolutions) that’ll allow you and your team to execute efficiently and with excellence.

It’s high-time for the specter that haunts outsourcing and remote hiring decisions to finally die and leave the engineering plane for good.