The CTO Show

Welcome to a new Cloudflare TV show that I've invented called, really imaginatively, The CTO Show, where I'm going to talk to other CTOs about what it means to be CTO. And the reason I'm doing this is that I think this is a much misunderstood role. It seems to mean different things to different people in different companies. And I'm very, very privileged to have Jason Warner, who's the CTO of GitHub, as my first victim or guest, depending on how these next 30 minutes go. Jason, welcome. Thanks, John. Thanks for having me. Well, thanks so much for doing this. My idea was that people don't really know what CTOs do. So I figured that one way to do this was just for you and I to talk about what we actually do all day without revealing any secrets. So what does it look like for you, a typical day, if it's a typical day? Well, when we first started talking about the show, we said, hey, what's the day in the life of a CTO? I just laughed because, as you said, no two days are ever the same. No two roles are ever the same. And it almost seems like every quarter or half of the year, the role gets reinvented and changed too. So my day as CTO now looks very different than my day as CTO a year ago and then two years ago. So my day now, I run a labs group, essentially, at GitHub called Office of the CTO, or Octo, which is cute because our mascot is the Octocat. It's an octopus. Very nice. Yeah. But what we do is we work on what I call horizon three things at the moment, things that may or may not ship on GitHub for two and a half to three years from now, essentially, but where we need to go kind of de-risk or answer questions or things of that nature and really strike out a lot before we figure out a way to go do something. Good example of this is, not that it's going to ship anytime soon on GitHub, but one of our more successful early projects was reimagine code search. What if we just reinvent code search on GitHub from the ground level, all the way up, throwing away a whole bunch of different concepts and trying to invent new ones? And we experimented with a whole bunch of different things for about three or four months. The project got to the point where we felt, hey, we think we understand the shape of what this would really look like. And we could see a couple of different paths. We wrote up our findings. We put the code in a repo. We put a whole repo together for it. And we presented it to the engineering product organizations that we think we have this thing that looks like it could be something. Do you want to take it over? And they did. They took it over. They're working on it right now. Expect to ship sometime within a year or so, probably, maybe a little bit longer, depending on how it goes. But that's what we're doing now. And you have a small team of staff engineers who work with you on this kind of stuff? Yeah. So the way I've structured it is we have I think we have 13 people in the group at the moment. This is live TV. So I get to let the cat out as part of this whole process. You were telling me about the structure of this. Yeah. I've got 13 people or so. But the way I've structured it is essentially I'm trying to staff engineers and what I call principals. So I have a couple of principals that report to me for various areas that they want to explore. They themselves are known industry people who are very deep in one specific domain. So I've got one right now that's exploring data and another one who they're going into the code search in code. Let's just call it code intelligence area. And they own those areas and it is very deeply exploring them. And so it makes it easy to bring up other efforts because if I wanted to go into running coded production, you find someone who's very passionate and has deep industry domain expertise around that and they hire a couple of staff engineers or bring some over and work on it. And then do you hand over the project to the product engineering team? Like, hey, we built this thing. You guys make sure it really works. So the way we have described this so far, yes, to this point, we've handed over all projects. There is a thought that there might be a team from the office of the CTO that goes over with the project to bring the continuity with it, though we have not done that yet. But we are thinking about that right now for our current project that we're working on. The reason why is that the project itself requires such deep domain expertise that we have those folks and it would make more sense for them to go over with it. But even so, maybe I think there's nine people working on that one right now. And I suspect that five might go and four might stay. Something like that. It's interesting, isn't it? How do you deal with these different sort of innovation styles? Cloudflare has actually three separate engineering organizations, basically. We have the main engineering organization, which is building the product that everybody uses, that's got strong product management, deals with customers and all that kind of stuff. We have the team that works for me, which is actually primarily the research team, which works with universities on really long term stuff. We published a thing the other day about trying to replace captures with something else. Really sort of super experimental stuff. And in the middle, we have this team called Emerging Technology and Incubation, which is working, I think, a little bit like some of the things you're talking about, which is like, what's the sort of next version that maybe the product team wouldn't necessarily have time to do or spend time on? And it's been interesting, what you described is like, how do you hand it over? Because we've gone through different iterations of that. And right now, we actually take the entire team and hand it over. I was thinking about when I started this way back, maybe about 14 months ago now, or something like that. One of the really important things that I needed to do was say, one, the group does not represent ivory tower thinking. Two, it's not the innovation center. This is not where innovation should happen inside of GitHub. It just happens to be that we're experimenting on specific areas. And three, we should be able to rotate in and out of the organization. So some engineers want to come in and work on something very interesting. We have the requisite conversations with engineering leaders and others, and they can rotate in and work on it. But yeah, it's like no one size fits all works anywhere, even inside the same organization. So you have to be kind of flexible with how you do that. Which is also one of the reasons why I like working at a place like GitHub in that scenario, too, because you can have those conversations. Whereas if you're at Microsoft, it feels like, no, no, that's not how we do it. It just happens this way. There's a procedure for this. There's a document somewhere that's 500 pages long that tells you how it works. Yes, yes, yes. One thing that's interesting, isn't it, if you get into a startup that becomes successful, I think there's this temptation I've seen where people look at companies that are a company, and they say, what do those companies do? We should do whatever they do, because that's obviously the right thing to do, because they've got 10,000 people, and we've only got 2,000, whatever. And I actually think what you're describing, which is that ability to have a conversation about, well, does this work for us, or does that not work for us in our scenario, is really, really important. I give a talk to startups called Architecting Teams for Scale, and it's all about company building. It's really what it's about. And the concept is two people in a garage all the way to 5,000 people, and how it works. And the one thing I tell them at the very beginning is, one, even everything I tell you is a singular data point. My experience is, you need to almost amalgamate mine and other people's information, and figure out your context, and what to throw away from even what I'm telling you. So don't take what I'm saying for granted. And two, just know that along the way, there's no hard rules. Everything is like this weird, flexible amoeba, and you've got to kind of work and shape it. And it's always in place. Everything is always in place. Always, yeah. Yeah, I agree with that. And actually, when we're hiring, we try to hire people who like that flux happening. Because if you hire people who would like the Microsoft 500 -page document, then they're going to feel sad working in an organization where everything changes. Well, the other way to think about this too is, as a cloud player, you probably understand this given that you were there for quite some time. I talk about this when startups are trying to hire their first outside executives. And they're saying, well, they worked at Google, or they worked at Facebook, or they worked at whatever. And I said, there's only a singular question you need to ask. Because people can be in a company, or they can be of a company. And can they bring the structure, or do they benefit from the structure? And if they can bring structure, that's what you need. You need some people who can pave paths, and lay down track, and all that sort of stuff. But if they would benefit from the structure, and they don't fully understand why, then it doesn't matter what their resume is. It's not going to benefit you the way that it benefited them. Right, right. That's a very, very good point. And one of the things I often say to people, because Cloudflare has this unusual hiring procedure, which is everybody who gets hired at Cloudflare talks to one of four executives, basically. So Matthew, Michelle, Janet, and I. And the four of us speak to anybody across the board. And many people often ask me, what should I do in my first, when I join Cloudflare? And one of the things I say to them is, you know stuff we don't from your previous experience. And also, we're living in a world where we may be blinkered by our own experience. The most vital thing is, before you get completely indoctrinated in the way in which Cloudflare is doing, I need you to stand up and say, why the hell did you do this? You know, this doesn't make any sense. And then that will actually help us grow. So there's this moment of very critical beginning bit where they're going to be in this confusion, and they can bring that experience in. And that accounts at any level. It doesn't matter who you are. That is amazing. One, it's insightful. And I think it's, I've not heard of other people kind of thinking of it that way. But in fact, I'm going to show you something. This is like a notebook that I had about my joining GitHub. I joined four years ago. Right, right. The very first two pages of this, it's all about like what I wanted to do, was, there's an underline in here. You know, I built this thing up with a month or two leading up to joining GitHub. It said, do not take a single task for two weeks. And it said, remember, you will lose perspective the moment you enter the building. And it said, you need to use the outside perspective a lot to start because you will then become mired in the fight, the daily fight. Absolutely. Absolutely. I mean, that's such a good way of putting it. I mean, you just get, I mean, I'm sure there are people would look at the way I do things like, why do you do that? And I'm like, well, I've done it like that for the last year or something like, well, that's dumb, you know, whatever. I actually got this idea because we moved into a new place a little while ago. And after a while, I was looking for a frying pan. And I was like, why is the frying pan in this cupboard over here in the kitchen? I'm like, actually, it's in that cupboard because we put it there when we moved in because the movers were unpacking everything. And now it's like there, but it's nowhere near the cooker or the other pans. I'm like, well, that's exactly what happens in companies. You get used to this. Well, you have to ask so-and -so about that because why? So yeah, that's a very good point about getting people on board. There's a funny story. A very, very funny architect from Salesforce gave a presentation to Heroku way back in the day about Salesforce core architecture, which if you know anything about Salesforce for architecture, you look at it going, what happened here? Like there has to be some sort of like Lord of the Rings story about how it ended up this way. And the architect is hilarious. And he said, listen, like this started in 1999, way back when, when things didn't exist or blah, blah, blah. It's like the architecture is this way because it got that sort. Does it really matter to you how it got that way? But the point being that like, you can second guess decisions that were made in 2001, two, five, seven, but it also doesn't matter for today because what we have to figure out is where to go forward. And that obviously is very insightful from an architecture perspective and also frames how you might want to approach a problem. But it applies to everything for me, like the company, my career, the way I approach, I don't know, fitness, like my, you know, I am this way because I got this way, but so let me introspect how I got here, but also then really what to do going forward and what I want to happen with that. Right. Right. It's interesting to say that because one of the things that we've, you would have seen this when you go through something that grows very, very rapidly, the thing you built yesterday or a year ago is completely unfit for purpose in the new world because you've scaled up so much. And people always go, we actually had this discussion like seven years ago with somebody on the sales team said, well, why didn't you build it right the first time? And I was like, at the minute I was like a bit taken back and I was like, it's an interesting question. And the reality of the answer is you're building on axes that you understand and there's some hidden axis that you haven't actually understood yet. And something as you scale up, it's like, oh, wait a minute, this is going to happen on this axis. And my thing is not in the right position. So I have to inevitably do it. You end up building the thing you know is the right thing to the moment you're in. And inevitably, you know, it's, it turns out to be wrong at some point in the future. It's one of the more interesting things about the industry too, because post hoc storytelling means that you actually have more information now to tell the story than when you were making the decision. So it can be richer and kind of enriched as well. We talk about that. I mean, I've only been in GitHub now for four years, but when I joined, what I was running, speaking of the CPO job, what I was running when I joined GitHub, I was running product engineering, security, product design, data infra, support. I had BD and corp dev for a little while. GitHub was an interesting place, but that's what was my role. And, you know, like GitHub Actions came out of that, GitHub Packages came out of that, a lot of the security stuff that you see came out of that. But if you were asked me to tell the story about how those things came to be today, I would sound like Albert Einstein in product design. I could, I could tell you all the rationalizations that make sense now and like what we've learned since. But back then, it was, it was like that vague notion of a kernel and a this is going to matter this way with this sort of thing. And I would also, you know, tell the story today, I would cover over some of the mistakes. I'd be like, yeah, I totally didn't mean to do it that way over there. So what we learned from the customer feedback, as opposed to like, oh, we totally boneheaded that one, you know. Yeah. Well, it's slightly, it's a little bit survivorship bias as well. Cause there's like something, some feature that was like, well, that was genius. How did they think about, you know, I don't know, GitHub Actions or something. And it's like, yeah, but there's the five other boneheaded things that didn't go anywhere that we thought about the same day, you know, and you sort of, you'd look like a genius if you were able to look backwards and see this thing in the other direction that's harder. So yeah, it's interesting. So tell me a little bit about that, that, that role change, because something that you just said really resonated with me. So I joined Cloudflare as a programmer. That was my title was programmer. And I had done lots of management stuff and I'd had it with managing people, which is going to news to the team that works for me. And I joined to actually write some code and I did actually write a load of code for Cloudflare and Lee Holloway, who was the technical founder of Cloudflare, no way did he want to manage anybody. It was just not his thing. He liked being inside Postgres writing stored procedures and just architecting the whole system. So at some point, Michelle Zatlin, who's the COO now says, John, can you temporarily take over running engineering? This was about seven years ago because Lee doesn't want to do it. And I'd done it before. So I reluctantly was like, okay, I'll run it remotely. But I also had IT, I had the security team, but he was like, anything that looked vaguely technical reports to you and you can run it. And then eventually I managed to sort of extract those things. So this is, it's interesting just to hear about a little bit, if you go back sort of six months, a year or whatever, like how has the CTO role changed for you? So I mean, definitely a, probably a more unique situation than most two, given that on one side of the fence, we were an independent company and the other side of the fence were a Microsoft sub-entity. On the other side of the fence as an independent company is where I was brought in. And if you know the story of GitHub and Cloudflare's offices and GitHub San Francisco offices, literally across the street from each other. So we know each other decently well there. When I joined GitHub, it was at one of its more lower points. And the CEO was stepping out of the business and just wasn't involved anymore. We didn't have a head of marketing. We didn't have a head of, I think we had an interim head of HR at the time who then became permanent. You know, product engineering, security, product design, none of them had heads. They'd all moved on or been let go of that nature. So I kind of knew what I was getting into. And my background is I'm a distributed systems engineer. I've been an engineering executive now for 10 years plus or 15 years plus, and 10 of that was running product as well. So I kind of had the sweet spot of like, I know how to run very large distributed systems, engineering teams, and I happened to be a product person inside the developer space. I kind of think I was basically like grown in a lab to go run GitHub engineering at some point. And it just kind of aligned. And the other side of that fence, after we built the things for GitHub and put the structure in place and kind of got engineering refocused and executing again, was I was working on the first version of GitHub Actions, which was a partnership play, a very intentional version of that. So fast forward, that is what led to the acquisition. We started to really push that forward. Now, on the post side of the acquisition, I look like a risk. So of 1 ,000 people inside the organization, 800 of them reported to me. And when you're Microsoft looking at a singular executive on that side of the fence too, oh, and subtle detail that I left out is I had a single trigger in my contract. So you know how that would look from a Microsoft perspective. So what I agreed to was that no matter what, I would start transitioning some of those duties to other people to de-risk the situation from myself from a single point of failure in that whole scenario. And on the positive side, I told them what I really like to do is I like to run engineering teams or I like to run those really long horizon experiments, the things that we are talking about. I have no issue running engineering teams or managing people and building the organization that way. I just so happened to also like this other thing. And I said, this is how we would like to run this. I was like, great, let's figure that out. Got it. Interesting. And one thing you haven't mentioned in all this is, you know, one of the things I end up doing quite a bit is dealing with our customers and dealing with public kind of stuff. So the press and things like that, has that been a thing for them from, I mean, maybe get outside of the company. Yeah. As a CTO now for the past year, no, that is not part of my job with the press. I do go talk to customers a lot. I happen to be quite good at customer facing things, or at least customers think I'm good. You never know. So I do a lot of customer stuff. Before the change, when I was running product engineering, all of them, that was at least 25% of my job, press analyst, as well as customer duties. But the press and analysts have kind of gone away. And now I do customer calls. I have a book of customers that I go and talk to on a regular basis. They happen to be, you know, some of the more technical ones, like with really deep infrastructure routes. Do you understand the type? And, you know, because you dropped me in from that, from the height of that and their engineering teams and I get along really well. Right. Right. So I was going to flip back to something you mentioned this, you know, training people on going from, you know, zero to something, something much larger. One of the things I've sometimes seen is really small companies, like it's like three or four people and somebody announces that they're the CTO of that company. And that's always given me a really uneasy feeling. And the reason it's given me an uneasy feeling is you don't really necessarily know that person should be the CTO long-term. And you're kind of hemming yourself into this thing where what if you have to take that title away? So I've always been, I think Cloudflare was very much like a don't give people crazy titles. I mean, basically Matthew's title was CEO because somebody needs to be CTO. Michelle, who was the other, you know, co-founder, her title was head of user experience, which was sort of a title. I'm not quite sure what it meant. It kind of gave her a title, but there was one there. Now, of course, she's COO and we're a public company, it's a different matter. What was your thinking about when, you know, when do you give someone the title CTO? This is a difficult one because it's always like, you know, if you're doing any sort of angel investing or investing with friends in VC and you see four co-founders walk in and each one has a C title, you're kind of like, well, hang on a second, what's going on here? You know, I think with the CTO title in general, co-founder status kind of gets you the one time I think that you can get that CTO title at an early stage company. And even then, I mean, I think that has to do more with co-founder status than it has to do with what your job responsibilities are. Because I would imagine if we actually dug through the data and figured out how many co-founder CTOs are still with the business 10 years later, it's a pretty low percentage. Anecdotally, they tend not to be involved in the business or they tend to be still on the books, but no longer coming to work type of deal. My recommendation, if you don't have a CTO and you're thinking about how to grow, is that title becomes one of those that's kind of off the table until you get to probably post A approaching B series, because you should get away with a lot more with heads up, as you mentioned, even in the Cloudflare situation, either heads up or like heads up might equate to director in some places, but like use that title more appropriately because it becomes more malleable. CTO is almost a static moniker. And even if we don't really know what it means, it's very difficult because then you end up with a conversation of should the VP of engineering report to the CTO who doesn't like to manage people, but it's VP of engineering tends to be a people oriented position. And many very experienced VPs at E do not want to report to the CTO. They want to report to the CEO. And so it makes things more complex. It introduces risk, which is the main job of executive organizations is to reduce risk inside organizations. So why bother doing that to yourself? So I would resist doing as long as possible, but that means that there's egos involved and you know how that works. Yes. Yes. And it was interesting in Cloudflare is that I started being called the CTO externally before anybody told me internally. I mean, Matthew would sometimes introduce me as, oh, John is the CTO. And I remember one time thinking I am, like I didn't know she told me that, but it was like, it's useful externally. It's very useful externally. And I think it does present a thing. The problem is, I just get stuck with this is that companies are kind of weird entities and organisms of themselves. There are no lines ever in the world in general, in companies in particular, there's no lines anywhere. And yet we create these imaginary boundaries for ourselves with organizations or teams or divisions or titles that somehow box us in, in our thinking. And titles in early teams are one of the simplest ways to become, go from a dynamic thinking perspective to a static thinking perspective. It's like, oh no, that's technical. That goes to the CTO. That goes to Susie or Johnny. Yeah. Yeah. That's very, very true. I think it's one of the reasons I think we use the title head off for a long time is it similarly from a structural perspective, from a management perspective, it's not quite, it's not quite so rigid. It's not like VP of something or SVP of something. It's like, okay, there's, and for a long time, the head of engineering did report to me. And then eventually we're like, oh, this doesn't really make any sense anymore. They should report directly to the, to the CEO. We moved it out. And that, one of the big things there is, is to go back to ego thing, which is to say, look, let's not have big egos about being deep structures or who reports to who, let's figure out what's best for the organization. And as you say, once you lock yourself into, you know, John's the CTO, you, you, you get this problem. One of the things I actually say to people is people sometimes ask me something about some product or some architectural thing, as if I know, because I'm the CTO, as if I know everything. There's like 2000 people in Cloudflare. And usually what I say to me is like, I'm the worst person to ask, because I have the least amount of information. I'm right at the top of this pinnacle thing. And now most of it doesn't report to me. You think I know what's going on? I need you to tell me what's going on. So please come to me and tell me. That, that is something that's very strange for programmers, particularly when they become engineering leaders. And then, you know, in this role to CTO is I always felt when I first, first did this many years ago, I always felt I had to know what was going on. And now I realize that it's impossible to know everything that's going on. You have to get comfortable with saying, don't know, but I'll find out. Yeah. You know, and that's a very uncomfortable thing for some people to be able to do. It wasn't comfortable for me, but once I got comfortable with it and I realized that's kind of a superpower, like, yeah, I don't know. I'll figure it out. Yeah. Yeah. Or I'll ask somebody and they'll tell me, like, I know that team is the one where I can figure this stuff out. So yeah, I usually try to, I convince myself I can keep doing this job if I'm still smart enough to understand what somebody's doing when they tell it to me. The day that I'm not, then I probably shouldn't be doing this job. Right. And there, and there are certain areas where I'm like, particularly on the machine learning side of things where I'm like, yeah, I'm glad you understand that in depth. Cause I'm not sure I do understand that in depth, but in general, it's like, am I smart enough to figure it out? Not do I know it? Yeah. Well, this is where I, at least from my background, distributed systems and complex systems thinking, it really does help. So again, the machine learning group, the AI group is a good example of this, which is they can tell me all the way that they're doing something and they can tell like, oh, you're not fully understand what's happening here. I'm like, no, but I understand the input and I understand the output. So as long as I understand that part for now, I'm okay. That could be a black box for me for a little while longer until I figure that out. Well, also you can, and then you can ask them about the sensitivity of that system and you can ask them how you tune it and what are the levers and all this kind of stuff and how you measure it and all that kind of stuff. And then you can get comfortable with it. You're not right down there at the, at the bottom of it. The most striking one for me here was that when I, at some point I was talking to one of the crypto people at CloudFront, I have a PhD in computer security, where we did a bunch of crypto stuff. And they're like talking about elliptic curve cryptography. And I was like, why do I not know this? Am I forgetting everything I did at university? And I was like, wait a minute, this was invented after I left university. That's why I'm just old now. So I was like, so you, you know, you're constantly having to relearn because new stuff is coming up. You know, you just can't rely on the, on all that stuff that was 30 years ago. It's, it's, it's passed. That is very true. Actually, I mean, CTO jobs in general and executive jobs are, you should be amazing learners. I joked with somebody a while back, he said, what's your superpower? And I said, don't know if I have any, but if I felt like I, the thing that unlocked a lot for me in my career was I got really good at Google and I can amalgamate information really quickly. It's amazing how much of my time I spend reading things. If I was to actually like, look at people say, what do you do every day? And it's like, this is big blank spaces on your calendar. I'm like, yeah, you know, they're not blank. I'm not literally just sitting here, you know, drinking tea all day. It's like, I have to, I have to read a lot of stuff and assimilate it. And it really is part of the job is doing that. It's not, I don't have the instant architecture, like all sketched out in my brain, this is where we should go. It's like, no, I have to figure out what's going on. That is something that I think that younger engineering leaders and particularly younger CTOs earlier in the career don't fully understand when I have these conversations with them, which is minds work very differently among all of us. But that part of my, part of my process in these things is I don't have the architecture. I have like this vague notion and a bunch of like cloudy pictures where you can see like maybe the top of a building poking through or a mountain over here type of deal, like, but it's not fully baked. And you're kind of like, I think I understand what's going to, what it might look like, but the more you read, the more you, you hone it, the more you roll it around in your head, the clearer the picture gets, but it's, it's very difficult because you can't draw. It's almost kind of like, it's a whisper. He's like, you can't draw it just yet. You've got to let it sit and bake for a little bit and you keep, keep, and then, you know, I use different processes for pulling these things out too. So I have a bunch of friends who, who, who will stress test it verbally. Some people want me to try to explain a specific process, but you have to use all these different ways because that is like how you will harden your own math, if that makes any sense. It makes absolute sense. Well, listen, we have 30 seconds left to go on the CTO show. Thank you for being the inaugural guest. It was great. It was absolutely great talking to you. Very nice to have this discussion about, it's my CTO therapy session anyway, about what it's like to be a CTO. We're going to do another one of these on Monday, but thank you, Jason Moore, CTO of GitHub for being here. Have a good day. Thank you.