The Changelog: Software Development, Open Source - Leading GitHub to a $7.5 billion acquisition (Interview)

Episode Date: May 18, 2020

Jason Warner (CTO at GitHub) joined the show to talk with us about the backstory of how he helped to lead GitHub to a $7.5 billion acquisition by Microsoft. Specifically how they trusted their gut not just the data, and how they understood the value they were bringing to market. We also talk about Jason's focus on "horizon 3" for GitHub, and his thoughts on remote work and how they're leading GitHub engineering today.

GitHub did not build CI for a long time. I had that decision at one point to make while I was pre-acquisitioning GitHub as well. And a lot of people wanted us to build CI. A lot of people did. But we looked at it and we said, we can't afford to build CI because it is such a cog's sock for us. But we could change the notion. We could skip it, skip the build step and go right to deploying workflows and give them a pseudo ability to do CI. It won't be the full solution, but it'll be enough where the really, really forward looking people can understand what we're hat tipping that we would have said build CI, and we would have had to figure out a way to make it work. But we had to think a little bit differently because we – and that's where we trusted our gut, saying like, hey, we're going to skip it because we think we understand why people really are asking for CI and go to the next thing or the thing after that and then build backwards.

So was that a wise maneuver? Yes. Got us acquired. Being with for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers.

Head to Linode.com slash Changelog. This episode is brought to you by DigitalOcean. DigitalOcean's developer cloud makes it simple to launch in the cloud and scale up as you grow. They have an intuitive control panel, predictable pricing, team accounts, worldwide availability with a 99.99 uptime SLA, and 24-7, 365 world-class support to back that up. DigitalOcean makes it easy to deploy, scale, store, secure, and monitor your cloud environments. Head to do.co. changelog to get started with a 100 credit again do.co slash changelog welcome back everyone this is the changelog a podcast featuring the hackers the leaders and the innovators in the world of software i'm adam

stachowiak editor-in--Chief here at Changelog. On today's show, we're joined by Jason Warner, CTO of GitHub. Of course, as the title suggests, Jason shared some very interesting details with us. He shared the backstory of how he helped to lead GitHub to a $7.5 billion acquisition by Microsoft. We talked specifically about how they trusted their gut, not just the data, and how they understood the value they were bringing to the market. We also talked about Jason's focus on Horizon 3 for GitHub and what that means, his thoughts on remote work, and how they're leading GitHub engineering today. So we have GitHub CTO Jason Warner here. Jason, thanks for coming on the show.

Thanks for having me, guys. So at the risk of sounding like the Bobs from Office Space, we're going to say, what is it that you do here exactly? CTO is a big role, but what's it look like day-to-day or tactically on the boots on the ground? What do you do? Yeah, so this is going to be a little bit of a short and then a long version

of an answer. Okay. So the short version is what I do day in day out is I look at what doesn't, but we think should exist in software. Generally speaking, looking at a couple of years, trying to figure out what things might need to exist, where software itself is going, where developers want to take it and trying to be out ahead of those trends. Though, that is a new role for me. I transitioned to the CTO role officially about three months ago. Before that, what I did at GitHub was I ran product engineering, security, support, infrastructure, and data. So while I was ultimately the person in charge

of all of technology still in that role, we have transitioned and split the two duties so that I now exclusively look at Horizon 3, is what we call that in the office of the CTO, type things, and we have somebody else who runs day-to-day product or day-to-day engineering or day-to-day security. And I have transitioned those duties to those folks, and now I'm looking exclusively at

Horizon 3. I would love to ask you what Horizon 3 looks like, but I'm not sure if you want to talk about that or if you know exactly what it looks like. There's a lot of unknown. The way I look at this, if you think about Horizon 1, 2, and 3. What's Horizon 1? Horizon 1 should be the next year. You've pretty much already done the customer development.

You already understand where it's going. I think of it actually as hit rates. Think about it this way. If your batting percentage in Horizon 1 is anything less than 100%, you probably have not done your job well. You've not nailed down the features. You've not nailed down the product launches nor the customer development. Horizon 2 is probably pretty well known, but not maybe fully baked yet. But let's say it should be in the range of 75% to 85% in terms of how well you're doing. But that changes dramatically to Horizon 3. We should be exploring things that are destined

to fail a very high percentage. So we should be right maybe 20 to 25% of the time. And only that many projects turn into future-oriented product. But it remains to be seen what exactly will come out of that. Though if you think about what GitHub has released in the last two years, you get an idea of where we're going to go and look at. So the best example about this is GitHub Actions, which basically came out of the same sort of thinking. What should exist? What doesn't exist? Where do we want to be in three to five years?

What do we need to do now? And what do we need to build now to get to that point? Yeah. What were some things that were Horizon 3-ish, maybe even Horizon 2 that you've put out that hadn't had the same success as GitHub Actions? We started on something right after I joined GitHub called security alerts.

And it was the idea that we're going to need to bring security to GitHub and security manifestations and just a stronger idea of security around the code. And the first foray into that with security alerts was met with mixed success. But as we kind of pushed through it and got further down that path, and then eventually post-acquisition with Microsoft, we ended up buying a company called Semmel out of the UK and combining it with that, we've had a lot more success. Though that was definitely more Horizon 2. It was just pretty well understood that we needed to do something.

We weren't quite sure exactly what. The first entry into it was met with a little bit of lukewarmness. But once we iterated at it and moved it further down the path, a lot more luck with it. Is this your first time being in a position to be a Horizon 3 focuser? Exclusively, yes. So my natural inclination is to think about the future of things. When I think about approaching a problem or approaching a job or even a company, I always think, where should we be in five years?

What are five or six different paths that this company could take? What would the market need to be for us to go X, Y, or Z? Why are those things that we should invest in? So you're one of those people that when somebody says, hey, where are you going to be at in five years? You like that question. Because not everybody does, right? Right.

I do. Although it is harder when you think about it personally as opposed to professionally. It's easy with companies or products, but personally it's also weirdly emotional. But you could be distanced from it with a company or a product. Do you do this with other people's products? Do you look at something like Tesla or you look at Amazon? You're like, you know what they need to be in five years? And you imagine what their product line might look like. I literally have notebooks for different

companies. Do you really? I do. So way back in the day, I used to joke about this. I had a Yahoo notebook. I had a Google notebook. I had a Google notebook. I had a Salesforce one while I was there, and then I gave up on that one after I left. I had a Microsoft one before I joined. I still keep a Microsoft one. I do think about other companies a lot. The ones I really think about, though, are kind of like the mid to late stage startup companies. Such as?

A good one would be Hashi at the moment hashy's in our space kind of equivalent to us i've got a lot of friends over there i know their product well but what might they want to be doing in the future what's the vision look like where could it be i do a lot because one it's fun it's kind of like one of those things that i like to do yeah um the other is i try to imagine myself if i'm the ceo coming into company now, what would I do and why? And the why part is really important because that helps you get better at honing the gut instinct or some of the data amalgamation. If you can articulate the why, I think you can do a stellar job at that. And so in some ways, it's my version of practicing for a future role.

Well, you seem well-positioned. That sounds like a super fun job, by the way. I mean, you have to feel pretty happy with where you are in terms of thinking about this thing that you do for funsies is like, I'm going to gather where these companies should go the next five years. Now you get to do it for GitHub. I mean, it's got to be pretty rewarding and interesting work.

Yeah. One, it's fascinating. One, it's fascinating. Two, it's fun. And three, as a person who's been in the space for quite some time, before GitHub was Heroku, before Heroku was Canonical, the people make Ubuntu Linux, I basically thought about developers for the past decade, platforms and clouds,

and it all comes together at GitHub because GitHub is the center of the software development universe. It's kind of a perfect match. You're well positioned, so you don't have to share with us a future roadmap or anything. Or do if you want to. Yeah, I mean, whatever you want to say, of course. But Horizon 3, maybe just solve, not the solutions, but what are some of the problems that you see? What's missing in developer world?

Yeah, so that's the part to me that's easy to share because there's nothing proprietary. It's just obvious to me, and I think others who think about software, what GitHub should naturally do. It's just how we do it will influence what it ends up looking like, and that's where the competitiveness might come in. But if you think about the software development lifecycle, and we boil it down largely from all these different discrete verticals to just four main steps which is idea code build and ship that is the software on the life cycle before it gets to production and then it goes into production and then you've got operate and you've got you know bug and error track and all that sort of stuff well github very clearly went from code to build to ship and well what do you do then? Well, then you go to idea or to the land of production. It's not rocket science where we would probably go,

but how we approach those problems is how we're going to differentiate ourselves. And how do you vet out then in your own mind or with your team these ideas of the how? Like how are we going to implement this on Horizon 3? How do you judge an idea? We're going to talk about some of the stuff you've learned as your role scaling engineering teams and building culture and all those things. We're going to get into that. One of the things you mention often is this idea of gathering all the data but then still trusting your gut.

I wonder if that plays into this style of decision making. What data can you get on solutions that don't exist yet? The most important one, if you think about how you might make a decision in this area, my lens is pretty exclusively the largest lens I'm going to use besides the micro lenses is going to be, does this effectively change all of software at once? Because of GitHub's market position and with all, you know, we have 40 plus million registered developers on GitHub, 100 million plus repositories and all that sort of thing. Like basically all the software lives on GitHub. So we are in a position that if we do something, it should be meaningful to nearly everybody in the world who cares about software. So if it comes down to that it's a feature or it's a nice to have or it's a shiny button type

of scenario, that is not what we're after. We're after something that completely changes it again, either takes software from level A and levels it up entirely to level B. That's what we want to do. So when ideas come to us, is this basically worth our time to go look at this is going to be, will this change everybody at once? Will this change the industry? Will this make something X percent easier or X times easier, which is actually what we're after or X times better, you know, that sort of scenario. That's how we have to think. And the truth is that most things that people come up with are friction reduction ideas. This thing is hard, or this is hard, or this is awkward. But that's not what we're after.

We're not after minor percentage change friction reductions. We want to change everything. The minor change friction reductions are incredibly important to GitHub, but that's what Horizon 1 and 2 are for. What's a good example, then, if you can hypothesize what a Horizon 3 might be? Is there any, like, fictitious,

you know... Well, unfortunately, all of them are stuff that we've already that I have in my head I've thought about, but just imagine this scenario. What if, because we have a code, we have the open source code, we have your code, we have that. What if we were to know something

about what was going on in production and an error happened and we happened to know who checked that code in and they happened to already have all the test suites available to it? Well, what if we could change the way that people had pager rotations, as an example? Like large teams have just large scale pager rotations, but we happen to know who checked in which code and what was failing. What if we could isolate that and

page that person specifically, but say, hey, we had to quarantine your code because it was released to production. And we paged you because you need to go figure out what's going on with this. But it's safe for now because we had all your tests, we had your staging environment, we had your production environment, we know what your blue-green deploys look like, so we just kind of quarantined your section of code right now. Can you go take a look at this and figure out what's going on and let us know when it's ready to turn it back on?

That'd be cool. To distill down what you're saying about your idea judgment, and correct me if I'm wrong, but it sounds like what you do is you come up with an idea. Maybe you have a notebook of ideas or you guys get in a room and talk. And then you ask yourself, is this idea big enough? And if it's not big enough, then it's like, well, it's not big enough. You're just going for the big ideas. In many ways, some of the stuff that we're looking at should be a fundable company that some VC somewhere says, this thing is probably a $10 billion company on its own

if it could solve that problem. On its own, yeah. That's the kind of scale you're thinking about here. Yeah. That's a good problem to have and solve. Fun to solve, for sure. Because, I mean, who wouldn't want to have a juggernaut like GitHub is and create sub $10 billion companies within it?

That's a fun job to have. That's what I was saying. You know what I mean? Are you hiring? I'm just kidding. Are you hiring? For his own position. Can I have your job?

Hey, we have an office at the CTO and it's not hard to recruit for that office, let's just say. I bet. That's interesting stuff. You've been at GitHub a long time to get to where you are, and you've been doing a lot of building to get to what now you can look forward and try to build these huge go-big-or-go-home sub-companies on Horizon 3. You've shared a lot of the things you've learned over the years

on how to scale an engineering team or teams while a company is scaling. GitHub has gone very large in a small amount of time, what, 10 years, something along that order of magnitude. Hypergrowth is what people use to describe this thing. I'm not really sure exactly what constitutes hypergrowth. Just like I'm not sure what a microservice is, how small does it have to be? How fast does your growth have to be to be in hypergrowth?

But we've been along for the ride. This podcast has existed pretty much the same time that GitHub has existed. We've watched GitHub go from just a few developers up to where it is today. Our friends, essentially. And very happy to just kind of ride the open source wave

alongside y'all. Curious what's your high level or even tactical advice to people who are maybe in a small business technology company that has a trajectory similar to GitHub's and they're like, wow, I'm overwhelmed by all these customers, all these features, I've got to hire real fast, we're overwhelmed, maybe the website's down.

In that milieu, how do you succeed? What do you tell people? Well, first, congratulations. If you're in that sort of scenario, just enjoy it. Hold on for dear life. Yeah. And also, just expect that you're going to get lots of inbound from VCs. But what I talk about quite a bit to early startup founders or people who are going

through this is maybe a set of things that I try to impart with them. One is things are going to happen to you and your goal is to make it so that things don't happen to you or your company. You need to get in front of a lot of stuff. Try to get as explicit about as many things as possible as opposed to implicitly your culture is formed or implicitly you've got processes evolved or people just happen to now start reporting into you and your product goes a certain way. Explicitness in your company and life and day-to-day should take hold. That's hard though because so many things are going to be on fire. And that's the other thing I talked about is many things in a startup company are always going to feel subpar. That's okay to a degree, particularly if you understand that you're explicitly letting

something go a certain way or not be fixed to the degree that you might expect it to be fixed at some point for a lot of different reasons. But again, if things are on fire just because they happen to be on fire and they just implicitly start to become more fiery, then you're probably in a bad spot. So I talk a lot about explicitness versus implicitness in decision making and really ruthlessly make decisions as a startup founder or startup executive team. The other thing I talk a lot about is how you organize yourself for scale from two people in a garage to 5,000 people and the various things that are going to happen in between here and there and their when and how and what maybe to do. And they're going to be vastly

different and you can't get too specific about any one situation until you know some of the context. But just that you're going to go through all these different phases and something that got you from two people in the garage to 50 people and $50 million in funding and a lot of success might actually hold you back tomorrow, as soon as you've left the door.

I mean, you can't become emotionally beholden to any one thing. Good example of this is GitHub in the early days talked very much about its flat structure. Talked about it very openly and how it was one of the keys to their success. Everyone's an engineer and everyone kind of makes their own decisions on what they're going to work on, right?

And if you look through the history, I think that did indeed help GitHub in its early days. And then it was the very, very thing that held it back for a three to four year period from releasing anything meaningful. But it didn't mean it didn't serve its purpose. What happened is it became the organization and the company itself became beholden to the idea and they held onto it for too long. I can see that. We talk about a lot of that stuff. It's hard to let go of the thing that brought you to where you are, right? Or the people.

Right. If those people won't let go of the idea. Yep. Perhaps, yeah. I think I talk about that. But one of the main things I do talk about is what I call, it's the most critical thing, I think, for getting, nailing startups and growth is communication. And communicating out what maybe a long-term vision and mission for the company is, what's important right now and why,

what our principles are, what our values are, how we're going to measure success, and then how you're going to organize yourself to do those sorts of things. That itself is kind of the art of companies in general and scaling organizations. And I've learned that through engineering because engineering is usually one of the first places you have to really, really, really meticulously organize yourself. Otherwise, you can't get anything done. And companies themselves have that same struggle. You just don't know it nearly as well. You can't feel it as ethereally as you can in engineering. So it seems like most companies start off maybe with a vision or maybe with a mission,

but often not both or not much clarity. Like there's a lot of like just iteration and testing, you know, like does this, is this a thing the market will, is there, you know, trying to find product market fit and it's just like we're trying to figure out something that's going to be a business or that people are going to want to buy or whatever it happens to be. Are you saying that you should have this mission and vision like day one? Are you saying like once you find product market fit,

like you need to figure this out eventually? Again, the timing on this is interesting because sometimes like the advice is just head west. You know, like, well, you got to just start building the thing but then you can also just get lost you know in the middle of the midwest and never make it over to the gold rush it's funny that you say just head west because that's actually one of the frames i use which is if you're standing on the east coast and you basically say we know we need to end up in california in two years we could plan it out meticulously or we can just

start walking. And I do think that most people should just start walking and every day ruthlessly start to iterate like, okay, let's reevaluate. Do we want to go down to Austin or do we want to go up and see Wyoming? Well, it's two very divergent paths now. They both are still generally heading west, but are they going to change us? Should they change us? Are we okay with that? I guess my general view on mission and vision and iteration towards product market fit is basically you end up with two types of companies. A company where there's a slam dunk product market fit, GitHub falls into that category. They didn't really have to test their way to anything. So there's a whole bunch of cheat codes that come with that path. And you just don't have to worry about a certain set of things. In that that scenario mission and vision and talking about developers in the

time horizons are so crucial to keep everyone focused on that other side on the product market fit side if you're particularly if you're testing your way to product market fit you really should understand why the company took money in the first place, or if it hasn't taken money yet, why the founders formed something. So if you've got a notion that there's a customer or a problem that to be solved, you know, or a friction that you're going to remove or something, you have to really understand that and why you're passionate enough about it

to spend some time away from your family to do that. when in doubt, iterate, right? What other twist do you have? When in, yes. Right. I mean, if you don't iterate, you're just going to stand still.

Yep. And that's going back to the go west. That's just the same, just one foot in front of the other. At the same time, you're not going to have to deal with the hyper growth problem because you haven't found the product market fit yet, so you're not there yet. The things that you're establishing, like how to scale engineering teams

or small businesses, startups into large ones, it's at a time when the growth has started to hit and that growth starts to hit once you've plotted a bit of a course and you've figured out which way is good. I recommend strongly that founders keep everything as lean as possible until you have what you think is product market fit. Because I think magic can happen with five to ten developers in a room who ruthlessly prioritize and iterate and really understand their customers and talk to them.

The best example that might be in our market is, well, they were much bigger than ten people, is Slack. They started out as a video game company. Then they developed an internal tool. you know, that might be in our market is, well, they were much bigger than 10 people is Slack. You know, they started out as a video game company, then they developed internal tool. And then that, that team kind of shed itself a little bit from the video game company and said, Hey, what does this thing over here? Let's start iterating on it really quickly with a really hyper-focused team. That's a really good example of customer development, essentially. So how do you then really define hyper growth then? Is it simply you found fit and you kind of see some semblance of a market, but now you know that that market is where you're at currently is nowhere near where you could be.

So hyper growth is know exactly how to go and grow as fast as possible to achieve that mass. I think with hyper growth, what it really comes down to is it's much easier to understand when you're in a SaaS model that if you wake up every day and you see some number somewhere ticking, basically kind of like passive income style, where it's just going like this and you don't have to do any customer acquisition, any customer development, it's kind of just coming to you organically, you're likely in either the start or already hyper growth mode in terms of your product takeoff. And that's really what it's about. I don't think hyper growth should be about scaling your organization per se. It should be that your product is ready to kind of go off on its own.

It hits some sort of exit velocity from you having to manifest it into the market. If the awareness shift happened, maybe a popular example might be a superhuman, the email client, maybe what, 18 months ago. So before I might have that timeline wrong, but there was a period of time where it was under the radar, but some people used it and had it. But then for whatever reason,

there was this VC moment where every VC was talking about superhuman and the way that was happening. Well, that was their kind of hyper growth moment. They were able to raise a crap ton of money off of that. They were able to do a whole bunch of stuff. Now, they didn't scale their organization past that there, but their product adoption number went off the roof. Right? Yeah, the best scenario is that your adoption number goes up and your organization size stays as small as possible, right? Like that's when you're really sitting pretty, I think, of WhatsApp and what they were able to accomplish,

something like 900 million users with 50 engineers. I mean, that number was here, but their engineer count was relatively flat in comparison. Yeah, and I don't think that you're, you know, I'm an old infrastructure nerd, and I definitely I don't think that you're, you know, I'm an old infrastructure nerd and I definitely still don't think that your business human count should scale the same way as your customer and product count and all that sort of stuff.

You should find some sort of thing where your product goes like, you know, your product has a hockey stick and you have more of a flat growth in terms of the headcount. That's just business efficiency. But on the flip side, you've got other types of business

that are very, very classically like blitz scaling, as I think is the term that's being used in the industry, which basically you're paying to acquire growth in customers. And those are obviously the Lyfts and the Ubers of the world where they're running at a deficit. And they're incurring organizational, technical, and then monetary debt to buy that growth, essentially. Now, that's a very, very strategic reason to do that.

If you're not explicit about the reason why you're doing it and you just kind of find yourself in that trap, well, you could find yourself in a different type of trap at some point, too. So two pieces of advice I referenced in the before that you have said seem to be somewhat at odds. And they are measure everything and trust your gut and I could definitely see a through line where you could do both of those things but it seems like if I'm going to be trusting my gut it's kind of the opposite of measurements right it's like my feelings it's my intuition or whatever you want to call my experience but if I'm measuring everything that I I'm supposed to be making data-based decisions. Otherwise, why measure? It's just a liability to have this data. So what are your thoughts on measuring and trusting your gut?

I like to look at data from the data-informed side as opposed to the data-dictated decision-making side. I think it's easy because of my seat in the business. And I don't run a government. I don't run a hedge fund. I don't run a lot of things in life. So maybe my advice explicitly is for software companies, and particularly ones where you are serving a wide audience, too. So a good example would be here that GitHub serves every developer in the world. That means infrastructure developers.

That means JavaScript developers. That means Salesforce developers. None of them are going to need all of the features that GitHub would release. None of them are going to ask specifically for a certain set of things. So we have to intuit a lot from disparate pieces of data or feedback or even positive and negative criticism. And we have to kind of use what we think as well from that. So that's what I mean by you trust your gut in some of these as opposed to be exclusively led by the data. Another good example of this, and I'll use one from GitHub's history.

GitHub did not build CI for a long time. I had that decision at one point to make while I was pre-acquisition GitHub as well. And a lot of people wanted us to build CI. A lot of people did. But we looked at it and we said, we can't afford to build CI because it is such a cog's sock for us. But we could change the notion. We could skip it, skip the build step and go right to deploying workflows and give them a pseudo ability to do CI. It won't be the full solution, but it'll be enough where the really, really forward-looking people can understand what we're hat-tipping that we're going to build in the future. But we're not going to do that right now. But if we listened to the data, we would have said, build CI,

and we would have had to figure out a way to make it work. But we had to think a little bit differently because we, and that's where we trusted our gut, saying like, hey, we're going to skip it because we think we understand why people really are asking for CI and go to the next thing or the thing after that and then build backwards.

So was that a wise maneuver? Yes, got us acquired. Really? Yeah. How did that get you acquired? Expand, yeah. The notion that GitHub understood its value in the market was incredibly important to the acquisition.

For a long time, it was not well understood that GitHub knew what it was sitting on. And I think the simple fact that we walked into all the major clouds and said, hi, we're GitHub. We're where the development happens. We want to serve those developers. We would like for you to be a party to it.

Here's what we intend to build over time. If you would like to be in, happy to have you. This is where we're going to go. I think it put those folks not unnoticed, because that would be the wrong term. We're talking about the largest companies in the world. But it at least showed them that we understood the value that GitHub was bringing to the market. And that story essentially was the take ourselves from a code host, turn us into a code platform, software development platform, go end-to-end and establish ourselves as the

only real end-to-end software development platform in the world where the major public clouds are at the other side of it. So the next step, you skipped the CI, you went to Actions instead. Is that why you're, it was Actions was the next thing. And then you built the CI on top of Actions? Yes. So what we did is, if you notice the way it's framed now, it's GitHub, I believe we call it, it's GitHub CI powered by Actions.

Or GitHub Actions now with CI. It's one of those two marketing terms. I can't remember what we're using these days. But the idea here is that GitHub Actions is an end-to-end workflow platform, all the way from editing on your code to deploying it into production. And working backwards, it's got package management built in,

now it's got CI built in as well. And then obviously we just acquired NPM to augment that story for the JavaScript ecosystem. So I don't have the numbers that you had to make your gut decision, but it seems like to me that GitHub Actions would require similar infrastructure that the CI would. So was it just the vision that changed?

Because I assume you still invested in the Actions similarly to the CI product. From the COGS perspective, Actions was a much healthier bet for us then. It was. But what does it not need? It doesn't need the same long-lived tasks that certain builds need. Okay. So you could do essentially, think of it as the original GitHub Actions

that we built was more of a functions-based solution, whereas this one has to be more like long-lived tasks. Kind of a different architectural approach. How much time does your team spend building and maintaining internal tooling? I'm talking about those behind-the-scenes apps, the ones no one else sees. The S3 uploader you built last year for the marketing team. That quick Firebase admin panel that lets you monitor key KPIs, maybe even the tool your data science team hacked together so they could provide custom ad spend analytics. Now, these are tools you need, so you build them, and that makes sense.

But the question is, could you have built them in less time, with less effort, and less overhead and maintenance required? And the answer to that question is yes. That's where Retool comes in. Rohan Chopra, engineering director at DoorDash, has this to say about Retool. Quote, the tools we've been able to quickly build with Retool have allowed us to empower and scale our local operators, all while reducing the dependency on engineering. End quote. Now, the internal tooling process at DoorDash was bogged down with manual data entry, missed handoffs, and long turnaround times. And after integrating Retool, DoorDash was able to cut the engineering time required to build tools by a factor of 10x and eliminate the error-prone manual processes that plagued their workflows. They were able to empower backend engineers who wouldn't otherwise be able to build frontends from scratch.

And these engineers were able to build fully functional apps in Retool in hours, not days or weeks. Your next step is to try it free at Retool.com slash changelog. Again, Retool.com slash changelog. So Jason, you mentioned that you had these notebooks with plans of what companies should do over the next N years, five years or so. And what we just learned during the break is that you actually had a GitHub notebook. So you talked about your notebooks for other companies,

but you had a GitHub notebook. And it seems like it was somewhat prescient. Can you tell us a story of your GitHub notebook and what was in there? Sure. So my notebooks are pretty standard things. I just grab kind of either the small Moleskine or the kind of the large loose leaf Moleskine types. And I just try to take notes on what I think the company is, what it wants to be, what it could be, and what I think from the outside. And it could be, and what I think from the outside. And it's always called whatever company I view from the outside. And then try to map it out. And so you're working on assumptions.

I just happen to know GitHub really well because while I was at Heroku, GitHub and Heroku were similar type companies. Even from a product perspective, they sat in similar spaces. They were formed even right around the same year, I think. So I just happened to have a GitHub notebook that was kind of formed. And I was fleshing it out as I was going through the very, very long GitHub interview process. But I should also point out that I cheated a little bit on the GitHub notebook. Because I put together a plan while I was at Salesforce to pitch up to buy GitHub while I was at Heroku,

because I wanted to combine GitHub and Heroku. That didn't work out, so I just kept iterating on my notebook because I said, what would I do if I had GitHub? What would I do? GitHub sits in the most interesting market position in software development. What would I do? And then that goes from a product perspective, but then you have to take into account the company's maturity and the leadership's maturity and other things too. So I just kind of put together a couple of year plan on what I would do. And one of my favorite artifacts from that time, I will not lose that notebook. It is sitting in my library and I am going to keep it out on the shelf always. The fun story with that one is I had in that notebook, June of, I think it was 2019, I put on there, I said, get acquisition offer. I had it circled several times with a star next to it.

So, okay, not that we would take an acquisition offer. That's not the goal, but to get an actual legitimate, at our value, acquisition offer. Got to think about that as a goal because we want to drive the perceived value of the company to that point where we need it. And I'm pretty happy with that. You were in the role of Senior Vice President of Technology at that point, right? I created the notebook before I joined.

Right. But you stepped into that role. And is that typically that kind of trajectory to go on? Is that typically what a SVP of technology does? he was going to look for a replacement. I had most of the non-sales functions in the business. So we had a marketing person and she was there. We had a salesperson and we had a CFO. Largely, that was about it. So I got everything else. I got product, I got engineering, security. I started out with support, infrastructure, data. I had most of those functions. And I shadow led BD and corp dev for a little while too. And the reason why, in my role, mine was SVP of technology was because it had that entire breadth. And my skill set lends itself to being what is more traditionally called CPO these days than it

is CTO. I just happen to be at a company where the product is the technology. Interesting. So when was the acquisition offer land? When did it land? We announced it on my one-year anniversary. I can tell you that. So we announced it to the public on my one-year anniversary. We got the acquisition offer, I believe it was first week of April of 2018. Oh, so you were off by a couple of months in your notebook. A year. Yeah. A year and a couple months. Yeah, I was off by a year of months in your notebook. A year.

I was off by a year. I wanted to do it in two years. You actually were ahead of schedule. So I thought for a minute there that you landed it to the T, like June 29th. But that's all right. I'm off by a year. So it was a year ahead of schedule. It happened much faster than I had anticipated it being possible to happen. And I think largely because I underestimated a couple of things

when I joined. GitHub always had a reputation for being a strong engineering culture, though the infrastructure engineering team at GitHub in particular was world-class. I also underestimated my ability to recruit several people in the industry, particularly one person who ended up running product design for us. And once that person came in, we were able to change a couple of things and accelerate them. I also do think that the founder stepping aside while he was looking for his replacement

accelerated a whole bunch of things. And the reason why is it just cut down communication pathway mishaps. And essentially, between myself, the head of sales, and the CFO, we were running everything at the company. So as long as we three were in lockstep, the entire company started to operate much more efficiently.

So you're off by a year, but you're ahead of schedule by a year. So if you're going to be off, you want to be ahead versus behind. It's better to win the 2018 championship than wait for the 2019 and take your chances. That's right. That's right. And I'm sure that was a moment of extreme joy or satisfaction or whatever it is.

Did you feel done? Like, well, I did it. Now what? I think everyone has that. It's very different. It's different than winning the NBA or NFL championship where you've basically just put it out on the line for 60 minutes or whatever. Just pour champagne on yourself?

We did not do the champagne thing yet. However, there was a moment. The head of sales, he's a good friend of mine now. He's since retired and he's moved to Chicago. He and his husband are there with their kids. And we had a thing. He said, hey, if you're able to pull this off, I'm going to take you and your family to Hawaii. So just Hawaii, Hawaii, Hawaii became a thing. He said, hey, if you're able to pull this off, I'm going to take you and your family to Hawaii. So just Hawaii, Hawaii, Hawaii became a thing with us. And there was a moment when I looked at him and he looked at me and we just kind of said, Hawaii. It was that moment for us. It was that kind of emotional thing. And it felt ridiculous.

It felt amazing. Couldn't believe we were able to do it. You know the grind of running a company, particularly one that you're trying to help along out of certain things, let's just say, and when you're able to see that done. But acquisition offers are hard. There was a long period of time between getting the offer, signing the letter of intent, and closing the deal. It was a long time. Long.

We had to go through a lot of diligence. Nine months, right? Was it roughly nine months or more? I think it was almost exactly nine months. Yeah. And we had a lot of work in between finding out about it, announcing it, and then closing it.

And there is the high of getting it done. And then there was the underlying anxiety of like, wait a second, do these things fall apart? What could possibly happen? What could go wrong? Yes. You know, like, am I allowed to make that comment on Twitter about a thing? Okay, you know what? I'm going to deactivate that thing for a little while just because.

No mistakes. No mistakes. And it was an interesting period of time. And how I got into tech, I like to tell the story, is I fell into it. I was not destined to be in tech. I grew up in farm country Connecticut. My grandparents are farmers. My parents are farmers.

My parents escaped farming to become other things. My dad was a construction worker and my mother was a typing teacher who went on to become a high school teacher. I fell into tech because in my high school, IBM was in the town. They wanted high school co-ops. I applied because my auto shop teacher said I should, because I was the only kid that he knew that didn't have a computer or a car or and a car or whatever I'm supposed to say in that scenario where you live in a very rich town and you're not that same thing and ibm was basically said we don't know anything about computers great you just carry these things around but you're the type of kid that should get this job because that's what we're after here so i kind of fell into it so you go from there in the mid 90s to a seven and a half

billion dollar transaction that you're primarily architect of is kind of amazing you know there's an emotional high that comes with that and there's this weird kind of other side of it too which is like oh wow i'm 40 at the time i think it was exactly and i'm like then what this is probably the pinnacle of my career if i was like i pulled this off like what's what's next like well microsoft's already got a ceo so that's that's out the window at this point he's doing pretty good too yeah he's doing amazing i don't know but the you get the idea it's like okay hang on a second that's kind of interesting and then there's the other side of it too which is i'm still at github obviously and i love my job and i love what i do though there's a different type of ownership that i have now over the company than i did before and

i don't mean percentage i just mean emotional because microsoft bought the company this is their company now it was never my company in the in the first place though i felt a certain type of ownership over it for that 18 months essentially essentially, until it closed that day of the definitive. It was interesting. So it feels less like your company now. No, but it doesn't feel less like my company. I still love it. I have the Octocat all over my house.

I've got so much swag you wouldn't believe, though I do have to let it go differently now, which is at some point I know I will leave Microsoft and GitHub, whether that's five years from now, 20 years from now, I will leave because it'll just be. That's not true, though. Unless you can find yourself,

let's say, $15 billion, you can own it. I mean, it's not that hard, right? You can think of one day you'd be yours, Jason. That could be your next goal as a buyback. I'll go buy the Giants, the New York football Giants, and try to make them as a buyback. I'll go buy the Giants, the New York football Giants and try to make them an actual team instead. There you go.

There's a challenge. Well, this certainly lends to your vantage point now for Horizon 3. Given what you've been able to do with culture, with team, with scaling, with refocusing the company in many ways or the three that you'd mentioned to enable this kind of transaction and then the future of what a developer platform like GitHub

should be, it makes sense to put you in a position or put yourself in a position that you've done to be focused on Horizon 3. There's no better position in the industry to focus on developers' needs than at GitHub. And as someone who's basically been steeped in the open source industry for a long time too, in the open source world, I have the emotional letting go that I mentioned before about GitHub, I never have to do with developers and open source. That will be with me forever.

And those people, and if you ever think about tribes in the world, basically developers are mine. I found them and I love them. And open source in particular, obviously is a super soft spot for me. That's an interesting perspective. I mean, I think we have a similar feeling that developers are our tribe. And regardless of where we go, we're always for developers. And you can see that with your career path, too. You've always been on that perspective of developers and being at the center of this universe of tech

and even the way that you've been able to take certain practices and extrapolate them from engineering in terms of product market fit and scaling and things. As it works in engineering, it might work elsewhere because of how critical you have to be, I suppose, in engineering, how meticulous you'd said before around planning and execution and stuff. Largely speaking, I think that engineering in general is one of those areas where you get less wiggle room than other areas in businesses. And I don't mean that as a knock on other areas or too much of a kudos to engineering.

It's just, it is. You've got to take some ideas and you've got to turn them into real product and you've got to do it on a cadence and you've got to guess or estimate when things are going to get done. So you've got to find some frameworks and mechanisms that allow you to have those conversations and make basically impossible things possible. And it's always interesting to me because here's something else I think. I think our industry should and will eventually go through this evolution where more engineering leaders, and I don't mean people with engineering degrees, I mean people who ran

engineering organizations, large engineering organizations, are the CEOs at companies. And the reason why I say that is because the skills you develop there, the same ones you need as a CEO, though as a CEO, you do need to develop a broader set of them. So here's what I encourage. I do talk to a lot of early and younger engineering leaders.

I encourage them very, very much to think about the strategy aspect of things and to understand the basics of finance and why marketing is important and things of that nature. But I do think that we'll see more CEOs come out of the engineering ranks because the skills you develop there are unlike any of the other skills in any of the business. And the closest one you can find is sales because sales is pretty methodical and salespeople have to think about

how you build an actual organization and how it's running and the efficiency of it, which is why I think you see more sales CEOs than others. And the reason why I don't think you see engineering CEOs is because they're the worst at marketing themselves. Well, it's to some degree visible, I suppose, in GitHub because earlier on, GitHub was ran in many ways by just simply by engineers. And as we were on that subject earlier i was thinking like in terms of like what got github to where it was at it was more like you know those things in terms of like this flat

culture got us here but it's not what's going to get us there and the there is that seven and a half million dollar acquisition so in many ways you needed that mindset of engineers sort of like running things to get github to where it needed be, to get to where it needed to go. So past that position, you get to that. There's only so far, I suppose, and it's not unanimous, but your aspect of sales, engineers, that kind of thing, and leading and running, I know many engineers, Jared being one of them, is very smart. And at the same time,'s a another side of the spectrum

that can lead well as well and engineers sometimes have uh this hold back i suppose maybe i don't know what how to describe but there's something that can uh that others can do maybe better to some degree like you're saying i think this is one of those things that we see in the industry which is if you basically grow up through the engineering ranks, a lot of companies, particularly late 90s, early 2000 companies would have one career track, which was you're either management or an engineer, or I see it, but engineer specifically. And the trap, what happens is people fall into is that they think that if you're an engineer, you need to go management, but some engineers should be distinguished engineers and

they should run small projects and they should have purviews that are super wide and they should have influence, but they shouldn't run the entire organization. They shouldn't come up with, you know, understand the efficiencies of it. They're not going to run the organization, but there are another set of engineers who think that way. So there's a couple of engineers that I know that are obviously many engineers I know that are way smarter than me, though we have different skill sets. I always said that the more abstracted I got, the better I got. I was an average developer, but I was a better team lead and a much better architect and a much better director and an excellent VP. And it just keeps going up because what happens is I'm a generalist and the purview

changes. And as you can be more general and you have a large purview, you can hold all that information in your head. That skill set is augmented. Some engineers, and particularly the really, really, really talented technical ones, that would be a torture job for them. But what they really like to do is they like to build the systems. And they're excellent at that. And we should liberate both sides of those engineering systems. If you need secure and PCI compliant payments for your website or an app with iOS and Android, where would you get started? Well, our friends at Square invite you to develop on the platform that sellers trust.

Head to squareup.com slash go slash changelog to learn more and create your Square developer account. When you build with Square, you get to outsource all the payments complexity to them. They take care of maintaining PCI compliance, detecting fraud, and managing disputes on your behalf. You can customize your checkout experience to match your style guide or save time by using the pre-designed payment flow. Easily integrate with digital wallets like Apple Pay and Google Pay to make checkout fast with increased conversions. And the icing on the cake really is the dedicated disputes team you get to access at no additional cost.

Learn more and create your Square developer account today at squareup.com slash go slash changelog. Again, squareup.com slash go slash changelog. Again, squareup.com slash go slash changelog. So, one of the things we're guaranteed in the software industry is change, and things have changed over the years at GitHub. And things have changed quite a bit drastically, not just industry-wide, but worldwide. In the last couple of months,

GitHub has always had an HQ. I've always enjoyed visiting GitHub HQ, but also remote workers. So I'm just curious what the COVID-19 quarantine has done for GitHub in terms of logistically running the business, but also scaling teams and engineering and some of the changes y'all have had to go through or haven't had to go through because of the way it works. Let us know how this has affected GitHub and the engineering teams. I think for the most part, GitHub, not much has really changed. About 70% of all of GitHub was remote or distributed, or is remote and distributed. Now, obviously, 100% of it is. If anything, I think what has changed is there is a set of people who had never worked outside of HQ, including a lot of the exec staff. Now they have and they are. And so interestingly, I think that they're coming to realize that they themselves can do it and not have a loss of efficiency.

Now there is Zoom fatigue and certain things are harder or maybe slightly easier to do in office, but it's possible. And when it's possible, then you talk about what you want to do. And that, I think, is an interesting conversation because i think many people in the industry um executives in particular and then really particular vcs thought can't do it best software is always developed in office with a team in san francisco fight me on it you're never going to convince me. And now all of a sudden, all their tunes have changed. Everybody's tune has changed. So much so that I've been doing a lot of talk about remote work

the last couple of weeks because everyone finds themselves suddenly distributed. And a lot of people are reconsidering never going back to an HQ or having a very, very different notion of what HQ is going to be. And I find that incredibly refreshing because as forward thinking as we think the software industry is, this is a really regressive topic.

Most executives, most VCs, most people who think of themselves as risk takers or thought leaders would never entertain having a 100% distributed company with no HQ, no matter what they said. So is GitHub HQ on the market? Someone can buy that spot? Or what are you guys thinking after this all shakes out?

We had the conversation, we're going to come back to the office, but we won't come back the same way. And in fact, if we came back the same way, we weren't paying attention. The world changed on us overnight. You can't imagine that everyone wants to go back to an open office plan, crammed into certain open spaces the same way they would before having a pandemic hit the world it would look it has to look very differently and so we have to think about how we go back to the office and um do we change some of the layout or do we change

having some of the pods like the multi-use small dimensional pods for phone booth rooms yeah they likely change we likely don't see those as much anymore you know but we'll still have an hq we'll just use it very differently this is definitely a wake-up call for a lot of people the businesses themselves the individuals who are have been forced to do remote work where they hadn't been even interested or think it was possible for them before. And it's just interesting how this is going to play out because I don't know how much you entertain this idea of work-life blending.

I think of it more like that because I just take a break from doing a podcast, go out, get a snack, have a micro moment with my family, and I just can't give that family. And I just can't give that up. And I just think like blending is the people always talk about balancing. I think it's more about blending rather than just simply balancing because work and life happen. And rather than try to balance the two, why not to some degree, blend the two, like taking a few minute break, seeing my family, give them a hug, go back to work. Like there's nothing more refreshing than that to me to like give me another win for the last segment of this show or any other scenario in

our business is like you go to have one of those micro moments come back refreshed and I'm ready to go that's a balance though because I I like the idea of merging more of my life into my work but I don't like the idea of merging more of my work into my life. I still want there to be a separation at times at least where it's like, to me, blending is like, am I working? Am I living? I don't even know. It's all one big bubble of life. And I think that's hard to sustain.

I think maybe that is beneficial in the short term but over the long term can really drain you well the specifics on the blend versus the balance is more around like I still believe in the times so nine to five I think there's a time constraint you still have that balance of that I don't ever want to be working outside of this room so that's the balance but the blend is sort of like I can take you take 45 minutes in the afternoon if I'm having, let's say, a frustrating morning or something like that. Or maybe a great morning and go celebrate, go to lunch instead. And maybe now it's a little different with going to lunch because maybe it's lunch out in my kitchen versus lunch at a nearby restaurant or something like that. But the blending is more just on the lines of like rather than try to balance the two, why not blend the two? But I do understand what you mean, Jared.

The blending can only go so far until you start to have harm. I think this goes back to the topic we talked about before with more explicitness and having some control over that. I always hated going to an office because I felt like so much of my day I lost control of. I was 30 minutes away from the house or an hour away from the house. I could not do certain things between a certain set of time and then with my commute. But now if I'm here, as you said, I can have a micro moment with my kids and I'm going to co-op that just so you know. It's spreading. We could have a micro moment with my kids. Micro or i could then say you know what i need to go out for an hour with my daughter to the park but that's fine because i'm already

taking a meeting at eight o'clock at night but i'm fine with that because i'm making that decision to go do that i feel that in some ways this gives the worker a lot more control over their life. And if they're responsible, they can really benefit themselves and the company and everyone around as well, which is weird because I don't think that I think most people would think that you're getting the most out of your people if they're in the office, but they're actually not because they're losing some sort of cognitive overhang for just having to be in the office. Was that a micro moment? Yeah, exactly. Adam just had a micro moment right there. Kid just walked in, brought me a bagel. I love it.

So let's talk about distractions. He wanted to say hi real bad. That's for a different time. I think in engineering, this is a really easy sell. And I've also been working remotely or for home office for a decade plus. And so I'm right there with you guys I'm not experiencing much of a change during this time but I wonder about the creative aspect of work and the riffing and this is something that I assume you do a lot Jason especially with your big idea eating and like bouncing back and forth and there is a certain energy in a room that can

happen and you're laughing or you're coming up with this, maybe you're throwing darts. There's like a certain riffing that happens in real life. And I'm curious if you find that you're able to get to a creative space on a Zoom call like you could in the same office, or if that's a real struggle. It's different, but I think you can do it. But let's say that the way I look at this one is percent efficiency. So let's say that you and three to five people being in an office is 99% efficient because it's like the most optimal situation you could find. There's all the white boards and snacks or whatever that's 99% efficient. Is the drop-off by doing the exact same thing on zoom and video from all from

your homes is it taking it from 99 to 0 or 99 to 30 or more realistically 99 to 90 yeah and that's what i think it more looks like so for what i get out of the situation what i my employees get and all the workers and like the too, because we can hire the best talent in the world. And several of our best engineers are never going to be in San Francisco. The most tenured engineer we have, the best engineer GitHub has ever had lives in North Carolina. The best database engineer that GitHub ever had was in Israel or was in Israel. We were able to benefit from that, for that 9% dip in that efficiency for that scenario. That's how I look at that.

Not quite as efficient, but I'm okay with that trade-off. I think what it's forced, though, is it's forced people to rethink creative environments. I think what you're saying, Jared, is you feel like riffing only happens potentially in person when there's real time. Not only. that's the percentage like it's an ideal scenario and that's what you have is you have people kind of challenging that idea that in some eyes it's an only scenario it's unanimous that that's where creativity happens is face to face whiteboard in a room hunkered down whatever and that idea is certainly being

challenged and in many ways being debunked. Well, we actually play this trade-off game every single day with podcasting because Adam and I have never been co-located in terms of the show. We've always been, I'm in Omaha, Nebraska, he's in Houston, Texas. Now, sometimes we would go to a conference like OzCon or All Things Open,

and we'd sit down, we'd have two mics, three feet apart from each other, and we'd have a guest over there, and we'd be in the same physical space. And we have some of the best shows in that scenario. I could name the situation. I still remember those conversations. There was a chemistry that just is better,

the timing is better, the jokes land a little better especially mine no just kidding and we say after that we say dang that was really really good and yet well should we move to the same city then and do that and then we're all our answer is always no no we should make the trade-off yeah i mean i think the trade-off is is the right way to think about it and that's how i've always thought about this. We supplement for what it's worth. At Canonical, we did it. At Heroku, we did it. And at GitHub, we do it. Which is, if you're distributed a couple of times a year, you're going to come into the office with your team for very explicit reasons and intentionally do it for a couple of different things. And we understand that. But 90% of your

time, you're going to be at your house and wherever it is. A 90% of your time, you're going to be at your house and wherever it is. Good example of this is I mentioned GitHub Actions before. The team that kicked that off, not a single person was in the same physical location we had. This is not true.

We had like three people, I think, in San Francisco, but the team of 10 or so people that started it and then grew to whatever it was, mostly was distributed. But the initial team, when they got together to write the code and prototype in a two-week period, they went to Nashville. And they got there, and they did it for a very specific reason, to go from zero to something demonstrable in a very short period of time.

And they did it. But they didn't need to be that same way all the time. And that's what I think about here is doing it again i go back to the notion of explicitness versus implicitness like explicitly it serves a purpose and then go back to the other way of working because it's much more efficient yeah well we're social species so there's obviously face-to-face in person is better as you said there is a cost for that and the trade tradeoff is, is it worth the cost? So in Jared's case and my case, the answer is no.

I love the guy. I love to hang out with him on the weekends, whatever, compare ideas face-to-face. But he's got his life, I've got my life, and that's going to be the same thing for everyone else in the world, that there is that tradeoff. So the answer is truly it is better face-to-face. It is. But there's trade-offs and there's costs. Yep.

And I think more people are coming to the conclusion that holistically, if you looked at the situation, being remote capable is a better overall environment for things. The story I used when I was trying to convince somebody of this for what it's worth is, I was at Salesforce at Heroku and Heroku was distributed, but Salesforce was not. Salesforce had offices in other places

and a lot of offices in San Francisco, as you all know. And we were in one Salesforce building and everyone else is in another Salesforce building or another one. And quite literally, we would spend all day on video calls anyway, talking to everyone else in the same city at Salesforce because people didn't want to go one floor down or one building over.

So effectively, you had all these people who were in the Salesforce headquarters, quote unquote, headquarters around a couple of city block who were effectively treating each other like remote employees. And I just found that to be incredibly ironic because everyone's paying this ridiculous rent to basically, they said, well, we can all go to happy hour together. I was like, that is not worth it to me. That's not worth it to me.

Yeah, right. Well, usually that's after hours or the balance hours of nine to five or whatever the number is for you, like whatever that spectrum of time is that you allocate towards mind focused on work, not just simply life. Now, the blend part happens there every once in a while. If you let it, you get those micro moments. I like that you like that that phrase. It's awesome. I enjoy it. And I enjoyed, you know, the execution of it every single day where I will never go up. I'll never go back to an office ever. Here's another way to look at this. This is a slightly different take on it, much more personal maybe, but family oriented. There's a statistic, I believe it's that you will spend 70% of the time you will ever spend with your kids before their 18th birthday. So if you think about that as a trade-off, if you're a family person, that is a staggeringly large percentage of your time spent with your kids before a certain time in their lives.

So if you're optimizing in some ways, optimize for those things. And that's time you're never going to get back. And that's one of those things that I want to optimize my entire life for is my family. Because when I'm 80, I doubt I'm going to look back and say, I wish I took that job at Uber. I wish I spent more time with my kids. One day I want to either read or write a book titled 18 Summers because that's what you get. When you have kids, the 70% of the time you're – I didn't know that statistic, but I can assume it's true based on my knowledge of being a dad because you only get those 18 summers. So how do you use them? Do you spend your summers blending your work to the negative side, Jared, and overworking or blending your life and, you know, not taking the

vacations or enjoying those moments or making those memories? Or do you, it's so focused on your career and growth and these things that, you know, in the end, they don't really matter as much as your family. I have a slightly unique situation too. Or maybe it's not as unique, but it's nontraditional in that my wife is home. She's homeschooling the kids now. She's a doctor, so my wife is infinitely smarter than I am. A much nicer person than I am too. You seem pretty nice.

She's just a wonderful person. Selected those words carefully. Well, she must be amazing then if you're good. Okay. So pin that one. We'll come back to that one in a second. But my oldest son is autistic. My middle daughter has a whole bunch of learning disabilities in terms of like dyslexia, dysgraphia,

expressive regressive language disorder. So in terms of like us optimizing our family situation, we are going to optimize it for their needs. That was one of the reasons why my wife doesn't work anymore. She homeschools them and helps with their care and that sort of thing, making sure that they're progressing in their education as they should. And then my third daughter is neurotypical, and she's pretty easy. But the idea is we were going to make sure that we optimize for that. Because if I wanted to chase career or money or all those sorts of things, we could have moved to San Francisco and lived this really kind of shoebox life with them

and sent them to the public schools there or even some charter, but it would have been harder. It would have been difficult. We wouldn't have been thinking about them. So this is, again, an efficiency optimization. We're 100% looking for them and then find the efficiency for my career

and the other things, the other side of it. So it was very intentional on our part to do that. So this life we now live in, the previous workforce ways didn't give everybody the same choice you have, right? No. The opportunity for remote. And I felt incredibly lucky to be able to do that. And I'm not saying that, you know, I'm not trying to skew towards that percentage. I'm just trying to say that before it was never an opportunity. Now, it took a pandemic like this for the majority of the workforce to open their eyes to the possibility that everybody wants to have that same kind of choice. Because

most people can be pretty wise about their life choices when it comes to their career, their families. And it hadn't been possible before to give everybody the opportunity to have that kind of choice. No, and I think that what I saw as negative feedback or reasons not to do this before was people are always worried. It's like, well, if I give this to my employees, how will I know if they're being productive? Or will they be as productive as they would be in the office or those things? And my feedback to people who were saying it was that tells me more about you than it does about your employees. So I would like you to take that as honest feedback and think, wait a second, is this about me and my ability to be productive in my situation or my ability to

structure my life or be disciplined enough? And that's really what it comes down to in a lot of situations is discipline. Am I disciplined enough to do this if someone wasn't watching over me all the time? Because most people are going to be okay with it. But yeah. We should be careful to keep the conversation focused on the technology sector because while this does provide a huge opportunity to show companies that working from home is a thing that can be sustainable and even better for your employees, there are literally millions of jobs that have just disappeared off the face of the earth yep and those people are not working but even in our sector too you think about like some of the robotics companies they're going to struggle with it because some of the maybe the software side of the house can the hardware can't and then

the mix in between is it is it not you know i'm i do feel privileged i've been in exclusively software companies for the last decade. And we talked about farming earlier. Farmers can't. They have to go. There's an analog thing that they have to do every day. Some automation that can happen, but they've got to get out. I do think that in our industry, in the software industry, we'll see it much more common.

It'll become a much more common pattern. And I think for the most part, what we'll see is, we'll see some interesting tech come out in the next five years, I think, too, that makes it much more possible for this to become the daily pattern for people. What about VR? Is VR going to have a resurgence because of this? What is VR again? I forget what that is. Exactly. What is VR? It's like the third

resurgence of VR. It keeps trying to, am I ready? Is that some new coin that I don't know about? Yeah, VR coin. Although mixed reality

is what it's now. They got an AR, see VR wasn't doing so hot. AR has a chance so they merge them and now it's MR, mixed reality. Interesting.

That's just my conclusions based on what I was reading. Who knows? To your point though, Jaredared there is a massive amount of people that the job just can't be done remotely yeah and that's just i mean you can't be without the stadium you have no concession stands or things like that like there's just things you totally totally in social scenarios that just aren't possible at all you can't serve serve me a Coke or I can't order a beer or whatever it might be from home like that. It's just not possible or in a remote scenario.

In the software world, though, this has accelerated a trend which was already happening. And it just really has kicked it into high gear. And so a lot of the people that were thinking, we can't actually do this, they're actually learning, well, we could, we just either didn't think we could or we didn't want to. Well, in many ways, where technology,

the sector might be a first wave as well, what we might see, and maybe not in our time, our lifetimes, but it might happen for other sectors as new technology comes out too, that allows, example being the farmers, to do more from the house because maybe with the drones and the satellites and the automation they're able to do a higher percentage from one location it doesn't have to be in the tractor right who knows

so when it comes to managing teams so you talked about discipline and explicitness. And I think definitely there's a certain personality traits that work well remotely or at home. And there's other ones that don't. They get to fight against them. And so people who generally are self-starters, and so far as they get up and they can put themselves to work, I do believe many people can practice that or get better at it over time. It's not like you're condemned to somebody who can't put themselves to work. But there are certain people that do better at it than others, right? And they need, even the commute, which nobody wants to get their commute back, but there is something about it where it's like a transition into a mindset

and back out of it, where they're like, I want to be in an office. I want to be with people. I want that. And I have a hard time working at home. And so surely you have people like this at GitHub or who are struggling with this. You're trying to help them through that. Like, here's how you can be effective

as an engineer at home. Here's how you can work with teams, manage teams at home. What are some, do you have do's and don'ts or tips and tricks or mindsets that you can help with your engineers who are struggling to be productive or to feel good about their work? Well, the true honest introspection is a superpower, I believe. And so if you really do, you're struggling for whatever reason, be really brutally honest with yourself and figure out what the struggle really is. Is it a lack of motivation or a lack of understanding, or maybe you're anxious or you feel deadlocked and you're waiting to be told

something and you want to go get it. You don't want to go get the information or maybe you're just lazy. And I'm not saying that in a bad way, but maybe just, you can't get up to go do this, but figure it out. And then you, once you know the answer to that question, you could probably know how to attack that. Though very, very broad stroke tactics that I've seen work are people talk about having a rhythm to your day. Just like a company should have a rhythm to its entire rhythm of the business for every year, you should have a rhythm to your day. You wake up. You do the same couple of things. Like you've got to commute.

Then you go to your office. You go to to your place and it's like going to work you know there's that that moment the other is to develop some of the skills needed because they are different to to be successful remote than they would be in the office and the most critical skill i think is to pick up the phone which is basically my way of saying that you need to go get information more than you need to get given information in a lot of scenarios. So if you're waiting to be told to go do something, it's much faster, better, easier to go ask to get some information. And if you're able to kind of shift that mindset around, you likely are like already 80% of your way to being successful remote. And it's a, it's more of a, you know, a passive type of approach to, to wait and in a remote scenario that that can't be.

And then the other thing I'd say too, is that if you're a manager, assume a set of things, but in my experience, what I've seen is that typically the worst traits of someone's mental makeup or behaviors will manifest in a remote scenario so if you're an anxious person you become hyper anxious if you're a micromanager as a manager you'll become a super micromanager it's like a level up apparently uh it feels like super micro yeah and there's super micro moments adam maybe sorry i just wanted to say the word again but you get the idea it feels like. Super micro? Yeah. Are there any super micro moments, Adam? Maybe. Sorry, I just wanted to say the word again.

But you get the idea. It's like, it feels like those things will become exacerbated in a remote environment. I talk to managers a lot about this because if you're the type of person as a manager who, quote unquote, just wants to check in, it's likely going to drive you crazy. And because you've got to find different mechanisms to give context and get information back about statuses.

Because if you're going to rely on the same office mechanisms, it's going to feel very different in a remote scenario. Yeah. When I think about other things that can happen remote too, is the lack of information becomes deafening in a remote environment. So you in an office setting, if management or the execs or some information is not flowing around, for some reason, it doesn't feel the same. But when you're not getting information pushed to you, and it's not being communicated in a remote environment or something feels like it's being lost, for some reason, remote, it's exacerbated infinitely, in my opinion. So it's also why when I'm talking to people about, particularly in this situation here, is to be over-communicative,

to really write things down, to do it a couple of times, to be willing to write it in an email or a GitHub issue or jump it in all hands and do a zoom for everybody and then then do a q a afterwards but ambiguity will kill you in a remote environment so try to drive to as much clarity as possible as quickly as possible the feedback loop is really the crucial thing right so you mentioned retrospective or introspective which leads to awareness so self-awareness is a i agree it's a superpower and the necessity of a feedback loop so relationships right that's a feedback loop how jared feels about me how the work we're doing is working you know etc those things those are all feedback loops yep and to you know to almost sort

of like have a resurgence of appreciation for quality feedback loops. Because what's happening is when you get cut off from information, whether it's purposeful or not, is isolation. And in isolation we wither. What you really need to come back is connection. We're on a podcast so no one's going to be able to see this. So this is just for you two, but I'll use my hands here because that's just how I roll. But imagine your company is the box of this Zoom call here at this point. Imagine basically that it looks this way. You're in the upper left-hand side of this box as a CEO. The CEO needs to communicate strategy, mission, vision, some context, something.

That communication needs to work its way down to any individual inside the organization. And that person, basically the job of this communication is that that person should know what they're working on that day and why. That's the whole purpose of that communication channel. And then there needs to be a separate communication channel backup about the status of those things, the feedback loops, the statuses, how things are going, where they are, all that sort of stuff. And it basically makes a V, if you think about that, that communication channel from CEO to CEO, all the way down and up. Bad organizations or poorly run organizations look like a flat line. There is no feedback loop or it's a long vertex. And the better you are, the closer the V comes to a vertical line.

Now, it's theoretically impossible to get to a vertical line, but if you can narrow the V as narrow as possible, you're probably a really good organization. Now, it just also happens, in my opinion, that that exact same scenario is what makes a co-located organization a great organization. If they can master that whole pathway, they're going to be an excellent organization. In a remote, it's required. So you're saying communication is key? Yeah. Okay. Communication.

Check. Yeah. I mean, undervaluing communication is, I mean undervaluing communication is i mean expectation communication those things clarity you can really thrive like if you know what's expected of you and you've clearly put out your expectations for those that work 100 but it's easier said than done much easier it takes work we're not saying it's easy it takes work it takes intention more than anything intention discipline yeah so this to me is it goes to a different topic though i'll mention it, which is my view largely of leadership in the tech industry is not a favorable view. And it's largely because most people have not mastered this set of skills. They might get really, really, really good at selling or vision setting or whatever, but the grind of building the skills

to do this right here, which is not a singular skill. There are many things that need to get done in between here and there. This is a project management feedback loop. This is about goal and expectation setting and context and delegation. And they all need to come together

to become an excellent company. Most people, that's the hard, deep work that a lot of people just don't either master or have time for or skip or for whatever reason just is not in their world. And I think if more people spent time on those things, we would, as an industry, have a much better view of leadership in general.

So you have not just a writer of notebooks, you're also a reader of many books. And so you've read many books to help you get to where you are in terms of your mindset, your view on leadership, high impact teams, etc. I know you have a short list of book recommendations, we would be remiss not to get that from you. For us and for the listeners, books that you find invaluable that have got you to where you are, and helped you lead so many high impact teams like this i'm going to butcher some of the author names i think so help me get these in front of people once we do this but we'll link them up james clear's uh atomic habits book is excellent and um i'm saying that knowing that he lives here in columbus with me so i just want to give him a plug regardless of that it's an excellent book too. I like Extreme Ownership by Jocko, I think his last name is Willick. Basically, it's the notion

of obviously just take ownership over something. And if you can, ownership leads to mastery. And that's what most organizations are going to need. I like Team of Teams, and I cannot tell you who writes it, but I like Team of Teams because it's all about organizational structures and how you organize to get things done in a lot of different ways. There's a book by, I think it's Patrick Lencioni called The Advantage, which is the follow-up to Five Dysfunctions of a Team. I like that book quite a bit in those two books. Ben Horowitz, either one of Ben Horowitz's books, The Hard Thing About Hard Things, or What You Do Is Who You Are, I think is his follow-up book. Both of those are excellent.

Read that one just for the hip-hop recommendations. I mean, for the music alone. Yeah. And I think the hard thing about Hard Things is a follow-up to Andy Grove's High Output Management, which I like the hard thing about Hard Things more. It's just more relevant to the time. But High Output Management is a classic. So if you do read it, it is good.

I would just recommend you skip the first two chapters, which are, I don't know why they're even included in the book, but the rest of the book is quite good. The other thing I do like, I recommend this quite a bit internally or to people as well, is I like the service called Blinkist. And I am not a paid person for this, for what it's worth. I just like the service and I use it a lot.

And most of these books, I think you can get on there and literally read in 20 minutes or have the audiobook read to you in 20 minutes. I'm as well. And I can't recommend that enough because most of these things should not be 300-page books. So most books have one, maybe two, if you're really lucky, three good ideas in them. And I'm also a non-paid blinkist shill because i i enjoy it quite a bit and you know you can get them the cliff's notes are good and that's what that basically is is modern version of cliff's notes yep you get the sense of it pretty quickly 15 20

minutes in and out boom although there's a weird side effect of that is that i feel like i've read a lot of books but then once people start talking about them, I'm like, no, haven't actually read that. And then I remember why I'm like, Oh, I summarized it. Yeah. Yeah. You do lose the story aspects of things.

Most of the filler is some, some story, which could be fun. It's like a side quest. And like half of the podcast here is the side quest of the stories. And, you know, you joked about having a podcast called the breaks because those are fun. It's just, if you're reading something, you really want to get to the meat of it. you know, you joked about having a podcast called The Breaks because those are fun.

It's just if you're reading something, you really want to get to the meat of it. You know, there's an awesome book about Abraham Lincoln. And I think it's called Cabinet of Rivals or something like that. It's something along those lines. And I believe it's like 750 pages. And I tried a couple of times to read this. And it is fascinating. And it is a couple of times to read this and it is fascinating and it is literally an amazing like story and stuff. I, but I do just want to get the CliffsNotes version. I want to

know who was trying to backstab who for what, you know, weird reason and how Abraham Lincoln was able ultimately navigate it. I just, it's, I just get lost sometimes in those. There are some stories that lend themselves to be summarized and some that are better enjoyed going through the details that's for sure especially if you're listening to say something that's fiction that's just for fun you know yeah that's what i say if you all could actually summarize 2020 for me and give it to you in 2021 and i can just go to sleep for a little while could you do that we'll'll try. We'll try. I would agree with that though.

I think there's plenty of us that would like to hit fast forward on this one and see what happens in the next chapter. I wasn't unanimous here in this mention of Blinkist. Is it Blinklist or Blinkist? Blinkist. Blinkist. Because here I am behind the scenes like a diehard FOMO kind of person. I feel like I'm going to miss out on something if I don't listen to the whole book. Oh, yeah.

However, I can appreciate summarizing certain books, which is why that's my perspective. It's great for nonfiction. Well, what it's really good for, it's great for nonfiction, great for business books. But it's also great to lead you to a book that you might actually really want to read. And I have done that. Kind of like a teaser, a summary of some sort to kind of get them yep i can dedicate more of my time to the full book is that what you're saying it's kind of like um back in those airport uh back in like the late 90s early 2000s hbr condensed book things that they

would sell in airports like hey read this book in five minutes or whatever and you know you use it to go say i want to know more about that topic. I'll actually pick up the book. Is your book list over? Can I add one to it? Is there more? No, go ahead. The book I want to add to it is Essentialism by Greg McKeown. There's a chapter in that book that I don't get right, but it reminds me of its importance. I don't recall the chapter number, but the chapter name is Protect the Asset. And it's essentially about protecting your sleep, protecting your health, because you can't be you unless you're you.

And you're not you unless you got your mind. You're not you unless you have your mental health, your body. And essentialism kind of reminds you, and I think even this pandemic has been a resurgence of finding out what's essential to you right what's essential to you and that's what it is it's not minimalism it's not a tribe it's not some sort of like religion it's what is essential in your life the vital

few versus the trivial many what do you need to work on right now what really matters to you and that chapter protect the, to me was like mind-blowing. It seems so simple, protect the asset, protect your sleep, protect your health, but so often do we trade our health, our mental freedoms for other things, for whatever reason. I literally have a half-written, poorly done blog post that I probably will never publish called how I sold GitHub and wrecked my back at the same time and how I fixed it. Because my back after the acquisition was basically trashed because of like the hours I was putting in and how little I was sleeping and doing some other things. And for the past year, maybe over that,

I've really had to focus on getting my health back, my back, my glutes, my hamstrings, my hips, things that are really were troubling me that I basically let go for that reason. And it's funny because I can't think about it the same way anymore because I'm like, if I'm 40 now and 80 and this is what I feel like now I need to get this thing sorted out otherwise I'm in trouble what do you think about

this then to add one more to that is is this idea of doing things like that with intention so in a season so knowing that you had to sort of like make some sacrifices during say a high pressure time in your life this pinnacle period of your career even, that there had to be some tradeoffs. Not to say that your back is worth it, but just this idea that sometimes we do things, we sacrifice certain things, but I'm okay with doing it only if I know it's for a season,

a sustained amount of time with constraints applied to it. There is an ending to it. I know when it is. I have a plan. That can be something I can get behind, but there's even some downsides to that too. What do you think? I'm okay with that. I think that there's a time and place for those things, and I think that you can essentially time box those and say, hey, we're going to put it on a clock.

A good example of this is going back to the acquisition. My wife and I had very explicit conversations about what I was and what I was not going to be doing. And at one point, I lived in a hotel in San Francisco. Not very many people knew about it because I needed to be down there to do certain things with people around. And I didn't make it home very often in a two-and-a-half-month period. But we had a very explicit conversation. It was only going to last for a certain amount of time until something either did or didn't happen. And at that point, then we move on to an alternate plan.

I could not live that way indefinitely. And I intentionally had to have a conversation about it. But I do think there can be seasons. And I think you can go through bursts. Projects go through this all the time. There could be a steady state for a project, but there needs to be a burst in the middle and then another burst towards the end. But they don't need to always be that way.

Well, Jason, I feel so much more wiser having had this conversation for many reasons. One, you blew our minds around the acquisition of GetUp, unexpected part of the conversation, very much appreciated. And I'm definitely going to, there's some of the books you mentioned I've read, some of the books I haven't, so I'm either going to Blinkist some of the books you mentioned I've read, some of the books I haven't, so I'm either going to Blinkist them and try it out. Blinkist, if you want to be a sponsor, you can reach out. Right now we're just promoting because, hey, Jared seems to love it and so does Jason, and I'd be willing to try it

because I'm down for anything. So I'll either Blinkist it or the arch nemesis of Blinkist, Audible. So I do Audible a lot. We would also appreciate an Audible sponsorship. We're not sponsored by either one one but we are open for both that's right but if you go back to that Corey Doctorow episode we did however he would say

sans Audible because of DRM and all those things if Corey's listening, Corey whatever your recommendation is sorry Corey but Jason thank you so much for sharing this story with us and your time with us and this wisdom. Absolutely. And we're much better to have you on the show.

Thank you. Thanks for having me, guys. Wow, what a story that Jason just shared with us. Let us know in the comments what you think. ChangeLog.com slash 395. What was the most interesting, fascinating part of Jason's story in this phenomenal acquisition story of GitHub and Microsoft. Open up your show notes and click discuss on changelog news. We'd love to hear from you. And we get asked this all the time. What's the easiest way we can support you? Well,

the easiest way is to tell your friends. The best way for this show or any of the show out there, any podcast really, is word of mouth. Tell your friends. Send a text. Send a tweet. Write a blog post of your favorite podcast episodes each month. That totally works and helps every podcast out there. Of course, thank you to our awesome partners, Fastly, Linode, and Rollbar. And thank you to Breakmaster Cylinder for those awesome beats. And one more thing, we have a master feed that brings you all of our podcasts in one single feed.

It is by far the easiest way to listen to all of our shows. Everything we ship is in that feed. You'll miss nothing. Head to changelove.com slash master to subscribe or search for ChangeLove Mastery in your podcast app. You'll find us. Thanks for listening. We'll see you next week. All right. See you next week.