20 patterns
for data-driven leadership
A field guide to help you transform your software engineering team
INDIVIDUAL PATTERNS
Domain
Champion
Hoarding
The Code
Unusually
High Churn
Bullseye
Commits
Heroing
4. Bullseye Commits
This pattern is relatively common in most teams, but it often goes unrecognized: an engineer understands a problem, breaks down the project into smaller tasks, and submits code that has little room for improvement.
How to recognize it:
In practice, Bullseye Commits can be identified by when they were submitted in regard to the deadline, their impact, and how they were treated in the review process. Generally, the code was started and completed in advance of the deadline, with negligible churn. The commit’s Impact was small to modest in size and was then thoroughly reviewed. It was approved on the first try.
Want to learn more?
Get more in-depth information by downloading the PDF
Get the 20 Patterns PDF
Over
Helping
Clean As
You Go
In The
Zone
Bit
Twiddling
The Busy
Body
Scope
Creep
Flaky Product
Ownership
Expanding
Refactor
Just One
More Thing
Rubber
Stamping
TEAM PATTERNS
Knowledge
Silos
Self-merging
PRs
Long Running
PRs
A High
Bus Factor
Sprint
Retrospectives
1. Domain Champion
The Domain Champion is an expert in a particular area of the codebase. They know nearly everything there is to know about their domain: every class, every method, every algorithm and pattern.
Domain Champions will always work in the same area of code. They’ll also rewrite their code over and over, and you’ll see it in churn and legacy refactoring metrics as they perfect it.
How to recognize it:
2. Hoarding the Code
This pattern refers to the work behavior of repeatedly working privately and hoarding all work in progress to deliver one giant pull request at the end of the sprint.
Large and infrequent commits can be a sign that the engineer is working privately until their project is finished, and then submitting their work all at once.
How to recognize it:
Churn is a natural and healthy part of the development process and varies from project to project. However, Unusually High Churn is often an early indicator that a team or a person may be struggling with an assignment.
This pattern is characterized by high levels of churn in the back of the sprint or project. Watch for churn rates that climb significantly above the engineer’s historical average (see the Snapshot and Spot Check reports), pairing that information with where they are in a project.
How to recognize it:
3. Unusually High Churn
5. Heroing
Right before a release, the “Hero” finds some critical defect and makes a diving catch to save the day. More formally, Heroing is the reoccurring tendency to fix other people’s work at the last minute.
The Hero typically dominates Pluralsight Flow’s Help Others metric, particularly in the form of late arriving check-ins. They’re also distinguishable in the review process, where they may be self-merging PRs (and typically right before the deadline), or they will show very low Receptiveness in the review process.
How to recognize it:
6. Over Helping
Collaboration among teammates is a natural and expected part of the development process. Over Helping is the pattern whereby one developer spends unnatural amounts of time helping another developer to get their work across the line.
You’ll notice this pattern in the same way you’d realize “Heroing” (Pattern #5) in Pluralsight Flow’s Review and Collaboration reports and the Help Others metric. Look for reoccurring, last-minute corrections between the same two people.
How to recognize it:
A codebase is continuously evolving by nature, but it doesn’t evolve evenly across all aspects. A Clean As You Go engineer will notice and refine shortcomings even if it’s not essential to the task at hand.
“Clean As You Go” refers to when an engineer contributes new code and also mends adjacent code in the codebase. Consequently, you’ll notice these engineers writing new code while also showing higher levels of legacy refactoring, that together usually exceed the expected scope of change for the assignment at hand.
How to recognize it:
7. Clean As You Go
This pattern is exhibited by engineers whose work is, in a word, consistent. They have a knack for getting in the zone and shipping high-quality work week in and week out. Their work is reliable and predictable in nearly every way.
An engineer in the zone organizes their day to eliminate distraction and focus on delivering business value. Their Active Days are consistently above average. Their Impact is high and consistent. Their PRs are timely, evenly paced, and nicely sized. They consistently participate in reviews, so their Involvement is high and consistent. Their churn is usually lower than average.
How to recognize it:
8. In the Zone
Bit Twiddling is like working on jigsaw puzzle to the point where everything looks the same and you’re not making progress anymore. You might pick up the same piece, try it in a few places, rotate it, put down, only to pick it up a few minutes later.
Look for high rates of churn in the same area of the code. The key is to couple repetition and refactoring with ambivalence or indifference in code review over an extended period.
How to recognize it:
9. Bit Twiddling
Download 20 Patterns PDF
Engineers exhibiting this pattern will show high levels of Impact and lots of small pull requests without any identifiable home base in the code. They’ll show a high level of Involvement in the review process. And because they typically spend their time building and spend less time bug fixing their own work, they’ll show high levels of new work and relatively low churn.
How to recognize it:
The Busy Body is an engineer who skips all over the codebase: they’ll fix a front-end problem here, jump to some refactoring, then fiddle with the database over there.
10. The Busy Body
Download 20 Patterns PDF
Download 20 Patterns PDF
Download 20 Patterns PDF
Download 20 Patterns PDF
Download 20 Patterns PDF
Download 20 Patterns PDF
Download 20 Patterns PDF
Download 20 Patterns PDF
Download 20 Patterns PDF
Download 20 Patterns PDF
Scope Creep is characterized by a sharp uptick in progress toward the back of a sprint that wasn’t driven by code review.
Generally, the problem a team is solving should be getting smaller over time as features are completed. So a sudden spike in activity, particularly in the later stages of a project, tends to be a signal that something new came in.
How to recognize it:
Intuitively, we all know what Scope Creep is — along with its associated risks. Still, there are plenty of different definitions for the issue so here’s what we’re focusing on:
11. Scope Creep
Download 20 Patterns PDF
This pattern tends to reveal itself in recurring scope creep driven by the same product owner. You may notice a significant expansion of code that wasn’t driven by code review in the back of the sprint.
How to recognize it:
Miscommunications between Product and Engineering can easily lead to Scope Creep. Flaky Product Ownership, however, can show up slightly different in the data and also generally requires a different approach.
12. Flaky Product Ownership
Download 20 Patterns PDF
A small amount of legacy refactoring is healthy. It’s when you notice a whole slew of changes in areas that are unrelated to the feature at hand.
How to recognize it:
Expanding refactors happen when a planned effort to improve or revise a section of code triggers a dramatic widening of scope.
13. Expanding Refactor
Download 20 Patterns PDF
“Just One More Thing,” when appearing across a team, is characterized by a spike in PRs being submitted near the end of a sprint after the main PR was approved. These engineers will also show a high level of New Work.
How to recognize it:
“Just One More Thing” refers to the pattern of late-arriving pull requests. A team submits work, but then—right before the deadline—they jump in and make additions to that work.
14. Just One More Thing
Download 20 Patterns PDF
Rubber Stamping is most noticeable in the Review and Collaboration reports. Watch the Review Workflow for PRs that opened and closed in a preposterously short period of time, with a very low level of Receptiveness. Low levels of engagement in reviews can also be seen in the Involvement and Review Coverage metrics.
How to recognize it:
Rubber Stamping is the process by which an engineer approves their colleague’s PR without giving it a substantial review.
15. Rubber Stamping
Download 20 Patterns PDF
When team members are co-located, a basic understanding of where people sit in an office along with an awareness of any other social bonds can be helpful indicators as to where silos may form.
How to recognize it:
Knowledge Silos are usually experienced between departments in traditional organizational structures, but they also form within teams when information is not passing freely between individuals.
16. Knowledge Silos
Download 20 Patterns PDF
Self-merging is easy to see because the submitter and the reviewer are the same people. In Pluralsight Flow these instances will show up in the team’s Unreviewed PRs metric as well as in their Review Workflow.
How to recognize it:
This pattern refers to when an engineer opens a pull request and then approves it themselves. This means no one else reviewed the work and it’s headed to production!
17. Self-Merging PRs
Download 20 Patterns PDF
Long-running PRs can quickly be identified in the team’s Review Workflow report, filtered by ‘PR Status: Open’ and sorted by ‘oldest PRs’. Select the number of PRs you’d like to see in one view, then hover over those that have been open for more than a day.
How to recognize it:
Long-running pull requests are PRs that have been open for a very long time (more than a week). A PR that doesn’t close in a normal amount of time (within a day) can indicate uncertainty or disagreement about the code.
18. Long-Running PRs
Download 20 Patterns PDF
A team’s distribution of knowledge can be visualized with the Knowledge Sharing Index. It’s best to use this report within teams that you would expect to review each other’s work. A low Index means that there is a lower distribution of knowledge across a team, representing a higher bus factor risk. This also means there may be silos forming; a high Index represents a greater distribution of knowledge across the team.
How to recognize it:
“Bus factor” is a thought experiment that asks what the consequence would be if an individual team member were hit by a bus.
19. A High Bus Factor
Download 20 Patterns PDF
A good Sprint Retrospective uses data to help people compare what they felt happened during the sprint and what actually happened in the sprint.
How to recognize it:
Retrospectives are a common practice that offer an easy way to continuously improve: take time to reflect, as an individual or a team, on a project, action, or occurrence
20. Sprint Retrospectives
TEAM PATTERNS
Download 20 Patterns PDF
A good Sprint Retrospective uses data to help people compare what they felt happened during the sprint and what actually happened in the sprint.
How to recognize it:
Retrospectives are a common practice that offer an easy way to continuously improve: take time to reflect, as an individual or a team, on a project, action, or occurrence
20. Sprint Retrospectives
