We won’t bury the lede 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.
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.
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.
