Secret Recipes on Working With Remote Developers: an Interview With Craig Cannon

Craig Cannon is the Director of Marketing at Y Combinator. Before joining YC Craig co-founded Comedy Hack Day, wrote a field guide to shipping containers, and set a world record on his bike.

Craig is an adept of remote work. The engineering team working on his current (secret) personal project is fully distributed.

In his interview with YouTeam CPO Yurij Riphyak, Craig Cannon shares his thoughts on working with remote engineers.

Yurij: Why do some founders choose to go for a remote team in the first place?

Craig: There are probably two answers to each of these questions. One for short-term contractors and one for long-term employees. I have more experience with contractors but will try to answer for both 🙂

For contractors, founders are often looking to onboard someone immediately and affordable.



For employees, founders recognize that most people don’t live in the Bay Area. If they can find and retain remote employees they’re able to build a super effective team with less hiring competition, for less money.

Yurij: Why do you think most of the other startups are afraid of hiring remote? What do the founders that do hire remotely know what most doesn’t?


Craig: Startups that are afraid of hiring remote probably think their development cycles will slow down. Either because they’ll spend a ton of time communicating vs solving problems in person or they’ll end up hiring remote software developers that aren’t as good/dedicated. And finding good people in the first place is difficult.

Founders that do hire remote know that those fears are legitimate but they’re pretty straightforward to overcome once you commit. The apprehension some founders feel creates the arbitrage opportunity for founders that can manage remote development teams well. It’s like what Charlie Munger said about China at the 2017 Berkshire meeting:

“The first rule of fishing is to fish where the fish are, and the second is don’t forget the first. We’ve gotten good at fishing where the fish are. There are too many boats in the damn water, but the fish are still in it. A good fisherman can find more fish in China; it’s a happier hunting ground.”

Yurij: Where do founders look for remote software engineers? UpWork and LinkedIn are the obvious answers but are there any other places to look?

Craig: Like all hiring, referrals are super common. Aside from that and the sites you mentioned, I’ve heard of people reaching out to open source contributors and people launching projects on Hacker News, Product Hunt, etc.

Yurij: What are the main qualities to look at when hiring a remote engineer or designer? In particular – the soft skills.

Craig: Three things:

You communicate clearly – This is non-negotiable. You must be able to clearly communicate that you understand what you’re working on and how you’re going to complete it. With everyone on different schedules, it’s super easy to block someone with an unclear question or statement.

You’re reliable – You have to do what you say you’re going to do. This sounds silly but often people get sidetracked and focus on the wrong thing or they fall off the grid entirely. Again, this will end up blocking other people, which is what we’re trying to avoid. To be clear, I don’t mean you have to be connected and available all the time, I just mean you get done what you say you’re going to get done.

You understand the product – This one took me a while to figure out. A lot of hired guns can get the technical work done but because they don’t think about the product in a larger sense, they build things in a way that hurts you down the line. A simple example of this is an unintuitive UI decision but mistakes of this kind deep in your code can massively slow down your product. Now, as someone managing remote developers, communicating how things fit together is mostly on you, it just helps a ton when your team grasps the big picture, too.

Yurij: How would you describe a typical process of screening and onboarding a remote software developer? What are key differences compared to hiring in-house?

Craig: To figure out if an engineer has the three skills I mentioned, I create a project that’ll take a few hours and give it to each person I’m interviewing. I pay them for their time and compare the results. The best people stand out immediately.

The test project will be something within the actual codebase so that’s the first step of their onboarding. If we both want to work together I’ll then give them a bigger project (1-2 days) and we’ll go from there.

Now, I mostly hire folks for shortish term projects so there’s not much onboarding to speak of. We just get to work.

For companies hiring long-term remote employees, this process is much more thorough. It’ll usually involve video calls with several members of the team and a trip to meet the team. So from that perspective, it’s fairly similar to hiring in-house though maybe it takes a bit longer.

Zapier’s remote guide is a great resource here – https://zapier.com/learn/remote-work/

Yurij: One YC founder I have interviewed compared remote to a form of drug: initially, the “cons” appear much stronger and more obvious than “pros”, but once you tried it – you’re hooked :). Can you reflect on this?

Craig: Haha. I think I’d agree with that. And to extend the metaphor, the hangover can be rough. It’s addictive to hire all these remote developers and feel like you’re getting so much remote work done by software developers but then you realize you’re doing a ton of work in the wrong direction.

If you don’t understand the problem you’re solving and don’t spend lots of time with your users, remote work can be an amazingly efficient way to burn a ton of money.

But yes, the remote is a hell of a drug when used correctly 🙂

Yurij: Most of YC founders I spoke to named asynchronous communication as the #1 disadvantage of a distributed team. How do founders that work with remote team address this problem?

Craig: They hire strong communicators and put a huge emphasis on documentation of work and goals. This is especially important when they have in-house and remote people. In practical terms that means frequent check-ins. It could be through Slack, email, or really whatever works for you.

Ali Rowghani from YC and Sid Sijbrandij from GitLab discussed this on our YouTube channel – https://www.youtube.com/watch?v=e56PbkJdmZ8

Yurij: How do founders beat the time zone difference – the second main concern after the communication?

Craig: I think this is a subproblem of unclear communication but I’ll answer it 🙂

Usually, they do check-ins each week at a mutually ok time. It’s not uncommon for a company’s entire remote team to be within one time zone, which can make scheduling easier.

Time zones can be a real issue when it comes to assigning who’s on pager duty. That said, if you do just a little bit of planning you can use time zones to your advantage in this case.

Yurij: Why do you think some founders prefer to hire their remote team individually, while other go through agencies? Can there be any core differences between these segments?

Craig: I’ve worked almost entirely with individual remote software developers. I think people are concerned that agencies are opaque about who’s working on your project and that that person might change, resulting in knowledge and quality gaps. If you can avoid that issue they seem pretty similar to me.

Yurij: Describe a typical working process with remote developers. What you as a founder have to do differently compared to when you’re working with a co-located team?

Craig: Assume nothing is inferred. Your goals and plans must be clear, discoverable, and often repeated. Put yourself in the shoes of your remote team and build your process from there. What information would you want to know if you were them?

This is a huge problem with co-located teams, it’s just less obvious.

Yurij: How do you measure the performance of remote engineers?

Craig: How clean is their code and do they complete their work when they say they will.

Yurij: What is the last tool you wish had existed or thought about building yourself to aid you in hiring/managing remote software developers.

Craig: Better search.