How to build a world-class remote engineering team

This is Chapter Two of the five-part series:
"Ultimate Guide for Building & Managing Remote Technical Teams."

We won’t bury the lead here: good hiring and management strategy is good hiring and management strategy, whether your team is remote or local. The difference? Remote engineering teams allow for growth and directional change more fluidly than the alternative, if you know what you’re doing. And if you don’t - that’s what we at Gun.io are here for.

Getting started managing a remote team

That first critical hire
You cannot run a hamburger joint using remote employees. This is just fact. Some industries are at the mercy of their product—if your model depends on materially producing a product on site and delivering it to the customer just-in-time, then you’re going to have to have a brick and mortar location. However, if you’re talking about a product that can be built on a distributed network, delivered to the customer anywhere in the world, and constantly improved upon and deployed regardless of where your team works, then there’s no hard-and-fast reason you’d need a physical location for anything!

Why are we talking about hamburger joints? Great question, we love where your head’s at. There’s a fantastic movie that was released in 2016 called “The Founder” which is a story about how McDonald’s went from being a single hamburger stand in San Bernardino to one of the biggest brands in the world which now feeds some 69 million people a day—purportedly 1% of the entire world’s population a year.

There is a scene in the movie where Ray Kroc (brilliantly portrayed here by Michael Keaton) tries to talk the McDonalds brothers into franchising their thriving burger stand so they can expand, make more money, and (obviously) give Kroc a slice of this potentially (very) lucrative enterprise.

The brothers flatly refuse. They had already tried Ray’s idea. It failed miserably. The reason? To quote Dick McDonald: “Two words: Quality Control.” The reason for this lack of quality control?
“Obviously we hired the wrong person,” said Dick.

Ray Kroc was tenacious. He was also (as the movie goes on to show) a total garbage person. But, there’s a big lesson to be learned from this movie in general and this scene in particular.

The McDonalds brothers were creative and gifted when it came to building a product—in this case; a delicious hamburger and a delightful restaurant experience. However, they had failed at expansion because A) That was not what they were good at, and B) they had hired the wrong person to take charge of that initial expansion.

I won’t spoil the movie but, once Ray Kroc took over the job of expanding the McDonald’s enterprise, well, if you’re reading this article and you’ve never eaten a Big Mac or at least been inside of a McDonald’s, then that’s kind of weird.



Bottom Line: Your first critical hire should be a person who is really good at those things that you are not. They should be confident, hard-working, talented, and have the track record to back all of that up. He or she should be someone who shares your values, can empathize with your vision of the company, and has the tenacity and know-how to do things you can only dream of, without screwing you over in the process.

That's a lot of pressure - we get it. It's an expensive choice to get wrong. That's why we started Gun.io - to help folks like you find and hire elite freelance talent that has already been vetted for the traits above. 

If your goal is to expand, hire somebody with outsized ambitions that match or even exceed yours.
When it comes to building a remote team, ambition is critical. If your goal is to refactor an existing product and make it better, hire an engineer or dev ops manager who can either A) get the job done themselves or B) assemble the right group to tackle each and every task on-time and within scope. If your goal is to build something from scratch, then assess what you know (and most importantly) what you do not know about how to make the thing, learn just enough to understand the effort that goes into creating it, and then evaluate what that first critical hire must be exceptional at.

What do we mean when we say “exceptional at.” Let’s take a hypothetical situation for example. You have an idea for an application that allows “user X” to interact with “user Y” and share stuff with them, whilst also being able to share something completely different with “user Z“ privately—but this product also gives “user X” the option to share this thing publicly with all other users with whom they are connected (user A, user B, user C, user D, user E, etc. etc.) just… whatever, we’re talking about Facebook.

You want to make the above product a reality? You need a front-end developer who can write in HTML5, CSS3, and Javascript faster than Ernest Hemingway could write in English—sober. You also need a back-end architect to create a solid and scalable infrastructure that is flexible enough to head off future tech debt in case your product takes off and you have to start building out new features fast. You’ll also need the time, ability, tools, and know-how to lead the operations and keep everyone on track.

If you don’t understand the complexities of any of these roles, and you’d rather focus on strategic vision and business development, then you’ll need either a bona fide, trusted CTO to partner up with and take the reins while you do what you’re good at or hire a seasoned devops engineer to piece that team together and lead them at your behest.

You could also throw a UX Designer, Content Strategist or Product Manager into the mix to give things a human touch while still maintaining business focus. But for now, we’ll assume you’re bootstrapping this thing and want to keep it simple. Besides, any front-end engineer worth their salt is part-designer/part-coder anyway.

Wanna know what the best part about all of the above process is? When you’re talking about a remote engineering model, you can afford to screw it up multiple times until you find the right recipe without taking a critical hit.

Wanna roll the dice and try and build the whole thing with a single “full-stack” engineer handling everything? Go for it!

Want to start by working with a UX designer to build and test a low-fidelity prototype without investing in a single line of code? Do it—actually that’s good advice. You should do that, you should always do that.

Want to learn HTML and CSS in your spare time, build and style your product yourself and then hire a freelance Angular developer to build out the functionality and use Firebase as your back-end? Give it a shot, what have you got to lose?

When you’ve got a remote development team, you can afford to make mistakes, learn from them, and try again. With the full-time employee model, you’ve got a whole other mess of problems to now deal with.

Just like the McDonald's brothers got saddled with Ray Kroc and ultimately lost their place in their namesakes history, if you hire the wrong person for that critical first role, give them an office in your building and let a “wolf in the henhouse” to quote Dick McDonald, again, good luck getting that wolf outta that house.

On the other hand, if that person is on contract and working remotely, just politely tell them their services are no longer needed, pay them what you owe them, politely defer their emails to the trash folder, and start the search anew.

Best practices

There’s really no “one-way” to optimize and manage a remote team. Everybody has got their own style and strengths. And your team and processes will evolve as they need to in order to meet the needs of your product and to optimize the time and output of your team.

However, there are a couple of must-have rituals that you should adhere to, in order to keep everything on track.

Daily stand-ups
At least at the very beginning of the project, you should coordinate with your team for a minimum of 15 minutes a day (literally a “stand-up”) where everyone gets on a video chat and tells you what they are working on that day and the previous day. When you’ve got people working for you in multiple time zones, this can be challenging. But it is crucial to the success of your team.

This conference call agenda can take all types of formats. The Agile system calls for each contributor to go around, talk about what they’ve been working on, what they will be working on, estimate how long it’s going to take them, whether there are any critical blockers that could cause delay, and what their bandwidth looks like. Whatever the format, these stand-ups should be fast, efficient and rigorously tracked by you or whoever is in charge of the project. If someone says they were going to start doing a thing on Monday, estimated it would be done by Wednesday, indicated that there were no blockers preventing that delivery, and nothing has been shipped by Thursday—then you’ve quickly and efficiently identified a problem. It could be a problem of process, could be software related, could be a personal issue, could just be plain old fashioned laziness—but you now know there’s a problem, and it is up to you (or whoever is in charge of the team) to identify and deal with it.

Once you have had sufficient amount of face time with your team via these stand-ups to build some trust (and everything seems to be going smoothly) you can cut the video stand-ups to weekly or even bi-weekly. Also, communicate to your team from the outset that these daily stand-ups probably won’t last forever—nobody likes daily stand-ups. Managing a remote team does not (or should not) more oversight.

If it’s absolutely impossible to get everyone on the same call at the same time for a stand-up, open a #stand-up channel in Slack where you summarize each day’s stand-up. For those who couldn’t make it, they'll do a “slack-up” where they summarize their “-24/+24” activity—basically “what I’ve done in the last 24 hours since the last update, what I’ll be working on for the next 24 hours until the next update.” Though not ideal, it’s a surprisingly effective compromise, and once everyone gets comfortable and into a rhythm, you can move the whole team to the daily “Slack-up” model.

Weekly demonstrations
This one is simple: get everybody on a video chat, share screens, have people show their work, and then talk about it. If something is exceptional, call it out. Good job! It’s Miller time. If something is buggy or substandard, ask why. This meeting should be longer than a stand-up as it is designed to literally “demo” the work that has been promised during stand-ups. Keep these demos limited to one hour at most. Tell everyone that if they have any “semi-off-topic” follow-up questions that might prolong the demo that you’ll save them for the retrospective meeting to be held directly after the demo.

Weekly retrospectives
A weekly retrospective is where you all collectively review what went well and what could have been improved based on the demo. Once you’ve really got a good group going and things are humming along, inevitably human factors are going to start to influence the production of whatever it is you are trying to build—people will have opinions. However, almost nothing is a bigger waste of a developer’s time (and yours) than holding an unstructured bitch fest about “x” feature breaking and “y” dependency causing this to happen and so on and so on.

It’s not healthy and it can end up costing you hours of productivity. One method of keeping this meeting on-track is called “lean coffee.” Just like anything in software development, lean coffee has its detractors and its advocates—but there’s no denying its ultimate goal: keep meetings civil and productive. Originally it started as an in-person exercise where people would literally “meet” in a coffee shop, pull out pencils and paper, write stuff down and then collectively vote on what the most important things to discuss were. Now they have online options that you can use.

A lean coffee method of holding a meeting is great because it gives everyone a voice—there’s an element of democracy in the development process now. You’re still “the boss” but everybody now has some skin in the game. This will also help to organically create a culture within your remote team—something we will cover at length in a future post.

Mistakes to avoid

As we mentioned at the top of this article, managing a remote team is no easy task, and not for the faint of heart. There are critical mistakes you can make when trying to leverage the vast amounts of remote talent out there in the ether of the Internet. Here are but a few to watch out for:

Forgetting that remote workers are people too
This one might sound a bit obvious, but the lack of proximity to a person and communication only through email can create a syndrome where you stop thinking of your colleague as a person and you start thinking of them only as an outcome. It’s a very human thing. Bad bosses have been doing it to employees in traditional office structures since the dawn of the 9-to-5. Bosses get busy too, and it becomes easy to forget that people are going through all kinds of crap day in and day out, just like everyone else in the world. And if you lump a distance of thousands of miles and several time zones on top of that, it becomes even easier to create a toxic culture of neglect for the human on the other side of that email chain.

The solution: Communication, lots of it. Video communication, daily stand-ups, one-on-one check-ins and (if possible) a once a year “retreat” where everyone can get some face time. Use email for long-form communique that you want to have documented, use Slack for everything else. If you’re the leader of the team and you sense someone withdrawing, reach out and suggest a one-on-one. Start a public Slack channel about a general off-topic where everyone can contribute, food, cars, movies, recipes, Jiu-Jitsu, literally anything that gives people an outlet within the working group that is not just about work.

But, it goes without saying, don’t let that chat get outta hand—and avoid divisive topics. Guns, politics, religion… basically, anything that might set someone off.

Burning out your team
It’s been proven that remote workers tend to completely ignore the confines of “working hours” and will work late into the night and sometimes into the day to accomplish a task irrespective of how long it takes. A study conducted by HBR in 2017 also concluded that remote workers also experience other anxieties like “feeling shunned” and “left out” when it comes to the rest of the organization. This toxic mix of overworking and feeling undervalued is a perfect recipe for all manner of psychological issues related to remote operations if those operations aren’t functioning correctly. We’re not just talking about lost productivity—family issues can develop, people can manifest depression and anxiety. Serious stuff. Burnout is a huge concern that you must prepare for.

The solution: a lot actually rests on the worker. They have to be disciplined and set boundaries for themselves about when they are, and are not, going to perform work. As there’s nobody around them to compare their productivity to, there are certain ways they can set a cadence that will keep them on track through a typical workday while also allowing for relaxing breaks that can work wonders for a person’s sanity. One method is called the Pomodoro technique where they literally set an egg-timer that will run for 25 minutes while they work. As soon as it goes off, they take a five-minute break, then they reset the timer and start another 25-minute “sprint.” After four “Pomodoro sprints” they take a 30-minute break. Rinse and repeat until they’ve reached the end of their time-boxed work day. As a manager of a remote team, you can encourage techniques likes this so they maintain a healthy work-life balance. At the very least it shows that you have concern for their well-being.

Wandering into technical debt
There have been entire treatises written on the topic of tech debt, and how to claw your way out of it, slowly, painfully and (not always) successfully. The chance of releases going out with legacy bugs that just never got fixed can be dramatically amplified when you’re dealing with distributed operations unless everyone is on the same page from the very start. However, if you just start building a thing without having someone in charge of architecture, you’re going to encounter worse than average technical debt. And it will only get more extreme as you keep building new features right on top of those old bugs that never got fixed, and probably never will.

The solution: A single person needs to own the architecture of what you’re trying to build, and must have put substantial thought into it before one line of code is even written, and everyone must be aware of that plan. Agile methodology has built-in safeguards for heading off tech debt, and some may be just right for your team structure. But the most important thing to remember is that someone must own architecture. This role isn’t even necessarily best-suited for the team leader either as it requires a great deal of cognitive power to think about and anticipate how a product may evolve from release to release and iteration to iteration and write code that can accommodate for those eventualities.