In a product-led organization, "humming" engineering teams are critical to company success. You can substitute "humming" for "gel-ling" or "healthy." Despite what word you use, these teams are focused on a common goal, are energized by their collective creativity, and confident in their overall alignment.
Usually humming engineering teams are focused on innovative work within the organization, or they're quickly transitioning from treading water or repaying tech debt to innovation.
Is your team humming, and you wonder how can you keep them here as the company scales or the work becomes more complex?
You might ask, why isn't my team humming? There seems to be little engineer motivation, our velocity is slow, there's stakeholder frustration, or requirements constantly changing.
This is a part of engineering. This is where data can play a big role in gaining engineering alignment and process improvement.
We've talked to over 100 engineering managers, and found "digging" to be at least 20% of their time. This is wasted time.
Digging can take many forms:
Invisible delivery was a term I first saw used by Jeremy Morgan, and it's a perfect way to describe engineering lifecycles. "From initial concept to production, the work of engineering teams can seem covert until a new product or feature is released." Once your team enters invisible delivery mode, as a manager, you can become inundated by questions about the development team's workload, timelines, and output. Lack of understanding begets frustration, when cruising in invisible delivery mode it's hard to collaborate with other leaders to plan and coordinate effectively.
Everyone hates meetings, especially unnecessary ones. However, to piggyback off of invisible delivery - when engineering teams and stakeholders don't feel like they have a good understanding of what's happening, people want to talk more. They may even ask irrelevant questions, but what's really happening is that they arefishing for understanding. This causes managers to start digging again. It's an endless cycle that can easily be stopped with the right internal data infrastructure in place.
Guessing, a.k.a risky decision-making, is not a stable process but so often is the process for many engineering managers. Admittedly or not, most decisions come from a guess based on past experience. At most high-growth companies, uninformed decisions can be costly and have ripple effects throughout your entire organization. Gut feelings and instincts are valuable, to a degree, but should be informed by objective, indisputable information.
When building Staat, we presented it to developers to ensure we weren't creating a predatory tool. Fifty-percent of responses were great, fifty-percent were a visceral reaction to how they know their managers have tried to use engineering productivity metrics in the past. This isn't ok.
Let's start with what data-driven engineering management is not:
Very rarely do engineers underperform because they're naturally checked out. This is a fallacy that needs to end. Most engineers are energized and motivated by fixing problems and shipping features. When they start to underperform it's typically due to lack of understanding, excessive meetings, waiting on others, or poor process set by a manager. Do not use data to "watch" or "measure" the performance of an individual person. This is one of the most irresponsible ways to judge individual performance.
Data should be used as an alignment tool, and nothing more. It should align developers, managers, directors, VPs, executives, and cross-functional stakeholders.
To piggyback on "people monitoring" - engineering productivity metrics are tricky. But there's a general consensus around particular metrics that are useless and predatory:
These are evaluation metrics and rarely help you learn more about the full context of the work or developer effort. If you've purchased a tool that puts evaluation over learning, find another tool.
Learning over evaluation is the purpose of data. Data without discussion isn't helpful and too singular to make a sound decision. Data should be used as a starting point. It should uncover unseen happenings that weren't visible before that then trigger more effective conversations with your team. Maybe a developer can't quite communicate that their velocity is slower because they keep waiting on another team member or that unplanned work is plaguing their day. Data should be able to help you spot this disruption where you can then have a conversation about how to fix it and help your developer get back on track.
Ok, finally - let's review how data can empower you as a leader and your team as an aligned unit:
Making confident decisions & asks
Confident decisions come from an assurance of fact. Operating from data at the core gives you the fact you need to gather the information needed to make sound decisions. As a manager, the more information you have the more you can better understand what your team needs to "hum."
Being a manager is also about making strong asks like additional resources, be it people or tooling. Using nuanced metrics and trends can help present an objective and reasonable argument to your directors vs. an excuse for why your team may be underperforming.
Understanding the work
In our research, one of the biggest challenges engineering managers faced was really understanding the work. Essentially what this meant was having deep visibility into the product lifecycle from conception to production. With data, leaders - and even developers- can spot disruptions in their product lifecycles, enabling them to more accurately equip the team with the right people, resources, and information.
More effective collaboration
Another big challenge we uncovered in our research was that teams were having lots of frustration, but not a lot of visibility into the gaps and overlaps in workload. I'm a proponent of enabling the entire team to put data at the core. It can help surface opportunities to make iterations in team dynamics so that they gel better together. It can surface opportunities to bring specific team members together, create opportunities for engineers that feel stagnant, and ease off the ones who feel overworked. This also gives an opportunity for developers to spot disruptions that they may not have visibility on and feel integrated into the collaboration process.
Review data in daily stand-ups. As a manager, glancing at data before your stand-up can help you pose important questions to the team. Reviewing ticket progression, what's been in code review, what's stuck, pull requests can help you and your team spot bad habits that need to be improved. You can walk away from daily stand-ups having addressed important workflow topics, getting full participation from the team, and often times encouraging team progress.
I wrote a post on how 1:1s used to be very awkward for me. It was partly b/c I didn't know what to cover or how to balance personal topics vs. work topics. However, data can give you a starting point for both. You can review the workload, talk about progress, and get a better understanding of areas that need attention. You can also review the types of work the developer has been working on to help focus conversations around role advancement and career path.
I've been seeing the question, "how do I get my developers to participate in retrospectives?" floating around the internets. Most responses are we don't feel like anything will change. So why does nothing change? Most of the time it's because upper leadership believes manager/developer asks are based on subjective underperformance vs. reality. By using data and better understanding trends with the whole team - it will make you more confident as a manager to get the support your team needs.
Revamp code review process
Code review processes are tough, and getting your team to fully participate is a challenge. With data, you can review items like no. of reviewers, no. of comments, time before first comment, time to resolve, and team distribution to spot patterns that you can improve upon. Often times overworked engineers are directly linked to being overly participative in PR reviews.
Improve cycle output with faster support
Observe work metrics to track unplanned work, the complexity of work, and type of work that flows through your average release cycles. You can begin to note the disruptions on a team and individual level like churn, engineers helping others, requirement changes, etc. You can also begin to see who's struggling with code, this is an opportunity for you to step up as a leader and get them the support and resources they need.
"How much of our software investment is spent on new work vs. supporting or refactoring legacy code?" is a common question by CTOs and CFOs. At first glance, this is a surface-level question that has so many nuances that it's hard to answer simply. However, when you're backed by data you can objectively communicate these nuances to help executive leadership gain a new level of transparency that they didn't have before. With a better picture and more context, executive leadership can allocate resources more effectively to support individual teams.
By bringing together the right data you can unblock yourself and your team faster to get products to market with more efficiency. Like developers, we as managers get just as much joy by seeing our team's work get into the hands of our customers. With the right tools, data can enable you to foster an environment of continuous learning and improvement. It can empower confidence in unsexy management work like lobbying for the team or in retrospectives with disgruntled team members.
Objective data creates a foundation of honesty and clarity that pushes teams into "humming" capacities. If your team is anti-metrics or anti-data, I suggest you do an introspection on how they view you as a manager. Do not spring a new metrics system on them, but talk to them and find a way to work together with data at the core.
Without data, it can make being a manager sandwiched between upper leadership and developers hell. Developers won't understand why you're not advocating, and leadership won't understand why you're making asks.
If you've read this far - I hope you're excited about the possibility of data with your team. I hope you search for a tool that is inclusive and powerful (try Staat, shameless plug). And I hope you build and maintain an engineering team that hums!