As organizations look to improve their operational velocity, one of the things they’re increasingly looking at is their developer experience. To understand how that can be improved, however, you have to understand what makes developers happy, and what makes them unhappy. Zenhub explored just this question in a recent survey and founder Aaron Upright joined us to talk about developer likes and dislikes, and where that intersects with the developer experience gap.
This was a RedMonk video, sponsored by ZenHub.
Rather listen to this conversation as a podcast?
Transcript
Stephen: Hi there. I’m Stephen O’Grady. I’m co founder of RedMonk, and I am here today with Aaron. Aaron, would you like to introduce yourself?
Aaron: Yeah. Hey, thanks for having me, Stephen. I’m Aaron Upright. I am the founder of Zenhub.
Stephen: Outstanding. Now RedMonk, for those of you who are unfamiliar with us, is a developer focused industry analyst firm, which is quite appropriate given the sort of topics we’re going to discuss today. So, Aaron, I understand you’ve run a survey on developer happiness. Why is that? Why would that matter?
Aaron: Yeah, there’s a lot of content out there when it comes to developer happiness and productivity. And our research though, that we found — we couldn’t really find anything that was focused on more the employee experience factors that were related to productivity. You know, we saw a lot of reports out there and we saw a lot of case studies or just independent studies even that were run that really seemed to treat developers like a resource to be optimized rather than “what are the experiential factors that kind of play into people’s happiness and fulfillment at work?” And then “how does that actually impact their productivity in a work setting?” So we really wanted to focus on more the human elements or the human factors, I guess you could say, as they related to productivity. But in a really important way, we wanted to establish more of a quantitative link there so that we weren’t just trying to figure out what made developers happy and then saying, Hey, here’s the findings of that report. I think people have inclinations of that, but really trying to understand that impact on productivity. And, you know, it does seem like a really obvious kind of tie that happier developers should be more productive at work. But getting that quantifiable aspect of it was what we really set out to do with that report, because we couldn’t find anything, at least that that had tried to establish that connection before. So, you know, we looked at a lot of different factors, environmental factors, human factors like where people are working, benefits and compensation all the way down to what kinds of projects they’re even working on as well.
Stephen: All of which makes sense because, as you say, you know, historically developers have been treated like a just another resource, right, to be optimized and try to refine over time. So looking at, hey, what actually makes people happy makes sense. Were there any takeaways that were particularly interesting or surprising to you?
Aaron: Yeah, I think there was some really surprising ones that came out in the survey, y’know some of the ones to call out for me were, we found that most developers of the ones that we surveyed at least felt more most productive in the office. You know, 33% of developers that we surveyed said that’s where they feel more productive, where they can feel they get the best work done, compared to only about 20%. That said, they get their best work done and feel most productive at home. That was really interesting because I think it’s somewhat counter to that narrative that we often hear that developers are the biggest proponent for remote work and always pushing to work remote. You know, I think there there is definitely an element to that. But I think there is what we saw at least in that survey, there’s desire for a more holistic balance there of people maybe being in office in certain days to be productive in certain functions and be productive in certain meetings while still having that flexibility and that freedom to work from home other days a week. So that was really interesting. Another really interesting takeaway for us too when we looked at kind of those human elements was what influences developers to stay with their current employers. We found that the the number one reason was work-life balance. And the number two reason was the quality of projects that they were working on. And compensation and benefits was only third on that list. And I think, again, there’s that narrative out there that kind of paints developers in a pretty cynical light saying, you know, developers have no loyalty. They’ll leave whenever there’s an opportunity for bigger pay or a bigger check. And that really simply wasn’t true with the research that we did. The number one thing developers want and are seeking out with their employers is work-life balance and then really good quality work in meaningful projects that they can then work on.
Stephen: Outstanding. Yeah. And, you know, that kind of brings us to one of the other things we wanted to talk about today, which is something that we see a lot of developers — and to put it in terms of our conversation here — expressing happiness about, which is the developer experience gap. And that sort of in a nutshell is the idea that we ask developers to do too much that’s not the thing that they want to do to get them out of bed in the morning, which is write code, right? We’re asking them to wire infrastructure together, link services, do a bunch of integration, operate these these sort of shambling infrastructures over time. And you know, that just ends up making them unhappy because it’s not doing again the things they want to do. What’s your take on that? Is that something that you see?
Aaron: Yeah, I mean, we see it a little bit internally and we try our best to kind of push against it. We see it a lot externally with customers, though, and ones that are reaching out to us, not just looking for our product, but looking for our help. And we see it especially as it relates to the amount of overhead developers seem to get stuck with around processes and tools that maybe their teams or their leadership have implemented. You know, specifically we see a lot of organizations, whether they’re mid-market or enterprise, where they’ve implemented these really, really heavy processes and sometimes tools that support those relative to the level of maturity of the team when it comes to how long they’ve maybe been together or how long they’ve been working cohesively together as a team. And, you know, the intent, I think always from those organizations and from leadership is to drive alignment. But what we often hear from people who are doing the work is that it creates a lot more overhead for them and it pulls them away from that application development work or the actual coding work that they’re doing to have to spend that time on managing work. And so that’s a big area where we see that developer experience gap. Products and teams that are just taking on processes and tools that quite frankly are way too heavy for what they’re building and what they’re trying to do. And it actually ends up slowing the team down versus helping align everyone around the organization. So that’s a big area where we see that gap.
Stephen: Yeah, and that’s exactly the kind of thing that we see in basically every category today. You know, it is just these these gaps between different pieces of infrastructure or tools in sort of in place that are too heavyweight, you know, which brings us to sort of maybe the last question here, which is how do you attack that problem? What’s the you know, there’s no one way to solve the developer experience gap because obviously it’s so many different manifestations of that in so many different categories. But from a Zen hub perspective, what’s the approach? How do you how do you make life easier, simpler, faster?
Aaron: Yeah, I mean, well, tool sprawl and context switching is a really real thing in a lot of large organizations. And it’s — tools definitely serve a purpose. But when we’re throwing tools at some of those problems or we’re throwing really heavy process at some of those problems, that that’s where those gaps can kind of form. You know, one of the adjectives that you use, Stephen, to describe kind of the future of the developer experience was was comprehensive and, you know, vendors evolving their products beyond kind of just their original core competency to look at how they can kind of bridge the gaps between adjacent spaces. I think the example you gave in the developer happy — or developer experience gap report that you put out was what GitHub did with GitHub actions to kind of bridge that gap with CI/CD. You know, we think about our platform in a very similar way. We started out being very, very focused on project management and software project management, but we’ve really started to build this more comprehensive experience around productivity management, product road mapping that makes it possible for people to build those roadmaps within Zenhub in a way that’s connected to their code base. You know, we see project management and product management as really adjacent spaces where the information from one system can really help inform the other and improve understanding. And so, you know, in building a more comprehensive solution, we’ve done that work to try to provide that more integrated experience so that development teams don’t have to go build those custom integrations.
Aaron: Instead, you know, they can leverage these kind of more comprehensive solutions like the one that we provide and really focus the majority of their time instead of building integrations or wiring systems together on writing application code. And so, you know, that’s a net positive for our customers. Another really interesting thing that you mentioned in how companies are closing this gap in kind of the future, the developer experience is this idea of it still being a multi vendor system, and I still agree with that. Now, even though we as a product are taking steps to kind of expand our offering and be more comprehensive, we recognize we’re never going to be everything to everyone. You know, we never want to get into CI/CD. We never want to get into source code management. You know, we know we’re never going to own the entire workflow. And so instead, let’s build those really rich developer native experiences and integrations that tap into those platforms where developers already are and where they already live. And that’s a big way that we and a lot of other companies are trying to focus on reducing context switching, by building into those platforms that are already established ecosystems where developers are spending time or where they’re actively working instead of trying to be everything to everyone and build the entire system out and own the entire system, right.
Stephen: Well, and unfortunately, we have to leave it there. But that is I think that’s an approach that one, we’re going to see more of and two, it’s going to pay dividends, right? Because the whole idea here is that there isn’t any one vendor. I don’t care how big or large they might be that’s going to be all things to all people. So what we’re going to need to see, frankly, moving forward more is approaches like this, which are taking that into account and trying to build an experience around that. And in spite of the fact that it’s coming from different places. But as I said, we have to wrap up here. So, Aaron, I just want to say thanks so much for coming on and talking to me.
Aaron: Yeah. Thanks so much, Stephen, for having me.
