The number of remote teams is growing, and they have specific needs. In this market, AngelList, a platform for startups, angel investors, and job-seekers looking to work at startups, has a special position — it has a remote team spread all over the world and also creates digital products for other distributed companies. To achieve its goals, AngelList recently hired its first Head of Remote, Andreas Klinger. The former CTO at Product Hunt, he manages his international team from San Francisco. We asked Andreas about his role and the best ways to hire and manage remote engineering teams.
On product development at AngelList
Tell us about your position. Why would a company need to have a Head of Remote?
Nobody knows what this role really means, including me. There’s one very specific aspect to it, and one that’s a little bit more general. We have the largest job board for remote work, with 7,000 companies actively looking for remote workers. We have more than 1 million users who indicated they are open to remote work.
My main job is to streamline and coordinate the product features that are useful for remote work. There’s a lot of nuanced details that remote teams need to do a little bit differently for hiring, and there’s a lot of things that remote workers are looking for. I have to make sure the applications and the job board actually reflects this specific requests.
I also have another aspect of my role that entails setting up remote processes across the organization. AngelList started as a San Francisco-based company. Over the years, it became more global. Making AngelList itself a remote-friendly company is an unofficial part of my job. It means helping establish rituals around meetings that are useful for people calling in, developing practices that work across time zones, etc.
PROFILE
AngelList
a U.S. website for startups, angel investors, and job-seekers looking to work at startups.
Founders:
Naval Ravikant and Babak Nivi
Founded in: 2010
HQ: San Francisco, CA
What are the specific needs of companies looking for remote employees, or candidates looking for remote jobs?
The most stark contrast you have is with the marketplace itself — if you hire in a difficult market like San Francisco, you’ll want to know about any candidate that roughly fits your criteria. If you’re looking for a remote employee, the supply and demand is almost the other way around. When we opened up remote roles for AngelList, we had several hundred applicants within one or two days. Very often we take job listings down just to be able to manage the inbound interest.
To help companies find the right person, we have AngelList tools that make it easier for companies to filter these applicants, and for applicants to know if they’re the right fit. For example, there are a lot of teams that are hiring remotely, but they are only hiring in the U.S. or Canada, or only hiring within European time zones, or Indian time zones. One feature allows the candidate to know upfront about these requirements.
Another challenge is that it’s hard to evaluate the background of a lot of remote candidates. Some hiring managers may not know what are the biggest universities in India are, for example. So you can’t just assume that a company will fully understand the candidate’s CV. You need a little bit of help showing what kind of background this candidate has, and if this candidate has the right qualifications. We’re working on ways to help companies understand these nuances.
What does the product development process for these ‘remote features’ look like?
Any feature that’s good for remote teams is also good for a colocated team. Any feature that’s good for remote candidates is also good for any other candidates. So it’s not something that’s outside of our normal customer journey.
My role sits between product management and engineering, where I work with individual teams who cover different aspects of the life cycle. I try to align what they do with where we want to get them in the remote context. Additionally, if I have an idea for a smaller feature, I will try to implement it myself — or I will join a team to implement it together with them.
This is a very unorthodox approach to product building, and we are currently just trying it out. It looks like it’s working, but I don’t know many other teams that approach this kind of expansion or new products this way. The interesting thing here is that I can leverage the whole team and instead of just having a handful of people reporting to me. It allows me to make AngelList the best possible location for remote work. Nobody likes to hear about silos, but I’m getting rid of them.
On managing remote teams
How do you measure success when you are helping your team work remotely?
This part of my job is more informal. AngelList is paying me for my product management and engineering skills, and the other part is something that I do to make my teammates’ lives easier. I am helping hire more remote engineers, and overall, more people working remotely. I am trying to measure the performance and feedback of these new hires. We look at NPS and overall team health.
I think good collaboration has to do with trust. Not just blind trust in each other, but more of a sense of having a systemized approach to trust. As a manager, you need to decide what kind of decisions people are making on their own, and when authority has to come into play. But how do you streamline processes to make sure that you don’t have to constantly verify these decisions? You need to agree how you make decisions as a team and how you expect other people to make decisions.
At Product Hunt, we have a concept called single-player mode — I’m working on introducing it to AngelList as well. The whole idea is that a single developer shouldn’t be blocked by anything that’s a common issue or problem. Imagine you play Mario and you press “jump” and all of a sudden you have to wait for your manager to get up to give you feedback. The goal should be for you to autonomously make decisions, and the rest of the team can fully
Engineering Management in Remote teams from Andreas Klinger
What are the top tactics that help you build trust in remote teams? Especially engineering teams?
I would say transparency, authority, autonomy, process, and an explicit decision-making processes.
The engineering team is a good example of how we enable this. We try to automate anything that can be automated. So when you’re writing code, the tools tell you if it’s the way we expect it to be: not too complex, readable, aligned with best practices, and so on. The tools will also tell you if you’re breaking something or creating a security risk. It will be instant, so you don’t have to wait for anybody to say, “Hey, this isn’t how we do things.”
Basically, the tooling will guide you to a solution that by default should already be good enough. It might not be excellent, it might have a few technical issues that the tools can’t know about, and it might be missing context about long-term thinking. But in general, the implementation should already be good enough.
Then, the team shouldn’t waste any time afterward in reviews. For example, we have a specific approach to code reviews where everybody requests reviews each morning. The idea is that you never have to remind anybody to do reviews, but everybody just does it at a set time. That means that if you submit your code in the evening, by the next morning, someone has probably already reviewed it.
This also means you review other people’s code before anything else, so that they’re also unblocked. Two people are expected to review, but if you don’t have time for that because there’s a problem, we fully trust you to review the code later. If people give you feedback on your code request, you either answer through updating code, or explain through a comment why you disagreed. We don’t expect you to change the code and then come again and ask for reapproval. If we didn’t have it that way, people would easily lose time waiting for other people. Remote teams can become very expensive.
How do you measure employee satisfaction and retention? Do you use NPS?
We’ve only been doing this for a few months at AngelList. At Product Hunt, we were able to measure it. From my experience, a lot of remote teams have very good retention rates. In San Francisco, it’s common to hire someone and they leave after two years, or even less. It’s extremely expensive. In remote teams, it’s very common that people stay for three, four, five…or even six years. At WordPress, there a lot of people who have been working for the company for 10 years. It’s actually a feature of remote teams.
Obviously, you have to differentiate between voluntary and involuntary attrition. It’s a good thing if nobody on your team wants to leave, but it’s a bad thing if you never want to fire anybody even if they’re not the right fit. So remote teams still need to be cautious not to use retention as a validity metric and say, “Hey, we’ve never had anybody leave the team.”. If you need to fire somebody, then do it — even if it might not look good on your metrics.
Hiring remotely will always save you money compared to San Francisco, but cost shouldn’t be the primary reason you do it. Instead, it should be having access to talent, and the retention of that talent.
Looking for a tool to align your remote team around a shared goal? Try Miro free
On hiring remote engineers
What are the main challenges of hiring remote engineers?
One aspect to watch out for is that you might not fully understand their CV or their background, because you don’t know the brands. Ideally, you need to find some time to ask them about their experience, so you get a bit more nuanced insight into what their background is.
The second challenge is that you can’t rely on technical interviews. For example, many San Francisco companies have a language-agnostic approach to evaluating programming skill sets. They do coding challenges or whiteboard tests. It’s not an objective way to evaluate someone’s skills, because this is usually very easy for people with computer science degrees in Western cultures, but it can be hard for people who have a science degree or come from another culture, for example.
In my experience, having a questionnaire around nuanced questions, culture fit interviews, peer programming challenges, and take-home tests is better. You give someone a very small problem that relates somehow to what we’re actually doing in daily work. Maybe if we’re using a specific language, we ask them to change something little and small on their own, and then we schedule a call for an hour and ask them about the problems they fixed. You work together on a problem and see how this person works. That’s my recommendation for evaluating remote candidates.
Have you seen any interesting trends or requests from other teams looking for engineering talent worldwide?
One request we regularly get is being able to hire people with very specific previous experience. For example, a company can look for someone who used to work at Google in a certain team, and now lives in central Europe and is willing to work remotely and has at least three years of experience. So we built a talent search engine on AngelList called Source. It helps to find good candidates even if you have a very good inbound pipeline. Many companies, don’t just wait for people to approach them, especially for senior roles.
Remote teams almost have an unfair advantage in hiring. I regularly talk to San Francisco teams that lose candidates because other companies offer an opportunity to take a job, but then move back wherever they want to live and still have this international career. This has become more and more common.
Do you think more companies will be remote in the future?
I think it’s the logical evolution of digital work. There is no future in which we will not work online, not work with other people in other countries, or in other places — it just won’t happen. I think that everybody is already a remote worker in the sense that you’re working at a coffee shop on Fridays and checking your phone on your way to work.
The question isn’t whether you’re working remotely, but how much you’re working remotely. I think at some point, we’ll stop calling it “remote work” and just call it “work, ” wherever the company is based.
