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

Open source software has been around for quite some time, but as I highlighted on the Dev Interrupted Podcast, only within the last decade has it come to be widely accepted and used, though many organizations are yet to use the concept. While many people still remain skeptical of open source, its growing popularity and use is undeniable. 

For many developers, open source is “the one true way”, almost a religion. Many of the world’s best and brightest developers devote themselves to creating and advancing the cause of open source projects. There are any number of foundations and organizations--from The Apache Software Foundation to the .NET Foundation--that openly support open source. Open source is a large part of some of the biggest tech giants in the world, including Google, Microsoft, and Amazon.

Benefits of Open Source

As the VP of Engineering of Logz.io, which has entirely embraced the open source benefits model, I am an open source “true believer” and see many benefits to using open source software. I highlighted five of these key benefits on the Dev Interrupted Podcast with LinearB co-founder Dan Lines:

1. Open source is widely used

What development organization doesn’t use git these days?

There are many open source projects that are widely used. Tools like Elastic, Kafka, and the Apache Web Server are amongst the most popular and commonly used software applications in the world. Because they and many other similar projects are so popular, there are copious resources available for learning, troubleshooting, and solving problems. 

Finding developers that are skilled in a particular project can be much easier, as these projects are so widely used and known. Plus, developers prefer to work at companies that use open source, because they know that they won’t be locked into a proprietary solution and that their skills will be transferable. 

2. Open source is responsive

Open source is usually very responsive to issues and bug reports, often delivering fixes and updates in days or even hours. These updates can often be deployed immediately whereas with proprietary software, you often have to wait months for the next release to resolve a problem.

New features are available earlier in the development cycle, and users can normally see and try out features as they develop. This enables organizations to more rapidly adopt new versions of projects.

3. Open source brings financial advantages

Open source can both cut costs and minimize maintenance. Of course, the biggest cost benefit comes from getting a complete, proven software package for no cost. Improvements and bug fixes also come to the software from external sources, keeping maintenance costs low. Development occurs outside of your organization, resulting in new features with little effort.

Using open source just makes financial sense. I don’t want to write a load balancer--why should I spend the time and effort to do so when I can use one built and maintained by experts?

Sure, there are some costs associated with open source, such as setup time, learning time, and continuing maintenance and configuration, but the same costs are incurred for closed source software. 

4. Open source is more secure

Security is a worry with any software that you use, and some argue that open source isn’t secure because everyone and anyone can see what the application does--but I say that open source software is more secure because of this. 

“What do you trust more? Security in a product that is fully transparent, where you have tens or hundreds of workers across the world testing and working on it, as opposed to a product where you have not seen the source at all.“ 

-- from the Dev Interrupted Podcast at 8:20

Since everyone and anyone can see the code, they do know exactly what the software does and doesn’t do. Thousands of pairs of eyes from all over the world look at the code and can spot vulnerabilities before they are exploited.  Thanks to this transparency, it’s much more difficult to take advantage of security holes because they’re fixed as fast as they are found.

Proprietary software doesn’t have this advantage. It only has a single development team looking at the source, and you as a consumer have no idea what security holes may lurk within.

5. Open source is future-proof

One of the benefits of open source is that it can never disappear. A proprietary company can go out of business, leaving you high and dry and with no options but to stick with what you have or migrate to another solution.

However, open source is available, well, forever. Put a project up on GitHub, and it will live as long as someone has the source code. 

In a worst case scenario, an organization can take over the project themselves, fixing things and adding features as desired. 

Managed Service Providers

Open source software very commonly lends itself to the managed service model. In fact, most managed service providers would not be open source-able without open source software. A proprietary solution cannot be used in such a manner -- the licensing would forbid it. Taking open source and providing it as a service is a powerful business model that is only possible because of the open licensing of open source.

We here at logz.io provide managed services for log and tracing analytics and observability. We use a number of open source projects to provide these services. Our value, like all managed service providers, lies in our ability to provide expertise for a service that another organization probably doesn’t want to spend the time and money to become experts in. This is only possible because of open source.

Is open source for everyone?

No -- open source software is not for everyone. 

Some organizations--especially large, enterprise companies--are not able to risk the “infection” from licenses like the GPL. Large organizations often have legal requirements that prevent them from safely absorbing open source. Some organizations simply can’t or won’t overcome NIH -- the “Not Invented Here” syndrome. Some want a company that they can yell at if something goes wrong. And some people just don’t see “the one true way”.

This is the Way

In the end, I truly believe that the benefits of open source vastly outweigh any costs that may be incurred. We’ve staked our whole business on it here at logz.io, and it’s clearly working not only for us but for many other companies and managed service providers. Fully and clearly considered, it’s hard to see why your company couldn’t benefit from using open source Software.

Listen here if you want to learn more about the benefits of enterprise open source software. 

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

We all understand that proper data analytics is crucial to the success of an organization. But what if your analytics can do more than help you troubleshoot current problems? Splunk is building a future where data analytics proactively solve problems before they occur. 

Data is essential to success and innovation for modern organizations. However, no commercial vendor has an effective single instrument or tool to collect data from all of an organization’s applications.

However, there is an open source framework: OpenTelemetry. By providing a common format of instrumentation across all services, OpenTelemetry enables DevOps and IT groups to better understand system behavior and performance.

Last week, Splunk’s Spiros Xanthos joined us on Dev Interrupted to explain OpenTelemetry - and to understand OpenTelemetry, we first need to understand Observability. 

What is Observability? 

Observability is the practice of measuring the state of a system by its outputs, used to describe and understand how self-regulating systems operate. Increasingly, organizations are adding observability to distributed IT systems to understand and improve their performance and enable teams to answer a multitude of questions about these systems’ behavior.

Managing distributed systems is challenging because of their high number of interdependent parts, which increases the number and types of potential failures. It is hard to understand problems in a distributed system’s current state compared to a more conventional, standard system. 

“It’s very, very difficult to reason about a problem when it happens. Most of the issues we’re facing are, let’s say, ‘unknown, unknowns’ because of the many, many, many, failure patterns you can encounter.” - Spiros Xanthos, from the Dev Interrupted Podcast at 3:02

Observability is well suited to handle this complexity. It allows for greater control over complex modern systems and makes their behavior easier to understand. Teams can more easily identify broken links in a complex environment and trace them back to their cause.

For example, Observability allows developers to approach system failures in a more exploratory fashion by asking questions like “Why is X broken?” or “What is causing latency right now?”

What is OpenTelemetry?

Telemetry data is the output collected from system sources in observability. This output provides a view of the relationships and dependencies within a distributed system. Often called “the three pillars of observability”, telemetry data consists of three primary classes: logs, metrics, and traces. 

Logs are text records of events that happened at a particular time; a metric is a numeric value measured over an interval of time, and a trace represents the end-to-end journey of a request through a distributed system. 

Individually, logs, metrics, and traces serve different purposes, but together they provide the comprehensive detailed insights needed to understand and troubleshoot distributed systems.

OpenTelemetry is used to collect telemetry data from distributed systems in order to troubleshoot, debug and manage applications and their host environment. In addition, it offers an easy way for IT and developer teams to instrument their code base for data collection and make adjustments as an organization grows. For more information, Splunk has an in-depth look at OpenTelemetry.

Benefits of OpenTelemetry

“In terms of activity, it is the second most active project in CNCF (Cloud Native Computing Foundation), the foundation that essentially started with Kubernetes. So it’s only second to Kubernetes and it’s pretty much supported by every vendor in the industry. And of course, ourselves at Splunk are big supporters of the project. And we also rely on it for data collection.” -- from the Dev Interrupted Podcast at 16:47

Since the announcement of OpenTelemetry 2 years ago, it has become highly successful. 

On the Dev Interrupted podcast, Spiros discussed how in his role as the VP of Observability and IT OPS at Splunk, he has seen OpenTelemetry grow to become an industry standard that Splunk relies upon for data collection. He highlighted three key benefits of OpenTelemetry:

  1. Consistency

    Prior to the existence of OpenTelemetry, the collection of telemetry data from applications was significantly more difficult. Selecting the right instrumentation mix was difficult, and vendors locked companies into contracts that made it difficult to make changes when necessary. Instrumentation solutions were also generally inconsistent across applications, causing significant problems when trying to get a holistic understanding of an application’s performance. Conversely, OpenTelemetry offers a consistent path to capture telemetry data and transmit it without changing instrumentation. This has created a de-facto standard for observability on cloud-native apps.  Enabling IT and developers to spend more time creating value with new app features instead of struggling to understand their instrumentation.

  2. Simpler Choice

    Prior toOpenTelemetry, there were two paths to achieving observability: OpenTracing or OpenCensus, between which organizations had to choose. OpenTelemetry merges the code of these two options, giving us the best of both worlds. Plus, with OpenTelemetry’s backwards compatibility with OpenTracing and OpenCensus there are minimal switching costs and no risk to switching. 

  3. Streamlined Observability

    With OpenTelemetry developers can view application usage and performance data from any device or web browser. Now, it’s easy and convenient to track and analyze observability data in real-time.

However, the main benefit to OpenTelemetry is having the knowledge and observability you need to achieve your business goals. By consolidating system telemetry data, we can evaluate if systems are properly functioning and understand if issues are compromising performance. Then, it’s easy to fix the root causes of problems, often even before service is interrupted. Altogether, OpenTelemetry results in both improved reliability and increased stability for business processes. 

Why OpenTelemetry is the Future

With increasingly complex systems spread across distributed environments, it can be difficult to manage performance. Analysis of telemetry data allows teams to bring coherence to multi-layered ecosystems. This makes it far easier to observe system behavior and address performance issues. The net result is greater efficiency in identifying and resolving incidents, better service reliability, and reduced downtime.

OpenTelemetry is the key to getting a handle on your telemetry, allowing the comprehensive visibility you need to improve your observability practices. It provides tools to collect data from across your technology stack, without getting bogged down in tool-specific deliberations. Ultimately, it helps facilitate the healthy performance of your applications and vastly improves business outcomes.

Listen here if you want to a deeper dive into the topics of OpenTelemetry and Observability - and how Splunk leverages them.

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