Data-driven engineering: what you need to know

You probably know this, but it can’t hurt to repeat it from time to time—knowledge is power.

In the software development business, knowledge can mean the difference between enviable success and a painful failure.

Luckily, today we have the knowledge at our disposal, easily accessible and ready to be used for achieving great results.

Data-driven software engineering teams can do that and more. In this article, we’ll examine what it takes to get the most out of data and how to take your engineering to the next level.

What data-driven software engineering means

Having insight into relevant data can transform any business, provided that they know how to use the full potential of data—and that also stands for software engineering.

But what does it mean to be data-driven? Paras Doshi, Head of Data Analytics at Amazon, explains it as making decisions based on available data.

In the case of software engineering, that means that you use data to optimize the whole working process of your software engineering team, leading to more efficiency, better results, happier developers and customers – in short, more success in every area.

You might ask yourself whether there’s an alternative to being data-driven. It turns out that there really isn’t a comparable one.

If you’re basing your decisions on something abstract like intuition, that isn’t a reliable method to build upon.

Do you think that Google updates their products, such as Google Classroom, based on their gut feeling?

Of course, they don’t, that would be far too unreliable. In the case pictured above, they collected the user data, which drove the changes.

Furthermore, data-driven software engineering doesn’t mean extracting as much data as possible from every metric and drowning your engineering team with it.

On the contrary—you should be smart about the amount and quality of data you use, as Kara Minotti Becker, software management and process consultant, advises.

“Engineering leaders need to be careful not to crush their teams under the weight of too many metrics.”

You can hear her talking about the basics of being data-driven in the video below.

Besides the quality of the data, organizations in which software engineering relies on data should have the 3 P’s framework—people, platform, and process.

According to Doshi, the term people refers to having employees who make data-driven decisions.

A platform is a data and analytics platform that you use to get the data you need when you need it.

Finally, a process refers to having well-defined data-related processes. For example, how to prioritize analytics requests, what’s a standard definition of metric, etc.

Those three elements make up an iterative process that requires constant optimization.

Data-driven software engineering is a complex way to organize that part of your business, but it can be worth it.

However, you should have certain components that enable it to reap its full benefits. We’ll examine what those components are in the next section.

Components that enable data-driven engineering

As we mentioned earlier, data-driven software engineering should have some necessary components.

According to Jonathan Fries, Director of Operations at PickNik Robotics, there are five of them:

• Company vision
• Key Performance Indicators (KPIs)
• Objectives and Key Results (OKRs)
• Engineering metrics
• Positive behavioral metrics

These components are all interconnected, and together they make a sturdy foundation for data-driven software engineering.

As you can see above, company vision influences other pillars; KPIs drive OKRs, and metrics also increase the velocity of OKRs.

On the other hand, behavioral metrics provide energy that affects performance.

Let’s go more into detail on every one of those components.

Company vision comes from the leadership, and it strongly influences other components, especially KPIs and OKRs.

In other words, company vision and leadership determine what defines success for your business and what measurable goals you aim to achieve.

Therefore, company vision determines which KPIs you measure.

In the context of software engineering, those can be technical KPIs like velocity or cycle time and user-oriented like cost per customer or cost per feature.

We’ll discuss more about which metrics to choose in the later section. However, whichever you choose, you can track them with software tools like, for example, Gtmhub.

Above, you can see how their own software engineering team tracks their KPIs on a weekly basis.

Along with KPIs, you should also have OKRs in place. The difference between those two components is not always easy to define, as they might seem similar.

The most helpful way to think about OKRs is that they’re ambitious goals with measurable steps to achieve them. ClearPoint Strategy defines the difference like this:

“OKR is a strategic framework, whereas KPIs are measurements that exist within a framework.”

Since the OKRs are so ambitious, it’s important to carefully consider which activities you and your software engineering team are investing your time and resources in, as Felipe Castro advises.

And how to know which activities are low-priority or non-value? By leaning on data.

There are tools that can help with OKRs, too. For example, Weekdone offers dashboards where leaders can develop team OKRs, and teams can set weekly plans to achieve them.

They even offer coaching for those unfamiliar with setting OKRs.

Another vital component is constituted by engineering metrics. Which metrics are suitable for measuring software development? Which ones show you what’s a good software developer?

We’ll examine those metrics more in detail in one of the later sections, but here’s a teaser—it isn’t about how much time an engineer spends in front of the screen.

Positive behavioral metrics show you how you can boost your engineers’ mood and energy and what are the most effective ways to do so.

For example, behavioral metrics might show that your team responds well to the acknowledgment of their efforts, so you can use tools like BreatheHR to praise them with kudos publicly.

Data can show if your team responds to that or something else, like team-building or coffee talks on Zoom where they can hang out.

These mentioned components are crucial to having data-driven software engineering in your business.

Each one contributes to the larger picture—having an efficient practice that relies on objective information to progress.

Benefits of data-driven engineering for the company culture

Using the power of data to improve your software engineering can produce outstanding business results. However, it can also positively affect your company culture.

We can say that those two elements are closely connected—good business results improve company culture, and great company culture impacts business results.

According to data from Accenture, being data-driven pays off—those organizations have an annual growth rate of 30% or more.

Better results come with using data in your software engineering.

For example, using customer data can show you what your users want and need from your products so you can steer decisions in that direction.

Research indicates that using that kind of data is indeed beneficial. McKinsey found that organizations that use users’ behavioral insights outperform their competitors by 85%.

That affects company culture, too—using data to know where to aim your teams’ efforts focuses their work, and knowing that their hard work pays off makes them more efficient and satisfied in their workplace.

It’s a chain of benefits that keeps on giving.

That ties to another benefit of being data-driven—a more precise work process.

As we mentioned, data can help your engineering team focus their efforts on what matters. As Abi Noda, CEO of DX, explains, data helps him have a clear vision of what’s needed.

In other words, stumbling in the dark with just your feeling to base your decisions on isn’t good for company culture.

Sooner or later, your software engineers will notice that they’re working without precise direction, and then the motivation and results can take a significant hit.

Using data also allows you to be transparent about the elements you base your decisions on.

That’s highly recommended because your software engineers can understand the company’s goals and optimize their performance accordingly.

Also, employees value transparency; according to Robert Hohman, Chairman at Glassdoor, 96% of employees say it’s important that the company practices transparency.

In other words, having a data-driven approach to software engineering encourages transparency, positively impacting employees’ work engagement.

Another benefit of data-driven engineering is the ability to have an optimized workflow.

For instance, you’re probably practicing some form of daily stand-up meeting with your team.

Having data enables you to pinpoint the issues in performance, see what they spend time on, identify bottlenecks, etc.—in short, have a clear view of your team’s performance.

On the other hand, you can efficiently answer any question your engineers might have because you already have the data.

Below, you can see how participants in the SCORE project used their daily stand-up to discuss topics based on data.

As you can see, they, among other things, discussed results and issues from the previous day, as well as using IoT devices in a public space—topics that require data to begin with.

That kind of workflow optimization, along with better results, improved precision, and transparency in work, are some of the main benefits of data-driven engineering.

If you’re curious about how to reap those benefits within your team, let’s dive deeper into that in the next section.

Tips for creating a data-driven engineering team

In previous sections, we’ve covered what data-driven software engineering means and what its components and benefits are.

But how to actually create a data-driven engineering team?

Luckily, that can be hassle-free if you follow a few tips. Let’s start with using software tools.

Use software tools

Using various software tools in your day-to-day work probably isn’t unknown to you and your team.

Even the most common tools for software engineers, like GitHub or Jira, can provide you with valuable data. For instance, the deployment frequency and cycle time, as you can see below.

Also, it’s good to have a foundation of software tools, regardless of the size of your team.

For example, every software development team can benefit from storing data in SQL and then using a business intelligence tool like Tableau to visualize data, build charts, create reports, etc.

That way, data-driven decision-making is easier. There’s no sifting through spreadsheets and rows of numbers.

Software tools can also help your engineers in dealing with bugs. For example, Shake is our bug-reporting solution that shows how beneficial using data can be.

Shake automatically collects tons of useful data and attaches it to the users’ bug reports. An engineer gets information about app version, build, permissions, network status, OS, screenshot or screen recording, etc.

However, using great software tools isn’t enough to build a truly data-driven engineering team. You should pay attention to the engineers themselves.

Provide training for using data

Having mountains of data and valuable insight won’t do much good if the people who’re supposed to use it don’t know how to do it, or even don’t want to.

For example, teams at Airbnb, an online marketplace for renting accommodation, had trouble understanding data.

As Jeff Feng, their former Head of Product, Data and AI/ML, describes, the product teams would come to data scientists for basic questions because they didn’t know how to interpret the data.

That would waste time unnecessarily, and was simply an inefficient way to work. That’s why it’s important to provide training to your software engineers.

Luckily, there are many options for that, like online courses for every level of knowledge. Below are just a few from edX.

There are also platforms like Enki, which provide comprehensive training in using data.

Whichever method you prefer, investing in your team’s training is the bottom line here; that approach can lead to significant improvements.

Use the right metrics

How to measure the efficiency of a software engineer? What are relevant metrics to assess their performance?

Determining answers to these questions can help you use the data in the right way.

For example, you shouldn’t take lines of code as a relevant metric; you also need a deeper context.

The number of lines can’t tell you how complex the work is or how important the feature on which an engineer works is.

On the other hand, a metric like cycle time is much more useful. It has multiple components, which you can see below.

You can measure every component separately and see if there are issues and at which stage they occur.

Software tools like LinearB, for example, can help track that metric.

However, as Kara Minotti Becker emphasizes, there are no must-have metrics to track.

“It’s all about knowing what your company’s goals are and picking metrics that help you figure out how you’re contributing to that.”

Whether you’re measuring velocity, change failure rate, or any other of many possible metrics, the important thing is to assess if they help you reach your goals.

If they are, you’re on the right track.

Conclusion

Data can give you and your software engineering team powerful insights into every aspect of the business.

Whether it’s your engineers’ performance, efficiency, and workflow or the users’ feedback on which you can base your next steps, data is a map that can prevent you from getting lost in the world of software engineering.

Using the knowledge from this article, you’ll be able to start to assemble a data-driven software engineering practice and reap the benefits.