This article is by Jeff Atwood, a software developer, author, blogger, and entrepreneur. He's well known for his blog Coding Horror, and as a founder of Stack Exchange and Discourse. He tweets at @codinghorror.
What’s the most consistent piece of advice you get as a startup?
Always hire the best people. Never compromise in your hiring standards, no matter how big your company gets.
And it’s true. A great team can take an okay idea and transform it into an incredible, world-beating product.
But something has always bugged me about this advice. There’s an elephant in the room in the form of an implied clause: Always hire the best people… who are willing to live in San Francisco.
Substitute Mountain View, New York, Boston, Chicago, or any other city. The problem is the same. We pay lip service to the idea of hiring the best people in the world — but in reality, we’re only hiring the best people who happen to be close by.
Call me crazy, but I think if we’re going to talk about hiring the best talent available, we should actually try to do that. This means letting go of the idea, at least in IT work, that people need to be physically present for any meaningful work to occur. There’s a better way.
When my co-founder and I started Stack Overflow (now Stack Exchange) in 2008, the company consisted of me in my office in Berkeley, having weekly calls with Joel Spolsky in New York. Then the team expanded to include a developer in North Carolina, and others in Oregon and Texas. A community manager in Florida joined. Two more developers signed on in the U.K. and Germany. I’m no longer at the company, but last time I checked, they’re up to around 150 employees.
One of the most valuable lessons I learned from that experience was exactly how many amazing software engineers don’t live anywhere near Silicon Valley. Recruiting from a global pool, rather than limiting yourself to the already talent-strapped Bay Area — or those who are willing to pull up stakes and move — lets you say you only hire the best and the brightest and mean it.
Discourse, my current startup, enables conversation between customers, fans, and audiences who are passionate about a specific topic, no matter where they happen to live in the world. I believe the internal structure of companies should mirror the audience they want. If you want a global community to use your software, the world should be helping to build that software, too.
In Practice
Integration of remote workers into your company may seem untenably forward thinking. Maybe it is. But as William Gibson once said, the future is already here — it’s just not evenly distributed. Consider GitHub, where at least two-thirds of the workforce is remote. Look at WordPress, where the majority of its 225+ current employees work remotely. These are companies that have changed the surface of the web, and I’d attribute a big part of that to making remote work a part of their DNA.
Ideally, you start out with remote work as a pillar of your company’s philosophy — it can be challenging to bolt on a remote work culture after the fact. But there are a few essential ways you can adapt:
“Show Your Work” vs. “Just Showing Up”
Just because someone shows up on time every day doesn’t mean they’re working. This is a business, not high school gym class — no one should earn a passing grade for perfect attendance.
It’s much healthier to judge work based on output:
- How many features did an employee implement this week?
- How many bugs did they fix?
- How many exchanges did they have with customers?
- How much faster is the code? How much smaller? How much more maintainable?
At Discourse, we generally point to GitHub commit logs as evidence of work either well or poorly done. I certainly don’t mean this in terms of quotas or anything — merely that you should be able to trace a breadcrumb trail of awesomeness wherever your employees go. Any sort of public or private artifacts will do.
Maybe you use Asana or Basecamp. I’m not big on process tools, myself. The important bit is this:
Enable people to leave a record of the useful things they’ve done. Not a 'to do' list, but a 'done' list.
I don’t care when our employees come to work or what their schedules are. I don’t care where in the world they live (provided they have a great Internet connection). I don’t care how they do the work. I’m not going to micromanage. If you’ve really hired the best, they should be able to prove it with output and show their work.
How do you know this is working? When someone you hired sees something that isn’t right (or broken completely), and takes the initiative to make it right completely on their own. When you feel comfortable giving people agency to make changes — and mistakes — all on their own, that’s when things are working.
Hire by Audition
Let’s say a candidate has breezed through the basic tests, has an amazing portfolio, is an excellent cultural fit, and also passed the phone screen with flying colors. Time to get them in for a face-to-face interview, right?
I’ve seen candidates nail all of the above, join the company, and utterly fail to get things done once they’re in the role. Judging work ethic and commitment is incredibly hard, even if you’re meeting with someone in person.
If you want to determine beyond a shadow of a doubt whether someone’s going to be a great hire, give them an audition project — even before having them speak to other employees on your team. I’m not talking about a generic, abstract problem. I’m talking about a real world, honest-to-God unit of work that you need done right now today on your actual product. It should be something you would give to a current employee, if they weren’t all so busy.
Ideally, your audition project should be a regular consulting gig with an hourly rate and a clearly defined mission statement. Select a small project that can be done in a few days, maybe at most a week or two. Let the candidate choose to come into the office or work remotely.
I know not every business has these bite-sized units of work that they can slice off for someone outside the company. But if you don't consider this:
If you can't find a mini audition project for a strong candidate, perhaps you’re not structuring work properly for your existing employees either.
At Stack Overflow, we had some open source components, and we’d often give candidates a chance to work on our wish list for those elements. Being able to work independently, communicate clearly with us, and deliver the requested feature in a timely fashion were hallmarks of success.
If the audition project goes well, fantastic — you now have a highly-qualified candidate that can demonstrably Get Things Done, and you’ve accomplished something that needed doing. To date, I have never seen a candidate who passes the audition project fail to work out. I weigh performance on the audition project heavily; it’s as close as you can get to actually working the job without being hired. And if the audition project doesn’t work out, well, consider the cost of this little consulting gig a cheap exit fee compared to an extensive interview process with four or five other people at your company. Worst case, you can pass off the project to the next strong candidate.
Hire from Your Community
I’ve found over and over again that cultural fit is a stronger predictor of success than skills. But how do you create (much less reinforce) a culture when your team isn’t all in the same place?
I realize that not every business has a community around what they do, but if you do have a broader ecosystem of users, developers or fans, you should try like hell to hire from that crowd whenever possible. These are the folks who are naturally drawn to what you do, that were pulled into the gravitational well of your company completely of their own accord. The odds of these candidates being a good cultural fit are abnormally high, and that’s what you want.
Did a few of your users build an amazing mod for your game? Are there power users on your forum answering other people’s questions every day? Did an engineer find an obscure security vulnerability and warn you about it? These are the people you should be going out of your way to hire. To increase your chances, start grooming the emerging stars early with increased correspondence, special offers, and notoriety among their peers.
At Discourse, we hired our first engineer based on their strong GitHub open source contributions, as planned. At Stack Overflow, we had a long list of “favorite people” who were highly engaged with the community on our governance and community meta site.
If your startup is so small or pre-product market fit, you still have options.There are most certainly other communities out there that resemble what you hope to build, in terms of the type of people and how they communicate. Go after them. Make a compelling argument for how you’re working on something that will speak to them and how they have an opportunity to help you shape it.
Somewhat counterintuitively, also try looking at communities that are passionately dissatisfied with the status quo in your field or industry. It might be harder to state your case, but if you reach out to the right people, you can explain that your product is the one they have been waiting for in the market. They will be immediately and urgently moved to help you make that product the best it can be.
Use Public Communication Tools Daily
When you have remote workers, communication tools can’t be something you use just when they are involved. Communication tools have to be used all the time, as a natural part of the work.
Don't lock important information into water cooler chats and hallway meetings where nobody except the locals who happened to be in earshot benefit.
There are a few fundamentals that every company with remote workers needs:
Real Time Chat
When your team member lives in South America, you can’t exactly walk by his desk to ask him a quick question, or bug him about something in his recent checkin. You need a way to casually ping your fellow remote team members and get a response back quickly. This should be low friction and available to all remote developers at all times. Hipchat, Slack, IM, IRC, some web-based tool, laser beams, smoke signals, carrier pigeon, two tin cans and a string — whatever. The important thing is that everyone is invested in using it consistently, something you may need to continually reinforce as a leader.
At Discourse, we’re currently experimenting with Slack, which we love a lot, but it only works because we’re all on it all day long exchanging ideas, creating new channels of conversation, reading each other’s comments, etc. Chat is the most essential and omnipresent form of communication you can have when people are working remotely, so you need to make absolutely sure it’s functioning smoothly before going any further.
Online Bulletin Board
Sure, your remote team may know the details of a project, but what about all the other work going on? How do they find out about that stuff or even know it exists in the first place? You need a virtual bulletin board that’s less ephemeral than chat: A place for announcements, weekly team reports, and meeting summaries. Discourse happens to provide this service, and there are many others with similar functionality.
You want something that will occupy that middle ground between mailing list and online discussion area. You should be able to subscribe to get emails for every post as they arrive, or view the live discussions via the web. Everyone should also get automatic weekly/daily digest summaries right out of the box.
One word of caution: Every time you see something like this arrive in your inbox, you better believe in your heart of hearts that it contains useful information. The minute these posts become just another “whenever I have time to read that stuff” … you’ve let someone cry wolf too much and ruined it. So tread carefully here. Everything that gets shared in this public discussion space has to be Need to Know.
Here's what this can look like:
Voice and Video Chat
As much as I love ASCII, sometimes faceless characters just aren’t enough to capture the full intentions and feelings of the human being behind them. When you find yourself sending kilobytes of text back and forth and are still unsatisfied with the clarity of communication, you should instill a reflexive habit of “going voice.”
Never underestimate the power of actually talking to another human being. I know, I know, the whole reason many people get into programming is to avoid talking to other people, but bear with me. You can’t get face-to-face with your remote team without flying over six hours, and who has that kind of time? I’ve got work I need to get done!
The next best thing to hopping on a plane is getting on Skype or Google Hangout so you can see each other’s body language and facial expressions. All that human nuance that is totally lost over chat or email will come roaring back if you schedule regular voice and video chats. I recommend at least once a week at an absolute minimum; they don’t have to be long meetings, but it sure helps in understanding the human being behind all those checkins.
Nobody hates meetings and process claptrap more than I do, but there is a certain amount of process you’ll need to keep a bunch of loosely connected remote teams in sync. Seeing the person interact in real time is key to making this possible.
Monday Team Status Reports
Every Monday, every team at your company (even if you just have one) should produce a brief, summarized rundown of:
- What we did last week.
- What we’re planning to do this week.
- Anything that is blocking us or we are concerned about.
This doesn’t have to be — and in fact shouldn’t be — a long report. The briefer the better, but do try to capture all the useful highlights. Post this to your digital bulletin board every Monday like clockwork. Now, how many “teams” you have is up to you; I don’t think this needs to be done at the individual developer level, but you could if you’re still very small.
No matter what, as the organization grows, people get disconnected — they have no idea what other people are working on, or what their job entails.
Getting a very brief, high-level summary of what each team did last week solves these problems. Monday status reports are much less of an issue for small teams, though it is helpful to briefly cover the highlights of what you worked on last week, even if only verbally, on a five-person team.
Meeting Minutes
Any time you conduct what you would consider to be a “meeting” with someone else, take minutes! That is, write down what happened in bullet-point form, so those remote team members who couldn’t be there can benefit from — or at least hear about — whatever happened in sequence.
Again, these notes don’t have to be long, and if you find taking meeting minutes onerous, then you’re probably doing it wrong. A simple bulleted list of sentences should suffice. You don’t need to record every little detail, just the big picture stuff: Who was there? What topics were discussed? What decisions were made? What are the next steps and action items that came out of it?
Both of the above should, of course, be posted to your discussion area so that everyone can be notified by email automatically.
All this said, there are a few specific scenarios where I’ve seen remote work become less than optimal:
Brainstorming
This is the big one. If you’re conducting blue sky imagineering improv meetings on a regular basis, that’s very tough to pull off remotely. There’s something about the physical presence of people in a room, seeing their faces, hearing their voices, watching their body language, that is far more conducive to quickly bouncing ideas around and figuring out the broad strokes of ideas. You need an extremely high bandwidth, low-latency, in-person connection to brainstorm effectively.
The good news is, at least in my experience at Stack Overflow and Discourse, these kinds of meetings are quite rare. And when you do need them, they can be in the form of a yearly offsite where everyone flies in to dream up bigger dreams for next year.
For example, at Stack Overflow’s annual meeting, we prioritized the values of the company by voting on them in person, and established what we called our “Big Hairy Audacious Goal,” which in 2010 was to become a top 50 Internet website. Since then, that target has been achieved. Having everyone in person aligned the team around making it a reality.
Mentorship
Mentoring requires a rapid series of back and forth exchanges, and a constant stream of interruptions as a junior engineer asks someone more senior for feedback on what they’re doing. It’s a particularly poor match for the loosely-connected model of communication that remote work requires.
Our “solution” to this problem was to avoid hiring people that need extensive mentoring. At Stack Overflow and Discourse we tend to hire at higher experience levels, not because we don’t believe in the possibilities of young talented developers (we do), but because mentoring them is just not practical remotely. From the perspective of hiring for remote work, you either got it… or you don’t. I find that peers can work fine remotely, but if there’s too big of a disparity in skill level, it becomes a drag on productivity.
If your strategy depends on growing junior developers into senior developers, you need to schedule time for them to work closely together in person. Pair programming is beneficial for a reason.
All drawbacks and adtvantages considered, when you imagine what digital work will look like in the next 20, 40, or 60 years, do you think it will continue be done by people spending one or two hours commuting to and from an office building every day?
Do you think hiring practices should be based on what work was a decade ago rather than what it is likely to be a decade from now?
In our case at both Discourse and Stack Overflow, hiring from around the world has been a huge strategic advantage. I believe remote development represents the future of work. If we have to spend a little time figuring out how that comes together — and maybe make some mistakes along the way — it will be worth it. The future is now. Why wait?