 One thing we care a lot about at GitLab is developer experience and developer productivity. The reason we are building the DevOps platform is to make software teams faster, more efficient and more secure. In this last session to close out day one here at GitLab Commit 2021, I'm pleased to introduce Namdi Eregbalam who also cares a lot about developer productivity. Namdi is a technologist and partner at Lightspeed Venture Partners where he invests in early stage software startups enhancing the productivity of technical knowledge workers. Drawing on his experience working with many great companies, Namdi will share with us his developer productivity manifesto. Let's check it out. Hi, my name is Namdi Eregbalam. I'm a partner at Lightspeed Venture Partners and this is a developer productivity manifesto. I've been obsessed with developer productivity for a long time. I've spent most of my career investing in and backing strong technical teams in individuals building developer productivity tooling. I'm on a mission and I borrow a little bit from Stripe's mission statement which is to increase the gross domestic product or GDP of the internet. And I think about my mission as increasing total software output. Now, when I say that, the first question I always get is sort of why should we care so much about developer productivity? Well, it's been said before and I'll say it here again because it's worth emphasizing every company is becoming a software company. Like Henry Ford's assembly line a century ago, new software development paradigms promise to transform modern software development. The software revolution truly is the new industrial revolution but there's a key difference. Labor in this revolution is much better positioned. Software developers have much better working conditions than much more highly skilled and as a result, they're paid a lot more and are a lot more expensive. I like to think about software as a sort of production function with developers as a key input and software as the output. Now, we can make this a little bit more complicated and turn it into an equation and think about software equaling the number of developers that we employ times their productivity. In other words, software equals developers multiplied by the amount of software that we get for each and every developer. There's two types of production in the world that of tangible goods and that of intangibles. They're very different. On the tangible side, this is sort of traditional physical products like cars, televisions, clothing and in the tangible production world, replicas have value. So two cars are better than one, two computer monitors are better than one, two is better than one. And so value is really connected to gross units produced. Now, the intangible side, these are things like ideas, patents and most importantly, software. Intangibles are infinitely reproducible at zero marginal costs. And so in the world of intangibles, it really only makes sense to measure net new output as opposed to gross. And value is really connected to novelty, new ideas, new patents, new software. In thinking about idea productivity, I think it's helpful to modify that previous equation, generalize it across all intangibles. You can kind of think about intangibles as requiring new ideas in order to be produced. And so we can think about new ideas as the output now and researchers as a key input. And again, our equation is effectively new ideas equals a number of researchers that we put to work finding new ideas times the productivity of those researchers. How many new ideas are we getting per researcher? And the point I wanna emphasize and what the data will show is that actually idea productivity, the amount of ideas we're getting per researcher is falling quite dramatically. I think this has serious implications for software development. I think an analogy that'll be quite salient for this audience is actually Moore's law. Moore's law is the idea that deserves this constant growth in transistor density. So we're packing more and more transistors onto a computer chip every year and that growth rate is roughly constant. You can kind of think about maintaining Moore's law as requiring a constant flow of new ideas in semiconductor manufacturing. Now, if Moore's law has been roughly constant over the decades and yet we're employing many, many more researchers in order to find those marginal gains in transistor density, as you can see on the chart on the right, then almost by definition, going back to our equation, that must mean that research productivity has declined dramatically. We're employing so many more researchers and only getting effectively the same output, constant growth in transistor density. Something must be going wrong. As I mentioned, I think this has serious implications for software development, another sort of idea production function, but I have a solution. It's what I like to call the developer productivity flywheel. And I like to talk about its three parts. So first off, new developer productivity tools make developers more productive, but it's not that simple. New tools can often impair productivity in the beginning as it takes time to adjust to new tooling. There's often a sort of J curve of productivity where productivity initially declines before eventually rising above its baseline. And the benefits are eventually realized. Higher productivity drives companies to hire more engineers. If you remember your Econ 101 class, these are classic supply and demand curves. And what I'm showing here is that as developer productivity increases, companies demand more developer talent and shift out the demand curve for that talent. That increases the number of developers employed in software development and also raises their wages, their earnings. Higher productivity over time can also encourage more developers to enter the industry who maybe couldn't before. That additional increase will further increase the software developer talent pool even further. More developers working in a higher productivity ship more software, going back to that equation that started it all. And so via the flywheel, you have this sort of virtuous cycle where new software, some portion of which is developer productivity tooling, generates higher developer productivity. Higher developer productivity leads to more developers being hired. And more developers working at higher productivity leads to more software. Some portion of which again, is developer product tooling software. And we get this virtuous cycle. Now, the second question I often get is why not throw more engineers at the problem? And it is a totally fair question. I don't know if folks remember this Microsoft event from decades ago where Steve Ballmer was up on the stage and he was yelling developers, developers, developers and he's like sweating and whatnot. As you can tell from the GIF, it doesn't end well for him. But seriously, why not just throw more engineers at the problem? I think it's worth addressing. So first off, I have to mention this sort of classic in software development, the Mythical Man Month. Here's a book by Frederick Brooks. And in the book, he coins what people refer to as Brooks law, which is this idea that adding more labor to an already late software project only makes it later. Or in other words, adding more cooks to the kitchen only lengthens cooking time. And the reasons for this are numerous. A couple of examples are just sort of the ramp up time it takes to get new people up to speed on a project, the communication and coordination complexity that you run into on large teams, the indivisibility of the fundamental units of software development, where at a certain point, putting two developers to work on a single task doesn't make the task happen any faster. There's also dys-economies of scale. You know, it's very common to assume economies of scale where costs or unit costs decline with scale. But I tend to think that dys-economies are just as relevant. Dys-economies of scale or when unit costs actually increase with scale. And again, there are multiple reasons. Complexity tends to increase non-linearly with size. There's these black swan effects where large systems fail in spectacular fashion. And lastly, there's a theme of what I like to call developer dropout, which is this idea that young engineers can keep up with the latest developments in software development, folks early in their career, but it only gets harder and harder with time. And eventually the torrential wave of new tools that come out every year, every week practically becomes too much to bear and developers either tune out or dropout. In fact, 30% of computer science grads who started in computer science occupations upon graduation from undergrad drop out by the age of 50. But it's not only about the number of developers, it's also about what developers actually do. Whereas I like to say busy work doesn't work. There's a study that showed that developers employed in purely maintenance activities, fixing bugs, correcting for technical debt, et cetera, actually probably destroy about $600,000 of market value for their employers. And it's not that the developers literally destroy value, it's that the value they create is not large enough to make up for what they're paid. On the other hand, a developer that's engaged in a mix of maintenance and innovation activities actually generating net new software actually adds about $855,000 of market value to their employer. It's a pretty big difference. Now, despite all of these sort of caveats and things to worry about, most companies are increasing developer hiring. And by the way, I'm not against that at all. In a survey done by Stripe, I'm more than half of companies so that they expected to hire more developers in the future rather than less. And it's important as these companies do this to keep in mind some of the pitfalls that I just went through. Now, I think an important question to answer to sort of size up this problem is to ask ourselves, well, how much software are we potentially losing by not maximizing developer productivity and not maximizing the number of developers that we could potentially employ? Or said another way, how much software are we leaving on the table? In the same survey, Stripe asked organizations and development teams, what do you think is really hindering developer productivity at your company? And the number one answer provided was the maintenance of legacy systems and technical debt. Over half of respondents mentioning this is a key hindrance to productivity. And when asked, how much time are developers on your team or your organization spending on addressing technical debt? The average response was 13 and a half hours, which relative to an average developer work week of about 41 hours in the survey is a massive chunk of developer time or about a third. And so if you do the quick arithmetic, you get to this answer that developers could be 46% more productive if only they could get the technical debt out of the way and spend 100% of their time on productive innovative software work. And so relative to that 41 hour work week, that would be an additional 19 productive hours, which is massive. As part of the survey, Stripe also did some back of the envelope math to calculate what they called these sort of aggregate GDP software developers globally. And while I won't walk through all of the math, they got to an answer of about $900 billion of aggregate GDP worldwide generated by software developers, which is obviously a big number. And by their own calculations, they got to an answer that there's about $300 billion of loss of a potential GDP due to software developer inefficiency. Now I actually think that they underestimated that number. And if you use the 46% that I mentioned on the previous slide, you get to an answer above $400 billion of loss output due to developer inefficiency. And so if we kind of sum up everything that I've discussed here, you think about how much software are we leaving on the table? If we try and quantify that, starting off with developers is about 20 million developers globally. And there are good estimates that say there's about a three million developer shortage in terms of jobs that are going unfilled today in software development. And so we can think about potentially gaining 15% more developers as a conservative estimate. We can take the 46% potential additional productivity, let's say round it up to 50 to make the numbers nice. So if we take the 15% of additional developers and the 50% additional productivity and multiply those together, you get to about 73% more software that we could be getting. And so that multiplied by the 918 billion of software GDP globally gives you an answer of $670 billion of software that we're effectively leaving on the table by not maximizing developer employment and maximizing developer productivity. This is why developer productivity matters. So that was a brief lens into how I think about developer productivity and why I'm so obsessed with the topic. I hope you enjoyed that. If you're also crazy about this topic, feel free to reach out anytime through any of these channels. But thank you so much for joining me here.