Developer Coaching
Developer Coaching allows those in a management or team lead position to view insights about an individual team member's workflow in order to identify information on developer wellness and experience. To access Developer Coaching, go to People > Coaching.
Filtering the dashboard
To control which developer you're seeing information about, select their name from the dropdown list on the left of the page.
On the top right of the page, you can filter by team and by time frame. If a team filter is selected, only members of that team will show in the drop-down menu. The time frame selection will adjust the time frame of the data used to generate insights:
Teams, knowledge areas, and coding languages
Next to the developer's name in the drop-down menu, you'll see a quick summary of the teams the developer is a contributor to in LinearB. Additionally, you'll see a list of the repositories they contribute to, and the languages they work in most frequently.
Development experience
The development experience graph tracks:
- The developer's individual coding time for the time period
- The developer's individual pickup time for the time period (how long did PRs they reviewed sit before being picked up)
- How long their reviews waited before being merged
- How long their merged code waited before being released
The top graph in each category represents the values for the current time period. The gray graphs below represent that value for the previous time period, so that you can track changes over time. If a developer's coding time suddenly drops dramatically, you may want to explore that—is it expected (they were at an offsite team-building), or a sign of concern (they are pulled in to too many meetings)?
Wellness workload
The wellness workload graph tracks the size of a developer's PRs per-branch and per-PM tool issue. This allows you to see how many lines of code a developer is committing, and whether it's broken up into appropriately small PRs. If not, you can dig in to why:
- Are our stories not broken into small chunks of work, forcing large PRs?
- Is this teammate just on a code-heavy week and feeling good?
- Do we need to set expectations with the team on best practices for their PRs, and perhaps set a team goal around PR size?
Developer metrics
This spider chart shows metrics associated with the individual developer as both a PR submitter and a PR reviewer.
Reviewer metrics include:
- Reviews
- Review depth
- Pickup time
- PR approve time
Submitter metrics include:
- PRs opened
- PR size
- Coding time
- PR maturity
This allows you to understand the strengths and challenges each individual developer is facing. For example, are they writing small, manageable PRs—and a lot of them? Then you might see them picking up fewer reviews in that time period.
Similarly, a senior dev may be reviewing a ton of reviews, and doing so in-depth and quickly—but as a result, they may have longer coding time and fewer PRs opened. Or, a team member might be in the middle of the pack on all of the metrics: they're a good team player helping both create new code and review their peers' PRs.
This isn't intended as a performance measuring tool. After all, a team needs all three kinds of developers in most cases. But it can be good to validate stress points for a developer and make sure that your team is spending the time where it's most valuable for your overall goals (maybe the senior developer needs to assign some of the reviews to mid-career teammates to work on a really important piece of architectural work). These graphs can help facilitate those conversations.
Hovering over any point on the graph will show you more info on that metric:
And checking the second and third radio buttons will allow you to compare that developer's work split to another team or to every developer at the org:
This can be especially helpful for showing onboarding teammates how they're progressing relative to peers, giving them reassurance that they're spending their time on the right tasks.
