Empower your engineers with a data-driven approach

What you don’t know can hurt your teams—and your company’s bottom line. That’s why successful companies use data to empower their software engineers and to measure their impact. Ideally, this data provides powerful insights on what your software engineers should do to optimize application performance, build new features, and prevent problems that can lead to service outages, bugs, and lost customers from suboptimal experiences. Whether that’s analyzing website traffic to optimize the performance of your web pages, benchmarking to ensure that your code runs efficiently, or using observability to detect anomalies, you need a continuous stream of all of your telemetry data—metrics, events, logs, and traces—to empower your engineers to plan, build, deploy, and run great software.

Data-driven engineering is the practice of using the telemetry collected from engineering tools and platforms to optimize the work of your software engineering teams, which leads to direct benefits for your teams, customers, and bottom line. 

Benefits of data-driven engineering

Here are a few of those benefits:

• Using a data-driven approach means you are using clear, concrete insights from all of your telemetry to drive business decisions, not relying on incomplete information or gut feelings.
• Making the data behind your decisions visible enables all of your engineers across every stage of the software lifecycle to see, understand, and optimize performance based on data.
• Measuring customer impact with data can illuminate what your customers need and can ensure that your business decisions, products, and services solve those needs.

In fact, according to a report from Accenture, "data-driven organizations with an enterprise strategy are actually growing at a rate of more than 30% annually."

However, despite the clear benefits of data-driven engineering and the fact that modern organizations use data for just about everything in their businesses, the concept is often poorly defined, which makes it challenging to implement.

How to implement data-driven engineering

Ultimately, data-driven engineering asks the following questions:

• Are your teams taking on the right projects?
• Are your teams doing work that has the desired effect on end-users?
• Are your teams’ resources properly allocated against business goals?

If you are using data to answer these questions about your software engineering teams, then you’re already practicing data-driven engineering and likely seeing noticeable benefits as a result. However, if you aren’t answering these questions through an empirical, data-driven process, you likely have blind spots that limit the full potential of your engineers and your company as a whole.

So how do you set up a process that actually answers those questions using a data-driven approach? To implement data-driven engineering across your organization, answer five critical questions.

What data should you collect to meet your goals?

You likely already have business key performance indicators (KPIs), but do you have KPIs for your software engineering teams as well? You should define concrete goals for them and then design metrics that measure those goals. They can even be similar to the goals of other teams in your organization. For instance, increasing user signups might be a KPI for your marketing and sales teams. It might not seem like an obvious goal for your software engineering teams, and yet your developers are the ones actually implementing the code for the signup page and experience.

In addition to establishing more general organizational goals, you can implement specific goals that apply only to software development. For example, you might include goals for the overall reliability and uptime of individual pages and customer engagement with specific pages. The chart below illustrates useful telemetry data that you can collect at each stage of the software lifecycle.

How will you collect and measure the data?

There’s a good chance you already use many tools that measure your software engineering teams’ work such as JIRA, GitHub, and Slack, which can provide metrics on the total number of tickets closed and features completed. But if your software engineering teams are siloed from the rest of your organization, they may be missing out on key metrics.

Your marketing and web teams might use Google Analytics for page views and bounce rates, but your software engineering teams might not have access to that valuable data. You might also consider implementing other tools to fill in gaps. For example, if you aren’t measuring and analyzing telemetry data about the overall performance of your applications and services, you could implement an observability solution to monitor your entire stack.

How can you bring disparate data sets together to create an actionable plan?

If you collect data from many different sources and some teams don’t have access to specific data sets, it’s easy to miss the forest for the trees, which leads to blind spots and misallocated resources.

You should bring disparate data sets together into a single source of truth. For example, your marketing team might see a reduced number of page views for a signup page in Google Analytics while your software engineering team is dealing with an increased number of tickets related to that sign up page; if that data isn’t correlated, both teams might end up misdiagnosing the appropriate fix and misallocating resources as a result while the user experience hangs in the balance. It’s absolutely necessary to connect the dots between disparate platforms and data sets so that teams can correlate data and correctly identify issues.

How can you apply a data-driven approach across your entire organization?

Every member of your organization should embrace data-driven engineering, not just engineering leaders and C-suite executives. For software engineers (and members of other teams too), this means implementing a process like the build-measure-learn cycle.

The cycle, which is part of the lean methodology, relies not just on building great software but measuring its impact and then learning from those measurements to improve that software in future iterations. However, the learning process can only happen if you have team buy-in.

What should you look for when choosing an observability platform to support data-driven engineering?

A good way to get team buy-in is to make sure that the observability platform you acquire and use has an engineer-centric pricing model. Many solutions on the market have a host- or subscription-based pricing model that bundles multiple SKUs. This often forces engineering teams to compromise the breadth of their instrumentation coverage and the volume of ingested telemetry data because of expensive licenses and misaligned pricing meters. They may end up having to sample data, count agents, create custom metrics, worry about surprise or hidden fees, or make infrastructure decisions based on pricing.

However, with a consumption-based pricing model, you only pay for what you use or consume. Consumption-based pricing is data-driven because it’s based on hard usage metrics instead of blanket assumptions, which aligns with an engineering mindset. An engineer-centric pricing model empowers engineers with a data-driven approach to get past the what to uncover the why. Modern engineering teams should demand a consumption pricing model going forward as it puts the value you receive and pay for at the center of the equation. You get far more value from your observability platform for each of your engineers.

Empower your teams with data-driven engineering

Data-driven engineering is just one piece of the puzzle—but you cannot gather all the pieces, put the puzzle together, and understand its meaning without analyzing the impact of your software engineering teams. After all, applications and websites are only as good as the software they’re built on. Data-driven engineering empowers your engineering teams to see how their work positively affects critical business drivers and your company’s bottom line.