video • 15MIN

Microsoft's Research into Developer Velocity

Henrik Gütle, GM of Azure for Microsoft Canada, breaks down the results and key takeaways from Microsoft’s research into the impact of remote work on developer velocity - and what engineering leaders can learn from it. Shared live with the INTERACT 2021 audience on September 30th.

 

Transcription:

Conor Bronsdon:
Hi folks, thanks for joining us today for INTERACT.
I'm Conor, one of your Dev Interrupted community leaders, and today I've got with me Henrik Gütle with me for our lightning talk about Microsoft research into developer velocity. Henrik is the general manager of Microsoft Azure. He's responsible for leading to commercial cloud business for Microsoft Canada. Thank you so much for joining us.

Henrik Gütle:
My pleasure, Conor. It's great to be here.

Conor:
Yeah, I'm super stoked to haveyou as part of INTERACT.
This new research is really exciting. Can you summarize the big takeaways for Microsoft's research in your developer velocity for everyone here?

Henrik:
Sure, I can at least try because whole developer velocity research actually expands to
different parts and two different surveys that we had in the market. So let me just spend a couple of minutes kind of level setting on the perfect findings. I think the first set we put in the market happened early 2012. So pre-Covid and we were researching just over 400 large companies around the world, and we were really trying to quantify what business impact that Developer Velocity has, and at the same time getting a bit more correspond what are some of the drivers behind developer velocity that have the biggest business impact? And as you could expect, like the survey found that there was a direct correlation between high Developer velocity and business impact, companies in the top quartile.

Conor:
You know that now.

Henrik:
Exactly, four to five times higher profit margin,
more innovative and so forth. But what I thought was really interesting on that first part of the survey was the drivers that make up the biggest impact, well the drivers that have the biggest impact because we like to develop the velocity across over 40 dimensions. And there were really four things that bubbled up to the surf that's like one was the importance of strong product management capabilities inside the organization. The second one was around culture, the third one was around developer tools and developer tool sets, and the last one was around the talent management. So out of the 40 dimensions we looked at, these were by the are the four most impactful as it pertains to driving high developer velocity.

Conor:
And then fastforward to the second piece,
what were the kind of outcomes you found there?

Henrik:
Yeah. So then in early 2021,
late 2020, early 21, we ran a second version out there, off the survey just to validate all findings, but also to take a closer look at did Covid and this whole shift to remote work actually have any impact on some of the fine things? And in general, it was a very similar theme, a very similar feedback we got in this survey. We particularly look at actually retail and financial service customers, in particular, developer organizations inside those companies because they were two industries that were pretty much on the front line as it pertains to the whole transformation. And findings were similar to, as in the first survey, and in general, they fell into one of three categories. There was a category around technology, there was a category around working practices, and there was a category around organizational enabled, and on the technology side, a couple of things that stood out. I think number one, shouldn't be a surprise to you or any of your listeners. I think cloud adoption was obviously one of the things that set the digital leaders apart from some of them being some of a lagger, but also having investments in solid tool sets and tool changes. And that actually came across in two regards. So number one, this whole shift to remote work, all of a sudden, like companies who had made investments in sophisticated and advanced developer tools that have unified developer tools across the organization actually saw a parity in developer productivity, between remote developer productivity and in person developer productivity. For many of these digital leaders, the shift to remote work actually did not impact developer productivity, and we actually saw the same at Microsoft, whereas those who were laggers obviously saw a decrease in developer productivity. Even more importantly, what they also saw is that the bug rate went up at 50%. So companies who had development teams that were distributed remote versus who were co-located actually saw an increase of the bug rate of 50%. So you have this interesting conundrum on the digital leaders, really, you know, not having a big of an impact on the mat the laggers was no dependent of velocity caught the double whammy on productivity and bugs in their product and which then ultimately leads to the third finding in technology bucket, which is security. That was one of the ones that stood out like customers with high Developer Velocity, indexes of high Developing Velocities in general were companies who had made investments in security, who had adopted DevSecOps practices, who had institutionalized, the whole notion of leaning last and so forth. But I think from a technology perspective, cloud adoption, the toolset and then this whole cultural thinking of security being a part of everyone's day to day job, were kind of three things that stood out on the security side and then working tactics as an organizational leadership were a big contributor.

Conor:
I'd love to trail more into those points.
What I'm kind of hearing is that the technological needs were such a baseline that if you missed out of those... You were screwed, 50% bug rate increase, you're going to be a laggerd or you have all these issues. But what did the data say about working practices and organizational enablement, then using those to increase velocity?

Henrik:
Yeah, if you start with working practices, I think really three things took out one
with this whole notion of agile, which again, should be pretty obvious. But I think what was underneath it was it wasn't just about, you know, adopting agile practices. It was actually some of the organizational implications behind that, because adopting agile practices without restructuring your team is not gonna get you very far. Exactly. So this whole motion of companies with high developer velocity really broke down their organization, traded these small, more autonomous, agile teams that own their product end to end and then combined with the technology side of architectures and so forth, that was kind of a big driver of high developer velocity, and we can maybe talk about it later, but it's actually one of the first things companies should be looking at if they want to drive high developer velocity. The other thing that we saw was, in a sourcing, in general that was a big driver of it, creating this openness collaborative environment inside the organization and then last, but definitely not least, it say, open source adoption. This one was interesting because it's not that open source adoption itself gives you high developer velocity but what we saw was that companies who already had good developer velocity were able to get to great developer velocity by adopting open source technologies. Those companies that were already in the leader category, so to speak, and then adopted open source categories were actually able to set themselves further apart both in terms of innovation and passive innovation, but also developer satisfaction. Open source being a great way to attract and retain developers that's companies contributing to open source project. And it's really a great way to show to the world that you're innovative and invested in that areas. Open source kind of in itself was a driver on the working practice side.

Conor:
That's so interesting. It's clear that there's this compounding effect
where if you miss out on one thing, you're going to miss on benefits that are compounding from the others. For the leaders who are listening to this talk, what should they do to begin using, integrating some of these learnings into their own organizations?

Henrik:
Yeah, I think a couple of things. I think around organizational enablement in general,
which I think a lot of leaders need to spend a lot of time on in this regard. There were a couple of really key pointers that I think every leader should take to heart. Number one, and again, no surprise, but the importance of world class talent management development. And it's one of those things like, as a leader, you cannot outsource. Like, the value proposition for your company on why top world class development talent work for you is something that every leadership team should have on the daily agenda. So to speak, really think through what is your value proposition in the market? Do you have the right programs in place to attract and retain? Talent is definitely one category. Making sure you use your top talent on your biggest project. I think obviously given will obviously help your top project more successful, but it also helps drive broader organizational enablement and broader organizational development.

Conor:
And everyone should just have happiness, too, right?

Henrik:
Absolutely, absolutely.
And I think that's exactly a key thing, like, this whole notion that the individual developer is, in most cases more important than the leaders and that the executive team in this world is really, really critical. So number one thing to do as a leader is really take talent management too hard. I think the second thing I'd say is this whole notion of agile and really setting your organization up for making sure that you restructure your organization into these smaller, more autonomous teams, making sure that you're working towards a more loosely coupled architecture and so forth. But I think this whole notion of agile should really be there. One of the first three things that every leader should look at. And then the last thing I would say is this whole... Something that's very dear to my heart is this whole notion of talent management as a discipline and building strong product management capabilities. Because if you move into a world where you have these autonomous teams that kind of own the product end to end both, you know, customer facing product or even internal product, like the whole importance of product management as a discipline and having people with a strong foundation in business and in technology is super critical. And as we talked up at the beginning, it was actually one of the top four drivers of high development velocity. So if this was my business, I'd probably start in those three areas. But then as you grow in maturity, you start looking at other things around the tool set and automation and so forth. But those are three things that every business leader could start on.

Conor:
Those are great takeaways, and I feel like there's this table stakes
now with technology where you have to be cloud adoptive, you have to meet certain standards and then you have these opportunities to these big moves like you mentioned. But if we drill down a bit into the individual developer experience, how can they make a broad impact on their teams from an individual standpoint?

Henrik:
Oh, that's actually really good question. I think a couple of things jump to mind.
The number one thing is if you really think about what developer velocity is, the whole idea behind developer velocity is how do you create the right environment and how you move points of friction for developers so that they can become more innovative. So as an individual developer it's almost one of the first call to actually speak up. Like if you see inefficiencies in the process, if there's anything in your data like that's limiting you from from being innovative and having high velocity, speak up. Bring solutions to the table. That's usually what really sets people apart. But don't sit by yourself and get frustrated when something isn't running, isn't optimal as it should. Speak up, take it, work with your colleagues taking up the management chain and every leadership that really wants to take developer velocity to heart, would listen and address. I think that's one of the first things to do with your point.

Conor:
I think they have to enable that too.Like leaders have to give this space where
developers feel not just allowed but encouraged and maybe be compelled in a polite way to speak up like you're saying.

Henrik:
Spot off. I mean again, that could tie to the beginning,
like culture was one of the only four things that really stood out on this. All comes down to it. Do you have that open and transparent culture where people cannot just do the best work but can also contribute to make others work better and contribute to higher developer velocity across the whole organization. Which then also is probably another thing I would call out on individual contributors is really, like, this whole notion of enablement. What are you doing to help make others better? Are you sharing best practices? We talked a lot about toolsets and tool chaining in the beginning. If you found out a different way of doing something, are you sharing that with your peers? You found a great way of continue to further your learning. Are you sharing back with your peers? So I really think, this whole mindset of not just becoming better as an individual developer yourself, but how can you help your colleagues become better developers is probably a second category and then third, because we talked about it in the beginning, security. Like I think take lean left to heart or secure your codes. The more time you're going to free up, not just for yourself, but for the whole organization to focus on innovation. So yeah, I think those would probably be the three things that I'd advise individual developers to take to heart as it pertains to improving their companies on developer velocity.

Conor:
I think these are really great points. And like you said,
when there's this baseline tooling and good hiring practices, a good culture in place, you can take those next steps of how do I help that my developers have ownership of their code. How do I really enable them to be able to fully embrace agile practices, which means you have to have a great organization. How do we make sure they have an opportunity to speak up and do all these things that are going to really take what we're doing to the next level? This has been super interesting and I know this are great takeaways here. So thank you so much for taking the time to talk to us today. What are the best places to dig deeper in this research?

Henrik:
Yeah, take a look at it. All the research papers are on the website,
azure.com/developervelocity. All the research paper who did with McKinsey is there as well as some of best practices on how to get started.

Conor:
Fantastic, we'll definitely drop a link in the chat right now.
And thanks so much for joining us. It's been wonderful.

Henrik:
Thank you, Conor. Absolute pleasure.

 

Explore your dev team's metrics in less than 3 mins!

I'm interested