How do you build 10X products … products that dramatically outperform the competition? GitHub’s CTO Jason Warner and I chat in this edition of TechFirst with John Koetsier on his playbook for building transformational product.
Recorded during a Traction Conference webinar, Warner covers how to prioritize features, ship products faster, and build and scale world-class engineering teams from a small startup to hyper-growth.
- Tips and techniques for building businesses with modern software development and open source at the core
- How faster software development, faster testing, higher innovation, peer review, openness, and transparency are surefire ways to catapult business growth
- How to build and scale world-class engineering teams
- KPIs and metrics executives and engineering leaders need to keep top of mind
Get the full audio, video, and transcript of our conversation below …
Subscribe to TechFirst: GitHub on 10X products with exponential impact
Apple Podcasts
Spotify
Google Podcasts
Overcast
Other podcasting platforms
Watch: GitHub on 10X products with exponential impact
Subscribe to my YouTube channel so you’ll get notified when I go live with future guests, or see the videos later.
Read: GitHub on 10X products with exponential impact
John Koetsier: How do you build 10X products that lead to exponential growth? Welcome to TechFirst with John Koetsier.
This is a really special TechFirst, because this is a TechFirst with the CTO of GitHub. GitHub is massive, it’s amazing, it’s incredible, it’s the place where developers gather to build what they’re building. And we’ll talk a little bit more about that in the actual podcast. But I actually did this as a webinar, as a show, as a presentation for Traction Conference, and was super happy to do so. And they let me use this conversation with Jason Warner, who’s the CTO of GitHub, for my TechFirst podcast.
So, now you get the privilege and pleasure of listening to somebody who is a C-level executive at a startup that sold for $7.5 billion dollars just a couple of years ago to Microsoft, and get an inside peek at how he came up from a very low level job at IBM and became the CTO of arguably one of the most important technical companies in the world, frankly. Enjoy!
Welcome, everybody. We are talking about technology and we’re talking about 10X products and we have the CTO of GitHub with us. It’s kind of interesting, I mean, in a tech-driven economy you can argue, of course, that developers kind of rule the world in some way, right? Well, GitHub has a central presence in that. There’s 50 million developers there, 3 million organizations on the platform from startups to full on enterprise. The Mars Rover team is there. I have an account. I have no commits lately, sad to say. And there’s a hundred million projects there and guess what? All those numbers are from 2019.
So it’s impressive, obviously sold to Microsoft a couple of years ago for a very nice sum, $7.5 billion dollars. There’s a lot to learn for startups by looking at GitHub, and this is about GitHub’s playbook for building 10X products. So Jason Warner, CTO of GitHub, welcome! How are you?
Jason Warner, CTO of Github
Jason Warner: I’m great. Thanks for having me. I’m glad to be back.
John Koetsier: It’s Corona time. Where are you staying? How are you doing? Is your family okay?
Jason Warner: Family’s fine, they’re great, we’re in Columbus, Ohio where we have a place and we’re settled out here and we’re doing well. It’s, I think the answer to that question is just as well as could be expected. You know, and when everyone’s healthy in 2020, you’re happy.
John Koetsier: Yeah, it is 2020. Let’s kick this off by maybe going through a brief kind of trail of your career. I mean, if you look at LinkedIn, your career starts with “IT Specialist” at IBM, which is one of those titles that you go, what does that mean? And you were at Canonical, Heroku, now you’re CTO of GitHub. How’d that all happen?
Jason Warner: Sure. So it’s a pretty straightforward but not normal story about how I got into tech in general, and IT specialist is a really good place to start.
You know, I didn’t grow up around computers. I actually didn’t have a computer until I went to college, of all things. But I got a job at IBM in high school as a high school co-op, and it’s because my auto shop teacher mentioned I should probably go apply for this thing. And they gave me the job mostly because it involved carrying things, carrying printers, moving them around the office and hooking them up and doing that sort of thing.
But they really wanted to give people who didn’t have opportunities, opportunities. So I like to say that I fell into tech. And while I was there, you know, I had to wear a shirt and tie to carry things around, and they told me if you got a computer science degree, we’ll give you a job after college. I was like, ‘Sure, what’s computer science?’ and at that point then I was into computers. And I stayed at IBM the entire time I was in college, in summer co-ops. And then after college, I went back to IBM for one season — one year, before I went off to a startup company. But there I was an IT specialist carrying around computers and then eventually programming.
John Koetsier: You know, it’s pretty amazing, and it speaks to the opportunity in our digital economy that you weren’t interested in programming or computers, didn’t have that exposure, but you got that exposure and boom, you know, it turned out that you were amazing at it. I mean, how many other great developers are there? How many other great engineers are there that we don’t know about?
There’s one part of your bio which is really interesting, your current bio says you “oversee the office of the CTO at GitHub, whose mission is to explore the unknown and non-existent aspects of technology and software in order to build a map of GitHub’s future.” What does that mean?
Jason Warner: It’s a really fancy way of saying I am trying to figure out where GitHub goes in several years, three plus years out, what we’re going to be building and why we’re going to be building it. Prior to the acquisition of GitHub, my job was basically all of technology. So I ran product, engineering, security, support, infrastructure, data, all of those sorts of things. So you basically are building up a roadmap and the day-to-day, and making sure that the day-to-day maps to the months, maps to quarters in a year.
Post acquisition, we filled out a lot of those seats with other folks.
And now, I am looking out way past what we currently have on the roadmap. So whatever I think we want to explore with others partnered, including Microsoft or Google, or others in the industry, about what should exist in software but doesn’t. And I think it’s interesting because of GitHub’s market position, if we add something to the platform, everybody in the world benefits from it. It’s not just a little niche software component that ends up on some random piece of product way over in the corner and if it gets adopted it could change the world. If we add it into GitHub, everyone gets it.
John Koetsier: That’s amazing.
Jason Warner: And we’re looking at those sorts of projects.
John Koetsier: Well, it sounds like a ton of fun. It kind of sounds like a dream job. I mean, like you’re not supporting an existing application and plugging on day after day, okay, where’s that bug that somebody introduced five years ago, right? You get to look at the future. That’s a ton of fun. Let’s dive into product. And by the way, if you have questions if you’re in the audience, feel free to use the Q & A functionality. A lot of these questions came from people who suggested them when Boast and Lloyed said that hey, the CTO of GitHub is coming. But if you have some more and we have some time, we’ll get to those as well.
So we’re going to start talking about product. 10X growth sounds great, right? Everybody wants 10X growth, but very few achieve it. How should startups think about building products as they go from idea, to product market fit, to potentially that hyper growth they want?
Jason Warner: You know, this is the trillion dollar industry question, really. And we all know that if you’re a venture backed startup, the chances of your success are not high.
In fact, we talk about that in the venture world, how if one out of every 10 is a unicorn or a decacorn you basically returned the fund in venture world. Now that doesn’t work when you’ve put your entire 100% into your company.
Venture can have misses, you cannot. So, how do you go about doing this? Well, the easiest way for me to describe this as thoughtfully and intentionally, and then explicit — and what I want people to understand, is that you have to understand who you’re building for, why you’re building it, and what is going to differentiate you, and then really truthfully and ruthlessly prioritize those things.
And then understand your motion to getting new customers.
So it’s been all the rage in the last couple of years, talking about bottoms up software development or tops down sales motions. And tops-down sales motions are the things you saw in the 90’s when you had people with slicked back hair and suits on taking people out to steak dinners and going out and golfing with them to win deals. Because people in the 90’s and early 2000’s had products foisted upon them, but now software developers or marketers, or even salespeople are adopting their own products in their workflows.
So the bottoms-up motion has liberated a lot of companies, because you can get to product market fit a lot faster. You can test a lot more easily.
So there’s a concept called “10, 100 or 1,000 raving fans” and I really emphasize this with people, if you know your motion, if you know your developer or your customer, and your audience and why you exist — start cultivating these raving fans, and they’ll be your best marketing channel.
They’ll give you the best feedback and then start to really cycle that in your early days. Don’t get ahead of yourself. Don’t try to launch before you need to, reasonable capital as you possibly can, and then ruthlessly get to those raving fans.
John Koetsier: I love it. It’s kind of more a 37signals [now Basecamp] type of plan versus a venture backed plan, right? I mean, it’s like build small, grow as you go, instead of, you know, always taking the home run shot. Obviously some people are going to take the home run, go for the home run, but for most people you’re saying, ‘Hey, go the 37signals route.’
Jason Warner: What I would encourage people to understand is incentive structures. So when you raise capital, what does that mean for your business? When you don’t raise capital, what does it mean for your business? And who has which incentive for what? And I am a big fan of venture backed startups. I think that they take more risks. But I want you to understand what a venture capitalist might give you as advice versus what an advisor who is a confidant to you might give you as advice.
John Koetsier: Yes, that makes sense. So, sometimes what you don’t build is more important than what you do build. And there’s some data out there that GitHub did not build continuous integration for a very long time, and that decision was one of the things that helped GitHub get acquired by Microsoft.
Can you walk us through that?
Jason Warner: Sure. This is a rather complex story and there’s some nuance in this, though what I would say, is that yes, we did not build continuous integration for quite some time. There’s a lot of reasons why we didn’t do it while we were a venture backed startup. The two primary reasons though, were cost. It was a very expensive business to be in.
And the other one was, honestly, it was strategy not to build it. Because, if you think about this, you have to look at, you have to market map everything out. You have to understand who your competitors are, or where the landscape is going, or what is going to happen in the market today, tomorrow, in a couple of years.
And one of the first decisions I made when I came into GitHub in this motion was the only existential threat that existed to an independent Github was Amazon entering our market from the production space. At the time, Azure was not the beast that it was, this was 2017 and Google was non-existent in cloud. So the only threat we had was Amazon.
So I decided very clearly that we were going to put the marker down at the deploy stage. We were going to run and jump over CI and PAK and a couple of other things and go right to deploy, and say to Amazon very clearly we know what value we have in the market. We know what we have and what we are, and if you want to have a “conversation” in the market, it’s going to be at this stage. It’s on our terms, not yours. And because of our market position, while it’s weird to say this, we could dictate that to Amazon. If we had built CI and focused on that, we left everything from CI all the way to deploy open as unfederated territory, or unclaimed claimed territory. Once we put the marker down at deploy that everything from code to deploy was basically ours.
John Koetsier: Yeah. Yeah. Super interesting. We’re in interesting times right now, obviously it’s COVID, and that’s accelerated a bunch of trends that are going on, but it’s been said since long before that every company is a software company or a technology company, and that’s more and more true these days, especially as technology is mediating how brands, how companies and people engage, right? Whether that’s mobile or desktop or inside a product, right? Maybe in search or a social platform.
How does faster software development and testing and quicker innovation catapult your business growth in that scenario?
Jason Warner: If you think about what happened in the world recently with software is that you want to, just like with continuous delivery, continuous integration, what you’re actually trying to do is get insights into your software development process faster, in a more automated sort of way. Well, if you could do that at your business level, how many more swings, how much, what’s the percent chance that you would have a better company if you were allowed to experiment more, faster? At the software level, that’s the root of it.
You want to be able to have more swings, more at bats in a game, more likely you’re going to get a hit, more at bats means more chance you’re gonna get a home run. If you have one swing every three years, you are in trouble. If you have three swings every quarter, good chance you’re going to have success.
And if you can get to that point from a software delivery perspective, much better from a business perspective. Now, and there’s also data out there that says, there’s two very interesting statistics. Stripe, the payments company, believe it or not, released some data out there that said that — it’s called the Stripe Developer Coefficient Report — and it said the more times a software development organization releases software a day, the more likely and the more often it’s attributed to a better business outcome.
Now, obviously there’s correlation-is-not-causation type of territory in there, but when you inventory the good businesses, it’s more likely that they have good software practices. And that includes, and primarily is the number of releases you make a day and how fast you remediate faults in productions called “mean time to recovery.”
John Koetsier: Wow, wow. Very, very interesting. Amazing that Stripe did that as well. Let’s shift gears a little bit, still talking about product, and you covered it a little bit when you talked about CI, continuous integration, and choosing not to go there immediately.
But maybe on a broader level, how do you prioritize what to build? I mean, you’ve got, especially in your earlier days as CTO, you had many competing priorities. Everybody is sure that their product, their project is the most critical one that’s going to bring the most return. What made, what were … how did you decide?
Jason Warner: Prioritization is, in my opinion, probably one of the harder things to do at any company in general, but startups, particularly ones with very bright futures, because you could basically go into every direction.
In fact at one point inside GitHub there was a competing thought that we would make it a GitHub for lawyers, and a GitHub for doctors, or the GitHub for… which instead of being primarily software developers, we would take the collaboration aspect and pivot into different industries.
You could imagine the breadth of conversations that we would have had at that point. And so I think you have to basically describe your mission and vision first, and once you actually have your mission/vision and a kind of a long range view, you could work backwards to understand. But if you don’t have those written down anywhere and well understood by the organization, you are basically a soulless organization and you’re chasing dollars effectively. And if you’re chasing dollars, there’s many things that you can do to chase dollars.
So I think you’ve got to write down those first.
Then, I think you have to have a bit of strategy. And if you don’t, then you can still have a long range mission and vision, but basically spaghetti it and get lucky. But if you have strategy, then you actually have experiments, and once you have experiments then you are likely in a spot where you can have a healthy organization.
John Koetsier: Interesting. I kind of want to see GitHub for doctors, honestly, but obviously that was not a good plan.
Jason Warner: I do think that someone’s going to do it. Someone’s going to make a highly collaborative something-something for doctors or lawyers or any of those things. It just shouldn’t come from the company whose primary audience is developers. You have to understand doctors, it’s, you’re selling to the wrong audience.
John Koetsier: Yes.
Jason Warner: It might be the product. It might be an interesting new way of working, but you have to understand the customers. We don’t understand doctors nor do we understand lawyers. I definitely don’t understand lawyers. So we have to focus on who we understand.
John Koetsier: That makes a ton of sense. Now, we had an interesting conversation as we were prepping for this call and we talked about good software and does it win? Does it always win? Those sorts of things. Can you talk about that a little bit? Does good software win?
Jason Warner: I like to think that good software wins. We have lots of examples of bad software winning. Though, I do think that that is …
John Koetsier: And we need to hear those examples, by the way.
Jason Warner: Yeah, yeah. I think though that’s historically true more than it is true these days, although you will see the odd bit of bad software can still win. And I’ll be very specific, like I am not a fan of Oracle as a database. And I think it’s generally thought of poorly when it comes to what it does, but it’s still a massive company and it’s winning.
And then there’s others that look the same way. I have been pretty open about my dislike of JIRA and Salesforce, and I used to work for Salesforce. I do not think that they are customer empathetic products. I think that they are customer lock-in products and I do not believe that they tend to, you know, I know of a lot of folks over at Atlassian, I know that they’re changing on this.
Salesforce is not, in my opinion, they’re still going to an entrenched mode of operations when it comes to these things. They want to keep the people in their ecosystem and they understand the value of their moat and their data. But, I believe that the customer empathetic view, particularly because the bottoms up motion and the bottoms up adoption model is what has won out in the last seven years, I think is really when it became popular. In the last three it’s become really well understood about product-led growth, bottoms up motions. You’re going to see more and more good software winning in that case because people won’t stand for bad software.
John Koetsier: Mm-hmm. Let’s shift gears a little bit and we’ll talk about building engineering teams. It’s funny because in the prep, we were also talking about a percentage of engineers on the team and how so many of the billion dollar, $10 billion startups of the last decade and a half, two decades, were so engineering heavy, you know, 75% engineering, 80% engineering.
If you were going to start a company today as a non-technical founder, how would you build your engineering team? And who would be the first few people to bring on board to help you get product market fit?
Jason Warner: Did you just, you just call me non-technical?
John Koetsier: No! Haha.
Jason Warner: Let’s just be clear about this.
John Koetsier: This is a general ‘you.’
Jason Warner: No, no, no.
John Koetsier: I wouldn’t call the CTO of GitHub non-technical, haha.
Jason Warner: That’s actually fair, most of the people that are inside call me non-technical these days. No, I think that if you’re, the ratio of people in startups at this point, particularly ones if you’re a debt-focused company or focusing on bottoms up growth motion, should be engineers.
And they should be engineers that know how to talk to customers and experiment and go back and forth.
And if you’re a non-technical founder, you should be, you’re the biggest champion of your product with your customers. Finding customers and linking them back to your engineers and those to test those cycles out. Is that a ratio? I don’t know what a ratio might look like, but I would say if you’re predominantly non-engineering, there’s likely you’re doing something incorrectly. I don’t want to be, I don’t want to attribute anything there, but I would say really understand what you’re trying to do.
I mean, I’m a small time investor these days in an angel level, and I want to ask folks, how are you building this? What does your team composition look like? How are you testing with your customers? And if I see too much heavy weightness inside an organization too early, you know they’re focused on the wrong things and there’s a chance to correct that, but predominantly engineers.
John Koetsier: Now are there…
Jason Warner: Design engineers too. Like, I want to be very clear here when I hear product design and engineering, I put all of them into the same category. They’re all engineers, as far as I’m concerned.
John Koetsier: Well, that’s great to hear and also great to put with your earlier comment about engineers who can talk to customers, right? Because as you’re an early stage startup, you don’t have necessarily a specific engineering department led by a VP of technology or something like that. You might be three, four, five, seven people or something like that and everybody wears like five hats. Those are pretty special engineers for that early stage, correct?
Jason Warner: Yeah, not as a rule, but as a general principle, you want to go generalist early because you do wear so many hats. And if you, let’s just assume some numbers out here. Let’s say you’ve got 10 total engineers in your organization. You’re having some success and you’re still growing, the ratio of front end to backend to generalist, you should not be heavyweighted to the backend unless you’re pure infrastructure play. And you also shouldn’t be super overweighted to the front end, unless you’re an API driven JAMstack play, which is showing how to use the broader ecosystem. You’ve got to have a good, healthy mix in the middle. This is kind of like the other signal, would be if you have seven C-level people and three engineers, it’s the same thing as having too many of engineers and get a ratio, unless it’s very, very intentional.
John Koetsier: Interesting, interesting. Now I’m guessing this has changed for you over the years as GitHub has significantly grown, become a major brand and a company that people want to work for, right. But especially for a startup, how do you source candidates and what hacks have you kind of picked up on finding talent that have worked well for you?
Jason Warner: So, the easiest way that I have found to get people is, well, it’s not the easiest way, it’s work. Finding and recruiting is work. It’s a lot of work, but you can use social media to do it. Twitter is a great avenue for following a ton of people to see what’s going on and getting a pulse for who and what.
Obviously if you want to look at, you know, various communities to see who’s building in what community, but that’s going to be a very, very small percentage of total people in the world. In fact, you’re not, you’re going to lose out on somebody who you don’t follow in Minnesota, or Manitoba, or someplace like that, because they’re not on Twitter. They’re not, you don’t happen to find them on their GitHub. So I try to be really explicit out there, you can only hop[e] to open the aperture wide enough that they know about your brand and they can come to you.
In that case there, I’m really explicit, hey, we’re remote friendly, remote first. Come find us, here’s what we’re doing. Here’s our mission and vision. Here’s who we’re serving. Do you want to be part of it? You know, let’s go have that conversation. If you’re really talking about finding candidates, the best way that I have found after you reach a certain size to find candidates — and I do say after a certain size, because once you’re, if you’re under ten people, maybe under five particularly, it’s less about finding people and just really kind of like banding together with who you have around you and getting to that point. But once you get to a certain size, I like to actually use recruiting companies — sorry, consulting companies, agencies. And why I like to use agencies is they happen to have a much wider net. So back in the day, you might use like a Hashrocket or a 37signals when they were, Basecamp when they were 37signals.
There’s one here locally in Columbus, Ohio that I love called Test Double. And whenever I have a new project or I’m advising a startup company, I say, ‘Go call Test Double, just have them come in and audit your systems.’ And what I really want them to do is I want them to take a look at their systems, but I really want them to show them what they need in a candidate. Like we know everybody in this space, we know thousands of people. Let me go find one for you.
John Koetsier: Yeah. Course that’s expensive. I remember spending about $40k to hire a developer about three, four years ago in San Francisco. And six months after, as the sort of contract expired in terms of, you know, that person left because they got a convertible note to start their own business. So, but yeah, that’s the roll of the dice, right?
Jason Warner: One of the things I would say too, is that the world has changed obviously with COVID, but even before that it was going to a more distributed and remote friendly world.
One of the things I appreciate about San Francisco is the access to dollars and VCs and a talent pool that had primarily existed in San Francisco. So that world no longer exists, and right now it’s only about access to money primarily at this point, because the world will become distributed.
I will say that there is a different attitude inside Silicon Valley and outside Silicon Valley, and I talk about it all the time. The loyalty factor inside of Silicon Valley doesn’t exist.
John Koetsier: Yeah.
Jason Warner: It’s a much more mercenary attitude, and I’m not saying good or bad, I’m just saying it is. You’re much more likely to find people who are mission driven outside of San Francisco.
John Koetsier: It’s amazing because I’ve worked with SF companies quite a bit, and I mean, if somebody was in their position for two years, they were kind of a long-timer, right, which is unknown outside there. But that brings up a really good point. We’re hiring remote teams right now. What do you do when you’re hiring remote, are all your hires remote? And does that change how you’re working?
Jason Warner: Not all of our hires are remote. We have offices and we have some what we call centers-of-excellence. And because we’re now Microsoft as well, we’ve taken on some divisions from Microsoft who have their own offices, and we just consumed those as well and brought those into the fold.
But when you’re hiring local people, you almost have to be in the local market — or sorry, remote people, you have to be in their local market. So you’ve got to find a way to advertise there. And then you also have hiring job boards that are remote friendly type of things. Everyone who’s remote maybe before COVID, knew where those were, because the remote jobs were 10% of the total market and you just happen to know. It’s become much more common.
So I had always, when I was looking for remote work before, I would always go to the VCs websites to see what their portfolio companies were, because VCs tend to advertise all the jobs for the portfolio companies. And then I would also go to the remote job boards just to see who’s out there, who’s hiring whatnot. Now on the flip side, when I’m trying to find remote people, I do the similar types of things, but I also pay recruiters. We have recruiters on staff and I pay other recruiters. It’s GitHub, we’re different obviously.
John Koetsier: Yes.
Jason Warner: But we’re at our size and scale where we have a luxury many do not. But I would pay people basically to spread the word that GitHub is hiring remote people, here’s their job board.
John Koetsier: Yeah, yeah. Interesting. So let’s talk about scaling. You started, you were 5 people, 10 people, you’re 30 people, all of a sudden you’re starting to scale a team beyond 30, going up to the hundreds or something like that. How’s that work? How do you build and lead an engineering team that scales? Is there a formula in terms of moving people, in terms of reporting structure, in terms of organizational design?
Jason Warner: There’s no set formula, but you understand the patterns now much better.
And I give a talk on this called “Building Organizations at Scale,” and it’s, the entire concept is two people in a garage all the way to 5,000 people, and the various things that you’re going to see along the way, and what needs to be consistent, and what you need to be okay with changing.
And the things that should remain consistent is you should have a very firm grasp of what your mission and vision is and your long term strategic view of what you want to do is, the customers you’re serving and why you’re serving them and why they would buy your product.
Those are rather consistent things that you should have those things written down.
And those help, because the primary thing that breaks down as you scale is communication. And it’s why am I working on this? Or if you think about it this way, if you’re a random engineer inside a 200 person company, what am I doing today? Am I waking up and what am I working on and why? And I talk about this ‘V’ when you’re scaling organizations and I have to — I’m assuming everyone can see the video here, I actually should have asked that earlier, but everyone see the video. So imagine you’ve got a V inside your organization. I call it the communication V, and at this end of the vertex of the V is a CEO, and this is the CEO as well. This is them saying, ‘We’re going to go work on things. We’re going to work on these sets of priorities and here’s why, and what they’re going to do.’
And assuming that they’re a decent CEO and they can do all those things, this communication V all the way down to the individual engineer or marketer or sales person is what are they doing that day to further this mission and vision and why and how. It’s all those things. And then this back up to the other side of the CEO is status. What is going on? What is the status? What’s off track? Are there red things, you know, red, green, yellow type stuff, all of that. It’s all classic project management, RACI model stuff.
And if your organization has a V, and it’s a narrow V, you’re probably a really good organization. But if you’re, you know, the two lines are at a horizontal and you’re 180 degrees, you’re probably a really, really bad organization.
And most of the problems I see when it comes to scaling, is that the CEO or the executive team cannot list the long term mission and vision and the priorities and why they’re choosing to do that. And it hits the individuals every day in terms of chaos.
John Koetsier: Mm-hmm.
Jason Warner: And I, if I see any pattern emerge most, it’s that right there.
John Koetsier: Yup, yup. Interesting. Excellent. Well, for everybody who’s participating, listening in the audience, thanks for being here, that’s great. We’re going through a few more questions here. I see there’s a few Q & A as well, if you have more, drop it in there, we’re going to have a bit of time at the end also.
We’re going to turn the corner a little bit and talk about leadership, and this is a really interesting time to have to lead an organization. You just talked about CEOs and the C team, and creating vision, mission strategy, all that stuff. Well, now it’s more important than ever, right? How are you managing your team and your product through COVID? Through this pandemic?
Jason Warner: We feel pretty lucky at GitHub in that we had been remote, I will say remote friendly for most of GitHub’s existence. I think at time of COVID, even with the divisions of Microsoft we brought on, we were roughly 65% distributed. I myself had never lived in San Francisco, and I think of that as a feature in an organization that is remote friendly and distributed. So I think that for the most part, we didn’t have to worry as much about that.
We do have to worry, and we saw that two types of people or situations emerged as the most situationally intensive. One was a person who was single and lived on their own, they tended to get very lonely during these times. And the other was a couple or a family that had several kids and was now balancing parent, and teacher, and worker, and all the other things at home, particularly if they were in a high rise apartment or something along those lines where they were very cramped.
You know, I said before something around the customer empathetic product and things of that nature. You know, if you’re not practicing extreme empathy in a situation like today, well, then you’re probably not a decent human being. So, if you’re going to orient towards any one way right now with people, it’s having a strong empathetic nature for what is going on in their life and how they’re dealing with it, and understanding that. So it starts there when you’re leading through crisis, it’s about the person at the other end of a video chat now.
John Koetsier: Yes.
Jason Warner: And the other is extreme clarity. Always over communicate what is happening with the office. When are we coming back? What are we hearing about testing? What are we hearing about our goals? Did we replan? Did we rebase? Did we take down our numbers for sales quarters? Did we not? Did we relax some of the requirements of what we were planning to do? What is our new plan?
If there’s any one thing I’ve learned in distributed organizations, if there’s any ambiguity, someone will enter with a negative version of a story to that situation … ‘They’re not talking about us, therefore, layoffs are coming.’ ‘They’re not saying anything about this product, therefore, they’re going to kill it.’ There’s an element of that.
Over communicate to your team.
John Koetsier: Really interesting, because often, certainly in the past, if people were remote, it was people in very specific defined roles, individual contributors, those sorts of people, right. But you’re the CTO, and you’ve been remote, you’ve never lived in San Francisco you said, that’s really interesting as an organization to support that.
How have you been able to be a leader even before COVID, without being in a specific place? Is that just about the way GitHub was created? Or are you doing something special personally to be able to connect with people, communicate with people and be an influence even when you’re not there personally?
Jason Warner: So I definitely think that there’s an element of the company that needs to support that, you know, and in a Google world in 2017 or so, or 2018, where you have to be in your seat and you can’t have any code that leaves your desktop computer. I don’t know how, if I would ever have been successful, no matter how good I was. It’s just the nature of the organization.
You cannot be so anomalous to an organization that they don’t know what to do with you. It will just reject you.
So that said, I do think that I am anomalous in terms of tech execs, in that being remote requires that you be better at your job. It really does, because you have to learn all about the communication pathways, and you have to over communicate, and you have to ask a lot of questions and get to a lot of answers rather quickly. It’s very, very different. It is strange to say, but it’s very different than being in the office. There’s things that you can just get away with in the office that you cannot remote, you have to be better.
So I think that over the last 10 years, I’ve learned those things and I do believe that I have a decent set of skills to navigate that. That said, again, I don’t think I would’ve ever survived in certain organizations as well.
John Koetsier: It’s interesting that you mentioned that there’s things you could survive in some organizations when you’re there, in person in the office, that you can’t survive remote. And I’m guessing some of those are around, you know, if you don’t know about something, something that’s going on, you’re there, well somebody will just catch you up on it.
But if you’re not there, somebody will assume oh, they don’t know about that because they’re remote, therefore that’s a problem. Therefore, that person is a problem.
Jason Warner: Mediocre organizations exist all over the world. Even highly successful, multi-trillion dollar organizations are mediocre, but they’re mediocre in a way that allows them to be that successful. However, again, if you’re anomalous, if you’re a tall poppy in that, you will get cut off if you’re an underperformer.
The whole point of large organizations is to actually even out the medium. That’s what they want to do. They want more predictability than anything than variance.
John Koetsier: Yes.
Jason Warner: So, with that said, yes, you can attribute a lot of different things. I don’t have any particular one, but you could attribute a lot of different things. But the one thing I will say about distributed versus in office, is that in office, you talk about politics and you can feel them and you can see them when you’re in office. But in a remote, what you’re actually fighting against is humanity’s worst nature, or humans’ worst nature.
So in the office, you can actually play some political games and you can do all that sort of stuff. And it looks and feels weird, and it’s basically, if you’re a bad organization and you’re co-located, you basically feel like middle school.
That’s what happens.
John Koetsier: Hahaha.
Jason Warner: In a bad organization and you’re distributed, what happens is you actually get to like your worst version of you is attributed to the organization. So if you’re a micromanager, you’re a 10X micromanager as a remote person. If you’re a work or a conflict avoider, you’re a 10X work or conflict avoider remote.
So you have to understand and manage that aspect of things, and that’s why it’s different too.
John Koetsier: Wow. Wow. Well, new challenges, new times, I guess. Let’s talk about in terms of leadership, what are the goals you set for yourself and for GitHub, and how do you find success? What are the KPIs that you look at?
Jason Warner: So GitHub measures a couple of things at the highest level, and we have four core metrics that we talk about. And basically I’ll break them down into categories and not talk specifically about them, but one of them is an engagement metric, or two of them are engagement metrics, one category with two metrics are engagement. And the other two are revenue.
And if you think about that, why we’re doing that is because the core of our business is the fact that we are a sustainable business and we return revenue to Microsoft and we’re profitable, and all of those sorts of things that you need to be a healthy business. But the other is that it’s about engagement. And mind you, I’m actually quite happy that we took this approach, if you only have one or two of those, you’re not actually doing justice to your, particularly GitHub, but your business.
Customers are not engaging with you, but you’re making money. Well, doesn’t that tell you something? Or you’re not making money, but people are using you like mad? Well, doesn’t that also tell you something about your business?
So we need both sides of those. So we measure ourselves that way. People have to adopt us, have to enjoy using us, have to really retain those users and have to pass, and we have to make money to use our product.
John Koetsier: Here’s a simple question that might not have a simple answer. What’s your biggest fear as a leader?
Jason Warner: As a leader or specifically? I would say that my biggest fear specifically is that I get hauled before Congress at some point. It’s not a fear per se, it’s just like, oh, that’s like, that’s going, you know, that’s one of those things. I joke with my CSOs, like your job is to keep me out of prison.
John Koetsier: Hahaha.
Jason Warner: So we do all the right things that are happening on that side of the world. That’s not really a fear, but more of an understanding about the complexity of the world these days.
As a leader though, I worried very deeply that you end up getting out of touch. As the organization scales, you don’t have the same connection to an individual engineer that you might, even somebody you’ve had a connection with for five years. You might be out of touch with your product, you don’t use all the nooks and crannies anymore every day. You might get out of touch with the industry.
General out-of-touchness is something that I don’t want to ever have in my career, and if I do, I’d probably go the other way. I’m like, alright cool, I’m out of touch. I don’t understand TikTok anymore. I’m no longer a consumer person, you know, I’m done with this. Thankfully, what I like to do is not something I find that I would probably get out of touch with. But as a leader, I want to make sure I have that connection with people on that side of the organization, all the stuff that’s happening. I don’t want to hear about someone, some organization, or some team, or some division having massive, massive failures across the organization or people or process or whatever, three months after it’s going on.
I kind of want to know that stuff’s happening.
John Koetsier: Yeah. And that’s really, really critical, right? I mean, especially right now there’s a heightened sensitivity of that — the Me Too movement, other movements around racial equality, other equality elements as well — where something can start and fester, and obviously you have a huge issue internally, but you also have a huge issue externally, right? And so you need to hear that pretty quickly. That kind of feeds into our next question, is how do you get unfiltered feedback? How do you measure gaps in your organization?
Jason Warner: So I assume that I will always get filtered feedback at this point. And I think I’m the same person that I was 20 years ago, though I recognize that I’m the CTO of Github now. And it’s different, and while I think of myself as a very approachable person, doesn’t mean I am approachable, so I assume I’m going to get filtered feedback.
So I think it’s work on my part to try to win over trust of the organization continually. I call it “earning the right.” I have to earn the right to do the job every day and if I can earn trust, a set of people will give me unfiltered feedback.
Now, you also have to understand that even getting unfiltered feedback doesn’t necessarily mean that all that feedback is valid either. There’s going to be various opinions on that space and, you know, they might not have the full context, but I very much want the raw data.
John Koetsier: Yeah. That makes sense. Talk about how you maintain communication and institutional memory. What tools do you use for synchronous as well as asynchronous communication?
Jason Warner: Sure. So I generally say that there’s a set of tools you need to work in a distributed company. And I think, so, let me tangent that real quickly and come back. I’d say if you can get really good as a distributed company, or let’s say good as a distributed company, you will be a great co-located company. Because of those things that you can’t get away with as a distributed company you can, over here.
And the things that make you a great distributed company are communication, and how and why and what, and all the answers to those questions that people can do that. So if you ever do go back to the office, you’ll be a great company. Now, most companies, again, are mediocre companies. Most companies are mediocre co-located, which means they’re going to be really bad distributed companies, really bad distributed companies. And we see that now, we see what’s happening when people are forced distributed with COVID, is that a lot of companies are saying, ‘Hey, it’s just not working out.’ It’s like, it’s not distributed, it’s you. It’s literally you, the executive team at this organization, that’s failing. It’s not, there’s other companies that are having this success at massive scale. So, what I say is from a tool perspective, because this is where a lot of people want to ask the first question …
John Koetsier: Yes, of course.
Jason Warner: … when it comes to distributed. As I say, there’s a category of things that you need to exist in your organization for a variety of reasons, and don’t use the wrong tools.
But the set of tools are: email, it should exist. There’s a lot of companies that don’t want to use email these days. You need email, you’ve got to talk to your customers, you’ve got to talk to partners, you’ve got to have things that long live, you know, talk to your lawyers or whatever it is. Email needs to exist.
Institutional memory is the singular most important one, I call it “async communication.” This is primarily why GitHub exists in the world. So basically you want to have something that persists for contextual reasons about either decisions or blah, blah, blah. You can go back and read it later. GitHub issues, GitHub repos, GitHub PR, all of those things are institutional memory. Codify something there.
Then you need to have video in a distributed world. Obviously there’s just things that you can’t do over the phone or can’t do in text, that video is a higher fidelity product for that. In fact, one of the things I like to tell people about video is it’s so important that if I can only pick two, I pick institutional memory and I pick video, email’s third.
And in video, one of the things that I very much encourage people to do is practice with video, because in a room when you’re in an office with people, certain things just come through, they do. And I’ve had to practice video conversations for years to get good at them, and I am overly expressive. This is not how I am in a normal world. I don’t use my hands this much, I don’t use my facial expressions this much, but I’m trying to express a lot of emotional state out visibly so that people can react to that. I have been told that I am not approachable on video, so I had to work at that.
And then the third is synchronous communication, like the Slacks, the Teams, the IRCs of the world. And the one anti-pattern I see when people are going distributed, is they abuse the synchronous ones, the Slacks, the whatevers of the world. And they say, ‘Hey, that’s our institutional memory.’ Literally the worst decision you could possibly make. Back scroll three days in some active channel in Slack to go find some conversation and you will literally never use that product again in your life.
John Koetsier: Very, very, very interesting. I never thought about training myself to use video communication, but I could see where it makes a ton of sense. Okay. We’re finally there. I’m going to go to some of the questions that we’ve got from the audience right here. And here is one from Vikas Kowane, says “I’m building a startup with an aim to get acquired. What essential tasks should I do in terms of tactics, strategy, etc., to get my startup acquired?”
Jason Warner: I think that if you’re targeting a specific acquirer, obviously the number of things that you’re going to do go down from that point. But if you’re targeting just generally to get acquired, you have to understand why someone would want to acquire you. And most of those, the reasons why someone would ever acquire somebody, are the fact that they can’t build themselves, they don’t understand the domain well enough, or it’s a market accelerant. And you have to understand what you are in that case.
Once you have the answer to that question, your strategy is probably self-evident about what you’re going to do. If you’re a differentiator and they can’t build you, then you let them FOMO. You give them FOMO, ‘you can’t do what we do, let’s show you how,’ and then they’ll just acquire you. And all the way to the other end of the spectrum if you’re a market accelerator, show that market accelerate.
John Koetsier: Makes sense. Here’s another one from Shadi Shehadeh, “Thanks for the insights. Similar to software release cycle, any recommendations on efficient ways to make business experiments to test product market fit?”
Jason Warner: I think it’s similar to the software development life cycles. You want to have as tight, as short a feedback loop as possible to your customers, to your experiments, you want to be running multiple experiments and seeing what they’re doing. You should have some opinion as well, though, about what is happening in your product.
And if you’re trying to test your way to a good product, you likely will start losing your own opinion about why you started the company in the first place. That also tends to work better by the way, for consumer products like high engagement consumer products where you don’t actually have an opinion, you just want to have a social app and you want to have high engagement, that will help. High experimentation, lots of experiments, like hundreds of experiments. There’s a famous story about Uber, how they, I think they ran thousands of experiments in their mobile app at any one time, just to get feedback on it.
John Koetsier: Yeah. I guess you need super high volume for that, but wow, thousands.
Jason Warner: Thousands. Yeah, they obviously did with their reach, but having a customer set that you can experiment with multiples or even tens of experiments behind feature flags.
John Koetsier: Yeah. Yeah, exactly. Here’s a third question, from Aaron Jones, he says “How much should personality fit factor in when choosing engineers?”
Jason Warner: I don’t think I understand fully the question, but I’ll answer what I understand and I’ll restate it, which is — I don’t want to say culture fit because I’m not a big fan of the word — but what you’re saying is, probably early to mid to late stage, what kind of a person do you want to hire? And I will…
John Koetsier: Yeah I th…
Jason Warner: Oh sorry.
John Koetsier: That’s a totally valid way of going with it. The other way potentially is, does my personality fit with this engineer I’m considering hiring? Can I work with this person?
Jason Warner: So, what I tend to ask people to think about there is, does this person have a skillset? Are they additive to the company? Will the company be a better place? And it’s less about personality. You might actually have conflict with somebody from a personality perspective, but that’s not a bad thing. You might just have to work out how you have conflict.
And a question I ask, I always ask every boss, if I ever have a boss again, is going to be, ‘How are we going to fight?’ I know me. I know me really well, but I want to know what their failure modes are.
So I think that you should take into consideration it should be if you’re too overlappy then you likely are probably groupthinking. If you’re too far away, you’re going to have too much conflict and some of that won’t be able to resolve. Find some sort of balance, but have the conversation with them too, about it.
John Koetsier: I love that. I love that. How are we going to fight? What’s the worst thing that can happen between you and me and how will each of us react in that scenario?
And that’s great because then you’ve got kind of a safety net, you know where it’ll go when it’s tough, and you understand that, you’re prepared for that and you’re good to go. Here is a question that is more on the macro business level and it’s from Shiva Wadhwa, and he says, “Do you think the boom in tech will vanish once COVID is gone?”
Jason Warner: No, I don’t. Obviously that feels like a biased, maybe self-serving answer, but I just don’t.
Software runs the world. Open source runs software. Developers are everywhere.
They’re effectively the new, you know, developers themselves are pretty much the new oil, it feels like. If you could have all the developers in the world you’re winning. You know, I don’t think it’s going to happen. I think that obviously you’ll see some corrections in the stock market at some point when the other portions of the economy get healthier, but I don’t think the boom in software, if anything, I think that it’s showed that software is the future.
John Koetsier: Yeah, yeah. And everything that I’ve been seeing about the data coming out is that basically COVID has accelerated existing trends four to six years in terms of e-commerce, m-commerce, those sorts of things. And they’re probably going to stick with us and people are making long term decisions right now about moving remote, you know, moving to Portland from San Francisco, or Columbus, Ohio, or wherever they might be, right.
Here’s another question from Saiad Ali, “How essential are code reviews and how do you avoid making them a major time sink as teams grow?”
Jason Warner: I like code reviews obviously, I think that they pay off. Any conversation about your code is a good one. I think that you should automate the mundane parts away though, like, hey, this doesn’t have tests, well you should have bots that do that. This doesn’t have, this is stylistically wrong bots, you should have bots that do that sort of stuff. You want to be talking about like the stuff that you don’t see yourself, like ‘This will break in production. This is not serving. I think you missed this piece here,’ that sort of thing. Those reviews are necessary, in my opinion, but you should be able to make them pretty lightweight. And in fact, like you could batch them. If you have an hour a day where you just do exclusively code reviews and you go through them that way.
John Koetsier: Interesting.
Jason Warner: But I think you have to be able to do them.
John Koetsier: Yeah, yeah. Here’s a question from Gilbert Mbeh, “Hi, we have a startup, AbegYa, that’s beginning to get traction in Africa. Now we have a cool feature that could be added to our platform, but we think it could do well as a standalone product or company as well. We are eight months old since our launch. What do you think would be a smart move for us?”
Jason Warner: Without knowing more than that, I would say that you basically want to run two experiments. You want to run the experiment of that feature or thing, could it be a standalone product, and verify it. Let’s say you’ve got a thesis, well how fast could you prove or disprove either one of those things? And the faster you get to that, the better you will know. But you basically want to answer the questions more than anything.
John Koetsier: And I guess what’s your burn rate because that speed will play into will you have cash left at the end of that experiment?
Jason Warner: And I will say too, the fastest possible way with the lightest touch to validate that. So I see that people say, hey, I want to validate that this product should exist in the market. So they go and build the full product. You don’t need to do that. You can experiment with the Figmas or Envisions of the world to a point where like, hey, will you be willing to pay us money for this product? And then you can show, then you can do a very lightweight proof of concept using a whole bunch of stuff behind the scenes that you don’t have to plumb. Like find the fastest path to answering the question, don’t find the fullest path to answering that question.
John Koetsier: And some tech companies, including startups, have been known to sell a product or a feature that they don’t have. And if they sell it, well, then we’ll build it. There’s some danger to that, but it has happened.
Jason Warner: So it’s important not to take the money. It’s important that you get the answer to ‘Would you be willing to pay us money?’
John Koetsier: Excellent. Here’s a question from Mark Trevitt, he says, “What changes do you think need to happen in management and C-suite of companies to become more true technology or software companies?”
Jason Warner: Oh, please, this is a simple answer and I’ve been thinking about this one for a long time.
We need more engineering leaders that run companies. And if anyone watched the, I forget what they’re congressional hearings or whatever it was a couple of weeks ago, where all four CEOs of major tech companies were interviewed, it was embarrassing.
So we need more engineers that run companies, and we need more engineers who understand technology and government. And once we do that, our society will get better. But even the companies themselves, all those product companies are “engineers,” but they’re actually product folks. We need people who have run up and run engineering organizations who run massive multi-thousand personel organizations, because that’s actually where you cut your teeth, you don’t know how to do that. I think that’s the next trend.
For the early 90’s and early 2000’s was marketing and sales people who were put in charge of companies, and I think that mattered to them because distribution mattered. Now it’s products. Products matter and attracting people to your organization matter. The real war that’s going to happen in the next 10 to 15 years is a talent war, and that’s where you’ve got to fight. So you need more empathetic engineering leaders who can articulate and stand up on stage and paint a compelling vision, and people can get behind. Those are the people that are going to follow.
John Koetsier: Very, very interesting. Here’s one from an anonymous attendee, says “At what level are OKRs used at GitHub, team, personal, etc. and how has that changed over the years?”
Jason Warner: So I would say that OKR, we’ve experimented with a lot of different modes for this one, and I would say that we don’t have a great one still. So let me tell you what we have and then let me tell you what I think is my ideal state. But what we have is effectively at the company level down to the department level, and then maybe, maybe there’s one level below them that have their own OKRs. And I like that approach best.
I’ve seen it at Salesforce where you had to go all the way from the top to an individual random engineer who had to have their own OKRs. That is [a] disaster. Do not do that.
John Koetsier: It’s also a lot of work.
Jason Warner: It’s a lot of work and it’s pointless. And so what I like, and I don’t, I’m only asked to make a boulder statement — I actually don’t like OKRs because people get too definitional. Is this an O? Is this a KR? I don’t like the way you worded that. Is that measurable in this way? I don’t like OKRs.
What I like is a one page doc that says here’s what we’re doing in this time period. Here’s why we’re doing it. Here’s how we’re going to measure what that looks like. Very straightforward, very simple to consume metrics. Here’s what we think is going to stop us, and here’s what we’re going to do to avoid those things. I like that one pattern to emerge for the organizations. It’s a very simple sort of way of getting about it, but it’s much easier for people to consume.
John Koetsier: I love, love, love that. It sounds like more of an Amazon way of operating. And I have been in a couple of startups where OKRs have been in vogue, seriously in vogue, for about two quarters.
Jason Warner: So what I described is actually closer to the Salesforce one, V2MOM, or the Amazon — you’re right about that, the Amazon one. So Salesforce has one they call V2MOM: Vision, Values, Methods, Obstacles, and Measures. And it looks like one Google doc with some words in it. And Amazon’s is similar, the one-pager, two-pager, three-pager. I, unfortunately, am the one who brought OKRs to GitHub and I think that was one of my biggest mistakes ever. I think we should have gone more towards the V2MOM-ish approach or the Amazon approach.
John Koetsier: Well, you know you have some say in that, so potentially you could make that change. I don’t know, but that’s a great segue because we’ve got to come to a bit of a close here, sort of last question, then I’m going to ask Lloyed to come in and kind of close us off as well. And the last question is, you know, “What do you wish you had done more of or differently? And what do you wish you had done less of?”
Jason Warner: In the company or career? I guess I could answer it anyway.
John Koetsier: Yeah, you get to decide.
Jason Warner: All right. So three things I wish I did more of. So I think that as a person I have become more confident in the past five or so years, in my own abilities. One of the biggest things that I think I failed in my career was I hate being right in retrospect. And I was very often right with a long term strategic thing that was about to happen, but I wasn’t able to be convincing in the moment, so we’d go down to go and go do that, but I was right five years later. And that feels terrible, terrible.
But it was a weird confidence boost to be like, okay, all of those things, I was right on those. I need to be more confident and be able to bring that out and more convincing too. Practice being more convincing, more articulate, write my thoughts down more. So I think the mistake I made was not doing that early enough, but I’m glad I was able to do it now and have that skill now. A couple of other things I, again, I think it all stems from maybe lack of confidence or conviction in my early days, but I wish I was more forceful to not acquiesce to a bad idea just because someone in authority said something you gotta do. But I don’t mean to be like a jerk and rail against them, I mean, you just have to be like, ‘No, I think that’s a really poor idea and here’s why,’ and be able to articulate it.
Some things I wish I did more of then too, obviously, is I probably wish I wrote more early. I write a lot now and I write a lot for the organization, but I wish I wrote more instead of trying to talk it through. I wish I was able to talk it through, then write it down and ratify it. And then maybe I also wish I took more cold emails, tried to reach out to people more often. Now I have the CTO at GitHub title, I’m the person responsible for selling GitHub to Microsoft. People pick up the phone when I call. I wish I did that 10 years ago. I probably would be in a very different position in my career now than I am, and you know, that would have been a fun thing to see. Learn from that, people respond to cold emails, not everybody, but they do and they open up opportunities.
John Koetsier: Mm-hmm. Very, very interesting. Excellent. Well, this has been a ton of fun. I hope everybody has gotten a great deal of value out of it. Lloyed, love you to come back in and just sum it all up for us.
Lloyed Lobo: I learned a ton because I’m a software engineer and a founder, and this was all a great learning for me. So thank you so much, Jason, thank you for taking the time with us today. And thank you, John, as always for teasing out the best insights from our speakers. Thanks everyone for joining us.
Jason Warner: Now let me put one more thing here for folks who are still listening, but I’m doing an AMA, an ‘ask me anything’ on my GitHub page, so if you just go to jasoncwarner, that’s who I am on GitHub. You can find me on Twitter, same handle. There’s a repo called AMA and you can just make questions there. There’s an anonymous form if you want me to go through, and I’m literally just going through and answering questions for people who put them in there if I didn’t get to anything here.
John Koetsier: Wonderful. Thank you so much.
Well, this has been a very special edition of TechFirst with John Koetsier. Thank you so much for being along with us on the ride. As always, there will be a full transcript available at johnkoetsier.com shortly, probably within a few days, maybe a week or so.
And there may actually be a story on Forbes about this one. I think there is enough in here to actually write about on Forbes as well. Have a great day! If you like the podcast, rate it, review it, share it, do all those wonderful good things, and thank you so much.