{"url": "https://www.infoq.com/interviews/greg-brockman-software-culture-delivery/", "page_url": "https://www.infoq.com/interviews/greg-brockman-software-culture-delivery/", "title": "Greg Brockman on Changing Software Culture to Deliver", "show_or_channel": "InfoQ", "date": "2014-02-07", "duration_s": 715, "type": "interview", "speakers": ["Greg Brockman", "Harry Brumleve"], "confidence": "medium", "notes": "InfoQ video interview recorded at QCon (11:55).", "people": ["greg-brockman"], "id": "2014-02-07_infoq-greg-brockman-on-changing-software-cultu", "audio_duration_s": 723.330625, "worker": "jc-w12", "transcribe_s": 19.7, "model": "large-v3", "segments": [{"start": 0.69, "end": 29.54, "text": "This interview was recorded at QCon San Francisco 2013. This audio file and others like it are available for free download at InfoQ.com. Hi, I'm Harry Bromlevy. I'm here at QCon San Francisco 2013 with Greg Brockman. Greg, can you tell us a little bit about yourself? Sure. So I'm the CTO at Stripe. I've been there for about three years now. And I work on a lot of different, I guess I've built a lot of infrastructure and continue to run the team and help us scale."}, {"start": 29.54, "end": 53.41, "text": "And why are you here at QCon? So I'm here speaking about building a culture where software projects actually get done. That I think that we as software engineers are actually pretty bad at actually completing projects. You think about the last time that you actually met a schedule that you set for yourself with building a software project. It probably has been a very long time. And one of the crazy things is that..."}, {"start": 53.41, "end": 78.11, "text": "We've just gotten really great at many aspects of the software development lifecycle, right? That we have really amazing tools now and really great languages and frameworks and things like that that increase productivity. But the thing that we haven't figured out yet is how do we actually organize ourselves effectively? How do we make sure that we're able to deliver on the promises that we're making? How do we make sure that we're actually able to work together effectively and get things done?"}, {"start": 78.11, "end": 87.7, "text": "That's something that just hasn't really moved forward in the past, certainly 30 years, possibly since the beginning of software engineering. And is that a function of culture then?"}, {"start": 87.7, "end": 110.22, "text": "It's interesting. I think it's a function of many things. I think that culture is actually at the root of it. As an engineer, I think it's very tempting to make everything into a technical problem. You say, oh, we don't have the right tools for this yet. That's all that we need. We just need the magical language that will solve all these problems. Or, oh, maybe we just need to automate away a lot of these problems. Maybe we need to make it, you know, you just specify some high-level behavior and then suddenly the code writes itself. I think that..."}, {"start": 110.22, "end": 136.58, "text": "Early on, people had a lot of confidence that we'd be able to do that, that we'd be able to just remove software engineers from the process of building software, and that none of that's gone anywhere. And I think that the fundamental reason that that's stalled is software is just inherently a creative process. It's inherently something that requires human ingenuity and people who are thinking really hard about how to combine these problems and how to think about things in different ways."}, {"start": 136.58, "end": 155.34, "text": "You sort of have this problem that's inherently human, and then you have lots of humans needed in order to actually accomplish something big. If you actually want to build some large project, you just need lots of people on it. And so now you're left with something that has been a problem for a long time, that we have spent a lot of time thinking about, which is how do you actually organize humans to do something?"}, {"start": 155.34, "end": 184.93, "text": "I also don't think that we've yet figured out the right way of applying those sort of things that we know about humans to software. And part of that's because it's new, but I think also part of it is because software is just inherently way more complex than anything else we've ever done. But there's been a lot of literature written about software engineering, especially in the 60s and 70s, that were talking about management and how to adapt to failure and even culture itself. Did they get it right and we've just changed since then? Or are there..."}, {"start": 184.93, "end": 207.58, "text": "Are they still applicable even now? Yeah, so there are a lot of things that have been written. So the classic one that I think always comes up is Fred Brooks' The Mythical Mad Month. And the idea there was that this was a project that was late and that the way that they tried to solve this was, okay, so we'll just add more developers. It'll get done faster, right? And what they noticed was that the time to actually get things done..."}, {"start": 207.58, "end": 230.82, "text": "The timeline just kept moving back further and further. And the problem there is that as you add more people to a project, that you just have more communication overhead, and that ends up slowing everything else down. And those problems, they continue to persist today. A lot of these things were identified in the 60s or 70s, and we haven't really made progress on them. And I think a really good example is just look at healthcare.gov. Now we're in a world where..."}, {"start": 230.82, "end": 256.26, "text": "The difficulties of building software have gotten so bad that they're headline news. This is something that is holding back our nation from actually being able to deliver on the things that we're trying to do. And I think that that's the beginning. It's going to get worse. It's not going to get better unless we do something about it. So if culture is so important, how can a developer know if their culture needs improvement? I think the place to start..."}, {"start": 256.26, "end": 276.51, "text": "I think there's a pretty easy litmus test. So spend a day, spend a week just time tracking. Don't do anything fancy. Just pull out a notebook and just write down every hour what you're spending your time on. And if the amount of time you're spending writing code is less than 25%, you're probably in a pretty bad state."}, {"start": 276.51, "end": 291.94, "text": "There are actually some good cultures where that's true, but for the most part, 25% is a threshold number. 50%, you're actually probably at a pretty decent company, and anything more than that, things are great. So what do I do once I get those metrics? Right."}, {"start": 291.94, "end": 309.47, "text": "Once you've realized that, okay, I'm not actually spending my time writing code, that there are a couple of things that you can do. Ultimately, it's a question of, okay, what are these distractions? Are these things that are in my power alone to change? Is it just that I'm allowing myself to be interrupted? One thing about building software is that..."}, {"start": 309.47, "end": 334.85, "text": "So much of it is, again, it's a creative process, right? It's something that requires just lots of focus and attention and that requires whoever's doing it to really be in the zone. And so there's this like ramp up period of 15 to 30 minutes before anyone's able to actually be productive, right? And like once you're in that zone, you're able to just like get things done and that it's all a question of, okay, so how much uninterrupted stretch do you have?"}, {"start": 334.85, "end": 361.3, "text": "And so what you should do is the first thing you should try to do is shift around your own schedule so you have more uninterrupted stretches. Sometimes that's not in your power. Sometimes there are these external interruptions that are driven by maybe things go down, maybe the site's down, maybe that there are customer requests that have to be dealt with. Some of those things, that starts to require cooperation from your team. And I think that there, it's worth..."}, {"start": 361.3, "end": 391.2, "text": "Talking with other people and figure out, are you the only person who feels like this? Or do other people feel like they can't focus? And there are actually a couple of different things that you can do within a team in order to better provide focus. I think one thing that we do is that we do a rotation where one person each week is designated as the runner. And it's their job to run the systems and to serve as a buffer between all these external interactions and the people who are actually building things. And that means that most people can focus on getting things done."}, {"start": 391.2, "end": 412.7, "text": "And sometimes the issues are deeper than that. Sometimes it's really fundamental to how your company is structured. Maybe that there are just a lot of meetings that don't need to exist or they just constantly interrupt you. Maybe it's something else. And at that point, I think it's worth talking to whatever the source of those is. I think one common thing that I hear is people who feel like..."}, {"start": 412.7, "end": 439.52, "text": "They don't have the power to shape their culture, that it's set by management, and the management doesn't really understand what the actual issues are. And I think at that point it's worth talking to whoever it is that's setting that and talk about whatever it is that they value. If it's we actually have a lot of projects that don't ship on time or it just takes far too long to make changes, start with that and say, okay, so what's the root cause here? Take a look at a project which didn't go well. What were the issues there?"}, {"start": 439.52, "end": 468.66, "text": "If you can identify those, then you can start talking about, OK, here are some things that we can try to make that be better. And one of the nice things is that most of the issues that you've run into, those probably are not unique to you. That probably someone else has run into the same sort of scheduled delay or feature creep or whatever it is that bogged down your project. And so the problem for you mostly is figure out, OK, where does this fit into the scheme, into the space of other projects that have gone equally poorly? And OK, so what were the takeaways that people had over there?"}, {"start": 469.3, "end": 495.28, "text": "And so after you've collected these metrics, maybe you've identified a few systemic issues, you've talked to your boss about it, or you've talked to someone who can affect culture on a large scale about it, now you have to talk to your coworkers. And you mentioned that some of them might have the same problems, but some of them might very well enjoy the culture that they're in. How do you approach your teammates with an idea of shifting culture? Start small."}, {"start": 495.28, "end": 520.03, "text": "The first thing to do, I would say, is either change something about your own work or pick someone, doesn't even really matter who, and try to convince them to shift work and to try and experiment to see whether this change is positive. So maybe try pair programming with them for a week. And there are two possibilities there. One is that you'll discover that, hey, this thing that we thought was going to be the..."}, {"start": 520.03, "end": 547.87, "text": "The panacea just hasn't worked out and isn't actually good. Okay, that's fine. It's actually good that you didn't convince more people to do it. Or it's going to turn out to be really positive. And then in that case, you'll keep doing it. And if it's really good, then other people will also start noticing, hey, they seem to be getting more done, or the stuff that they're producing is great, or they're just having more fun, whatever it is. And then they'll join in as well. And so I think that all the best cultural shifts, whether it's coming from bad culture or even coming from a great culture, I think that all of those just need to be organic."}, {"start": 547.87, "end": 579.09, "text": "Because you won't know ahead of time which shifts will actually work and which ones won't because it's also dependent on who the people are. And so the best way of doing it is just try it out, see what works, see what doesn't, and then organically spread it. So we've had about 40 years of empirical data about how we deliver software. And now we're starting to focus on culture after we focused on all the tools and processes. And we have this huge array of tools to help us deliver software. Where do you think the future is going in regards to culture?"}, {"start": 579.73, "end": 608.66, "text": "It's a good question. I would actually disagree a bit with the premise that I think that we actually haven't made that much progress on anything non-technical. I think that we've clearly made a lot of progress when it comes to tooling, to languages, to all of that stuff. But I think that we continue to have exactly the same sorts of problems when it comes to organization that we did a long time ago. And I think there are a couple of possibilities here. One is it just turns out that we're doing..."}, {"start": 608.66, "end": 638.58, "text": "I'd like to believe that's not true, and I think it's pretty unlikely, but there is certainly a chance that it'll turn out that that's the universe we live in. I think a more likely world is that we'll continue to come up with lots of failure cases, and we'll keep discovering, here's a project that went wrong, here's what happened, and start evangelizing that. And I think that that's going to require a shift in how we, as a community,"}, {"start": 638.58, "end": 667.49, "text": "Convey ourselves in the sense that right now, I think people just don't talk about these stories very much. That you have the mythical Mad Month. You have some stories about the second system effect. All those are from the 1970s. I guess you have the story of Netscape and their massive rewrite almost killing the company. But in the past 10 years, there's just way more software being done, but far fewer of these stories. And it's not like we've solved these problems. It's not like they've gone away. It's just I think we've stopped."}, {"start": 667.49, "end": 677.14, "text": "Talking about those. And so I think that the future where we actually solve all of these and that we figure out here's a great way."}, {"start": 677.14, "end": 698.14, "text": "That is repeatable, that is scalable for organizing ourselves to build software. I think that that's going to require us shifting what we're doing today. I think that's going to require us talking about these things a lot more. I think it's going to require us thinking a lot harder about how to organize them. I think it's going to require people really sitting down and fundamentally changing how we structure ourselves and just how the community works."}, {"start": 698.14, "end": 721.84, "text": "I think that there's some chance that that's going to happen. And that in that case, I think that the future will look like something where we get software engineering to the point that other engineering disciplines are in terms of being something that can reliably deliver things that are both quality and on time. That sounds great. Thanks a lot, Greg. Have a great time at QCon. All right. Thank you very much."}]}