You have 1 article left to read this month before you need to register a free LeadDev.com account.
Being a data-driven leader can help you 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 do their best work.
How do you define a healthy team?
A healthy development team is critical to the success of a 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 article help you build a healthy team using data? We will be answering the following questions:
- What problems can leaders face without data?
- What is data-driven engineering leadership? And what is it not?
- Why does leading engineering teams with data, work?
- How can data optimize workflows and meetings?
- How can data boost team health?
What problems can leaders face without data?
Data can provide visibility into how your organization is collaborating and solving problems. For example, you can use objective metrics around the processes that engineers are beholden to, and consequently provide a roadmap for how to improve 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.
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 that 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 justify your needs to those with the power of the purse.
What is data-driven engineering leadership? And what is it not?
There are enough misconceptions about data-driven engineering leadership that it’s important to start with the healthy ways you can use data to help you and your team collaborate better.
What it is
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. For example, examining behavioral metrics to see the team’s nuances, building a case for more headcount, or informing 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 it 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, and create more helpful 1:1s and less contentious board meetings.
What it is not
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 reveals 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 serves as more than just a measure of productivity and performance. It’s 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 3 files at multiple insertion points. This results 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.
Why does leading engineering teams with data, work?
Improvement in anything requires more practice and better understanding. While data can’t do the work for you, it can offer an 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 do their best work.
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. In the 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 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.
How can data optimize workflows and meetings?
If organizations 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 standups
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, pull requests, 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 by encouraging the team to share solutions to an existing problem during the meeting.
1: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 behavior, 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 is 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 the number of customers isn’t going up, then who cares how much code the team wrote? Engineering leaders should. Especially if they’re concerned about the return on investment (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 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 innovation, better collaboration and 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 vs. 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 vs. technical debt. Data-driven engineering provides a whole new level of transparency that didn’t exist previously.
How can data boost team health?
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 analyze the 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.
Additionally, 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. You can now begin to create standards for 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.
By looking at data on a team’s and individual activity over time and comparing it with industry benchmarks, it can show whether the team needs help to remove blockers and streamline development cycles.
Revamp code review processes
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. Then, compare data and improve by using baseline pull request metrics from the team, and analyze areas for improvement in the code review process.
Improve daily output across the release cycle
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. Then, ensure that you recognize nuances by noting the deviations from output levels from teams and individuals. This includes when engineers are putting in extra effort dedicated toward helping others and churn. It is now possible to identify opportunities and improve. When engineers are struggling through code, get them the 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.
Become a better leader
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.
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.
I hope this article helps you to harness data-driven engineering leadership and make a real impact on your team and the wider organization.
