The Definitive Guide to Sucking with Remote Development Teams

“Remote work” is all the rage, with everyone from Fortune 500 CEOs to Silicon Valley startups touting the benefits.

Stripe, the Silicon Valley-based payment processing platform with 100,000+ clients just announced that their 5th development center will be 100% remote.

With talent seeking increased time freedom and employers looking to access a broader talent market, it’s no wonder — but is it all that it’s cracked up to be?

We believe there’s HUGE promise — we wouldn’t be building Fuel if we thought otherwise — but we’ve also seen and heard enough horror stories to know it’s a nightmare for both employer and talent if you do it wrong.

We believe there’s HUGE promise but we’ve also seen and heard enough horror stories to know it’s a nightmare for both employer and talent if you do it wrong.

What follows is the (inexhaustive) guide to 100%, without a doubt, take-it-to-the-bank-guaranteed roadmap to failing at using remote teams.

Misaligned Expectations

‍Why are you looking at remote teams? Are you looking to augment your internal team? Release features quicker? Access new talent pools or scarce skills? Get more flexible in your staffing?

Or are you just looking for the cheapest, “good enough” developers?

Both camps are totally acceptable reasons but make sure you’re clear with yourself and your team in terms of motivations.

Nothing kills enthusiasm and project momentum like a mismatch of expectations: just like the other areas of your life, having “champagne tastes and a beer budget” is a recipe for disappointment.

Remote teams can create cost savings, and they can make you more flexible and agile in terms of your talent-sourcing — but asking remote teams to be simultaneously cheap and high quality is asking for trouble.

‍Communication

‍Just like regular, full-time employees, remote teams need good, clear, consistent communication. Want to make sure your project fails? Just be sure to leave the remote team in the dark, delay message responses, or generally give vague feedback.

When speaking to clients we often hear them express the reservation that remote teams will require extensive hand-holding and over-communication; nothing could be further from the truth!

Remote teams need as much communication as any other member of your organization, but if you generally give poor/inconsistent/vague feedback to your regular employees, expect the effect to be amplified if you do the same with your remote team(s).

‍Language & Culture Barriers

‍“Remote talent” definitely means people outside your organization, and most often, means people in different geographies. That’s great! It means new perspectives, new talent, new possibilities.

No problem, right?

Wrong!

If you’re not mentally prepared for language challenges (sometimes), accents (often) and different ways of working (occasionally), then congratulations! You’re on the road to disaster.

Adding in remote talent can be a huge boon for your organization, but if you’re expecting the remote team to be “just like my guys/gals, only cheaper”, you’re setting yourself up for failure.

‍Lost in Translation Issues

‍Nevermind any global language or cultural issues; sometimes we forget how much internal language and culture is present.

Every organization has internal cultural nuances and ways of working — it’s one of the levers leaders use to distinguish their organization in a positive way from competitors, for recruiting purposes. Full-time employees get up-to-speed quickly, both via onboarding and via “organizational osmosis”.

When you incorporate outside team members, they won’t have access to those elements, unless you make it explicit. If you don’t set clear guidelines around, for example, surfacing issues early — you’re probably going to get frustrated over time.

‍Time zones

‍Fishing for talent in a global pool opens up new possibilities for blending in-house and remote teams, or carving-off entire elements to be delivered by external team members.

Just remember, your clock isn’t necessarily their clock.

If your remote team sits in a different time zone to your core group, make sure you establish up-front what the working hours and overlap (if any) will be — otherwise teams get frustrated and out of sync.

If you choose to work opposite hours of the day: great! Your core team can dev during their working hours, highlight any issues or expected outputs for the remote team, pass the baton and come back to a completed task list in the morning — a dream scenario!

Just make sure you talk to both teams about managing asynchronous communication, otherwise things get missed, balls get dropped, frustrations rise — and your remote experiment goes off the rails.

‍Wrong/no tools

‍Have you ever tried to drive a nail with a screwdriver? Not very effective. You need the right tool for the job.

Using remote workers and teams requires the right tools for the job, too: Zoom, Slack, Google Docs, GitHub and so on.

If you add remote teams into the mix with your core team, don’t equip them with the right tools and hope they’ll just “make a plan” — you’re on the road to ruin.

‍Trying to deliver fixed-scope with changing requirements

‍Everyone loves knowing up-front what something’s going to cost; it helps organizations budget and forecast effectively and reduces uncertainty.

At the same time, when building software, we often don’t know what we don’t know (the dreaded “unknown unknowns”). That’s OK, so long as you manage your resources accordingly.

Fixed-price engagements require clear scopes of work, so that your remote team can estimate the effort correctly. Adding requirements later will require a change order (you weren’t expecting your remote team to just “eat it”, were you? 😉). Nothing wrong with one or two of these, but if you’re constantly chopping and changing, it’s confusing for both sides (“Is this change part of the 1.4 release, or a new feature?!”).

Fixed-price is great as long as you manage appropriately; try to jam a square peg into a round hole, though… you’re bound to be disappointed with the result.

‍Code Quality & Definition of “Done”

‍You have coding standards documented internally, right?

You use an issue-tracking and project management tool like Jira, correct?

You defined required tests and coverage ratios before you began, didn’t you?

If you answered “no” to any of these, how were you planning to sign off on the deliverable?

Without a solid plan, any destination will do. When your team is internal you may be prepared to burn time getting these issues right (although hopefully not too long!) but when you’re leveraging external resources and paying by the hour, this becomes critical — and an unnecessary expense.

This issue is often conflated with the fixed price vs. time & materials contracts debate, but in either scenario the same rules apply: define success before you start, then the check-in process is a binary yes/no.

Or… you could just wing it and argue at the milestone.

‍Poor planning for hand-off and maintenance

‍Whether you build tech with a full-time internal team or a remote team, planning for hand-off and ongoing maintenance is critical. Poor planning in this area just creates “key man” risk — but when leveraging remote teams that risk sits with an external group.

Get this element wrong and the problems won’t show up until later, when systems need to integrate or maintenance needs to be done — and the documentation is missing or the team has moved on.

Your external team can absolutely maintain the code, but if you don’t ask for it (and budget for it!), don’t expect them to “just know”!

‍Conclusion

‍Remote teams are a great way to move faster: getting access to skills you don’t, can’t or won’t hire locally, full-time — but it’s also a journey wrought with pitfalls and mistakes.

The good news is, pretty much every mistake than can be made has already been made, documented and shared! No-one wants to be the first one through the door; with remote teams, you most certainly won’t be.

Marc is responsible for company strategy and all market-facing activity. He lives and breathes “the future of work” and all things distributed/ remote/ exponential — and it shows in the passion he brings to the topics.

When he’s not busy espousing the merits of remote teams, he’s either eating a muffin or feeling bad about it and working it off at the gym.