Successfully Managing The Hyper-Growth Stage

Please welcome Julio Avalos, chief strategy officer of GitHub, and Blair Hanley Frank, staff writer at Venture Beat.

Hello. Hello everybody. Hi.

This, I have to say this is profoundly weird for me. I knew it was going to be profoundly weird for me when I got up here and got to sit behind a desk, but it's profoundly weird.

I feel entirely comfortable.

Well, you're the one in the cushy armchair.

I am.

So, hey, to get started, I'd love to hear a little bit about kind of who you are, what your background is and what brought you to GitHub and what your background there is.

Sure. I've been at GitHub since 2012, joined right after the Series A and I think, and I'm sure we'll get to this maybe, or we might 2012, the company had just done its Series A, but was already a four year old company with close to 100 employees. And I think that's unusual and that GitHub has always had that. But I joined GitHub from, I'd been at Yelp from for a couple of years before that was an attorney, was a practicing lawyer, had moved out from the east coast not knowing much or anything about Silicon Valley. One of the biggest fights I remember that I had with my girlfriend at the time, now wife, we've been married 10 years, was she told me that she'd gone to Stanford. And I being an east coast person, and not just that, but also being a child of immigrants who no one had ever taken the SATs or gone to college before I did, I'd never heard of Stanford. And so she says, oh, you know, I went to Stanford. And I said, oh, what is that? And she looked at me really puzzled. She's like, are you serious? Stanford's like Harvard. And I said, well, I've heard of Harvard, but so just a frame of reference for, you know, as of 10, 12 years ago, I was not a Silicon Valley creature. And I think that in a lot of ways that's been helpful to me, not always knowing who it was in the room that I was supposed to defer to orthogonal thinking or whatever it is that people out here say. So a little bit of an unusual, I think background but at GitHub. So I joined as the general counsel and I joined at some high water mark in 2012 of GitHub. Anarchic weirdness where we were right around 100 people, maybe a little bit over. No, managers weren't going to have managers for another year and a half or close to two years, I think from that point. And we didn't have titles, we didn't have managers, we didn't have reporting structures. You weren't on a team, the onboarding at the time, somebody handed you a computer that was probably just had terminal because they hadn't been hiring anyone that was not a developer. I think probably 90% of the company, company at least, was technical at the time. And it forced me to think about myself differently than I'd ever thought about myself at any other company that I'd worked at, where I'd always been an attorney or a lawyer that happened to work at X company or that happened to be representing Y company. And at GitHub, because you didn't start off with your function and your title didn't necessarily precede you. I was a GitHub employee and I was a GitHub employee that happened to have this skill set that was different than what other people in the building had, but that was no better, that was no worse. And that's something that I think that we've tried to maintain, even though we're now several years out from instituting more of a traditional reporting structure, organizational structure. You're a GitHub employee first and foremost. So for me, I've had a number of different titles and my role has changed over time at the company, but I've always, and I would like to think that we'll be able to continue that sense of, okay, you're a GitHub person. And that, I think, has had a big role in maintaining a consistency in. Well, what does that mean? What are the values? What are the. How do you work? How do you collaborate? How are you empathetic with your co workers and that you really start from there and then you apply. Okay, your particular expertise or your particular function. And even though we've instituted, I think, more of a hierarchical, more traditional reporting structure, it does make for a flatness in how we relate to one another, how we think about one another across departments. And then as we've grown, I think that that's one of the things that's really been able to kind of hold things together through these periods. And we'll talk obviously about. About hypergrowth, but the idea that you're no better, you're no worse, if you're not here as a salesperson and if you're not here as a PR person or comms or an engineer, the thing starts to fracture and fall apart. So I think that that level of cohesion is something that's been important for us at GitHub. And that I hope that we're able to continue even as we continue to see the growth that we've had.

And so it's, it's interesting that you mentioned that sense of cohesion because one of the things that I enjoyed talking to you about and preparing for this was kind of your definition of what hyper growth is and what that means.

Right? Yeah, it's interesting for me, the number of times when I talk to, and part of the reason that I like this talk and the conference, getting a chance to speak to other people who are operating, who are managing. Even the prompt for today's talk, managing hyper growth, really to me speaks to as a human being who's sitting in that seat, who's helping to build this company. How do you manage that? How do you manage yourself? How do you think about it? So in the literature, hyper growth and you see any kind of difference to stats or rules of thumb where you've doubled the size of your company over X period of time or you've hired this many people in a quarter, I think more foundationally, hyper growth is any amount of growth we, within your business, within your workforce, that stresses the systems that you currently have in place and that requires you to iterate upon and grow those systems. So I'd say that for us, hyper growth, I've never been, we've always been in a hyper growth stage. I think since I got to GitHub before I joined the company, I think we doubled in size in the 12 months leading into it. I think that the community, similarly, you think about the amount of developers, we've gone from 2 and a half, 3 million people maybe back in 2012, to 25, 26 million people developers using the site today, 70 million repositories, and it was maybe a third or a quarter of that several years ago. So you can have all of these metrics, but internally, when you're operating your business, that sense of tension where, oh, like, we need to adapt our onboarding process because we've never had a class of 15 people before, we've never had a class of 30 people before. How does that work? As I'm walking around the building, the monitor doesn't work, the door is broken. Whose job is it to think, okay, like, we have a different scale of issues, we have different needs that we hadn't thought about before. So anything that puts, I think, a stress on your current system and that requires you to iterate upon it, you're probably in some level of hypergram growth.

And so that seems like a pretty good Definition for what it is. Yes, but how do you figure out why that's happening?

Right. I think that's a great, It's a great question because knowing and understanding why you're going through hyper growth or even whether it's something that you want to be engaged in and asking yourself why that is and then writing it down, I think is one of the most important things that we've learned in our own experience where we assume, and I think that the tech industry as a whole is reasonably criticized for being overly infatuated with growth for the sake of growth, disruption for the sake of disruption. Even innovation maybe is different, but I think that growth and disruption for the sake of themselves and you lose sight of growth towards what? Growth for what reason. And as antithetical as it might be, I think in the Valley and in tech and startups, generally speaking, even questioning whether or not you want to be in hyper growth is as reasonable a first question to ask yourself as any. And that if you. And that I guess, is on a kind of, on a macro level, on a slightly more granular level, trying to understand what it is that is working is one of those things that you don't often have the opportunity to ask yourself. And that if I think back to GitHub when I joined and what learnings we had to go through over time, it's interesting, the four years of being bootstrapped and then this external validation that we had the clearest sign from, let's say, the business side, the clearest we had validation of the product market fit, maybe the developer love the brand, all of these things were working, but it wasn't until you have this imprimatur from what you think of as some of the preeminent business minds in the Valley and in the world. And I think that we didn't maybe take stock and stop and ask ourselves, how do we isolate which parts of the business are actually leading to this validation? And what we did, and I think in typical GitHub fashion, where we always kind of cranked everything not just to 10, but in a spinal tap way up to 11, we doubled down almost on everything that was going on at the company in 2012. And we wanted to do more for developers, we wanted to innovate more on the product and that's as it should be. But we didn't have say, we didn't have a sales function at the time, we didn't have a marketing function. We were primarily developers and we thought that we'd been very successful with that sort of composition in mind and didn't poke at what those assumptions were going to be moving forward. I think even the organizational and the operational structure that we had, that radical flatness, stopping to isolate, well, what role did this play in our branding? What role did this play in our capacity to be nimble and to be innovative? Do we want to do more of this? How do we start to run some tests on maybe we structure this team a little bit differently, anticipating what we're going to be 12 months from now, 24 months from now, we just doubled down on everything. And that I think obviously GitHub has continued to have success, but that we took a few knocks along the way as a result of that. And one of the things I think that you see a lot in the literature around managing your business, let alone managing a business through Hyper growth, is trying to find that cocktail, those things that are repeatable. And I think that's right. We needed to stop and think, okay, like this thing has been working until now, how do we do more of it? But stopping and thinking about whether it's going to be repeatable, I think misses a little bit of a point around repeatable until when? Repeatable right now, what's been working in our community up until this number? Are we just going to repeat that? Are we going to keep that going as we double, as we triple, as we quadruple the revenue or the size of the community? So really understanding and writing down your own assumptions about what you think is working in that business and then teasing that out, pushing on that, I think is really critical. Hiring people externally. And one of the big things I think, in managing hyper growth is always about the talent that you have and the different, the variety, the taxonomy of functions that you end up with at a company that you don't necessarily start off with. And it's obvious, I think, to say, look, we haven't had to have a sales function and now we need to go out and hire a head of sales. But more fundamentally, the value that you get from a new hire on poking at your own assumptions, questioning your own Kool Aid, kind of. Because I think that GitHub, we, not only I think we're drinking our own Kool Aid, but we're swimming in it. And that's true, I think, across the industry where it's very easy to get to fall in love with everything that's going on in your own business and that when you're helping to run these things, ego ends up playing, I think, a remarkably large role in managing what your own responsibilities Are your own assumptions about how the business needs to function in order to still be GitHub? In order to still be GitHub Y pushing on that I think is really important. And new hires, if you're not hiring folks so that they can come in and help push you and question you, you're missing a real opportunity. And then I say that, but at the same time balancing that out with what are your North Star convictions, what are the values of your company? And I think that also writing that down is something that you need to do as you're managing and operating your business. And what are the things that you think, regardless of what the composition of your team is, regardless of what the composition of your community is or where you're expanding internationally or whatever it happens to be? What still makes this place GitHub, what still makes this place Acme Corp. Or whatever it's going to be? I think that's important. I think it's really critical. And then I think figuring out a regular cadence, whether it's quarterly, whether it's annually, do these things still serve us? Which elements of this have continued to lead us to be successful? And I think at GitHub it's always begun and ended with a commitment to the human being at the center of the development process. The, the idea that software doesn't just fall from up on high or somehow self materialize. On my iPhone, there's a human being that built that. And I think that one of the things that GitHub we need to, that we've been doing and I think we maybe want to be doing more of moving forward is the humanization of technology, period. That there is a genuine sense of like, we take it for granted that people here recognize that Google is a company that was made by human beings. The Internet is handmade. That's an Earth theater track, I think of Brooklyn artists, but the Internet is handmade. And that I think has been this common thread that we have had at GitHub where, okay, we've got some new feature and we want to push more on data and automating. Things that can be automated or artificial intelligence, whatever it happens to be be, how do we route that back in terms of who that's going to be in service to? And what does this do for a human? What does this do for a developer that's always been this kind of critical, foundational idea for us and everything else, I think ends up kind of falling into place and is maybe open to evolution and to transition. But that fundamental, not losing sight of that Human being. Is this growth going to be good for the developer experience? Is it going to be good for the employees that are inside of your building? I think that that's really the first question that people should be asking themselves.

I wanted to go back to something that you said about writing down the assumptions that are underpinning a business as well as questioning them. Because I think from a very basic level, it can be really easy to be like, okay, we figured out what the assumptions are. Here are the assumptions. 1, 2, 3, 4. Okay, great, we've written them down. Do we want to change any of them? No, they all seem pretty fine. Because as an organization, you've integrated and ingrained these assumptions and so great. Okay, we've checked that box. We can move on. Like, what's the. How can you be successful at actually going and doing the work and interrogating them beyond the sort of like surface level? Okay, cool. We've checked the box that these.

Yeah, no, I think it's the right question. It probably ends up boiling down to triangulating from there to what's in your own head to where you want to be. And I think that that vision statement exercise that maybe feels very basic and facile ends up if you really use that as an alignment opportunity or to be able to question whether this mission statement is. And these things that you've written down. If the vision is to be a global platform for X, if the vision is to be to go after a particular community, how is that person going to respond to this stuff that we just wrote down? One of the things I think that we found is we expanded more internationally, certainly on the business side. Developers, in our experience, developers tended to be developers almost regardless of where they were and the tool was functional for them. And beyond functional was providing a great experience as we went to market outside of the United States and maybe even outside of the Valley, leading with a developer first kind of messaging that wasn't always the right thing for your Procurement or your CIOs or the CTOs or the Technical decision makers in Romania or places where they have all kinds of different assumptions around how they're going to buy software or what they think they're getting in exchange for buying software. And if you think about, you know, Twilio, like, ask your developer. I've always thought that was just, you know, I've always wanted that and it's gold. You show up in a different market where they don't care about the developer necessarily and their main KPIs that they're being judged on are productivity and cost. And you're going to have feature parity. And it's a completely different conversation when people are like, why am I going to optimize? You mean, Christina, like in the basement that we paid 20,000 kroner to, like, why? Why is that important to me? And it led to, okay, like, how do we question the assumptions even in what the go to market is going to be or what the messaging is going to be? Maybe we need to educate some on what? Not only on we do have the best in class, we do have this or that, but why you view the world in the way that you view the world world. Why the developer is so central to the future of your business and your industry moving forward and not just placating the developer, but how are you creating the best in class experience for them? That's going to be iterative, that's going to be fast, that's going to be nimble. That's something that we had to figure out. So I'd say, had we taken more time in saying, okay, how is this going to land in this particular geography? How's this going to land with this market? Is this still going to be true at 500 people? Will it still be true at 1000 people? And if the question, if the answer is no or the answer is we're not sure, then that, I think is always a place to drill down on. And when you happen to hit upon those rare things that continue to be true, regardless of where you see your business or where you see your company or your employees, then I think that you probably want to keep that. And that's some core conviction or some core tenet that you've got. But yeah, that's a good question.

One of the things that has dogged GitHub to an extent, especially a few years ago, is the company has had some fairly well publicized issues with, with workplace harassment and workplace culture. What are the things that you've learned from that? And what do you think other businesses, especially those who are hoping to grow quickly, hoping to end up in that same state of hypergrowth that GitHub is in, what lesson should those businesses take from it?

Yeah, it's an important question. And I think that we were really on some, you know, we took our hits early. I think if you look at everything that's been happening societally, et cetera, that we were front and center in some ways of this. The first thing that comes to mind, and I think that we were just talking about this, is that we didn't always question our own assumptions in terms of how the business needed to be structured. So we went way longer than any company should ever go. Before you begin investing in world class human resources, thinking that too many of the systems and procedures that we had in place, the openness that we had, well, you know anyone, we don't have managers. You can just talk about any problem that you have and the assumptions that you had within your organization. I don't think that we pushed enough on those. So I think the number one thing I think that and very basic is that the value of hr, the value of ch checks and balances and control and processes and why these things are important within your organization. That's something that we had to learn I think the hard way in some sense. And so I'd probably start there. I think the second thing that we've learned and that I've tried to focus on and really invest pretty seriously in is hiring and promoting women. Hiring and promoting people of color into positions of authority and power within your organization. The current composition of our exec team, I think with six or seven people, we've got three women on the team, several people of color in the organization and diversity there. If you're not putting, I think if just would take the sexual or the gender aspect of it, if you're not putting women in charge, then you are missing real opportunities for growth. And when you think about questioning assumptions at GitHub where early on we valued so much this idea of meritocracy and this almost kind of libertarian idea that look, there almost are no rules in the company is whatever you make of it and that there's no gender to that we're all able to have an open argument or conversation on some campfire thread somewhere without sophisticated people who are expert in unconscious bias, let's say without having that be a common conversation that you're having within your organization, it's too easy to just look at something on paper and say this is bias free. Like what could be more open and what could be more egalitarian or equal than this meritocratic structure that we've created within the org.

And.

And I think that what we learned was that it wasn't that way that we were dealing with structures and systems of conversation and communication that had deep gender bias within those things. That the idea that you're going to just argue it out in some way wasn't always people didn't want to operate in that way. And over I think there was probably an over inclusion or an over representation of people that didn't feel comfortable just being the loudest voice or the reasoned argument or the persuasive argument or whatever it is that we called it at the time. We didn't question those assumptions and we didn't question a lot of those biases. So I think that really taking an analytical and critical view to the systems that you have in place within your organization, how communication looks within your organization and what you're for looking leadership looks like within your organization, all of those things are things that you really need to be taking seriously. I think at GitHub, it's also been interesting that as our community has evolved, as our base has changed, as our customers have expanded globally, if we do not have representation for those voices and those perspectives within the company, it is not possible that we will be able to perform, provide the right product experience, business experience to those folks. The next several million software developers and users of all of our technology are not coming from the same places as where the last several million people came from. They're not coming necessarily just from Menlo park and from Stanford, they're coming from Detroit, they're coming from Pittsburgh, they're coming from China, they're coming from Africa, they're coming from India. So rather than thinking about diversity and inclusion and unconscious mind bias as kind of ornamental social responsibility factors within your business, how is this actually the long tail or the short tail and will be an existential threat if you do not take these things seriously. And I think that thinking of it in that way also caused us and causes one a business to really weave that into the DNA and the fabric of your organization so that you just don't have some ornamental DNI feature hanging off of the structure in that way. So we've learned a lot.

Yeah, for sure. Well, and so when you're talking about adding process and re evaluating personnel decisions and being thoughtful about how you do all of that, it seems to me like you can make a kind of very facile judgment there, which is we need to be moving fast, we need to be growing fast. We don't have time for all of this procedure that seems to be a part of a bigger, more calcified organization and organizational structure. How do you strike that balance of moving fast enough while also having the frameworks in place that you need?

Yeah, I think a, it's not easy. I think when I think back to early GitHub and I get asked a lot whether what could we have done differently in order to keep the anarchist kind of the no manager thing alive if we had wanted to, and I'm not sure that we wanted to, we would have needed way more process and way more bureaucracy than what we thought we had an appetite for. And that in some way the lack of process, the lack of structure leads to confusion which within your organization. Over the last couple of years we've tried different planning exercises, going to okrs or whatever. It happens to be viewing those things as less planning necessities or something that are being dictated from your operational function or whatnot and just alignment exercises. I think that you end up having way more loss of productivity and confusion within your organization when people don't know where to go for answers, when people don't know who the ultimate decision rests on. What is the process whereby we actually have a thumbs up or thumbs down for some decision? And I can tell you that early on when we didn't have clear structures for that or processes, I just got 50 sparkles and 10 thumbs up plus 100 emojis in chat. Do we have consensus? And at 25 people, yeah, sure. Like we had that. At 150 people I just got 30 zaps that I got a bunch of plus ones. Do we have agreement? I don't know. I mean, and that was increasingly kind of those questions and that without that bureaucracy and without those questions, I think that you end up spinning in place a lot at the same time, any amount of corporate bureaucracy that is ultimately not so streamlining that process or that you feel is too heavy is by definition redundant and unnecessary bureaucracy. And it's been interesting for us over the last couple of years how to unwind, maybe even in some cases where post introduction of managers we knew that we needed to over rotate almost in order to get back to center in some way. And how much of my job over the last couple of years, couple several years, has been almost looking at some of the stuff that we did in 2014 and saying, well, you know, maybe we didn't need 35 levels of engineering within that department or maybe this feels too heavy going back to some OG GitHub kind of way of, you know, this thing, let's question it, let's test on it. It's not nostalgia, it's not a brogram or kind of melancholy that we want to bring this back. What elements of the culture and what elements of the structure that we had back in the day would continue to serve us to be more nimble, to be able to develop faster and striking? That's a daily occurrence. I don't think that there's any magic bullet there but asking your employees, talking with your folks, hiring the right people to be able to ask those questions because you don't scale everywhere, I think that that's always critical, but that's a common problem for us on a regular base is striking. That balance between necessary planning to build a scalable, predictable business that will meet the needs of our employees, of our customers, of our users, while not going too far overboard, I think that that's something that every company probably needs to figure out for themselves.

One of the other things that I would love to touch on is you mentioned the necessity of bringing in new people to fill roles in your organization and the importance of doing that and bringing in new perspectives who can help you go and question the assumptions that you have. At the same time, in a world as culture obsessed, as the Valley and the startup world, where having a distinctive company culture is important, and a company culture that is your company, how do you get the right mix of free thinking with also somebody who's ultimately going to be a good fit for what you want the core of your business and your organization to be?

Yeah, I think that's another question that you deal with on a regular basis at a high level. I'd say that one of the things that we have moved towards is taking a lot of operationalizing those decisions. Culture fit is a. Nobody knows what that means. It is a thing that too often gets used to bat down candidates for reasons that are unclear to you, unclear to them, and, and that you are not in a position to articulate necessarily. And there is real danger in that. There's real danger in that. And I'd say that taking the time to define the number of companies that I talk to that are companies at scale that haven't gone through the exercise of. Okay, when we say culture fit, what does that actually mean? Have we written that down? Have we communicated that to people? Have we gotten feedback from, from the constituency on whether or not that's what resonates with them. That I think is a foundational exercise that needs to be had. And again, it also touches upon this idea that you need to hire people that have expertise in those areas in providing the frameworks that you're going to filter those types of culture. Okay, well, what do you mean by that? So I think that there's a hiring component, ironically, you can have chicken and egg. How do you hire for the folks that are going to help you think through that? What do you mean by culture fit? Culture, I think in the Valley has taken on a level of fetish that literally Right. It's something that we're now kind of doing and don't understand completely why we think and speak this way and why these things are important to us. Do they still serve us today? It goes back also to that exercise is still going to be true five years from now. What are we missing out on today if we are applying this framework to our hiring process? Taking, hiring, moving, professionalizing, sourcing and recruiting, I think is something that we have learned along the way is very important. Where early on and even recently, I'd say you had anti engineers or developers or marketers or sales folks that were responsible for coming up with their own hiring frameworks and then applying their own hiring frameworks to their team. And you end up with people that you've hired to spend 80% of their time, 90% of their time performing this exercise, who all of a sudden are in interviews and applying their own kind of matrix on what the company needs and what the company fits, as opposed to a more central professional rubric that a hiring team and that experts have. That's something that we've slowly, I think, begun to transition to. And then you end up with, you know, creating hiring committees on a departmental level, on an organizational level, so that you continue to have that feedback there. Software, I think, has played a large role and will continue to play a large role in all of our lives when to it comes, it comes to hiring. What does the HRIs look like? What's your applicant tracking system look like? How do those systems facilitate the goals and the vision that you have for your organization to the bias point, to the cultural point? How are you anonymizing those elements of that flow so that you actually do have something that's both predictable and tangible and that will lead to actual results? So I say that investing in systems is something that on a general level that we had to learn the hard way. GitHub being GitHub engineering centric, developer centric, we wanted to build everything. We wanted to build everything. And that's not that unusual. I think with startups and with companies where you've got a homegrown billing engine sitting alongside some homegrown HR whatever tool. What was different about GitHub was going back to that kind of validation of that Series A, oh, we're successful. We have this variable that exists within the company. We should continue to scale and invest in that. As opposed to do we want to be in the business of building out our own applicant tracking system, which we had. Do we want to be in the business of building our Own HR tools. Is this the right hr? What do we know about any of these things? And then in a lot of cases we were building our own mousetraps that were inferior to or on a level with what existed out in the market, but that we'd spent two years and I don't know how many millions of dollars building something that we could have just gotten off the shelf. And that I think goes to a lot of the questioning assumptions. So I'd say that systems and software also plays a big role in that.

So as we're coming to a close here, one of the things I wanted to circle back on is this very sort of almost subversive to Silicon Valley idea that you introduced earlier on, which is the concept of do you want to grow? Which as somebody who covers a lot of venture backed startups, it can seem like a non question sometimes when it's like yeah, of course you just brought in these however many millions of dollars for funding round X and you now need to grow and really accelerate your company in order to keep up with the pace of all of the expectations that come with the checks that you just got. And so how do you, from a company standpoint, how do you think about evaluating that, evaluating that question of like is it even right for us to grow right now?

Yeah, I think it goes down to basic, very basic question around the mission existentially, what is it that you're in the business of and why are we doing this at all and what is the vision that we want to get to and that there are plenty of reasonable, yeah, plenty of reasons why in order to meet a vision of being a global platform, of being a, or providing the best experience, experience in this, or doing some backwards vertical integration throughout your stack or your developer life cycle, whatever it happens to be for your business, any number of different reasons why we will be unable to do X, we will be unable to meet this opportunity that we have conviction around for taking capital, for growing the business, for increasing revenue, et cetera. But again, the growth needs to be in service of a mission, of a vision. It has to have a reason. And too often I'm surprised by look, we're growing at 50% year over year and we want to get to 70% year over year. Well why? Well, I don't know. Because more is better. Because we want to have that hockey stick, we want to do that up and to the right. But there are any number of different things that as your business grows and as you get more sophisticated, sophisticated and you want to show some consistency to Wall street in four years. Maybe you don't want to have a 70% spike in year one and then it starts going down to 60 or 50 or 45% and your line is off. And there are any number of reasons why. But if you're just investing on, we're going hard this year and growing for the sake of growing. And that's your reasoning. It will actually end up, I think, backfiring in some ways and that you need to try and think about what the goal is that you are moving backwards from and then what the growth needs to be in order to achieve those goals. In terms of headcount, in terms of revenue, what the rate looks like. And you're not going to be able to figure that out. We weren't able to figure that out until we hired experts, let's say, that had experienced that, that had been at public companies and tried to think about what the right line and what the right financial profile for your business is. But growth at all costs and accelerated growth just for the sake of it, I think is a recipe for disaster.

Well, since we've only got a couple of minutes left, I've got one last question for you. And that is if there's a piece of advice or a couple of pieces of advice that you could give past you, looking back on your career at GitHub and the rest of your career for that matter, what would they be?

I think on a real operational level, it's a point that I just touched on, which is investing in the right systems within your business that are going to scale with you. It is always a painful exercise. You don't know what the right stack looks like. You don't know how this system is going to API and integrate into this thing over here. But if you don't have a view of we're going to be international and we're going to be in 35 different countries in two years, or we want to be for whatever the reason is, you're in a situation that, you know, that we found ourselves in, where we built a billing engine that wasn't able to collect VAT in a particular jurisdiction, or you're not, you know, you're not creating, you're not collecting sales tax, whatever that happens to be the systems part of it is critical to your ability to run your business. If you're not able to hire people and to track the data and to tell you to be able to have a source of truth in a data warehousing standpoint as to the externalities about your business, and your intrinsic factors around what makes for a successful hire. How do we shorten this? This person seems to be hiring a lot of people that are choosing, churning out of the organization within 16, 18 months. What is it about that? How do you understand that you can't even make a decision and you're flying 100% blind unless you actually have those systems in place? And that I think maybe feels like a really basic remedial thing. But I found it to be pretty critical to our ability to understand what we're doing and then to do anything about it. I think the other thing really is just questioning why you have been successful and what that vision is and what the values are and those convictions, like really putting pen to paper and pushing on them every single day and not losing sight of the customer. Because I think that for a while there, we maybe were overly infatuated with how we were working as a company as opposed to what we were doing and why we were doing it and who we were doing it for. So somewhere in there, there's an answer.

Well, cool. Thank you so much for the time. It was a really enjoyable conversation and thanks everybody for joining us.

Thank you, everyone.

Thank you.