20 Patterns to

Watch for in Your

Engineering Team
A field guide to help you recognize achievement, spot bottlenecks,
and debug your development process with data.
20 Patterns to
Watch for in Your
Engineering Team
A field guide to help you recognize achievement, spot bottlenecks,
and debug your development process with data.

©2019 GitPrime Inc.

Ed 2019.03.18
Table of Contents

PART 1
Domain Champion 2
Hoarding the Code 5
Unusually High Churn 8
Bullseye Commits 11
Heroing 13
Over Helping 15
Clean As You Go 18
In the Zone 20
Bit Twiddling 22
The Busy Body 24

PART 2
Scope Creep 27
Flaky Product Ownership 29
Expanding Refactor 31
Just One More Thing 33
Rubber Stamping 35
Knowledge Silos 37
Self-Merging PRs 40
Long-Running PRs 42
A High Bus Factor 44
Sprint Retrospectives 46
Introduction

At GitPrime we believe effective engineering managers are

also effective debuggers.

Effective managers view their teams as complex

interdependent systems, with inputs and outputs. When the
outputs aren’t as expected, great managers approach the
problem with curiosity and are relentless in their pursuit of
the root cause. They watch code reviews and visualize work
patterns, spotting bottlenecks or process issues that, when
cleared, increase the overall health and capacity of the team.

By searching for “why” they uncover organizational issues, and

learn how their teams work and how to resolve these problems
in the future.

20 Patterns is a collection of work patterns we’ve observed

in working with hundreds of software teams. Our hope is that
you’ll use this field guide to get a better feel for how the team
works, and to recognize achievement, spot bottlenecks, and
debug your development process with data.
PART 1
Work patterns exhibited on an individual level
PATTE R N 0 1
Domain Champion
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.

In truth, they probably wrote most of it, and Domain Champions will typically show low
in some cases rewrote the same sections of Receptiveness in incorporating feedback
code multiple times. from reviews.

The Domain Champion isn’t just “the engineer Domain Champions will seldom, if ever, appear
who knows credit card processing”; it’s all they blocked. Short-term, it’s a highly productive
ever work on. It’s their whole day, every day. pattern. But it’s often not sustainable and can
lead to stagnation, which of course can lead to
Some degree of job specialization is essential attrition.
and often motivating. But even within
specialized roles there can be ‘too much of
one thing.’ Managers must balance enabling a Primary Focus
team member to unilaterally own the expertise,
and encouraging breadth of experience.

How to recognize it
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. What to do
Assign tickets that focus on other areas of
Domain Champions are deeply familiar with the codebase.
one particular domain. As a result, they’ll
typically submit their work in small, frequent Of course, some engineers would prefer to
commits and will show a sustained above stay where they are. It can be very enjoyable
average Impact. to do a task you’re good at. And, it can be
uncomfortable to take on work that requires
Because no one else knows more than the information or skills you have less practice
Domain Champion, there’s usually very with. But effective managers will strive to
little actionable feedback that others can challenge their team.
provide in the review process. As a result,

20 Patterns to Watch for in Your Engineering Team 3

Start a new conversation in your next 3. Ask them if they are willing to take on a
one-on-one: small assignment outside their domain
in part to help share the best practices
1. Acknowledge their expertise and they’ve developed refining the code in
encourage them to share that expertise their domain.
with others. Ask them who, if anyone,
would benefit from participating in code Inch the engineer out of their domain
reviews in the domain to learn best using small, low-risk tickets. A little bit of
practices. diversification can go a long way toward
minimizing attrition risk and maximizing best
2. Ask them what they like to work on — first
practices.
generally, then specifically.

20 Patterns to Watch for in Your Engineering Team 4

PATTE R N 02
Hoarding the Code
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.

It’s not uncommon for programmers to wait When you see large and infrequent commits,
until their work is done to share it. In creative first consider the pattern’s duration (have
and research-intensive fields, it can be a we seen this pattern for years, or has it only
natural tendency to avoid sharing work when recently been visible?). This information
it’s only just started. There are plenty of can help determine whether this is the
reasons why this might be: a fear of having engineer’s preferred way of working, or if this
others judge the work in progress, a fear of is caused by something outside the normal
others taking ideas, or a desire to make the development process.
whole process seem effortless, to name a few.
CODE COMMITS
THIS WEEK
Whatever the reason, the heart of the
Eng 1
problem is this: the more an individual saves
up their work, the less they collaborate with
others. Working alone is inherently riskier Eng 2
than working with others. And Software
Engineering is a team sport.
M Tu W Th F
This tendency to work privately and then
submit work all at once doesn’t just limit and
slow down the individual — it’s damaging to How to recognize it
the team’s progress as a whole. Submitting Large and infrequent commits can be a sign
work all at once means that there weren’t that the engineer is working privately until
any opportunities for collaboration along their project is finished, and then submitting
the way. Even more, once the work was their work all at once.
submitted, someone else had to review all
of that work. So naturally, this work behavior This pattern is typically first seen in the
can also lead to lower quality code — both Work Log report but is also identifiable in the
from the Submitter’s standpoint (who didn’t team’s Review Workflow. These PRs are larger
check in their work early to get feedback or and usually come later in a sprint or project.
notice potential missteps), and the Reviewer’s Because of this, they’ll typically either take a
perspective (who likely doesn’t have enough longer time to review (relative to the team’s
time or energy to adequately review all of average) or will get a lower level of review
that code). (see Review Coverage).

20 Patterns to Watch for in Your Engineering Team 6

It’s also common for these engineers to show This can be great timing for an impromptu and
lower than average Receptiveness in the informal 1:1. Going on a walk or getting coffee,
Submit Fundamentals. When people work in for example, can keep the conversation casual.
isolation, only submitting it for review once Get them talking about their latest project, ask
they’ve decided it’s the ‘right’ solution later in what went well and what didn’t, and recognize
the sprint, it’s generally much more difficult to their achievement.
take feedback on that work objectively.
Along the way, bring up the topic of team
collaboration, and how saving work until it’s
What to do completed leaves little room for learning from
Above all else, be compassionate. Odds are, others throughout the process. When teams
you’ve recognized this pattern right before do work together throughout a project, they
or just after the end of a sprint, so these can learn from each other’s perspectives,
engineers are likely tired, stressed, and worn reduce uncertainty and move faster, and
out. Make sure they get the time and space even find improved solutions to the problem.
they need to recover from delivering such a In practice, that might look like submitting
big payload. work far before the engineer thinks it’s ready
for a review.

20 Patterns to Watch for in Your Engineering Team 7

PATTE R N 03
Unusually High Churn
3. Unusually High Churn

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.

In benchmarking the code contribution nn They’re struggling with the problem at

patterns of over 85,000 software engineers, hand. This situation manifests differently
GitPrime’s data science team identified that than with Hoarding the Code (Pattern
Code Churn levels frequently run between #2), because in this case, the engineer
13-30% of all code committed (i.e., 70-87% initially thought they had correctly solved
Efficiency), while a typical team can expect the problem, perhaps even sent it off for
to operate in the neighborhood of 25% Code review, and then discovered it needed
Churn (75% Efficiency). to be rewritten. Not just touched up.
Rewritten.
Testing, reworking, and exploring various nn Or, most commonly, issues concerning
solutions is expected, and these levels will
external stakeholders. We see this with
vary between people, types of projects, and
unclear or ambiguous specs, late arriving
stage in the software lifecycle. Given the
requirements, or mid-sprint updates to
variance, becoming familiar with your team’s
the deliverables.
‘normal’ levels is necessary to identify when
something is off.
How to recognize it
Unusually high churn levels aren’t a problem This pattern is characterized by high levels
in themselves. More likely, there are outside of churn in the back of the sprint or project.
factors causing the problem. Watch for churn rates that climb significantly
above the engineer’s historical average (see
An unusually high level of churn can be the Snapshot and Spot Check reports), pairing
indicative of one of three behaviors: that information with where they are in
a project.
nn Perfectionism: When an engineers’
standards of “good enough” are not
aligned with the company’s standard of
“good enough.” Engineers keep going back Productive
Throughput
into the code to rewrite it because they
think it can and should be better but may
Code
not add much to the actual functionality
Churn
of the code.

20 Patterns to Watch for in Your Engineering Team 9

What to do
Churn is normal in lots of situations. If an external stakeholder is not driving the
Redesigns, prototypes, and POC’s are all Unusually High Churn, call in the cavalry!
examples where you would expect to rewrite
large chunks of code. So when you notice It is usually preferable to be coached by
unusually high churn, take into consideration a fellow engineer or team lead instead of
whether this is routine or something’s off. If a manager.
it’s the latter:
1. Ask for a pre-submit code review or a
Determine whether an external stakeholder rubber duck.
is driving the situation. If so (and the
2. Ask to split the work. The act of dividing
engineer has verified that this is causing the
the work often reveals the root issue.
higher levels of churn), then:
3. Ask a more senior engineer to assess
1. Show the data. Show how late arriving what “good enough” is in the context of
specs or last-minute changes are the project.
throwing the project off.
4. If the problem is difficult, or if the domain
2. Pull the ticket from the sprint, or decide is unfamiliar, bring in another engineer to
on an MVP and split off the additions into pair program.
a refinement sprint.

20 Patterns to Watch for in Your Engineering Team 10

PATTE R N 04
Bullseye Commits
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.

Most likely, not all of the commits that make Eng 1 PR Opened
up the project will be Bullseyes. But the ones
that are, generally have a small to modest Eng 2 Review and Comment
impact and were thoroughly reviewed and
approved on the first try. Celebrate them! Eng 3 Review and Comment

Eng 1 Responds
How to recognize it
Eng 2 PR Merged
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 What to do
process. Generally, the code was started Recognize a clean bullseye in a stand-up,
and completed in advance of the deadline, or a simple note: “I saw that check-in, nice
with negligible churn. The commit’s Impact job!” Whether it’s public or private, showing
was small to modest in size and was then that you noticed and that you care will only
thoroughly reviewed. It was approved on the reinforce this pattern.
first try (see Review Workflow).
If there’s an engineer who regularly makes
It’s the level of thoroughness in the review Bullseye Commits, it may be helpful for others
that distinguishes Bullseye Commits from to understand how they approach projects.
Rubber Stamping (Pattern #15). In Bullseye Ask the engineer to do a lunch and learn, or
Commits, code reviews are substantive. consider asking them to provide feedback on
another engineer’s work in the review process.

20 Patterns to Watch for in Your Engineering Team 12

PATTE R N 0 5
Heroing
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.

Granted, a good save is usually better than level of engagement in the review process
no save. But regular Heroing leads to the (see the Review and Collaboration metrics).
creation of unhealthy dynamics within the
team or otherwise encourages undisciplined Helping Others
programming. Some team members even learn
to expect them to jump in on every release.

TEAMWORK
Heroing can be a symptom of poor delegation
or micro-management. It also points to
Review Coverage
trust issues on a number of levels. The Hero
will ultimately undermine growth by short-
TIME Release
circuiting feedback loops and, over time, can
foster uncertainty and self-doubt in otherwise
strong engineers. At its worst, the Hero feeds
a culture of laziness: everyone knows the What to do
Hero will “fix” the work anyway so why bother. Rather than managing the ‘saves,’ manage the
Ironically, those last-minute fixes are the code review process.
genesis of a lot of technical debt.
Ideally, team members are making small and
frequent commits and requesting interim
How to recognize it reviews for larger projects. If that’s not the
The Hero typically dominates GitPrime’s Help case, consider working toward that goal first.
Others metric, particularly in the form of late It’ll help to get the Hero’s feedback early, even
arriving check-ins. They’re also distinguishable before the code is done.
in the review process, where they may be
self-merging PRs (and typically right before When the team is in the habit of getting
the deadline), or they will show very low feedback early and often throughout a project,
Receptiveness in the review process (meaning as opposed to submitting massive PRs all at
either others aren’t providing substantial once, the barrier to participating in the review
feedback or the Hero isn’t incorporating it). process is lower. This can make it easier to
promote healthier collaboration patterns and
It can be hard to disagree with their get everyone — especially the Hero — to
changes — especially with these changes give and be receptive to feedback in reviews.
being made so late in the sprint. This is partly Coach the Hero to turn their ‘fixes’ into
why the Hero’s PRs usually show a very low actionable feedback for their teammates.

20 Patterns to Watch for in Your Engineering Team 14

PATTE R N 0 6
Over Helping
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.

Engineer One submits. Engineer Two cleans Review Coverage. The other engineer will
it up, over and over again. This behavior can not. One engineer will have a high Impact; the
be normal on small project-based teams. But other won’t.
when that 1-2-1-2 pattern doesn’t taper off, it’s
a signal that should draw your attention. This behavior can be perfectly healthy and
expected when in a mentorship-type situation.
The problem is threefold: (1) always cleaning But beyond a certain point, rotation is in order.
someone else’s work takes away from one’s
own assignments, (2) it impairs the original
author’s efforts toward true independent
Disproportionate Help
mastery, (3) it can overburden the helper and Code Review
and leave the original author in a continuous Eng 1 Eng 2
unnatural waiting state.

How to recognize it
You’ll notice this pattern in the same way you’d
realize “Heroing” (Pattern #5) in GitPrime’s
Review and Collaboration reports and the What to do
Help Others metric. Look for reoccurring, nn Bring additional engineers into the
last-minute corrections between the same code review process. A side effect
two people. of this solution is that by increasing
the distribution of reviews, you’re
In the Review and Collaboration and strengthening the team’s overall
Operational reports, you’ll notice these two knowledge of the codebase (see
consistently review each other’s work. One Knowledge Sharing).
engineer will have a high Help Others, but it’s nn Cross-train and assign both engineers to
not reciprocated. The “load-bearing” engineer
different areas of the codebase.
will also show high levels of Influence and

20 Patterns to Watch for in Your Engineering Team 16

 nn Assign the senior engineer a very former employer. Making light of a friendship
challenging project. The idea here is to or teasing them can be incredibly damaging
give them challenging projects where they and hurtful. Go the extra mile to keep it
don’t have the time or energy to review professional.
their colleague’s work.
And, as always, be transparent. You’re
nn Lastly, the stronger of the two is not trying to split up friendships. It’s the
showing natural leadership and coaching manager’s job to ensure that knowledge of
tendencies. Look for opportunities to feed the codebase is distributed evenly across the
this more broadly to the whole team. team and to ensure that people are honing
their craft and growing their careers.
One note of caution: be mindful when the two
engineers are friends or were colleagues at a

20 Patterns to Watch for in Your Engineering Team 17

PATTE R N 07
Clean As You Go
7. Clean As You Go

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.

This pattern of continually improving the code WORK FOCUS TEAM

AVG.
adjacent to the code the engineer is working New Work 31%
on, is a fantastic pattern to encourage.
Legacy Refactor 52%
Help Others 6%
“Fixing” work certainly doesn’t get the
attention that “feature” work does, in part Churn 11%
because there’s rarely that ta-da moment.
While the activity of regularly fixing existing
code while working on other tasks can
be much less visible and recognizable What to do
than working on new code, this engineer’s Recognize this engineer’s work publicly and
contribution is invaluable. use it as a model for other team members
to work towards. Regularly acknowledge it
in sprint retrospectives and standups, even
How to recognize it after you first observe the pattern. Consistent
“Clean As You Go” refers to when an engineer acknowledgment lets everyone know you
contributes new code and also mends value this effort.
adjacent code in the codebase. Consequently,
you’ll notice these engineers writing new Encourage this engineer to formalize their
code while also showing higher levels of work pattern with documented coding
legacy refactoring, that together usually standards (e.g., naming conventions, getter/
exceed the expected scope of change for the setters, preferred patterns for ORM work, etc.)
assignment at hand.
A little bit of encouragement can go a
long way to minimizing tech debt, and the
engineers who Clean As They Go can help
demonstrate how these best practices look.

20 Patterns to Watch for in Your Engineering Team 19

PATTE R N 08
In the Zone
8. In the Zone

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.

Professional software development is an Collaboration reports will show this pattern

endurance sport. To create lasting enterprise over time, and they can be used to support
value, you must show up every day and the story (e.g., “six weeks of committing code
produce quality work. Real value creation can every day is something to admire”).
take years.
COMMITS PRs TICKETS
It’s tempting to think of this as a person
and not a pattern. However it’s useful to
Eng 1
depersonalize this engineer’s work as a
pattern — it’s easier for others to model
discrete behaviors than it is to model a person.
Eng 2

How to recognize it
M Tu W Th F
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 If increasing overall team velocity is important
Impact is high and consistent. Their PRs are to you, helping everyone on your team find
timely, evenly paced, and nicely sized. They their zone is a foundational place to start.
consistently participate in reviews, so their
Involvement is high and consistent. Their An essay from Paul Graham, titled “Maker’s
churn is usually lower than average. Schedule, Manager’s Schedule” offers context
and strategies for blocking meetings and
creating space to get in the zone.
What to do
Similar to engineers who exhibit the “Clean Small changes in scheduling and reduction
As You Go” pattern, it helps to acknowledge of interruptions can amount to significant
this pattern either publicly, privately, or both. increase in capacity. Furthermore, consistently
Emphasize their consistency and how great getting in the zone allows your team to ship at
code is built not in a single sprint or pulling a sustainable pace without suffering from the
all-nighters. The Work Log and Review and burnout of heroic sprints.

20 Patterns to Watch for in Your Engineering Team 21

PAT TE R N 09
Bit Twiddling
9. Bit Twiddling

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.

Bit Twiddling reveals itself when an engineer H I G H I M PACT

is unwaveringly focused on a single area of

the codebase for a very long time, making
only slight changes here and there. This often
happens because the engineer doesn’t fully
HIGH LO W
understand the problem or the context for CHURN CHURN
making the change.

They may be losing steam and motivation, or Could be Stuck

are at high risk for doing so.
LO W I M PACT

How to recognize it
Look for high rates of churn in the same
area of the code. The key is to couple What to do
repetition and refactoring with ambivalence Look for ways to reenergize the engineer with
or indifference in code review over an a new project. Find a ticket, even a small one,
extended period. that will lead into new and interesting areas of
the code — even if it comes at the expense of
For example, watch for a standard library the team’s productivity in the short-term.
call, or otherwise stable code, get refactored
into customized code for some difficult to Creative workers thrive when tackling new
articulate optimization. Or, watch for code and challenging problems, even if they at
that gets refined and refactored multiple first balk at working outside their area of
times with disinterest — light code review expertise. New experience typically leads
and PRs with generic submitter comments to learning something new, a process most
like “refactoring,” “reorganizing,” or “touch up,” engineers enjoy.
followed by “LGTM”.

20 Patterns to Watch for in Your Engineering Team 23

PATTE R N 10
The Busy Body
10. The Busy Body

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.

Their work is always lightweight and shies

A R E A S O F S P E C I A L I Z AT I O N
away from heavier problems. This behavior
can be perfectly normal over short periods
or in isolated instances. And, in fact, some
shifting around is healthy.
The
But the Busy Body is problematic over a Busy Body
long period because these engineers end up
without a strong sense of ownership. There’s
DOMAIN KNOWLEDGE
nothing for them to point at and say, “I made
that.” Even if they can solve a wide range of
problems, lacking something that they own
can lead to attrition. What to do
Give these engineers something to own top to
bottom. Whether it’s a module, a new feature,
How to recognize it or a large project, ask them to do more
Engineers exhibiting this pattern will show than just ‘get it done’. Ask them to become
high levels of Impact and lots of small pull an expert in that particular area or on that
requests without any identifiable home specific project.
base in the code. They’ll show a high level
of Involvement in the review process. And Then, double down on their strengths in that
because they typically spend their time area: assign them the 1.1 version, the bug
building and spend less time bug fixing their fixes, the unit tests, and the documentation,
own work, they’ll show high levels of new work then give them the 1.2 and 1.3 versions as
and relatively low churn. well. Allow them the opportunity to get to
know their domain, to work with it, to teach
These dynamics are often first identified in the others about it, and to develop a mastery.
Player Card report or in the team’s Submit and Ask them to give a presentation on the
Review Fundamentals. project to highlight lessons learned and best
practices. The key is to nurture a true sense of
ownership.

20 Patterns to Watch for in Your Engineering Team 25

PART 2
Work patterns exhibited on a team-wide level
PATTE R N 11
Scope Creep
11. Scope Creep

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:

Scope Creep (noun): a pattern whereby the team, look to the external stakeholders that
originally agreed upon scope increases or interface with that team to see what might be
changes after implementation has begun. causing the issues.
Often, though not always, Scope Creep
happens incrementally and thus invisibly.
Bad

COMPLEXITY
Using data to make Scope Creep visible
to all parties can help mitigate the risks of
unexpected work, and can also be used to Good
combat this pattern moving forward.

Even in the most well-defined projects, out-of- TIME Release

scope tasks arise. As a manager, you need to
watch for runaway situations where engineers
are being asked to shoulder an unreasonable
increase in scope. What to do
Use GitPrime data to show the additional
work caused by the scope creep. Scope creep
How to recognize it is caused by poor planning and insufficient
Scope Creep is characterized by a sharp attention during design. It’s not the engineer’s
uptick in progress toward the back of a responsibility to shoulder the work resulting
sprint that wasn’t driven by code review. from bad specs. Call it out! Let the people
who are responsible for pushing a poorly
Generally, the problem a team is solving designed project into implementation know
should be getting smaller over time as that it’s simply not ok.
features are completed. So a sudden spike in
activity, particularly in the later stages of a Then show them how much additional work
project, tends to be a signal that something their carelessness caused. Show them the
new came in. data. This more than anything will make the
true consequences of scope creep visible and
When you see this occurrence become a thus actionable.
pattern sprint over sprint with the same

20 Patterns to Watch for in Your Engineering Team 28

PATTE R N 1 2
Flaky Product Ownership
12. Flaky Product Ownership

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.

There are two important behaviors that fall + Frequent

TICKET JITTER
Mid-Stream
under this category: Changes
0
nn A Product Owner submits incomplete
requirements, leading to extra engineering -
time spent toward filling in the gaps or
resulting in ‘miscommunications’ later on. What to do
nn A Product Owner changes their requests Ambiguous or changing requirements from
after implementation began, leading to a Product Owner can often be a sign that
missed deadlines. that person is stretched thin. They have too
much to work on, so nothing gets their full
attention. It’s helpful, for that reason, to have
How to recognize it a discussion with their manager. Bringing data
This pattern tends to reveal itself in recurring to the discussion can eliminate skepticism
scope creep driven by the same product around what’s happening and help cut straight
owner. You may notice a significant expansion to the discussion about how to resolve the
of code that wasn’t driven by code review in situation.
the back of the sprint.
The handling of the situation should generally
be left to the Product Owner’s manager. If
it’s an issue of too much work, it can help to
eliminate the individual’s work in progress.
Otherwise, it may simply require coaching
around any areas they tend to overlook when
creating specs.

20 Patterns to Watch for in Your Engineering Team 30

PATTE R N 1 3
Expanding Refactor
13. Expanding Refactor

Expanding refactors happen when a planned effort to improve or

revise a section of code triggers a dramatic widening of scope.

What was intended as an optimization Legacy

Refactoring
exercise, becomes a wholesale rewrite.

WORK FOCUS %
How to recognize it
New Work
A small amount of legacy refactoring is
healthy. It’s when you notice a whole slew of TIME
changes in areas that are unrelated to the
feature at hand.
What to do
Look at the Work Log for outsized code Open the topic up for discussion with the
commits in sets of files that seem completely team. Ask team members to make a case for
unrelated to the feature at hand. Talk to and against the refactor, and then come to a
the engineer, expanding refactors are rarely conclusion about whether it’s best to move
driven by the product teams. forward with the project, drop it, or tackle it
with a different approach.

It can also be useful to provide standards

around what success is — what “done” looks
like. That way, everyone’s clear around what
the project is and isn’t, and so the expanding
refactor doesn’t consume too much of your
team’s time and energy.

20 Patterns to Watch for in Your Engineering Team 32

PATTE R N 14
Just One More Thing
14. Just One More Thing

“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.

Sometimes only one or two individual What to do

contributors will show this pattern, but that Late-arriving PRs are a sign that work is being
generally points to behaviors that require a rushed and given less review. Even when the
different approach. But when the majority of work is submitted by engineers who are very
the team is submitting PRs right before a familiar with the code, the PRs should be
deadline, it can mean there are larger process treated as riskier than other equally sized PRs
or even cultural issues that are causing an that are submitted earlier in the sprint.
unpredictable workflow.
When you notice a spike in PRs being
This pattern can occur for a wide range of submitted, it can be helpful to review the work
reasons, including last minute requests, poor submitted and decide whether it should be
planning or estimates, and too much work given an extra day’s review.
in progress.
Longer-term, consider working with the team
to identify any bottlenecks or process issues
that could be eliminated or improved.
PRs SUBMITTED

nn If the team’s estimates or deadlines

are causing last-minute stress, consider
setting internal deadlines for projects.
Another framework that some teams use
TIME Release is to consider ‘the three levers’ in setting
a deadline: the external deadline (if any),
the scope of the project, and resources
available. It’s typically not realistic to
How to recognize it change one without having to change the
“Just One More Thing,” when appearing across others, so it can help the planning process
a team, is characterized by a spike in PRs to take all three variables into account.
being submitted near the end of a sprint after
the main PR was approved. These engineers
nn If last-minute requests are coming in
will also show a high level of New Work. from outside the team, talking to the
managers whose groups are regularly
causing the problem can give you the
opportunity to show the impact of the
problem and understand what’s going on
from their perspective.

20 Patterns to Watch for in Your Engineering Team 34

PATTE R N 1 5
Rubber Stamping
15. Rubber Stamping

Rubber Stamping is the process by which an engineer approves

their colleague’s PR without giving it a substantial review.

Often, the Submitter will have some level review process over any given time period.
of seniority in the team, and the Reviewer These reports will help watch and manage the
trusts that the work is good enough. In other trends in the long-term.
situations, someone doesn’t value code review,
or everyone just ran out of time and felt the
FRI 4:55 PM Eng 1 PR Opened
need to push the PR through.
3 Commits, 5 Files Affected
++95 Lines, -- 67Lines
In any case, the code review process has a wide
range of benefits and outcomes: teams see 4:58 PM Eng 2 PR Merged
“LGTM”
improved code quality, increased knowledge
transfer within and across teams, more
significant opportunities for collaboration
and mentorship, and improved solutions to What to do
problems. So when an individual submits code While reviewing other people’s work is a
for review and no review is given, we sacrifice substantial part of what it means to be a
all of these outcomes for short-term efficiency. professional software developer, it’s not
always recognized as such. Rubber Stamping
often occurs in environments where the
How to recognize it review process is given little attention or
Rubber Stamping is most noticeable in the recognition; when leadership praises the
Review and Collaboration reports. Watch the behaviors they want to see in code reviews,
Review Workflow for PRs that opened and we generally see that the way people work will
closed in a preposterously short period of shift to match those expectations.
time, with a very low level of Receptiveness.
Low levels of engagement in reviews can On an individual level, it can be helpful to
also be seen in the Involvement and Review coach team members on what substantial
Coverage metrics. reviews look like in practice by showing
examples from others on their team. Try
When review happens later, as opposed to right deconstructing the feedback together in
after the PR is opened, there will be little to no a 1:1, so engineers leave the meeting with
back-and-forth in the comments (see the PR a framework they can use moving forward.
Resolution report). If there were no comments If there are specific engineers who are
on the PR, this PR will show as Unreviewed. frequently given less review, take into
consideration how they’re responding to
The Team Collaboration metrics will also any feedback in the process, how large their
provide insight into the time and energy that PRs are, or the time at which their PRs are
team members are allocating toward the submitted.

20 Patterns to Watch for in Your Engineering Team 36

PATTE R N 1 6
Knowledge Silos
16. Knowledge Silos

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.

In software engineering, Knowledge Silos signs of Rubber Stamping. Reviewing a select

can be identified in the code review process. group of engineer’s work for a long time
Knowledge silos form when a group of can lead to less substantial reviews simply
engineers only review each other’s work. because the engineers trust that each other’s
Imagine two or three engineers who review all work is good enough. When that happens,
of each other’s PRs, and don’t review anyone these situations can turn into bug factories.
else’s PRs on their team. These engineers Work is being approved and pushed forward
learn about each other’s work and techniques, without adequate evaluation.
and the areas of the code that they’re working
in. Other engineers on the team who aren’t
MORE REVIEW

part of the silo don’t have that same level of

information.

There are plenty of reasons why engineers

will get into a cycle of only reviewing each
other’s work — figuring out the reasons why,
through discussions with the team and by
LESS

reviewing the Team Collaboration metrics,

can sometimes point you toward the broader C O N C E N T R AT E D DISTRIBUTED
KNOWLEDGE
team dynamics at play. For example, if these
engineers only want to work together because
everyone else is slow to review their code, How to recognize it
consider setting expectations around Time to When team members are co-located, a basic
First Comment, and Reaction Time. understanding of where people sit in an office
along with an awareness of any other social
When knowledge silos exist for an extended bonds can be helpful indicators as to where
period of time, they can often begin to show silos may form.

20 Patterns to Watch for in Your Engineering Team 38

You can also use the Knowledge Sharing What to do
report to visualize how knowledge is being Bring in the outsiders! One of the most natural
distributed across a team in the review ways to manage this pattern is to look for
process and to identify knowledge silos. If outliers and stranded engineers and get those
there are two or three people who only review individuals involved in the review process.
each other’s code, the team’s Knowledge You can also see whether there’s anyone who
Sharing Index will trend toward 0. If the could be cross-trained or onboarded on a
majority of the team reviews each other’s specific area of the code that an engineering
code, the Index will trend toward 1. within the silo is working on.
You can then drill down into specific team Assign other engineers to review the work of
dynamics with the Review Radar. When the individuals that make up the silo, and have
there are Silos, there will be a small group of the individuals within that tight-knit group
engineers that review only each other’s work review the work of others outside their group.
across multiple sprints.

20 Patterns to Watch for in Your Engineering Team 39

PATTE R N 17
Self-Merging PRs
17. Self-Merging PRs

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!

As a general rule, engineers shouldn’t merge Self-merging represents a material security

their own code. In fact, most companies risk to the company, no matter how talented
don’t permit them to: self-merging bypasses an engineer is.
all forms of human review, and can easily
introduce bugs. But even in organizations that don’t enforce
review, managers should be in the know when
If the code is worth putting on the main these situations do happen. Reviewing these
branch, it is worth having someone review it. PRs on a case-by-case basis, even though
they’re being reviewed after they’ve have
been merged, will help ensure that any bugs or
How to recognize it problems are not going to get buried.
Self-merging is easy to see because the
submitter and the reviewer are the same If the commit was trivial, you might be able to
people. In GitPrime, these instances will show give QA a heads-up to take a close look at it.
up in the team’s Unreviewed PRs metric as If the unreviewed pull requests are non-trivial,
well as in their Review Workflow. walk those back if the circumstances allow it
and require a code review.
PR Opened PR Merged
Reducing the frequency of unreviewed and
Unreviewed self-merged pull requests is a best practice
(Unreviewed PRs should be 0%, or close
to it). If engineers are in the habit of self-
merging without review, it may be helpful to
have an informal conversation with them to
ensure that they understand the ‘why’ behind
getting the review process or at least clear on
What to do expectations. If they’re more senior, encourage
Many organizations prevent self-merging them to follow the best practice of getting
PRs by configuring their build systems to code thoroughly reviewed by others, so other
reject them. Enforced review is most common engineers will model that behavior.
among companies that work under regulatory
compliance, like Fintech or Biotech companies.

20 Patterns to Watch for in Your Engineering Team 41

PATTE R N 1 8
Long-Running PRs
18. Long-Running PRs

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.

Often in long-running PRs, you’ll notice a few If you see a few back-and-forth comments
back-and-forth comments, then radio silence. with signs of uncertainty or disagreement in
their communication, followed by silence, it’s
Apart from the possible disagreement or worth checking in to see how you can move
confusion amongst the team, long-running the conversation forward.
PRs are also themselves a problem. A PR that
is a week old can quickly become irrelevant,
especially in fast-moving teams. Long-running What to do
PRs can also become bottlenecks. It’s usually best to first check in with the
Submitter. It’s their responsibility to get
Sort PRs by: Oldest their work across the line, so they should
be encouraged to bubble up disagreements
Recently Opened or uncertainties as they arise. If there is a
disagreement, get their read on it and offer
Smallest advice to move it forward. Depending on
Biggest
the situation, get the Reviewer’s read on it
as well — ideally when everyone is together
Least Activity
in a room or on a call. Make a decision, and
Most Activity ask anyone that disagrees to ‘disagree
and commit’.

To manage this pattern in the long-term,

How to recognize it consider setting expectations or targets
Long-running PRs can quickly be identified around Time to First Comment, and Time to
in the team’s Review Workflow report, filtered Resolve. It’s also helpful to communicate best
by ‘PR Status: Open’ and sorted by ‘oldest PRs’. practices around timely response — when it
Select the number of PRs you’d like to see takes engineers a day to respond to feedback
in one view, then hover over those that have (see Responsiveness), that can mean there’s
been open for more than a day. a lot of time spent waiting on others, and the
communication isn’t timely enough to be as
effective as it otherwise could be.

20 Patterns to Watch for in Your Engineering Team 43

PATTE R N 19
A High Bus Factor
19. A High Bus Factor

“Bus factor” is a thought experiment that asks what the consequence

would be if an individual team member were hit by a bus. More specifically:

Bus factor (noun): The number of team Furthermore, it helps to start with the Index
members that need to get hit by a bus before to get a high-level understanding and then
your project is doomed to fail. drill down into specific team dynamics. If the
Index is trending downward, check to see if
Having a low bus factor is risky. A High team members are getting into a cycle of only
Bus Factor means that there is a greater reviewing each other’s work.
distribution of knowledge and know-how
about the code across the team. When more 100%

KNOWLEDGE SHARING
than one engineer knows about each area of
the team’s code, there’s more optionality for
managers to assign tasks and more people 50%
that can provide substantial reviews, reducing
the possibility of bottlenecks to a release.
0
TIME
For example, if three engineers know how
to work in the billing system, a manager
can assign a task in that domain to any of
those three engineers. Contrarily, if there are
knowledge silos, or if only one engineer has What to do
experience working in the billing system, the Knowledge Distribution can be achieved
manager will have difficulty assigning those when team members are making small and
tasks to any other engineer. frequent commits, and there’s a healthy level
of collaboration and debate in reviews from
everyone on the team. It can be helpful to keep
How to recognize it this in mind when providing feedback in 1:1s
A team’s distribution of knowledge can be and when onboarding new hires to the team.
visualized with the Knowledge Sharing Index.
It’s best to use this report within teams that When you see a low Sharing Index (i.e., a low
you would expect to review each other’s bus factor, higher risk), see the Review Radar
work. A low Index means that there is a lower for opportunities to get team members more
distribution of knowledge across a team, involved in the review process. When you see
representing a higher bus factor risk. This the behavior you want to see in the review
also means there may be silos forming; a high process, consider recognizing that in a team-
Index represents a greater distribution of wide meeting.
knowledge across the team.

20 Patterns to Watch for in Your Engineering Team 45

PATTE R N 20
Sprint Retrospectives
20. Sprint Retrospectives

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.

.While reflecting on the goals of the sprint, What to do

what actually happened, why it happened, and As a manager of managers, it helps to
planning for what’s next, use data to provide coach managers of individual contributors
a more complete view on the team’s progress. on the practice of including data in their
Instead of looking just at what was built, look retrospectives.
at how it was built. Visualize the development
process and watch for trends in work patterns If there are specific work patterns you see
across the team and at the individual level. in the team that you either want to see more
of or want to manage away from, consider
showing them what those behaviors look like
How to recognize it in the data, how to watch for them, and what
A good Sprint Retrospective uses data to to do when they see them.
help people compare what they felt happened
during the sprint and what actually happened Build
in the sprint.

F E E D BAC K
LO O P

Learn Measure

Encourage them to include data in discussions

with you, and with others in the organization,
and show them how to do so.

In short, Sprint Retrospectives are about

watching for and managing work patterns.
It’s about recognizing achievement, spotting
bottlenecks, and debugging the development
process with data.

20 Patterns to Watch for in Your Engineering Team 47

“A world without GitPrime is one without hard data and no real evidence of how things
are going. As engineering teams get larger, it’s more complicated; more repos, more
code, more people. Without a tool like GitPrime that pulls it all together, it’s almost
impossible to get a handle of what’s going on.”

— Adam Abrevaya, VP Engineering, CloudHealth by VMware

“In Engineering we’re good at measuring the what. GitPrime gives us is the ability
to measure how we get there. I can’t imagine a company like ours operating without
GitPrime metrics.”

— Mathew Spolin, VP Engineering, AppDirect

About GitPrime

GitPrime is the world’s leading Engineering Logistics Platform.

We help organizations of any size use data to debug their
development processes, so engineers can spend less time
waiting on others and more time working on what matters.

Today more than 400 enterprises, including PayPal, Atlassian,

and Adobe, rely on GitPrime to keep a pulse on the health and
productivity of their teams.

GitPrime aggregates data from git repos, ticketing systems,

and pull requests and transforms them into easy to
understand insights and reports. With visibility into the
software development process, we help you map initiatives to
outcomes, adjust processes with confidence, and advocate for
your team with facts instead of feelings.

Visit us at gitprime.com to start a 15-day trial or chat with

someone on our team about how GitPrime can help.