3 Flow reports to help your one-on-ones

One-on-ones are the key and crux to open communication with your team. They can offer you an unfiltered glimpse into the needs of your team when done right, and can create friction when not. It’s important for engineering managers and leaders to foster autonomy among their team. The more you create an autonomous environment for your team, the more you can remove themselves from the daily weeds of the code. As you allow their team more space to make decisions, engineers will take ownership of the fine-tuning of the codebase. 

When you, as a leader are allowed to step away from the minutiae of submitting code, you can focus on clearing obstacles and help solve challenges to make the engineers’ job easier. Using data in one-on-ones can also offer your team space to support and showcase their progress. By coupling data with qualitative analysis, you can help your team bring their efforts to the front of the conversation in a way that builds trust.

Additionally, you as a leader can be more effective for your team when you understand the nuances of your engineers and their challenges beyond just anecdotal information. You can highlight unintended consequences of ambiguous requests, advocate on behalf of specific team members, justify additional budget needs and draw the throughline between your team and the outcomes of the business. Let's dig into how Pluralsight Flow can help facilitate data-driven one-on-ones.

The player card shows an individual's core metrics over a selected time period, in one clear dashboard. It's specifically designed for developers to use in one-on-ones with team leads or managers to showcase core individual metrics across three categories. The code fundamentals, the submit fundamentals and the review fundamentals.

In addition to getting a clear picture of each engineer’s workload, progress and roadblocks, the player card can be easily used to highlight team and individual performance to leadership. Managers can bring these reports in one-on-ones with leadership to help them keep a pulse on how the team is doing and proactively make the team's work visible. In many cases, leadership simply wants to know that your team's output is relatively aligned with expectations. Start incorporating this report on a monthly cadence to help your manager know how things are going. 

One of the most rewarding parts of management is the unique opportunity to further your team's growth, learning and career. Here are a few ways using the player cards can help you focus on the code, submit and review fundamentals. Since these metrics provide the most succinct, quantitative narrative for an individual over time. Give team members the opportunity to tie their outputs to relevant business needs and objectives. Bring the player card to your one-on-one and focus on your team member's strengths or where they're in the top percentiles while also allowing time to discuss any potential issues or roadblocks.

Project Timeline shows you aggregate outputs. With it, you can see progress and trends for the team, which can act a lot like a highlight reel. You can also show how much time is spent writing new code versus paying down technical debt. Think of it like a snapshot of where your team’s efforts are going, including, new work, legacy refactoring, helping others and churn.

You may know the release your team is on and the goals of the sprint, but do you know how each engineer’s time is being spent, and on what? To get an understanding of each engineer’s workload, use the project timeline to analyze how much of the team’s collective time is being spent on the different aspects of the job, and where the individual’s time is going. 

If your team is more focused on releasing new products or features, you'd probably expect around half of the work delivered or more to be new work or new code that doesn't replace other code. Other engineering teams might be spending more time on legacy refactoring, which is defined as code that updates or edits old code. The project timeline can offer a good way to see if an individual is struggling through a project that could be shown through churn rate, or they could be being overworked or spending a lot of time helping other developers, and may need some assistance offloading some work. 

Data like this makes the invisible work your team does visible to the people who need to understand it.

Flow’s code fundamentals are a great way to dig a layer deeper on what the team and individual developers are working on. By measuring commits, codebase impact, efficiency, mob/pair commits and pull request metrics, you can extract learnings on each engineer’s coding and collaboration habits. This will allow the engineer to break down the nuts and bolts of their day-to-day and bring up any roadblocks they’re facing.

It’s not always easy to know how each engineer feels about their job. They may be grinding away, and growing ever more frustrated. Maybe, they’re feeling stumped, but are hesitant to ask for help, especially if they’re new. Using code fundamentals in one-on-ones can, leaders can offer go on more of a deep dive of different aspects they feel need to be addressed. 

If an engineer feels they are consistently swamped, they can show you, rather than just tell you, what they believe the problem is. Situations like this can lead to great conversations about workloads, and in many cases, create concrete data showing the need for additional headcount or other resources. 

Code fundamentals can also be helpful for knowing how long it takes new engineers to start creating value using impact. The impact measurement is essentially the complexity and bigness of output. Each hire should increase the impact score. Leaders can benchmark the timeframe of when new hires can expect to be contributing and help those individuals get up to speed.

Looking to improve your data and insights, but aren’t using Flow? Check out all the ways Flow can get you the clarity you need by heading here.