When your team is building a software product, the majority of the work that they do is invisible. As a manager, you have to rely on in-person cues for blocked work or frustrated engineers. When they move to a remote workflow—your team also becomes invisible, and all those critical signals are dropped. In-person, you might notice: Nonverbal clues during stand-ups or retros Frequent interruptions as developers are pulled into meeting after meeting Tension between team members as they work through problems Acting on these signals is one of the most important ways you can help your team. You might say: “I noticed you seem frustrated each time you worked with Jack—is everything okay?” Or “I noticed that you’ve been helping the marketing team a lot, do you have too much on your plate right now?” When you transition to a remote workflow, you lose indicators that anyone is stuck, demotivated, or overworked. To adjust, you have to find new ways to broaden the now-limited purview that remote work allows. Signals to Remain Context-Aware From Afar When thinking about productivity or output, many software leaders think in terms of features or story points. They get a general sense of how things are moving (or not moving) based on whether these features are getting completed. But these metrics are lagging indicators, and they’re not diagnostic. If you know that you’ve shipped fewer features one sprint than you did in the previous, you have no insight into what you can do to improve things. Fortunately, we can derive much more granular signals for the speed and effectiveness of software development from the systems in which engineers already work. Data from how a developer works in their version control system, such as Commit Volume, Code Churn, or Pull Request Cycle Time, better clues you into how your team is working in real-time. These metrics are imperfect (as all metrics are), but they give you much more to work with in terms of diagnosing process problems within your newly-distributed workflow. Below, we’ve recommended a set of metrics that you can look at on a daily, weekly, and monthly basis to stay connected with how your team is working. Daily Signals for Stuck Work The most imminent threat to an efficient and happy remote team is stuck work. An engineer might be stuck because they are unsure of how to implement a change, because they’re unfamiliar with a portion of the codebase or for a number of other reasons. Any unit of work that isn’t moving through the Software Delivery Process quickly enough is a signal for you to check in. Look out for: Are team members working incrementally? Are they working on a particularly tough portion of the codebase? Infrequent pushes: Are team members reworking the same lines of code over and over again? Is there clear communication surrounding feature implementation? Rework: Are there Pull Requests that have been open for more than three business days? Is this causing multi-tasking? Long-running Pull Requests: Is a single Pull Request taking up the attention of several engineers who may be in disagreement? Pull Requests with 3+ participants: Are there Pull Requests that have been passed back and forth between the reviewer and the author several times? Pull Requests stuck in code review: shows all work in progress. See at-a-glance the Pull Requests that are most likely to impede your team. If you look at these signals with your team, you’ll have a shared understanding of how things are moving and where someone might be stuck. This data will take the pressure off developers to raise their hand during when something’s off track, and enable you, as a manager, to know when you can step in and help. Velocity daily stand-ups Weekly Signals for Goal Setting Once you’ve started tracking daily signals to keep your team on track, you can take a step back and start looking at how your engineers are working. If individual engineers are spending days working through a problem on their individual device, then opening huge Pull Requests that are perpetually getting stuck in the review process, your team will constantly feel stuck and frustrated. Agile and Continuous Delivery workflows demand that team members commit frequently, work in small batches, and limit work in progress. These habits set in motion what we call the : Virtuous Circle of Software Delivery Building these habits is crucial to minimize the risk associated with merging a PR and decrease the chances that an individual unit of work will get stuck in the process. For this, we recommend working with team members to set up process SLAs for good collaborative practices every week. Then, during retros and 1:1s, developers can work through concrete examples of when something went off track. You can set targets for things like: Can we agree that 95% of PRs should be successfully merged? We’ll investigate PRs that were closed or abandoned. Pull Request Success Rate: Can we agree to get to code reviews within 8 hours for 80% of Pull Requests? We’ll look deeper into PRs that couldn’t be reviewed quickly. Pull Request Time to Review: Can we agree to keep Review Cycles under 2 for 95% of Pull Requests? We’ll look into any PRs that get passed back and forth between author and reviewer multiple times. Pull Requests Review Cycles: Can we agree that 70% of the work should be done by at least 50% of the team? We’ll investigate deeper if just a few individuals seem to be doing most of the work. Workload Balance: Velocity’s Target feature lets you set SLAs to help hold your team accountable to their goals. Naturally, you don’t need to look at all of these metrics right away—just pick one or two that represent commonly reported issues. Selecting a granular metric, like Workload Balance, will be a much more effective indicator of what’s going amiss than a metric like Features Completed. Over time, your team can build habits that minimizes the opportunity for work to get stuck and slow down the team. Monthly Signals for Continuous Improvement Once you've identified signals that can point you towards daily and weekly improvement opportunities, you’ll want to start looking at your processes end-to-end to ensure that they’re working for, not against, your team members. First, you’ll want to make sure your processes work. If you’re working in a traditional Git workflow, you’ll want to make sure that PRs are moving along the “happy path” from Open to Reviewed to Approved to Merged. Any PRs that skip steps are working outside your process and represent opportunities for deeper investigation. Next, you’ll want to see how well this process is enabling a low time-to-market. If it takes days or weeks for changes to get into the hands of customers, your team will have a hard time quickly mitigating issues in production, and, ultimately, keeping up innovation. For this, you’ll want to keep an eye on your team’s delivery Cycle Time, or how long, on average, it takes PRs to go from a developer’s laptop to being merged to production. Velocity lets you visualize the journey of your Pull Requests from open to merged. Below, you can see metrics that represent constituents of this journey to better diagnose slowdowns. A that’s short and consistent is an indicator that your team is working with little friction, and your processes are enabling rapid innovation. If your Cycle Time is spikey, you’ll know to look into the units of work that make up a particularly high week. If your Cycle Time seems consistently high, you’ll want to to see, specifically, which processes or practices are dragging down your speed. We recommend looking at: Cycle Time break it up into components How much time passes between the earliest commit and the opening of a Pull Request? Time to Open: How much time passes between when a PR is opened and when it is first reviewed? Time to First Review: How much time passes between when a PR is opened and when it is merged to production? Time to Merge: Comparing these side by side will help you see where in your process your developers are being slowed down. When your team moves the needle and improves Cycle Time, it means you’re working together to boost the efficiency of the development process and to accelerate innovation. It’s important to communicate and celebrate success surrounding this metric to encourage continuous improvement on your team. Remote Engineers Deserve Great Leaders An unexpected transition to remote work is one of the most trying experiences for many software engineers. The already-isolating job of writing code becomes even harder when team members can’t chat or take breaks together. Leadership that is disconnected or not aware of all the challenges that they’re facing can be the final nudge that can disengage a team member. Fold in just a few extra signals to stay aligned with engineers and lend a hand when they need it most. We’ve worked with many organizations to help them smooth the transition from on-site to remote workflows. During this particularly difficult time, we’re giving away our analytics product, along with data coaching and support, for free for 45 days . Previously published at https://codeclimate.com/blog/the-essential-data-for-leading-a-remote-engineering-team/

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

The Essential Data for Leading a Remote Engineering Team

Too Long; Didn't Read

Code Climate

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

The Essential Data for Leading a Remote Engineering Team

Too Long; Didn't Read

Code Climate

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES