Hiring and Managing World-Class Remote Teams, with Andreas Klinger

Andreas is the Head of Remote at AngelList, the largest remote hiring job board in the world. After building multiple remote teams at companies like CoinList and Product Hunt, Andreas has become one of the preeminent voices in the remote work movement.In this episode, we discuss how Andreas uses metrics for de-risking instead of politics and how he builds an onboarding process that makes it easy to scale remote engineering teams.

‍

‍

‍Listen to the Full Episode Here:

‍

‍

‍Full Transcript:

Wes Winham:
Andreas, thank you so much for joining us today on Scaling Software Teams.

Andreas Klinger:
Hey. Thanks for having me.

Wes Winham:
You said that you believed in the power of 10 when it comes to getting a group of people together, they can accomplish amazing things. What’s wrong is you get over 10?

Andreas Klinger:
First of all, nothing is wrong. I just strongly … I’m always surprised how good small engineering teams can execute if they’re structured well. The more you scale, you obviously inherit more complexity in your team and it just gets harder to manage. You lose more time. People are more limited. You lose more coordination, communication effort. In my experience, having for example, three teams of each three [inaudible 00:02:00] some are structured. Like one is alone and some teams are a little bit bigger. Something around the number of 10 is a very natural number for a small team where you can stay really well aligned.

I think the big magic to scaling companies is actually keeping teams around that size and very communicative, very clear what the different goals and expected outcomes are. By that, being able to create autonomy, responsibility, and ownership and be able to scale. This sounds super easy in theory and I think there is millions of books and millions of podcasts done about this. It’s not that easy in practice obviously.

Wes Winham:
So at Angel List, are you working in groups of two to three in a bigger group of 10? Is that how you are structured?

Andreas Klinger:
Yes. At Angel List, yes, it’s a little bit hard to answer any question around Angel List, because Angel List is several different units that work very different in some of this regard. Some teams are fully distributed, some teams are hybrid, some teams are co-located. Some teams work this way, some teams work that way, right. In the talent team where I’m currently working at, we have small teams that own a complete area and outcome. Basically, it’s OKRs. They own a complete area and coordinate between these areas. Each of these teams tries to be as small as possible. So usually it’s less than five people I would say. I think most of them are around three.

Wes Winham:
On that team of three to five, do you have a mix of engineers, designers and product? Or is design and product a level above?

Andreas Klinger:
It depends. In our case, we have mix because we realized that a lot of this stuff is usually facing product, so it’s usually, you have to have good design and all this kind of stuff. And you have to have a lot of iterations just on design and doing UXR and getting design studies and all this stuff, basically getting in front of users as quickly as possible. But it depends on the team and each team is working a little bit differently obviously. Each time most likely can answer that question for their regard better than I would now.

Wes Winham:
So the[inaudible 00:04:16] that you see is more user facing a team is, as far as the product, the more likely they’re going to have a designer and a product manager on that[crosstalk 00:04:23]

Andreas Klinger:
Yeah. In general, I strongly believe in cross-functional teams, which I think is kind of the cultural norm right now, so that the team can actually own the outcome and not a function. That’s my personal belief. In some teams … I know some teams that have, for example, like Coin List, we had units where you had a mix of compliance people, design, engineering and customer care in one unit that had one specific outcome. I strongly believe in this kind of setup because that creates a certain sense of, ownership is a positive way to frame it and responsibility, or you’re in charge. If you mess this up, it’s your fault kind of thinking. All of a sudden, you’re like okay, we have literally there’s no way that I’d push the ball to the other people and it’s their fault now. You need to figure this out.

I think it creates a lot of clarity and a lot of healthy decision making.

Wes Winham:
Sometimes I hear outcomes as, “We’re going to ship this feature by X date.” My guess is, that’s not what you’re looking for when you talk about outcomes in a cross-functional team. You made an example of the better outcome.

Andreas Klinger:
I think most people who listen to this podcast ignore that framework, like OKRs or anything related. In my experience, the later stage a product is, or a feature is, the easier it is to define quantitative goals and the earlier it is, the harder it is. We have very often early stage features. We have exploration related goals. So basically it can literally be, “Ship that freaking feature please.” That’s the goal. But it can also have 10 different, whatever, interviews, or get feedback from 20 different customers about this. It can be something that’s almost soft in a way.

It can even be, have the marketing launch ready in time and so on and so on. In my experience when it comes to early stage products that can be also features within a larger product, quantitative aspects become more like a reality check. It’s more like are we lying to ourselves? This is how you use it or it’s maybe a potential opportunity, this kind of reality check because the variance in the outcome tends to be that big that you can’t really make estimates. The estimate then becomes more of where you’re saying we believe that this needs to be successful, it will need A, B, and C. And if you don’t hit it at that point, you can go very objectively back and see, okay back then we thought about this in that way. We thought having this very natural process of you lying to yourself and all of a sudden having like, “No, no. I always expected that 10% increase. I think this is a huge success.”

Or now it’s like 5X and you’re like, “Yeah, 5X is by far too little.” But if you go back and you’re like, “Hey, back then we said actually everything above 50% is amazing.” Or we expected this to go 10X or whatever. This gives you an objective window into the past. So as a reality check in early stage quantitative metrics are really useful. In later stage products, I would primarily rely on them to be honest.

Wes Winham:
When I’m really early, it might just be get that feature out, or do the interviews around leading indicator on them. Get the feature right. Later on, I might be on a double the conversion rate, do this funnel, or I want to half the time between these two steps.

Andreas Klinger:
This is at least my personal opinion on that, yeah.

Wes Winham:
I think I’ve gotten in trouble using quantitative metrics a little to early sometimes because I really like that.

Andreas Klinger:
One interesting aspect here is what I regularly see with teams is, using quantitative aspects, for example, AB testing to verify stuff that they’re anyway going to do which is super dangerous in the early stage. So you kind of like, we’re doing now an AB test to launch this one feature, and okay, but what are you actually going to change based on that number? Is there any strategic change if this number is this or that? Assuming it’s not a complete catastrophe. The numbers are never the polar extremes. They’re always wishy-washy, somehow muddy in the middle right?

What are you actually expecting as an outcome depending on that number? How is your decision going to change? And this decision is anyway not going to change, most likely the whole thing you’re doing here is much more like a dance of a process that you’re doing. It’s much more lying to yourself and feeling very cool about what you do than actually doing meaningful, de-risking. The whole job around anything related to a quantitative evaluation is de-risking. So if you don’t de-risk, if you don’t change decisions around that, then most likely you’re wasting everybody’s time and you’re using numbers for internal politics maybe to feel good about it, whatever, to get external authority because whatever your mangers don’t believe in you and that maybe is a valid reason.

But realistically, you’re not doing it for product reasons.

Wes Winham:
Yeah. The internal reasons don’t bring value to the customer.

Andreas Klinger:
Exactly.

Wes Winham:
Let’s switch gears and talk about remote teams. You’ve written about remote teams, you’ve worked on remote teams and all the different flavors. You said that remote teams take roughly five times the process needs than a co-located team. Can you talk more about why that is?

Andreas Klinger:
Sure. I’m saying 5X. I think the real number is more like 3X, but 5X sounds so cool right.

Wes Winham:
Nice and round.

Andreas Klinger:
Yeah, it sounds like really something you can tweak, so it’s like fuck it, I will put 5X now. My thinking here is if I’m five people in an office, I’m like, “Hey, let’s have a meeting,” and everybody jumps up, runs into a meeting, is excited about having a meeting, has a meeting. It’s like woo, we’re having a meeting and decide something and go out. This is how I expect most people have meetings I guess. In a remote team, even with five people, you can’t just say, “Let’s have a meeting right now,” because maybe Frank is currently not available because he’s bringing kids to school, right.

Maybe this other person has to leave in 10 minutes. Maybe this other person is currently asleep. All of a sudden you need to do crazy things, like scheduling meetings in advance, saying, “Hey, can we have a meeting tomorrow at 10AM?” You need to do insane things like taking notes. What was discussed in the meeting, which you most likely wouldn’t do if you’re five people in a co-located office. It’s like whatever. Brian wasn’t there. Who cares? Somebody will tell Brian.

In a remote team, somebody should take notes, because somebody won’t join and it would just be easy to keep them up to date because you don’t want to have constantly hang ups with everybody. This goes on and on and on. You will be more explicit about decisions because you can’t constantly double check with everybody because somebody might not be online. The whole thinking about process changes and all of a sudden you don’t act like you’re five people. You act more like if you would be an office of 20, 25 people. You introduce processes, structure, work flow. You try to make expectations really clear. You try to make outcomes and decisions really clear. You maybe start crazy things, like writing onboarding manuals or tutorials or all this kind of stuff.

This almost happens naturally in a remote team, but has to have. All of a sudden we’ve 5X’d the process than with a normal office. The good thing about that in my personal opinion though is, it makes scaling a little bit easier because you now can onboard people and they can read meetings. You can have meetings without getting everybody into the room, because people can just read those notes. You have onboarding documents that just onboard people maybe faster. The interesting thing is around a certain scale [inaudible 00:12:17] personally know what that scale is. It starts to level off. It starts to become … if you have like 100 people, it’s not like you act like you’re 500 people. And if you have 500 people, it’s not like you act like you have 12,500 people.

It’s more like it levels off, it logarithmically levels off at this stage. So it becomes almost like a super power when it comes to scaling, at least in my opinion.

Wes Winham:
So you have the framework in place, the structure to scale a little bit before you even need it and that helps with the later scaling.

Andreas Klinger:
You’re forced to think and structure frameworks around a lot of concepts that you would consider processes for example, or work flows. But even down to things like trust, you act if you need to systemize and structure how you give trust, how you expect trust, how you validate trust and all these kind of things, which implicitly, you would need to do in, I would say management of digital knowledge work [inaudible 00:13:14] management of knowledge work in general. You need to do that to enable people. But you are almost forced to do that in a remote team, if you want to succeed.

Wes Winham:
So thinking about agendas and meeting notes, that’s really easy for me to visualize. Everyone eventually does that it seems like. This explicitly working through validating trust and giving trust. Can you give me some examples of how you’ve been able to do that? That seems-

Andreas Klinger:
It’s being aware how you do … basically it means good management, in a nutshell. But what the fuck does good management mean? And I don’t have the answer. I have my own framework that I’m trying to apply. It means being able to do and being able to explain how you do decisions. For example, decision al layering. Who in the company makes what kind of decisions? If you join our team, what kind of decisions do we actually expect you to be able to do week one, month one, year one? What do we actually want you to decide? Very often, this is often a tribal thing where you naturally learn that and you just try to bump the edges and that works good enough.

Ideally, you have at least a rough structured thinking about that and be able to communicate this to new employees as you scale a company. The whole framework around here is like for example, authority. What kind of authority do you get in the team to make decision? How do you make decisions? To make decisions, you need to be able to understand how the company values things, how the company values decisions. For example, would it be okay for you to just build it, ship it, but only ship it to 1% of the audience? Or is this holy shit! What the fuck did you just do? We are a security compliance company. You don’t do this in our company.

In a consumer app, maybe. Hey, fuck you. Ship this to 1%. You have these numbers. Holy God, you [inaudible 00:15:07] after week, right? Very different cultural values, very different decision making process, but this needs to be explicit to the team and through this, you have clear decision making. Through clear decision making you have better delegation of authority or delegation of decisions and through that, you are able to systemize at least giving trust. The other end here is validating trust. How do you expect people to deliver outcomes? Communicate the goals, like what they actually want to do, all this kind of stuff is classic processes. It goes on and on and on and I can talk forever.

Another thing which I personally like, and this is the one thing I would like to leave here as well is, processes don’t mean big use of decisions. It’s doesn’t mean 20 people making decisions. Like I say something and I pass on to you and you add your stamp and whatever. It doesn’t mean this whole complex layering of whatever. Processes means explicit expectations. It means, for example, [inaudible 00:16:04], we use to have and they still have, every morning everybody does pull request reviews. The idea is that you do it of everybody. The team is small enough. There’s, I think, 10 engineers or so, that you can still do it from everybody and you should be expected to do it from everybody, at least from people that you work with, that’s the minimum.

You do it every morning and the reason why you do it every morning is that people can rely on that you do it the next morning. This means, when you push your code in the evening, somebody will have had the morning before you get up, will have looked at their stuff and will be able to give you feedback. The whole idea here is that you don’t need to remind people, hey can you please, hey can you please. You don’t need to interrupt people and do something else and be like, “Hey, can you take a quick look here? Can you look quickly add your plus one here?” Which is a huge distraction to everybody. You just push your code and you expect everybody to do it in the morning. You expect them to it in the morning before you do anything else, before you answer emails, before you look at your own stuff.

Because you are unblocking other people, and that’s an explicit expectation. That’s the process and this kind of process on this, I would say level, are small enough that people can easily incorporate them and they’re small enough that you can iterate them on. This kind of process creates, again, trust. This is the systematization of trust that I think.

Wes Winham:
I heard you talk about onboarding documents as to what your authority is week one, month one, month two. Is that … how do people learn that morning is the time for code review. Is that on your onboarding document?

Andreas Klinger:
Absolutely. I think manuals are one of the most underestimated aspects of managing people. They are kind of now getting hip. It’s becoming now more like a thing, but to me, manuals are one of the most under respected, under appreciated aspects in any team. It gets to the point that most manuals are only updated by people actually joining because they notice errors. Manuals are one of those things that help you scale, one of those things that help you make stuff explicit, even to people already longer in the company and really, really healthy and important. Period. I highly recommend.

Wes Winham:
What are things you’ve learned about … there’s a lot of manuals out there that are stale, they’re old, they don’t affect reality, they’re incomplete. What are some of the ways that we can establish norms that result in manuals that are useful?

Andreas Klinger:
Make it explicit what actually is … it’s the same as code. When you write code, you want to make it explicit what is stepped, like stuff that is no longer updated and what is actually important and good in how it works. The same with a manual. Make sure that it’s … remove stuff that is no longer updated, or don’t expect people to read it at least. Put it in an archive or something, but make it explicit. In case of doubt, we remove everything but five articles and these five articles are up to date and you have to read them. Rather reduce to things that you actually want people to do and want people to read than trying to have everything there and fine your own adventure game for everybody.

It’s the same with processes. With processes, in case of doubt, have less and product can be used to say we only have like four processes that we expect everybody to do. In case of doubt have less, but insist on those explicitly. Out of that, as soon as you have this, you can have a fundaments, you can build on top. I know a lot of people who love just writing a lot of stuff and telling their employees how to do shit and how the cultivate apparently should be. Then they leave all these huge documents that nobody a part of them has ever read. What’s the point? You’re making this to feel good. You’re not making this for the team. What is something that’s actionable for the team?

Wes Winham:
So have the smallest surface area of the manual as you can be functional. Prefer having less than you think you need if that’s what you can maintain because unmaintained documentation is bad. When it comes to that review process, is this something that you’re thinking of? Like I’m going to look at the documentation every week. Or is it when I check and code, I need to think about how it impacts the documentation? What’s the cadence?

Andreas Klinger:
It depends what. Onboarding documents should be owned by people. We had a product company that had the expectation of anybody who joins to update them as well. It’s kind of like the first change you do. Product Hunt has a very aggressive onboarding schedule. [inaudible 00:20:48], who you will talk to next week, even made my opinion more aggressive, but in a very healthy way. That sounds very contradicting, but you will hear next week what this means. One thing that we did, is we expected everybody to ship something on the first day, like code and also change something in the onboarding documents while they still read them. It was almost like an explicit expectation.

It was like yes, I know you just joined. I know you have no idea whatsoever, but change something. We don’t care what it is. You can change the formatting if it improves it. You can fix spelling mistakes, and trust me, I will leave enough for you to fix. You can iterate on something that’s not clear. You can add troubleshooting if whatever is not clear. That’s fine. You can add books that you would recommend and all this kind of stuff. Everything is cool, as long as you are at this moment changing it and taking ownership of it in a way. So that was a clear expectation. On the other hand, onboarding docs always have a certain person, usually the engineering manager being responsible for them. Also making clear what is the onboarding documents they expect people to read and what is further reading if they want, which is obviously potentially outdated.

Wes Winham:
Gotcha. So we’ve got the required core engineer manager that runs it. New folks are expected to change it on the first day, expected to deploy on the first day. That sound like a great process to keep a remote team working. You’ve said before that iteration is easier remote, but innovation is easier in person. What does that mean?

Andreas Klinger:
What I try to explain with this is a little bit nuanced because when I say innovation, I don’t mean doing innovative stuff. Every startup, every team, every knowledge record [inaudible 00:22:37] stuff, otherwise you wouldn’t succeed. You can’t just do what everybody else is doing exactly the same way. You need to do something, smarter, better, cheaper, faster, whatever. You need to be innovative by default. I don’t mean being innovative. I mean innovation in the sense of, we need to fundamentally change our business, even to a huge pivot. We need to change how we manage. We need to launch a new, new product. We need to do our quarterly planning and we need to hit new revenue goals and we have no fucking idea how to do that.

This kind of stuff tends to be a little bit easier in in-person discussions because there’s a lot of nuance that you lose in a hang out call. There is a lot of, especially with complicated topics, it’s hard to do them in a hang out call because it becomes two people talking, three people listening in a way. Sometimes you can pre-structure for documents that everybody can read. That’s fine, but there’s still a lot of nuance that you lose. I highly recommend even remote teams to meet, let’s say, every quarter at least. One thing that I personally prefer is actually having teams within the remote company to meet more often than that. Basically fly together for kick-offs, or fly together for whatever, because it becomes at some point when you’re 30 people, 50 people, each [inaudible 00:24:01] that meet becomes really complex to arrange.

At that time you shouldn’t waste it with project discussions. You should actually use it to get to know each other. Even remote teams need this in face time, so innovation there is [inaudible 00:24:15] better. On the other hand, iteration in my opinion is by far better remote. If I can optimize my day for my own performance and not for being sure I have enough face time with Sandra at the office because Sandra doesn’t like me and tries to fire me and constantly nitpicks when I don’t arrive on time, this is by far better for my productivity. I can bring my kids to school and I can afterwards go to the gym and then I start working. Then maybe I take a break and read a book that I want to read and then I get my kids from school and then I do dinner for everybody and then I work four hours at night.

I know people who do this schedule. I know people who do a completely different schedule, but optimized for their own performance. I can optimize my own performance, like I work from maybe a special room at home that are optimized just for work, or I go to a small office of people I like working with and I optimize this place for my own performance. I personally believe in a few years from now, it will be almost ridiculous for us that we expect high performance engineers to adapt to whatever weird framework we have and just come and adapt this framework instead of them owning their own performance outcomes.

Instead of them owning their own schedule and their well-being and their health and happiness, we were like, “No, no. We actually want you to come to the office and be miserable in the afternoon because that’s the time you would love to take a nap, but you can’t.” Instead of that, we were a company office. Instead of … just be like, “Oh course, you’re like one of the best engineers in your field and you’re highly productive and you want to own your own performance and productivity.” Holy fuck, of course. Innovation better in person, iteration better remote is kind of the summary I’m trying to have with that.

Wes Winham:
That makes sense. One question. It sounded like some of the cases … like time shifting, my guess is there are some co-located teams that are very pro time shifting. They don’t have standardized times. And there are also remote teams that are very strict about time overlap. It’s more synchronous, because maybe they’re not across time zones. Do those things really go hand in hand, like remote and time shifting and co-located and synchronous time?

Andreas Klinger:
In remote teams, there’s almost this cultural spectrum, from synced to asynced. Meaning, for example, Envision is a company valued at I think 1.3 billion dollars or some crazy number.

Wes Winham:
They’re doing all right.

Andreas Klinger:
Fully remote. But they expect everybody to work on Eastern time, so even if you are based in West Coast, or in, I don’t know, Europe, they expect you to work on Eastern time. This obviously doesn’t work for a lot of people because you’re basically shifting your whole day schedule. Most remote teams I know try to have an overlap of five hours of synchronous time. It doesn’t mean that you constantly work together, but being able to roughly have the same time where you know you could ping somebody and they would instantly, or within a reasonable time, reply.

For example, at Product Hand, we used to hire and we still hire between West Coast and Eastern Europe. This includes Latin America and Africa. This was a huge spectrum of time, but it comes down to if you expect people on the East Coast to get up early and expect people on the West Coast to get up early and in Eastern Europe to stay a little bit later, everybody has roughly a reasonable working frame of time, but has enough overlap. I know teams that are fully asynchronous. I know teams that intentionally try to have no hiring limitation and work completely asynchronous. Most asynchronous companies I know have their individual teams synchronized. So they have the mobile team in Indonesia, or in Indonesian time zone roughly, in Asian time zone maybe. They have their marketing team in American time zone and so on and so on.

This is one thing of the spectrum. Even with an asynchronous team, companies a lot of time have synchronous teams. Then there is the extreme cases as I mentioned before, like asynchronous teams, like [inaudible 00:28:30], that has an expectation that everything is asynchronous. If you write something, you don’t expect people to instantly reply, but you expect them when they reply to have a thought through answer. It’s a little bit different thinking and this is almost like a spectrum. Most discussions around the future of remote work aren’t so much we’re the future, like we will work in the future remote, which to me is a no-brainer because the internet is not going away. We will work more online. We work more internationally. This won’t change.

So the question is not so much will we work remotely, but it will be much more like how synchronous will we work? And that will be more like the spectrum where the discussion will happen in my opinion.

Wes Winham:
Let’s say I’m leading an engineering team. We raised a Series A, so we’ve mostly gotten by on network hiring locally. I am excited about remote and I’m thinking about this synchronous, asynchronous spectrum. What are some of the things that I should consider when I’m deciding how I want to structure, or how I want to move my culture?

Andreas Klinger:
Yes. Hybrid teams. If you have people in the office and you have people remote are naturally a little bit hard to do. The reason is, if I’m in the office, it’s very easy for me to just talk to somebody and it’s very complicated for me to write something down. In a remote team, it’s very, very complicated, annoying, to speak to somebody because hey [inaudible 00:30:01] hangout and then like sure hang out and then maybe it works, maybe it doesn’t work. But anything longer than 30 minutes is a pain for everybody. It’s a little bit more annoying to talk to somebody in a sense. But it’s really, really easy to write something properly down and you actually start to make … it’s actually enjoyable. You start just writing your thoughts on a … you draft your whole thoughts and at some point it becomes natural for you to write down your whole thoughts before a meeting so that everybody can read them instead of you just articulating.

This becomes very natural, but it’s very different. It’s almost like it’s different communication layer that just acts differently. It’s not one is better than the other, it’s just different. Both have to do more of the other, blah, blah, blah. But in a hybrid team, the problem you have is that one part of the team acts on one layer and the other will act on the other layer. If you have a critical amount of people in the office and a few poor souls not in the office, these people will constantly expect communication layer that’s really annoying and hard for the other group.

These people will feel isolated. So how do you get around this? Let’s assume you still want to have the hybrid setup. Of courses you could say everybody works remote, everybody is happy and we live joyful, fairy tale, blah, blah, blah. Let’s assume this is not reality. Assume you want to keep the office, or you have to keep the office, whatever reason. You can segment. You can, say for example, this team here is now remote first. There’s a special unit in our team that for example focuses on one large area of the company. They do for example, the mobile app or they do whatever.

This whole team, the whole engineering team in the office might be 20 people, but in this team there’s only two, and there’s three more actually remote. All of a sudden, this team has almost a critical amount of people remote and it comes to the point that this team can act like remote first. It’s very, very normal for companies to have segments of their company remote. It’s traditionally is the sales team. You have a sales team that visits clients, or you have a sales team that has some part in this city and you have some sales person in that city or whatever. By default, sales is very natural to remote. Another one is customer care. Shopify has more than 1,000 people working remote in their customer care team. This team acts like it would be a remote team in a company that’s technically not a remote company.

Segmentation is a very healthy one. The other one is … also the good thing about segmentation is you start learning patterns and behavior that you should incorporate in the whole company to just make it easier to make more and more people work remote. So you’re starting to learn in a more or less testing area. This would be my number one recommendation. There’s a few nuanced extra ones. For example, make sure that remote people come to the office to meet everybody regularly, then ideally not make them come to the office, but make everybody go somewhere else and this kind of stuff. Or another one could be give this, if you have remote people, give them as much authority as possible. Another hack is, if you really want to force remote behavior is trying to have the people that people have to report to being remote.

Andreas Klinger:
So all of a sudden it changes how you need to communicate. You can’t just go to … you’re not preferred because [inaudible 00:33:33]. The boss is also remote. There’s a few hacks and little nuances you can do, but the primary one would be segmentation to me.

Wes Winham:
So if I’m in that Series A, I know that my CEO is not going to be excited about going fully remote, I can say, our mobile app, or our data pipeline or some other big piece.

Andreas Klinger:
Yes, or the classic one is infrastructure. That’s the most classical one. Like hey we have two [inaudible 00:33:57] people that are remote and they are like poor souls. But on the other hand, they are on two different time zones, so therefore they have almost a natural overlap on [inaudible 00:34:07] time would be roughly online. We have … dev ops is a classical case of that. I wouldn’t recommend it personally because it tends to be very isolating, but another one is, like you said, mobile. It can be … it’s very healthy if you don’t segment by technology for example. You don’t say like dev ops and mobile, you say more like by goals and outcomes. So you have one team that’s around customer engagement, or one team about resurrection and all this kind of stuff.

Then you create a team there and that’s usually healthier.

Wes Winham:
So let’s switch gears and talk about hiring in maybe a distributed context. When I talk to folks, in especially smaller markets, the number one complaint is always I have no canvas. I basically have none when I talk to folks who are hiring remotely, they don’t have that problem. What’s different about remote hiring?

Andreas Klinger:
I get the arrogance of expecting to be having a lot of engineers if you are in San Francisco. I get that, right, or Silicon Valley, sure. Why not? But if you’re in a small town, even if it’s a major city in America that has less than a million people, why do you expect the best people of the world to live? Sadistically speaking, the majority of the world is not in the city where you live. Period, by a factor of billions. Period. You’re fishing in a small pond and if the small pond has a lot of other interesting startups to work on, holy shit.

It gets to the point I regularly invest or advise people to invest and I talk to [inaudible 00:36:27] like you’re launching in San Francisco and you’re trying to build up your engineering team here. I don’t see this to be like the hip ship every engineer wants to work on because it’s their fucking career boost. If you work on a really technical, complex product, that’s a good career boost that you can go to Google afterwards. So how do you expect actually to hire people and more importantly, how do you expect to retain them? Because if you have to re-hire every one and a half years, your whole hiring process is fucked. You can’t build up anything and a team.

That’s the default in San Francisco. That’s the default if you’re good. That’s not the default if you break out, you’re just starting and nobody knows about you and your product is not really interesting. It’s just whatever. What the fuck are you doing?

Wes Winham:
There’s a lot of interesting things we can make an impact in San Francisco.

Andreas Klinger:
Exactly. Honestly, it is true for almost every city. Remote, you just have a bigger pond to fish in [inaudible 00:37:27]. That being said, it’s not necessarily easier just because you have more candidates. You can be a little bit more pickier, which is very often fine. But it’s still a very highly involved process. Most remote teams that I know have people hired full time just for hiring because it’s a very involved process. If you have, for example, at Product Hand, we used to have several hundred applicants for each job after one or two days and we’re like, “Okay. I’m cutting this job after four days.” I know it’s freaking unfair because you might not have heard about it. You might not … you’re considering it. You’re preparing your shit and now the job is gone, what the fuck?

But I can’t deal with more than four or five hundred applicants now. And I will re-open it maybe. I don’t know. But holy shit, and this was a regular scenario for us. I know companies, you most likely don’t even know that are bootstrap, 30 people. Another one is 40, 50 people. They get 1,000 applicants per month for two to three jobs. If a larger, well known remote company like [inaudible 00:38:36], opens up a role, a non-engineering role like customer care, they get realistically more than 1,000 applicants. But not all of them good. Not all of them perfect. Not all of them matching. But it’s at least a start.

Having 1,000 applicants is … exactly. Having 1,000 applicants is better than not having 1,000 applicants right.

Wes Winham:
Other than hiring someone to do full time hiring, what do you do as an engineering leader and you’ve got 100, 200, 300 applicants and close the job early? But then you still have that pool. What do you have to change versus someone that has way fewer applicants?

Andreas Klinger:
Ultimately, we can automate. There’s stuff you can just automate with good tooling. Another one is know what you want and ask good questions up front. Asking those questions up front becomes a form of-

Wes Winham:
Like on the application itself?

Andreas Klinger:
Yes. Yes. Absolutely. Ask them up front, first thing people do. One company I highly admire, it’s called Zapier, they’ve got this down to a freaking form or art. If you read the application form of Zapier, the questions, is honestly feels somewhere between [inaudible 00:39:47] application and soul searching. It’s to this point where you have to not only think about what is the question, but what is the question behind the question they’re actually trying to get at and what is the question behind the question behind the question.

One that stuck with me was for engineering [inaudible 00:40:03] was what kind of archetypes of developers are out there? And which one do you think you are the most? And which one do you like working most with? I’m like, “How the fuck do I answer that?” How do you answer that? That’s like the questions behind the question behind the question. Is the correct answer saying I believe everybody is unique? Or is the correct answer saying there’s this kinds of archetypes? Or is the correct answer saying no, I believe there’s more different kinds of behavioral patterns, or phases in life? How the freaking fuck do you start answering this question? And then which one am I?

Then it’s like holy shit. What do you want from me? Asking good questions up front is an absolute must. One more I highly recommend is if you hire internationally, and for some reason your network is exhausted, CVs tend to be a little bit complicated because you don’t necessarily know … you’ll get this applicant from India and he went to some university that’s called like ITT or something like that. You have never heard about it. What the hell does it mean? It turns out it’s one of the best universities in the world, but you have never heard about it. How do you deal with that? That’s hard work. That’s, again, tooling. Angel List offers some tools in their hiring process for that.

But, it’s just hard work. Another one here is, at least for me, is a non-native speaker. If somebody speaks to me as a native speaker, they automatically sound more intelligent. They’re eloquent. They are precise. They’re on point and they just sound smart, like those people I hear all the time in the podcasts. But if somebody comes who has an accent like me and struggles finding the right words to put into sentences, it’s a little bit … I’m not saying it sounds stupid, but I’m a little bit biased automatically. I realized that at some point, and what I did, and I highly recommend every engineering manager to do, is a little pair programming with every candidate that I pre-filtered.

Pair programming in the sense of I sent you an application. You get it to run locally. You prove that you got it to run locally somehow. Maybe you [inaudible 00:42:15] syntax some result or something. Then we jump on a call and I give you a challenge in this one application that you already know now, that you have played with, that you understand, and we together work on this challenge. It’s a real world application problem. For example, a product can be used to be a mini version of Product Hand. At Angel List venture, it is and used to be something [inaudible 00:42:40], but something around working with really large data sets of … I can’t even properly explain it right now.

But basically with complex structures and investments is the summary. In Coin List, it was one around ICO offerings and so on and so on. It’s a real thing that if you actually do that well and you enjoy it, you most likely learned what kind of work we do. By watching people pair programming and helping them through the challenge and hearing what questions they have on how to solve them and all this kind of stuff, you learn far more than by talking a technical interview or doing white boarding or asking them some hypothetical questions because that just tests how good are they in English and how long did they go to university and literally nothing else.

Pair programming is one of the most underestimated and not enough utilized aspects of hiring that we have out there and not enough people do it and a remote team in my opinion are forced to do it almost.

Wes Winham:
My guest today has been Andreas Klinger. Andreas, thank you for joining us on Scaling Software Teams.

August 6, 2019