GitHub CTO Jason Warner Got His First Job At IBM Because He Could Lift Heavy Things

The chief technology officer of GitHub didn’t have a computer in high school. He got his first job in the tech industry because of a tip his auto shop teacher gave him a tip about a role at IBM. And he got that job mainly because he could carry around heavy things.

GitHub, of course, is the hub of the technology industry.

It’s where 50 million programmers gather, create code, and share it to the world. Three million organizations use the platform to develop more than 100 million software projects there, including NASA’s team writing code for the Mars Rovers. A couple years ago, Microsoft bought GitHub for $7.5 billion. In other words, it’s the place where the most technical people on the planet connect. And it’s not the place where you’d think find someone who didn’t have a computer until college, who didn’t hear about computer science until his boss at IBM told him about it, and who took a shop class in high school. Much less the place where that person is the chief technology officer.

I recently chatted with Jason Warner, CTO at GitHub, for a webinar with Traction Conference and published the interview in my TechFirst podcast.

Warner, who eventually annexed a CompSci degree from Penn State (plus a Masters in Computer Science from Rensselaer Polytechnic) did end up taking a developer position with IBM. He then bounced around a bit, moved to Linux developer Canonical, worked at the cloud-based mobile development platform Heroku, and is now in his third year at GitHub.

In our chat, he talked about how technology entrepreneurs can build 10X products: products with outsized, exponential growth.

Here’s a condensed version of our chat:

Koetsier: 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?

Warner: 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 top-down sales motions. And top-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 bottom-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.

Koetsier: 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.

Warner: 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 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 meant everything from code to deploy was basically ours.

MORE FROM FORBESWe’ve Spent 1.6 Trillion Hours On Mobile So Far In 2020By John Koetsier

Koetsier: What’s the value of speed to deployment?

Warner: You want to be able to have more swings, more at bats in a game, [which makes it] 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, [that’s] much better from a business perspective. Stripe, the payments company … released some data out there that said that — it’s called the Stripe Developer Coefficient Report — 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.

Koetsier: How do you prioritize what to build?

Warner: Prioritization is, in my opinion, probably one of the harder things to do at any company in general.

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.

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.

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.

MORE FROM FORBESHow Retailers Use AI To Predict When You’ll BuyBy John Koetsier

Koetsier: Does good software win? Does better software always win?

Warner: I like to think that good software wins. [But] we have lots of examples of bad software winning. 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 … 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 bottom-up motion and the bottom-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, bottom-up motions. You’re going to see more and more good software winning in that case because people won’t stand for bad software.

Koetsier: Before you build software or a startup, you have to built a team. How do you start that effectively?

Warner: 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 engineer [heavy]. And they should be engineers that know how to talk to customers and experiment.

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.

Koetsier: What about remote versus colocated teams?

Warner: 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.

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 … 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.

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.

Koetsier: Thank you for your time!

Get a full transcript of our conversation here.