Leveraging Data as a Proactive Engineering Manager

In 2012, Jessica McKellar and her MIT friends started up a workplace/team chat app, Zulip, which was quickly acquired by Dropbox 18 months later. This wasn’t a unique endeavor because McKellar had managed it before — selling Ksplice to Oracle in about the same amount of time.

What does she credit her soaring success to?

Engineering management “done right.”

According to McKellar, this includes:

• Directly supporting the people on your team
• Managing execution and coordination of code across teams
• Stepping back to observe the broader organization + its processes in ways that help it naturally evolve and grow in case you were wondering, this is also what proactive engineering management looks like.

Impactful leadership is always about humans — but, when it comes to engineering leadership in software development, the best way to support humans is two-fold:

First, through data, and, second, through staying responding well in advance of rising situations and anticipating curveballs before they appear. Luckily, the two — data and proactivity — share a bidirectional relationship. That is to say, the best way to be proactive is to harness data analytics, and establishing and tracking data requires a proactive approach.

Now, proactive leadership and management isn’t one of those Platonian ideals, pursued because it’s “good.” There are real advantages and benefits to be realized when smoothing out the development pipeline, for identifying (and eliminating) major team issues, and in strengthening team and individual coaching during short- and long-term.

What Is Proactive Engineering Management?

Proactive (software) engineering leadership means you’re not a firefighter all the livelong day. Instead of being in reactive mode, solving one problem after another, or wasting time clarifying cross-team miscommunications, you’re calm, ready to empower others to do better work. You’re willing and able to identify potential problems or bottlenecks with a curious mindset.

From here, you have a clear plan to address these, improving the overall health and capacity of your team. You have time on your side — insofar as you’re able to spot unhelpful working patterns that may lead to issues before they arise — and you’re supported by the data that brings transparency to the details of “who,” “what,” “why,” “when,” and “how.”

Proactive engineering management definitely clears up efficiency and productivity issues. But, even better, it promotes a culture of trust, advocacy, and self-awareness among your team members.

The Role of DORA Metrics in Proactive Engineering Management

There’s one more aspect to proactive engineering management. It’s a benefit that we’ll explore further in this article. For now, you should know that it’s not just internal teams that benefit from this mode of operation.

You can drive tangible and significant business value — whether that’s edging out the competition by cropping up greater market share or expanding your customer base and revenue — from observing data that comes in about DORA metrics.

The idea here is that delivery performance does lead to a competitive edge, and proactive engineering management is the culture that enables it.

When you’re pursuing data about DORA metrics, you’re looking at four main software delivery indicators:

• Lead time to changes (LTTC) — the time between the first commit and the moment the code is released
• Deployment frequency (DF) — how often a team releases code
• Mean time to recovery (MTTR) — how fast a team recovers from a failed release
• Change failure rate (CFR) — the percentage of releases that lead to failures

If you’re focused on improving these metrics as a proactive engineering manager, your mission begins with using data to assess and address team performance in an ongoing way.

Taking DORA metrics into consideration at an early stage in the analytics-tracking process will allow you to drill down to granular but all-too-common issues around factors that could be bogging down lead time for changes or interrupting your deployment frequency.

Imagine being able to move from “low” performance metrics on LTTC — taking from one month to six months to move code from a developer’s workstation to the end-user — to high or even elite performance metrics. For LTTC, that would be anywhere between a day and a week to less than a day, respectively.

Coupled with a velocity-focused metric like MTTR, this means higher-quality code gets released to your customer with a lower impact from potential failed releases (supported by a healthy deployment frequency so you can focus on and ship just one pull request at a time).

Imagine what that means for your end customer’s delight at having improved features and functionality.

You can see now how the data can help even the most reactive software engineering managers shift into a mode of proactive response for software delivery performance and internal team workflows, which ultimately leads to better business profitability.

Short-Term Gains

Proactive engineering management is an experiential thing. It’s best shown rather than told, and observed for its effects rather than described. You know it when you see it because of the results it creates.

Immediate Improvements to Workflow

The lowest hanging fruits get picked first, right? For software engineering teams, these are the everyday details that can enhance or stymie their coding process and progress. It all depends on whether they’re aware of these issues or not, and whether they have a clear path forward to unburden themselves.

Fortunately, these are also the first issues a proactive engineering manager can iron out.

Through our observation and data collection of engineering teams, we’ve been able to zero in on nine workflows that present challenges that proactive engineering managers need to use as coaching moments or opportunities to improve the workflow through their team members’ behavior or changes in, for example, the code review process.

These include:

• Bit fiddling
• Pinpoint commits
• Code and clean
• Domain expertise
• Code hoarding
• Hero engineering
• High churn
• Overhelping
• Zoning in

In the Engineering Managers’ Handbook, you can find a detailed explanation of each of these workflow scenarios as well as how to improve them. For now, you should know that a proactive approach to software engineering management advocates for a defined plan to address each of these common issues.

Let’s take a look at the first one, which is “bit fiddling.”

Bit fiddling occurs when one engineer focuses on a specific area of the codebase for a long time — far more than is necessary. There are minor changes, but they’re somewhat meaningless because no real progress issues as a result. At this point, the engineer themselves risks losing motivation.

Remember the Lead Time? It was all about gaining visibility into the amount of time between the first commit and the moment the code is released.

During the course of journeying from those two points, there are a number of things that could detract from the timely releasing of code. Code could be stalled because there are too few reviewers. The code itself could be hard to comprehend for a variety of reasons, or there could be a lengthy series of unit tests required before code deployment.

A proactive software engineering manager will rely on pull request activity and define metrics that they can track to improve both development performance and software delivery performance.

For example, a proactive manager might choose to look at pull request flow ratio, which is the sum of opened PRs in a day divided by the sum of closed PRs.

This gives you insight into how many PRs are actually getting closed — if there are too many open, you have a clear set of issues to investigate from here. It could be that motivation is declining or there’s a lack of responsiveness on behalf of the contributor.

Either way, you know your goal is to reduce the number of open PRs, move them to closed, and optimize your review workflow. You can do this by then turning your attention to the review collaboration process or reimagine the process by syncing up PRs with a project management tool to better assign tasks and planning.

Eventually, you’ll get to an improved Lead Time, which means a faster, high-quality code release. You’re not confined to or limited by only one solution, either. There are many paths up the mountain, and it’s up to you, as a proactive software engineering manager, to highlight the best one.

Identifying Coaching Opportunities Faster

Strategically coaching your developers is only possible when performance data about their own patterns as well as metrics around the results exist.

In other words, it’s not enough to be able to see how fast a developer works, or spotting code churn and high-risk commits at the eleventh hour (a pattern we call hero engineering). The key is to link these metrics with the outcomes or results elicited.

In the hero engineering scenario, for example, you’ll find that one engineer tends to fix other members’ work right before a release. They’re clearly a key individual, but the net effect is not as positive as you might imagine.

Instead, strong engineers are likely to feel deflated when another individual swoops in to save the day. They could even begin to doubt their otherwise solid skills. This could stymie their growth and degrade the overall team dynamic.

Fortunately, you can, in a very tangible and visible way, track this occurrence and stop it before it gets too far.

Look for self-merged PRs, which indicate merging right before a deadline. There’s also low engagement because there’s not enough time left in the sprint.

Look at the commit risk metric — watch out for high-risk commits — and consider refining the code review process so that your team is making small, more frequent commits.

This way, you don’t alienate or call out the hero, and you don’t risk the cohesiveness of your team.

So these are cases where a proactive engineering manager’s activities and strategies are focused on being the “glue” that fills the gaps you see when others can’t.

But it’s not just about problem mitigation — your job is also about identifying and harnessing positive or helpful behaviors and strategies. If another team member is “doing it right,” it would help to bring that out, highlight it, and formulate a plan to make it a new standard.

For example, code and clean developers are a fruitful opportunity to bring in positive new change, rather than focusing on simply plugging up the holes.

Code and clean developers have a habit of paying off personal technical debt. This means that they both contribute new code and fix legacy code.

You can spot these individuals by looking at their percentage of Legacy Refactoring code.

These individuals will be key contributors to more than just an ever-evolving database. You can recognize their accomplishments but also ask them to document their process, which allows others on the team to try and implement the same process and pattern.

The result is a thriving codebase and dev team.

Implementing Best Practices that Suit a Team’s Progressive Improvement

Fact:

Using data to affect short-term, quick wins is an exciting prospect. Not only do these wins give you confidence and motivation, but they also stack up and accumulate, accelerating your dev team’s progress on all fronts — from professional improvement to process changes.

But everyday improvements eventually lead to long-term change — as long as you go from using the data to move the daily needle to harnessing the data to make broad decisions.

These decisions are usually about how teams do software development.

The three examples outlined above — developers that may bit-fiddle, issues with PRs, and opportunities presented by clean-and-code team members — are all situations that progressively contribute to a reevaluation of a team’s standards.

Engineering management analytics always focus on gains in productivity, performance, and efficiency. These are clear and tangible areas of ROI that a software development team should aim for. This is especially true when working in an Agile environment.

However, shifting from reactive to proactive management means that, within the smaller, daily, and “short-term” insights, you, as a leader, understand a significant truth:

Within these small changes are the big issues. Failing to address them early on means they can (and will) eventually spiral out of control and unfurl into bigger problems that you’ll have to react to.

When you take steps to transform developer behavior, track and change code review process, or use qualitative data about metrics like commits, pushes, or review speed, you’re being proactive because you understand this truth.

Furthermore, you’re also in the perfect position to use these metrics to scale up the impacts of these changes across the team, organization-wide. Best practices, after all, like your product’s codebase, will evolve — and being a proactive leader means that you get to decide what that evolution looks like.

Optimizing Software Delivery Performance

It should be clear by now that proactive engineering managers are curious and investigative. They’re empowered by the inflow of data and information their developer analytics software collects. And they’re strategic about how to then use that information to make meaningful change.

However, the picture is complex — and that’s why we’ve looked at situations where one metric or report was simply not enough. We needed to corroborate and establish a more holistic picture using multiple code quality and velocity metrics.

These “smaller” metrics contribute to the ways in which we optimize the software delivery process. Yes, internal teams hugely benefit from proactive management. But factors like cycle time or the four DORA metrics also benefit from these progressive, incremental changes.

Frankly, it’s optimization activities that remain the closest or most immediate tools for positively impacting revenue growth. Simply put, a product deployed and released with little to no failures, bottlenecks, and sources of developer frustration means that what you’re focusing on is completely wowing your customer.

For cycle time, proactive software engineering managers will consider KPIs like:

• Coding — activities before a PR is opened. While coding activities occur before the first commit, the time between the first commit and opening a PR can reveal whether or not your team is dealing with manageable PRs instead of those that are far too big. Large PRs lead to greater code churn and the potential for task-switching and multi-tasking, which then simply bogs down your process.
• Pickup — the effectiveness of your first hand-off in your PR workflow, quantified as “Time to First Review.” This is often where work gets stuck — and where you have an opportunity to review and refine the process so that PR reviews are more meaningful and timely. Improving this aspect of cycle time could also mean reimagining your code review process.
• Review — the velocity of changes and additions to the initial code based on reviewer feedback
• Deploy — how fast code is deployed

Reducing cycle time through the stages of development is a massive undertaking that is simplified by automating the measuring and reporting process. Waydev does offer tools to do this, but only a proactive manager understands the inherent value in prioritizing this activity as a routine best practice.

Conclusion

Any shift from reactive to proactive management is going to require time and tools.

Software development analytics by Waydev are those tools, designed to give you visibility and insight into:

• Improving developer and code review workflows
• How to strategically coach and transform team dynamics and practices
• Creating organization-wide best practices
• Optimizing both the development process and software delivery

The fact is that performance and productivity in software teams only happen in an environment of proactive decision-making and leadership. If you’re ready to do this for your team, schedule a demo with Waydev.

Also published here.