6 Reasons Why Data-Driven Engineering Teams Build Better Software | Pluralsight

A healthy development team is critical to the success of tech led organization. Healthy engineers are eager to share ideas and lend their expertise. Each member is comfortable enough to raise concerns and ask questions. They’re focused on a common goal and take pride in their collective diligence and creativity. 

No matter the leadership role listed on your business card, data can help you assess the health of your team. From there, you can diagnose and treat any problems to empower engineers to do what they do best—solve complex problems in brilliant and beautiful ways. 

So, how will this guide help you build a healthy data-driven engineering team?

1. What problems leaders can face without data 

2. What data-driven engineering leadership is (and isn’t)

3. Why leading engineering teams with data works

4. How data can optimize workflows and meetings

5. How data can boost team health

6. How to become a better leader using data

Data can provide visibility into how your organization is collaborating and solving problems. Using objective metrics around the processes engineers are beholden to, and provide a roadmap for how to improve on their current state. But if you don’t have the data to stand on, you could be leading blind and can expect a variety of issues.

Invisible delivery: From concept to production, the work of engineering teams can seem covert until a new product or feature is released. As a result, leadership meetings can be overtaken with questions about the development team’s workload, timelines and output. When other leaders aren’t in-the-know about your team’s work, it’s difficult to plan and coordinate the other arms of the business effectively.

Unfortunately, not everyone in the organization understands the steady, yet silent progress of software development.

Risky decision making processes: With other companies ready to snatch away your market share at any given minute, uninformed decisions can be costly and even threaten your organization’s existence. Stakes this high leave little room for error, meaning from gut feelings and instincts, while valuable to a degree, shouldn’t be the sole basis for major decisions and organizational motions.

Lack of confidence in the boardroom: Articulating performance results and staffing needs based solely on anecdotal accounts could result in increased resistance to requests for resources. When you don’t have empirical data to lean on, you’re essentially missing part of your vocabulary to identify your needs to those with the power of the purse.

There are enough misconceptions about data-driven engineering leadership that it’s important to start with healthy ways to use data that can help you and your team collaborate better, and unhealthy ways that could result in a culture of mistrust.

Understanding your team
Data-driven engineering leadership gives you the power to shift from making decisions by intuition to making decisions based on data. Engineering leaders who inject more data into their development operations can better understand what their team really needs. From behavioural metrics to see the team’s nuances, building a case for more headcount or to inform better team feedback, improved data can help leaders visualize their team more clearly.

Visibility into the work
Objective use of data allows leaders to create more informed product roadmaps, remove potential roadblocks and prevent misunderstandings from other teams, leadership and board members.

With a data-driven approach, leaders will gain more transparency into the ebb and flow of the production cycles, allowing them to more accurately equip the team with the right people and resources. 

Collaboration opportunities
Data is a good way to identify where teams have gaps and overlaps in their workload and can help surface opportunities to bring specific team members together on a project, or possibly mix-up the teams to create a new dynamic. If leaders rely on their experience paired with objective data, they can create opportunities for engineers who feel stagnant and ease off those who are overworked. Leaders who can see concrete examples of their team’s nuance are poised to serve the engineers better, resulting in a healthier team culture. This can even eliminate low-value meetings, create more helpful 1:1 meetings and less contentious board meetings.

Using data to help drive progress should never be a substitute for management and leadership. Data can’t possibly replace your specialized skills and experience. Instead, it acts as a compass to suggest where managers and leaders are needed most. 

Replacement for conversations
Data without discussion isn’t helpful for anyone. Once data reveal the issues engineers are facing, it’s up to managers to start a conversation with those involved. Ideally, leaders can collaborate with their team on ways of removing blocks so that engineers have the time, energy and freedom to thrive at work. Without the data and collaboration, decisions can be fraught with tension and risk.

For example, say there’s conflict brewing between two team members. A leader is eager to eliminate the awkward tension and avoid further divisiveness. So on impulse, the leader alters code review expectations. Now how would they quantify their decision when it’s based entirely on a feeling? And what happens if, or when, another argument arises? There’s a boardroom-sized risk of jumping to conclusions when decisions are only based on biased and cursory feelings. 

Focused on lines of code 
Data serve as more than just a  measure of productivity and performance. They’re a window into understanding the intricacies of both. Think about the most basic measurements of output: lines of code and commit volume. Most of the software engineering industry agrees that metrics aren’t a good indication of the complexity or sophistication of work completed. 

With more robust data, we can better understand the cognitive load of that work. For example: If one engineer contributes 100 new lines of code to a file and another engineer’s contribution touches three files, at multiple insertion points, resulting in adding 16 lines and removing 24 lines.

Although the first engineer added more code, the second engineer’s work is arguably more complex since it involved several spot-edits to old code. Instead of being fixated on the team’s commit volume, leaders can explore the nuances and depth of that work with data. 

Creating “big brother” monitoring
Engineers come to work every day looking to solve challenging problems and ship value to customers. But unfortunately, something usually gets in their way. Maybe it’s process, meetings or waiting on others. But rarely is it the case that engineers are simply checking out or purposefully creating problems. Data should never be weaponized against your engineers, or all existing team trust will evaporate.

Data’s job is to reveal what’s obstructing engineering work so that managers can make developers’ jobs easier by eliminating blockers and smoothing out clunky systems and processes. This leaves engineers free to work and build products they’re proud of.

Improvement in anything requires more practice and better understanding. While data can’t do the work for you, it can offer understanding of where you could use some practice or additional rigor.

Building a solid foundation of data around your team provides leaders with the tools to understand and analyze the larger context of development work, know what’s working (or not) and bring the right resources in to propel teams and individual engineers to their best work. 

Here’s how: 

Track performance with industry benchmarks
With the right data in the mix, engineering leaders can help set individual and team goals and evaluate performance relative to cost. Long term, you can review coding and collaboration trends and see how those compare between teams and industry-wide.

Recognize when normal work patterns are being disrupted
If a team or individual is straying from their normal pattern, data will reveal that. The goal is to surface metrics that identify issues—like code blockers or engineers who may need coaching—then discuss solutions. 

Make informed decisions
Comparing data visually can help you see which areas of your team need help and allocate (often limited) resources where they’ll have the most impact, including requesting additional headcount or individual promotions. By using data to validate or challenge decisions that impact employees, you become a stronger and better team advocate.

If organization’s are not able to improve on day-to-day operations, growth and sustainability become impossible. Data can bring forward important learnings that will enable leaders to get constant feedback on how their team is doing and bring forward opportunities for improvements. 

• Daily stand-ups: Before the daily huddle, managers can check where the team is spending time by reviewing what’s been in code review, how long it’s been in code review, what might be at risk and why, as well as the team’s habits across commits, PRs and tickets.
  
  Using the resulting data, leaders can pinpoint workflow topics to address, like when developers are committing new work at the end of a release, or encouraging the team to share solutions to an existing problem during the meeting.

• 1-on-1s: Use metrics to understand where individuals are excelling, how they can advance their role and, when necessary, where they could improve. This offers a way to create more concrete goals for the engineer to pursue.
  
  If there are outliers in developer behaviour, managers can broach the topic during a 1:1 and get the larger story behind the data to give informed feedback to support the engineer’s ongoing growth. 

• Sprints: The story of every sprint can be enriched by metrics, but only if the data are reviewed and discussed with your entire team. Ultimately, uncovering the sprint’s true narrative will help the team spot bottlenecks, debug the development process and get engineers recognized for their crucial work.
  
  By reviewing the data before a sprint, managers can predict velocity, identify metrics of a healthy development cycle, set attainable goals and compare progress sprint-over-sprint.

• Retrospectives: Leaders can ask the engineers how they feel the sprint went, and compare that qualitative assessment with quantitative data. Once the team sees and understands the metrics, they can help identify team work patterns and determine whether those are healthy or need strengthening. 

• Build and optimize features: If your revenue’s not going up and customers aren’t going up, then who cares how much code the team wrote? Engineering leaders should. Especially if they’re concerned about ROI. Productivity always impacts the bottom line.
  
  If you’re not using data and have a feature that generates $100,000 in value, the amount of development time that went into production may not be properly accounted for. You do know which team members were assigned to that project, but they didn’t spend every hour of every day building that one feature, and without metrics, your ROI insights are blurry at best. 
  
  Leaders need clarity on what’s happening during the delivery process to figure out where resources are going and help set or reset expectations. 

• To adopt best business practices: The entire business world—with the exception of software engineering—is driven by metrics. Leaders who embrace data-driven engineering are poised for more innovation, better collaboration and better team health and clearer visibility. 

• To improve visibility: A common question posed to both CFOs and CTOs is ‘How much of our software engineering investment is spent on new work, versus supporting or refactoring legacy code?’ This is a metric that can be easily quantified by analyzing code at the time of commit and creating hard data on how much of a team’s productivity is dedicated to new projects versus to technical debt. Data-driven engineering provides a whole new level of transparency that didn’t exist previously.

Increasing team engagement and job satisfaction is important to any good leader, and objective data can help. By creating the data capture around the metrics the team cares about, leaders are able to see the roadblocks, visualize procedural pain points and make informed decisions on the fly.

• Understand and optimize team work patterns: Look at the baseline data to understand how teams and individual engineers are introducing code to the codebase. These metrics would typically include commits, pull requests and ticket activity. Using these as a general guide can allow leaders to identify and work toward fixing potential issues with processes, overworked engineers or persistent churn.

• Identify and celebrate healthy patterns: As mentioned above, data should never be weaponized against employees. Rather, leaders who want to use their data to truly benefit their teams should champion those teams and individuals who are showing healthy, productive patterns and look for ways to maximize each engineer’s strengths.

• Create guidelines and standards from good work patterns: Using the teams and individuals who are exhibiting healthy and productive work patterns as a benchmark can be a very effective way to create realistic team guidelines and best practices. 

• Analyze long term data: Looking at team and individual activity over time and comparing it with industry benchmarks can show whether the team needs help to remove blockers and streamline development cycles.

• Review collaboration: Take a look at key metrics, like each pull request’s number of reviewers, number of comments, time before the first comment and time to resolve to get a full picture of how the engineers are working and how much the code review is distributed throughout the team. 

• Compare data and improve: Using baseline pull request metrics from the team, analyze areas for improvement in the code review process.

• Analyze the daily output: Observe team and individual engineers’ contributions while taking into account the type and complexity of work completed. For example, you may decide to measure new work differently from legacy refactoring. 

• Recognize nuances: Note the deviations from output levels from teams and individuals, including when engineers are putting in extra effort dedicated towards helping others and churn.

• Identify opportunities and improve: When engineers are struggling through code, get them help and resources they need. When churn rate is on the rise, explore the reason. Overall, look for ways to make tweaks to process to improve output.

• Measure results over time: Check back at the end of sprints, after projects are completed and on a regular cadence to monitor the team’s progress and continually make adjustments as needed.

Data enables leaders to change their interactions with their teams and executive leadership alike for the better. Whether it’s lobbying for the team with the board or in a 1:1 with the new engineer on the team, objective data creates a foundation of honesty and clarity that can help teams and leaders excel. 

• Understand individual patterns: Get to know the work patterns of engineers by observing metrics, such as commits, pull requests, code activity and daily output to see the nuances of each engineer.

• Assess the complexity of their work: Seeing just lines of code entered by engineers is insufficient to fully grasp what an individual engineer is contributing to the team. It’s important to factor in the types of commits completed and breakout of work delivered (by type of code).

• Measure work long term: To see how an individual has progressed, it’s important to analyze recent work to longer term work patterns.

• Celebrate and discuss: Using the data as a guide, leaders can create meaningful goals, opportunities and plans for each engineer. It’s important to celebrate milestones and successes, and step in as a mentor and coach when an engineer feels stuck.

• Advocate and champion: The black box of software engineering has always created a messaging issue for tech leaders. Without data to stand on, it can make things like requesting more resources, creating strategic plans and advocating for the complex work the engineering team is doing much more difficult.

Need help with your data? Pluralsight Flow is built to keep you and your team in the know on your development cycles. Get started here.