‍Editor’s note: This interview was published at the start of the global pandemic when Jason Warner was the CTO at GitHub. GitHub was acquired by MSFT in June 2018 for $7.5BN. Prior to joining GitHub, Jason was Head of Engineering at Heroku, Canonical, and 41st Parameter — all distributed companies. He has a great deal of experience managing remote teams and building remote cultures, having been remote himself for more than a decade.

‍

Unusual Ventures held an AMA session with our founder community where Jason shared key advice, perspective, and tactics learned from his time leading iconic companies during "normal" times and past market corrections. This is part 2 of this interview; read part 1 here.

Hiring and talent

Can you talk about how to approach headcount planning during uncertain times, when there's runway and key milestones to hit on the product roadmap?

When it comes to headcount planning, ask yourself, "What's our burn? What does 18 or 24 months look like?" If I were running a venture-backed company, I'd be thinking about basically making it through 18 to 24 months. What does that look like? That's my first question I want to ask and answer.

‍

I’ve been through 1999 and 2000 and 2007 and 2008. I've experienced a couple of market corrections. In some cases, depending on where you are on your funding and maturity curve or your customer base or ARR, it might just be about survival. And if that's the case, understand that and be realistic. If it's not about survival and it's about acceleration and thriving, understand where your competitive advantage comes from and how you're going to thrive and get better through this. If you're a later-stage company at this point, you could focus on becoming more efficient and making your communication pathways better and becoming a better company. But if you're a Seed or A Stage, it's cockroach time to some degree. You have to get hyper-vigilant about your burn.

What's your tactical advice on hiring strategy, possibly with a remote team — especially if you're just getting off the ground and running with your MVP team?

You're going to have to get really good at remote interviews because you're never going to see this person if you plan to hire them quickly. Find questions that allow you to feel comfortable with that person pretty quickly.

‍

I am super expressive on video calls with my face. I try to express my emotional state with my eyes, my face, my hands, and I get overly dramatic. It's intentional. I’m trying to convey what's happening because it's a lot easier in person, but over video, no matter what we think, it's a little bit harder, so overdo it. Expect that the other person's not that good at it and that it’s your job is to pull out who that person really is.

‍

For your interview process, if your company has one or two founders and you're interviewing for new employees, I recommend you do the interview together, because you're going to want to coordinate your information with the other person with the same context. Individual one-to-one calls don't allow you to calibrate, and you want to calibrate now more than ever on hiring decisions. I do think that projects are useful, but might be harder at the earliest stages.

‍

"I did my entire interview with GitHub remote. The process included a presentation that I gave multiple times to the GitHub exec staff and the investors — all virtually. So it's very possible to run an effective interview and hiring process entirely remote."
‍— Jason Warner, CTO, GitHub

Would you change any part of your interview process if you were not able to meet a candidate in person before making a hiring decision?

Not necessarily. You just have to be a bit more adaptable to the human element of someone being remote. 30/60/90 presentations are great, which you can still do remote. Having someone do a presentation followed by a Q&A session still works really well remote. There might be awkward silences at times, so you have to be mindful of that and help candidates through those situations. Fun fact: I did my entire interview with GitHub remote, except for meeting the founder once in person. The process included a presentation that I gave multiple times to the GitHub exec staff and the investors — all virtually. So it's very possible to run an effective interview and hiring process entirely remotely.

Any tips for onboarding people remotely?

Onboarding people remotely is hard. Your onboarding goals should fit whatever their role is. For instance, if they're a developer, you want to get them pushing code as quickly as possible. Think about their onboarding in the context of what they need to get that done. Try curating a ticket or a project for them to execute quickly. Going through that process will help them to understand how work gets done at your organization and how to communicate along the way.

‍

I do think that if your company is large enough, you should assign an onboarding buddy for them for their first one to two weeks. Their job as a buddy is to have a daily standup with them and say, “Here's what you're going to do or how you're going to do it. What questions do you have? Let me help you with a couple of those things to break the seal.” If you're big enough and you have an onboarding class of people, you should have a person who handles the class so you can onboard the entire group of people and make sure that experience is consistent and positive.

Developing a positive remote company culture

How do you share our team vision, values, and culture with new hires?

I feel very strongly that the habits of a distributed company are the ones who make great companies in general. My advice here is the same that I would give to a co-located company or distributed company. It's all about communication. I feel very strongly that the best companies in the world exhibit a couple of traits. They understand their mission and vision very distinctly. Everyone in the organization knows what that is, and they're able to know how they're going to make decisions in line with that mission.

‍

Think about your communication channel inside your organization as a feed that looks like this:
‍

The V communication channel for growing organizations

‍

‍

• The job of CEO or a senior leader is to provide the mission, vision, context, and build the pathways that communicate all the way down to the marketers, engineers, devrel team, etc. You’re communicating those values, those contexts, and the “whys” in the organization.

‍

• On the way back up, you want to create a feedback loop. That includes project status and making sure that things are progressing. You need to build those mechanisms. Now, your job as a CEO is to close that “V” as much as possible to create that tight feedback loop. The sooner you are able to provide the context, clarity, and vision and get the feedback loop that things are progressing, the better your company is going to be. You're never going to get to a straight up line. However, the further you get away and look more like a horizontal line, the worse your company's going to be.

How would I go about closing the “V”? Particularly in a distributed world, I would write it all down. I would provide a lot of the context around why we're making this decision, who we're going to do it for, and in what timeframe we hope to achieve it. The job of any leader in an organization is to make the set of decisions that only they can make and to empower the people below them to make all of the other decisions that can be made by others. That's how you achieve scale. So if you are able to do that and you're providing the context and the autonomy for those groups to make those decisions, you're going to tune the organization over time. Tactically speaking again, write it down. Over-communicate. Do it in multiple mechanisms, put it in GitHub; have weekly status meetings; send all company emails; put it in Slack channels. Say it once, say it again, say it multiple times, and then provide the feedback loops that things are happening. Write down your company goals, how you’re going to measure progress, and give regular updates about the achievements of those goals.

Github has been transformational for many teams in a lot of ways. Most of the founders can only dream to achieve such massive impact. How do you operate to be able to consistently deliver great quality products? What level of autonomy is given to engineering and product teams?

This has gone through many evolutions at GitHub over time because this is one of the ways that you grow and scale companies. It's two people in a garage vs. 5,000 people. GitHub right now is about 2,500 people because we absorbed internal Microsoft teams post-acquisition. My view, in principle, if you go back to that “V” that I mentioned before, is how I think about company building. To take a little bit of liberty in answering this question, I want to give you a little bit of history of GitHub and why some of us had success.

GitHub had massive initial success because it had a massive immediate market appeal for several communities — programming language communities, dev communities, etc. At the same time, the zeitgeist was changing from Java, J22E, to Ruby on Rails, and going through a weird transition. But the product just clicked and what GitHub did incredibly well initially was hire a bunch of people who knew its core audience deeply and just unleashed them and let them go build features that they themselves wanted personally. That proved to be a formula for success. GitHub didn’t invent the pull request but it made it popular because what GitHub had really early on was this notion of taste. It knew that its customers wanted a lot of taste and it biased towards that.

GitHub then went through about a four-year period where it was terribly run. It had almost no feature releases. It famously got a letter called, "Dear GitHub'' from the open-source community because it was ignoring its needs. What happened is it over-oriented too much toward individual opinion and ground to a halt where no features got released. It was a very strange dichotomy. I essentially was brought in to help GitHub fulfill its potential and get back on track. When I joined in 2017, coming on off Heroku, GitHub was basically a plane hurtling towards the ground. It was by all accounts a highly successful product, but internally it was so mismanaged and so poorly run that the numbers didn't support its valuation anymore and investors were wildly worried.

How we got our mojo back (which is the way I put it) is that we basically unleashed the teams again, but in a structured sort of way. So, I as the head of the company at this point, said, "I will make a set of decisions and then I will fine-tune and train the neural net that is GitHub's management ladder to make the same sets of decisions, but better than me." So I set out to give us a mission and vision. I put out a five-year charter. I said, "In five years, this is what we want to do." That immediately clicked with everyone. They understood why they came to work every day. The next step is slowly tuning the organization to make decisions that you once needed to make, but slower inside the organization at each level. Once you're able to unleash those people on the mission and vision, you're able to achieve massive success again. However, the challenge in doing that is keeping people aligned. That's why you need to make sure that that “V” is as close together as possible because the further the “V” moves away from each other, the less alignment you have.

When I joined GitHub, the "V" was basically a horizontal line. My job was to create the “V” structure again and then slowly move it closer and closer together. And I did this via a series of mechanisms, but to distill it all down:

• I told the organization where we were going by telling them what I wanted to do first.

• I told people what I wanted to see and in what timeframe. Then I started holding people accountable to achieving those objectives.

• I ruthlessly used meetings or other organizational constructs to see if we were making progress and tuning the organization along the way.

‍

I had to do this when Github was around 800 people. Today, the mechanisms would look very different because you can't use the same tools at 5,000 and you shouldn't use the same tools at five. But that clarity around communication and alignment underlies my philosophy for company building at any stage.

Remote tools

We usually have a lot of discussion of product design overview. We used to create documents, and then you would go with a document and post them in your white boarding sessions. Now it's getting difficult for us to do it offline. How will we make sure that things are fun and productive working from home? Any virtual whiteboarding tool recommendations?

Brainstorming is weirdly one of the harder things to do remotely. I took cues from the open-source community on this one, which is to show it in code. And for developers, that's easy. But get to code as quickly as possible. Use Figma, InVision, Framer — those types of tools to do a lot of the mockups and demos. InVision is a completely 100% remote design company, and that's why their tools are pretty good for this stuff. But if you're a developer, show it in code or mock code or some high-level prototyping code, but get to it as quickly as possible. That is one of the habits you need to get to. Don't spend three weeks or even three days on a prototype. Get to a workable passable prototype you're willing to throw away in a couple of hours. Have a Zoom session up while you're typing away. Use VS Codes live coding sessions or other telepresence software.

For non-tech teams, I think Google Docs, InVision, Framer, or Figma with a video call is a good passable alternative for now. I use pen and paper all the time. However, when I'm doing a brainstorming session, we do it in Google Docs. iPad with Zoom and a pencil is worth a shot too.I heard of a tool called Miro where you can whiteboard virtually. Everybody either uses Confluence or Google Docs to document.

‍

If you're in the early stage, incorporating a general writing culture really helps. Many of my own decisions for my team — even stuff that's usually understood — we just write it down. And over time, you start seeing that people make those decisions and write them down a lot more than you would expect. That leads to a written down communication culture that makes a positive difference. In general, write stuff down here, document it, and ratify it. Google Docs has certain sharing and permissions issues. My rule of thumb is if it doesn't have a long-lived URL, you're in trouble. Screenshots, mockups, Figma, InVision sketches, screenshots with annotations on them are way better when they're text and those combined. It just lands orders of magnitude better than straight-up written text. Slack screen sharing is also great. When you share a screen, other people can actually just write directly on your screen and it's collaborative as well, so you can see what everyone else is typing in real time. And then if you are an engineer, the more code you can have on an online collaborative text editor, instead of just running locally, will dramatically increase how effectively you're able to communicate.

‍

Remote management

How do you handle your one-to-one meetings remotely?

So I've always done 1:1’s the same way, which with a shared Google Doc that we have shared beforehand that’s also in the calendar invite, alongside a video call. We open up the shared doc while we stream things during the week that we need to discuss, whether it's personal or work things. I'm not one of those people that believes that 1:1’s are all about career development, nor do I believe it's all about work. It's a mix of things. It's whatever is top of mind for everybody. A lot of the conversations now have been, “Anything that's on your mind? How's the home situation? Is it different? Is it causing you to have any sort of stressors?” Once you acknowledge the human to human factor, most people want to move on and actually get back to work discussions. They just want you to acknowledge the human side of things a little bit more in light of COVID.

Can you share your weekly cadence with your remote teams?

My weekly cadence doesn't look that dissimilar to the in-office stuff that I would do. My Monday is just executives basically and we conduct exec staff, and review meetings, including a product review meeting, go-to-market review meeting, and marketing plan review meeting. I also do a couple of 1:1’s with other execs on Monday. These can be monthly, bi-weekly, or weekly, depending on how much I need to interact with them. Tuesday is staff. I'll do my staff meeting and then my review meetings, such as an infrastructure review meeting or security review meeting. The review meeting is a chance for those teams to come and present what they're working on, whether they're the boulders or the rocks or big initiatives or whatever, and get feedback from me. I call them my “editing meetings” vs. my “author time”. I'm basically being presented with a whole bunch of things and I review them. Then I do all my staff 1:1’s. I try to get them all out on Tuesday, so that my week is front-loaded. Wednesday and Thursday, I have work time, and Friday is mostly review—we do demos or reviews of things that have happened that week that we need to course correct, make decisions on, or adapt for the next week. I bifurcate my week so it's heavy on exec on Monday, my staff on Tuesday, review meetings, course-correct with planning, and then review on Friday about what we achieved and what we didn't achieve. And then what we might have to correct for Monday. As for tools, I use GitHub, Slack, and Zoom. Those are the big ones. Google Docs for shared collaboration. I very much encourage everybody to pull up a Google Doc and co-write things as you're doing it. Don't take notes locally here, take notes in a shared space. My 1:1’s are tracked in a Google Doc. We do that so both of us can see it at the same time. We memorialize decisions in GitHub, have the one-off chats in Slack, and then take it to video as quickly as possible with Zoom.

What strategies have you found most effective when dealing with communication barriers due to time zone differences?

Communication is incredibly important, now more than ever. I break it down to three communication channels (not counting email). Type 1 refers to channels for storing institutional memory, ratified decisions, and things of that nature. A good example would be Github. Type 2 is for high bandwidth communication like a video call or Zoom. Finally, Type 3 is for more casual, real-time chatting like Slack or text. If you have timezone gaps, it is incredibly important that you ratify decisions in Type 1 channels like GitHub as opposed to Slack. The reason is it's easier for team members to consume that information once they come back online.

That said, one of the best strategies to mitigate that time zone gap is to actually have timezone overlap. I have had a hard rule for many years that there can be no more than a four-hour time zone gap between teams. If you wanted to be on an overseas team, you needed to have at least four hours of timezone overlap with that team. We've got a team in London; therefore they can work with the East coast and maybe a little bit of the West coast in the U.S. at times if it was an exceptional case, but they won’t have members of the team in London, the U.S., New Zealand, and Australia. It's just not going to work out well. Too many things go wrong. Too much lag happens because you're not able to speak live when you need to. One of the most important traits that you need when working distributed is the ability to pick up the phone or Zoom as quickly as possible. Any slight miscommunication, you need to jump on the phone. But if you need to have 12-hour gap coverage as well, make sure that decisions are ratified in institutional Type 1 channels like GitHub, and that is where people consume their context from. If you force someone to scroll Slack, it’s a horrible experience. You're going to miss many, many things.

What are tell-tale signs someone is struggling with the remote work setup?

Telltale signs people are struggling with remote tends to be that they go for longer than expected without hearing from them. Or the opposite, where they reach out way too much, because what happens in a remote scenario is that the worst attribute of your own personality tends to get exacerbated. So if you're a highly anxious person, you might be worried that somebody else is talking about you when they're not. And you just have to watch for those signs. If you know your folks well enough, you can actually see those signs pop up early. On the flip side, your worst attributes as a manager are probably likely to come out too. So if you tend to be a micromanager, in our current scenario, you're likely to be an extreme micromanager. And that's probably going to cause all manner of problems, too. It’s important to understand what your failure modes are and know if you're over exhibiting them in a remote environment.

Especially if you're working full time remote or even just during the time now, how do you keep a line between home life and work life? How do you delineate between the two if right now everyone’s lives are pretty combined.

I'm an "always on" person. It drives my wife crazy. One tactic I’ve found to work is picking a couple of times when nothing can interrupt you except for something literally being on fire. And so I've picked dinner, bedtimes, and my workouts. Those are my three times that nothing can interrupt me and I've had to set boundaries pretty stringently. As a matter of fact, I got called by a boss once and I missed it while I was at dinner. When I called back I said, "Hey, I’m at dinner." He said, “But when I call, you pick up." And that was a chance where I could educate him that wasn't going to happen. I was at dinner, I was not going to pick up, I will call him back right away and if he needed something in the moment and it was super urgent, he can text. But there's very few things that he needs at the moment. So, I was just using that as a time to set the expectation. But I have had to pick three times to keep a line between home life and work life and my wife has to hold me to it.

Jason’s book recommendations

• What You Do is Who You Are by Ben Horowitz: I like this one because it’s in line with a principle I have: "Your reputation lasts longer than your role." In other words, you should do your job, but while maintaining your reputation. That means being explicit about who you want to be known as in the world. It's one of my prime principles and drivers in life.

• Atomic Habits by James Clear: A great book about forming habits and keeping them.
  ‍
• Extreme Ownership by Jocko Willink: How U.S. Navy SEALs Lead and Win: How you build ownership inside your organization and keep it going.
  
  
• Team of Teams by David Silverman: A good book for thinking about how you organize teams and keep them going. I've learned over the last ten years of being an executive that scaling a company is really about how you get teams of teams to work together.