If you’re a developer, or a developer team lead, this article offers you actionable insights from a research study conducted by McKinsey & Microsoft that delves into the relationship between Developer Velocity and fundamental business outcomes, such as revenue growth, operating margins, and how quickly a business can innovate.

Microsoft worked with McKinsey on this study to further our understanding of the critical role that developers play in the success of organizations around the world. As a company that deeply understands the impact of developers, we’re excited to share these results, and hope the findings will grab the attention of senior business leaders. Our message for them is simple: orienting your organization to prioritize and empower the success of developers is a decisive competitive advantage.

Before we dive into the results, let’s take a moment to define Developer Velocity. This terminology refers to the pace at which a team of developers can deliver innovative software that is loved by end users. Developer Velocity goes well beyond the simple pace of delivery though. It’s about helping business leaders understand the value of providing world-class developer tools, structuring working groups to promote autonomous productivity through Agile and DevOps practices, and incentivizing innovation through a culture that fosters psychological safety.

The Developer Velocity Index (DVI) was created for this study as a quantitative measure to enable a comparison of Developer Velocity at 400+ global companies. The next step was evaluating the impact of Developer Velocity on business outcomes that matter to every senior business leader. In short, the research study demonstrates that companies scoring in the top 25% of the Developer Velocity Index experience 4-5x faster revenue growth, 20% higher operating margins, and 55% higher levels of innovation.

Top 5 Drivers of Developer Velocity

While the results of the full research study are intriguing, for the sake of brevity, let’s focus here on the top 5 drivers of Developer Velocity. And if you’re interested, you can find all the details of this research through the “Learn More” links provided at the bottom of the article.

#1 Developer Tools

Organizations in the top quartile of Developer Velocity invest in developers by providing access to world-class developer tools. Specifically, these companies provide developers with a flexible choice of integrated developer environments (IDEs), collaboration software, and continuous integration and delivery (CI/CD) tools that support each stage of the software life cycle. Another common tendency among top companies is enabling non-developer employees to create applications through low-code and no-code platforms, thereby protecting the time of their software engineers to focus on more challenging tasks. The rewards of these investments become obvious when you consider that these top 25% of companies achieve developer satisfaction and retention rates that are 45% higher than the bottom 75% of companies.

#2 Organizational Culture

The most critical cultural attribute shared by the top 25% of companies is creating an environment of psychological safety. This means establishing a shared belief that incentivizes risk-taking through experimentation and embraces failure through learning and knowledge sharing. This approach fosters innovation and continuous improvement, which becomes particularly effective when paired with a customer-centric philosophy. These top companies also frequently recognize the efforts of their developers, taking the time to publicly acknowledge and reward individual and team achievements.

#3 Product Management

Highly effective product management is a differentiator that’s increasingly valuable for the top 25% of companies. Along with managing budgets and project timelines, the role of a product manager focuses on delivering a compelling experience for end users. This job function requires a unique blend of business acumen, technical understanding, customer experience, and interpersonal skills that are necessary to deftly influence others towards desired outcomes. Hiring, training, and retaining skilled Product Managers should be treated with the same strategic significance as finding the right developers for your team. The most successful teams of developers also embrace a mindset wherein they take turns stepping into the shoes of the Product Manager to better understand the problems facing their end users and the solutions they can develop to address those challenges.

#4 Developer Experience

Best-in-class organizations do the best job of hiring, incentivizing, educating, and retaining talented people by deeply considering their internal developer experience. It begins by recruiting top developers with a compelling value proposition to join the team and continues by building programs that support continuous learning and set clearly defined career paths. Another critical step is structuring the organization around smaller developer teams to prioritize autonomy, loosely coupled architecture, and the implementation of Agile and DevOps best practices. Finally, introducing formal processes that encourage transparent dialogue and measure team health through regular surveys create an important feedback loop for the organization to listen to their developers and understand how to improve their experience.

#5 Open-Source Software

Companies in the top 25% of DVI that adopt open-source software and encourage their developers to contribute to open-source observe three times the impact on innovation compared to the organizations in the bottom 75%. Here we learn that embracing an open-source mentality has a significant multiplying effect on innovation for companies that are already leaders in Developer Velocity. And it should be reinforced that embracing open-source means adopting open-source software, motivating employees to contribute to open-source communities and projects, and adopting a similar internal sharing philosophy that is commonly referred to as InnerSourcing.

I hope this article has inspired ideas that you can bring back to your role as a developer, or developer team leader. Below are links to the full research study by McKinsey, along with a short-form (5 Questions) and long-form (10-15 Minutes) assessment tool with results from each that provide actionable guidance to help you accelerate the Developer Velocity of your organization.

Learn More:

Join the Dev Interrupted Community

With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>

Dev Interrupted Discord, the new faces of engineering leadership

Unless you’ve been living under a rock for the last year, you must have heard about this brand new shiny thing called “No-Code” and “Low-Code”. According to Gartner, 50% of all software projects will be delivered before the end of 2021 using Low-Code and No-Code constructs. Even if Gartner’s numbers are inflated, automation processes for generating code automagically have gained traction lately, and it has gained traction very, very, very fast. So obviously we’re way beyond the “hype factor” in regards to these technologies. Hence, in this article, I will try to break down the advantages, and illustrate with an example use case, so you can see the advantage for yourself. But first I need to define Low-Code and No-Code.

The difference between Low-Code and No-Code

Although obviously related, Low-Code and No-Code are actually two completely different concepts. No-Code is the idea of “citizen development”, where people without software development skills can create software. This is typically achieved through drag and drop interfaces, similar to how DreamWeaver worked a couple of decades ago. On the other hand, Low-Code is typically a software system that generates code automagically for you, by for instance reading metadata from your RDBMS, or Swagger, etc.

In a way, you could argue there’s nothing new to No-Code. DreamWeaver has had No-Code constructs since the late 90s, and so have Adobe Flash, Microsoft, and literally every single software company out there beyond some certain size threshold. Visual Basic and WinForms for instance used to have GUI interfaces for “generating code by dragging and dropping components into a visual surface.” While Low-Code it could be argued, has always been around in some ways, due to individual software developers’ ability to reuse Open Source libraries and frameworks, to reduce the workload required to deliver applications.

So what’s new?

Well, let me illustrate with a walk down history lane, and use Gutenberg and the printing press as an analogy for what’s happening. In the 15th century, it would require one human being roughly 18 months to copy a Bible by hand. These jobs were typically done by monks, and because of the resources required to create a Bible, “the Good Book”  typically took 300 sheepskins or more to create. One hundred years later, Gutenberg’s printing press became mainstream, and today born again Christians are throwing Bibles at you on the street for free. With mass printing, the cost associated with creating books has plummeted. 

This was only possible because of the printing press, and its ability to automate what was previously a manual job. Hence, the more we can automate, the lower our total cost of ownership(TCO) becomes. Such benefits don't require a Ph.D. in math to understand but are probably intuitively understood by most.

With today’s automation techniques based upon Low-Code constructs, we’re now at the point where we can deliver similar optimizations in regards to generating software systems that result in the same quantitative improvement of the TCO of creating software. To illustrate it as blatantly as I possibly can, let me ask you a question: “Would you want to pay 50 million dollars for your software, or would you want to pay 50 bucks for the same thing?” This is really the heart of the matter. To understand how this occurs, imagine having to create your own operating system to serve your own software. Obviously, such a thing would be madness, when you could just pick Linux off the shelf, and start out with an Open Source system solving these problems out of the box. Hence, the qualitative similarity between Open Source and Low-Code.

A Low-Code use case

Disclaimer; I’m the CEO of ServerGardens.Com, and we exclusively deliver software systems based upon Low-Code constructs, and our own internally created Open Source system we refer to as Magic Cloud. Therefore, I might not be completely without bias. But really, most people can easily reproduce what I’m about to show you here, so it doesn’t really matter if I’m biased or not, since you can test and verify my thesis yourself. Anyways, with that out of the way, let’s illustrate a use case for Low-Code.

One of our clients came to us and asked us to create a CRM system. It needed the ability to track purchasing and selling of horses, and hence a traditional CRM system couldn’t be used, since it was more like a logistic system that he needed than a traditional CRM system. We spent 25 minutes creating a database schema after having asked some questions about how he wanted it to look, and digging through Google Spreadsheet documents which he was currently using for this job. All in all, the process took about 2 to 3 hours before we had a working system deployed into production for the client.

The process was as follows: After we had the database done, we clicked one button, and the computer-generated 1,813 lines of backend code for us; this code again became the input for the next button click, which generated 27,000 lines of frontend code. Even after having removed the boilerplate code you’d typically have around in a manual workshop, we’re easily looking at 10,000 to 15,000 lines of code here, automatically generated for us, in 2 seconds. And the code is perfectly valid Angular code in the frontend, and Hyperlambda and .Net 5 in the backend.

And of course, the code generated by our system is easily several orders of magnitude higher quality, according to every single neutral metric we use to measure quality. In fact, run this code through one of your frontend/Angular developers if you want to assess it from a quality perspective. I guarantee you that he won’t find a single bug in it! Then realize that this code is running here. Try it out for yourself by logging in with admin/admin.

The reasons for the qualitative improvement are quite simple to understand, In fact, our stuff runs in thousands of apps, implying we can share the burden of improving it equally with many projects. Something you’d typically never be able to afford if you manually write code on a per-project basis. To see this effect in the printing press improvements, try reading an old Bible that was manually written by a monk 550 years ago (if you can even find one) - then try to read one of Gutenberg’s Bibles and notice the difference in readability. Low-Code improves both your quality and reduces your cost by several orders of magnitudes.

How Low-Code improves quality and reduces cost

The way it works is by reading metadata from the database schema, to then use this metadata as a formal specification to generate the backend. The backend exposes a lot of metadata itself, which again is used as a formal specification to generate the frontend. However, the time to market quantitative improvements is simply ridiculous. To understand why realize that a (human) software developer can deliver at most 750 lines of code per month. Our software system delivered at least 10,000 lines of code in 2 seconds. Of course, these types of comparisons aren’t completely fair one might argue, but this becomes a quantitative improvement of 17,280,000 times faster Time2Market! In fact, so far I have not been able to identify a theoretical upper limit in regards to either quality or quantitative improvements. In theory, our software systems can produce 750,000 lines of code per second, which becomes a quantitative improvement of 216,000,000 times faster than a human being.

Hence, we’re now at the point where we can literally throw customized software systems at our clients - almost the same way born-again Christians are throwing Bibles at strangers on the street - simply because of the cost associated with creating such custom software systems for our clients is almost ZERO.


Yes, there is a but. For instance, our system needs an existing database. The end application will also be database-centric, implying it’s typically for the most part only interesting for CRUD systems, where CRUD implies Create, Read, Update and Delete. However, the last figures I saw in regards to this was that there are 26 million software developers in the world. These numbers are a bit old, and are probably much larger today than a decade ago when I saw these figures. Regardless, the ratio is probably still the same, and the ratio tells us that 80% of these software developers work as enterprise software developers.” An enterprise software developer is a developer working for a non-software company, where software is a secondary function. 

Examples could be insurance companies, banks, hospitals, or the public sector. So let’s imagine there are 21 million enterprise software developers in the world today and 80% of their workload is CRUD. If you don’t believe me, go ask your DBA how many relational databases you have in your company, and whether or not these are crucial for your company to function. Chances are his answer will be, “Our company would go bankrupt if we lost these database systems.” Then realize that every single time your applications are accessing these database systems, they are either Creating, Reading, Updating, or Deleting items from the database - A.K.A. CRUD!

This implies that if you adopt Low-Code and Open Source as a strategy for your enterprise, you can optimize the way your software developers work by (at least) 5x, probably much more. Simply because at least 80% of the work they need to do manually is as simple as clicking a button, and waiting for one second for the automation process to deliver its result.

Also realize that the code generated is just plain old fashion code, that can be easily extended upon by your (human) developers once the process of automatically generating the automated parts is done. Except, of course, your (human) developers start out with something that is 1 million times higher quality than whatever they would typically be able to start out with themselves. Respectfully, but there is no way of saying this politely, so I’ll just say it: Not taking advantage of such improvements is simply madness!

Wrapping up

If you want to play around with the Open Source Low-Code framework that delivered the above results, you can download it for free from our website. All of our tools and Low-Code constructs are 100% Open Source. We also help others strategically make the transition into a Low-Code automated software development ecosystem if they need help. Our services include training of your existing software developers, open-source frameworks, hosting, and, of course, software development at the speed of light! See you at the other side of the Universe mate ^_^

Join the Dev Interrupted Community

With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>

Dev Interrupted Discord, the new faces of engineering leadership