Sure. I am the CTO at Stripe. I have been there for about three years now and I work on a lot of different – I guess I built a lot of infrastructure and I continued to run the team and help it scale.
2. And why are you here at QCon?
So I am here speaking about building a culture where software products actually get done. I think that we, as software engineers, are actually pretty bad at completing projects. When 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. One of the crazy things is that we have just gotten really great at many aspects of the software development life cycle. We have really amazing tools now and really great languages and frameworks and things like that, that increase productivity but the thing that we have not figured out yet is how we actually organize ourselves effectively. How do we make sure that we are able to deliver on the promises that we are making. How do we make sure that we are actually able to work together effectively and get things done? That is something that just has not really moved forward in the past, certainly 30 years, possibly since the beginning of software engineering.
3. Is that a function of culture then?
It is interesting. I think it is a function of many things. It think that culture is actually at the root of it. As an engineer, I think it is very tempting to make into everything a technical problem. You say: “Oh, we do not have the right tools for this yet! That is all that we need. We just need the magical language tool to solve all these problems. Maybe we just need to automate away a lot of these problems. Maybe we need to – you know, specify some high level behavior and then someway the code writes itself.” It think that early on people have a lot of confidence that we would be able to do that, that we would be able to just remove software engineers from the process of building software and none of that has gone anywhere. I think that the fundamental reason that that stalled is that software is just inherently a creative process.
It is inherently something that requires human ingenuity and people were thinking really hard about how they combine these problems and how they think about things in different ways. So, we sort of have this problem that is 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 projects, you just need lots of people on it. Now you are 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? But I also don’t think that we have yet figured out the right way of applying those sort of things that we know about humans to software. Part of that is because it is new but, I think, part of it is because software is inherently way more complex than anything else we have ever done.
There are a lot of things that have been written. The classic one that I think always comes up is Fred Brooks – The Mythical Man-Month. The idea there was that this was a project that was late and that the way that they tried to solve this was: “OK. So we will just add more developers and it will get it done faster, right?” What they noticed was that the time to actually get things done, the time line, just moving back further and further. The problem there was that as you add more people to a project that you just have more communication overhead and that ends up slowing everything else done. Those problems, they continue to persist today. A lot of these things were identified in the ‘60s or ‘70s and we have not really made progress on them. I think a really good example is just to look at healthcare.gov. Now we are in a world where the difficulties of building software have gotten so bad that they are headline news. This is something that is holding back our nation and from actually being able to deliver on the things that are we are trying to do and I think that this is the beginning. It is going to get worse, it is not going to get better unless we do something about it.
5. So if culture is so important, how can end developers know if their culture needs improvement?
I think that the place to start is – I think there is this pretty easy litmus test. Spend a day, spend a week just time tracking. Don’t do anything fancy, just pull a notebook and just write down every hour what you are spending your time on. If the amount of time you are spending writing code is less than 25% you are probably in a pretty bad state. There are actually some good cultures where that is true, but for the most part, 25% is a threshold number. At 50% you are probably a pretty decent company and anything more than that, things are great.
6. So what do I do once I get those metrics?
Right. Once you have realized that “OK. I am not actually spending my time writing code”, there are a couple of things that you can do. Ultimately it is a question of “What are these distractions? Are these things that are in my power alone to change? Is it just that I am allowing myself to be interrupted?” One thing about building software is that so much of it is a creative process, it is something that requires just lots of focus and attention and requires whoever is doing it to really be in the zone. So there is this ramp up period of 15 to 30 minutes before anyone is able to actually be productive. Once you are in that zone you are able to get things done and it is all a question of how much uninterrupted stretch you have. So, the first thing you should try to do is shift around your own schedule so you have uninterrupted stretches.
Sometimes that is not in your power, sometimes there are these external interruptions that are driven by the things going down, maybe the site is down, maybe there are customer requests that have to be dealt with. Some of those things that actually require cooperation from your team. I think that there it is worth talking with other people to figure out whether you are the only person who feels like this or do other people feel like they cannot focus. There are actually a couple of different things that you can do within a team in order to better provide focus. One thing that we do, we do a rotation where one person each week is designated as a runner and it is their job to run the systems and serve as a buffer between all these external interactions and people who are actually building things and that means that most people can focus on getting things done. Sometimes the issues are deeper than that. Sometimes it is really fundamental to how your company is structured: maybe there are just a lot of meetings that do not need to exist, they just constantly interrupt you, maybe it is something else. At that point, I think it is worth talking to whatever the source of that is. One common thing that I hear is people who feel like they do not have the power to shape their culture, that it is up by management and that management does not really understand what the actual issues are.
I think at that point it is worth talking to whoever it is that is setting that and talk about whatever it is that they value. If we have a lot of projects that do not ship on time or just takes far too long to make changes, start with that and say: “OK. So what is the root cause here?” Take a look at a project which did not go well. What were the issues there? If you can identify those than you can start talking about “OK. Here are some things that we can try to make that be better”. One of the nice things is that most of the issues that you run into are probably not unique to you. Probably someone else has run into the same schedule delay or feature creep or whatever it is that bugged down your project. So the problem for you mostly is to figure out where does this fit into the scheme, into the space of other projects that have gone equally poorly and what were the takeaways that people had over there.
7. [...] How do you approach your teammates with an idea of shifting culture?
Harry's full question: After you have collected these metrics maybe you identified a few systemic issues, you have talked to your boss about it or you have talked to someone who can affect culture on a large scale about it. Now you have to talk to your co-workers and you mention that some of them might have the same problems, but some of them might very well enjoy the culture that they are in. How do you approach your teammates with an idea of shifting culture?
Start small. The first thing to do, I would say, is either change something about your own work or pick someone - it doesn’t really matter who - and try to convince them to shift work and to try and experiment to see whether this change is positive. Maybe try a pair programming with them for a week. There are two possibilities there: one is that you will discover that “hey, this thing that we thought was going to be the panacea just hasn’t worked and isn’t actually good” – OK. That’s fine. It is actually good that you did not convince more people to do it – or it is going to turn to be really positive and in that case you will keep doing it. If it is really good then other people will also start noticing: “Hey, they seem to be getting more done” or “The stuff that they are producing is great” or “They are just having more fun, whatever it is” and then they will join in as well. So I think that the best cultural shifts, whether it is coming from bad culture or even coming from a great culture, I think that all of those just need to be organic because you will not know ahead of time which shifts will actually work and which ones will not because they are 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.
It is a good question. I would actually disagree a bit with the premise. I think that we actually have not made that much progress on anything non-technical. I think that we have clearly made a lot of progress when it comes to tooling, to languages, to all of that stuff. 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. There are a couple of possibilities here: one is that is just turns out that we are doing the best possible thing already and that humans are just incapable of organizing to build software. I would like to believe that is not true and I think that it is pretty unlikely, but there is certainly a chance that that will turn up. That is the universe we live in. I think a more likely world is that we will continue to come up with lots of failure cases and we will keep discovering “Here is a project that went wrong. Here is what happened” and start evangelizing that and I think that that is going to require a shift in how we, as a community, convey ourselves in the sense that right now people just do not talk about these stories very much.
You have the Mythical Man-Month, you have some stories about the second system effect - all those are from the 1970’s. I guess you have the story of Netscape and their massive derailment almost killing the company, but in the past ten years there is just way more software being done but far fewer of these stories. It is not like we have solved these problems, it is not like they have gone away, I think it is just that we have stopped talking about those. So, I think that the future where we actually solve all of these and where we figure out a great way that is repeatable, that is scalable for organizing ourselves to build software. I think that that is going to require a shift in what we are doing today. I think that is going to require us talking about these things a lot more, I think it is going to require us thinking a lot harder about how to organize them and I think it is going to require people really sitting down and fundamentally changing how we structure ourselves and just how the community works. So I think there is some chance that is going to happen and that in that case 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.
Harry: That sounds great. Thanks a lot, Greg. Have a great time in QCon.
All right. Thank you very much.