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
A field guide to help you recognize achievement,
spot bottlenecks, and debug your development
process with data.

©2019 Pluralsight

Ed 2019_Q4
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 Pluralsight 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
PATTERN 01

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 others can provide in the review process.
it, and in some cases rewrote the same As a result, Domain Champions will
sections of code multiple times. typically show low Receptiveness in
incorporating feedback from reviews.
The Domain Champion isn’t just “the
engineer who knows credit card Domain Champions will seldom, if ever,
processing”; it’s all they ever work on. appear blocked. Short-term, it’s a highly
It’s their whole day, every day. productive pattern. But it’s often not
sustainable and can lead to stagnation,
Some degree of job specialization is which of course can lead to attrition.
essential and often motivating. But
even within specialized roles there can
be ‘too much of one thing.’ Managers
Primary Focus
must balance enabling a 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
Domain Champions are deeply familiar of the codebase.
with one particular domain. As a result,
they’ll typically submit their work in Of course, some engineers would prefer
small, frequent commits and will show a to stay where they are. It can be very
sustained above average Impact. enjoyable to do a task you’re good at.
And, it can be uncomfortable to take on
Because no one else knows more than work that requires information or skills
the Domain Champion, there’s usually you have less practice with. But effective
very little actionable feedback that managers will strive to challenge
their team.

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

20 patterns to watch for in your engineering team 4

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

20 patterns to watch for in your engineering team 6

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

20 patterns to watch for in your engineering team 7

PATTERN 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 n They’re struggling with the problem

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

20 patterns to watch for in your engineering team 9

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

20 patterns to watch for in your engineering team 10

PATTERN 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

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

20 patterns to watch for in your engineering team 12

PATTERN 05

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 review process (see the Review and
than no save. But regular Heroing leads Collaboration metrics).
to the creation of unhealthy dynamics
within the team or otherwise encourages Helping Others
undisciplined programming. Some team
members even learn to expect them to

TEAMWORK
jump in on every release.

Heroing can be a symptom of poor

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

20 patterns to watch for in your engineering team 14

PATTERN 06

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 In the Review and Collaboration and
cleans it up, over and over again. This Operational reports, you’ll notice these
behavior can be normal on small two consistently review each other’s
project-based teams. But when that 1-2- work. One engineer will have a high
1-2 pattern doesn’t taper off, it’s a signal Help Others, but it’s not reciprocated.
that should draw your attention. The “load-bearing” engineer will also
show high levels of Influence and Review
The problem is threefold: (1) always Coverage. The other engineer will not.
cleaning someone else’s work takes One engineer will have a high Impact;
away from one’s own assignments, (2) the other won’t.
it impairs the original author’s efforts
toward true independent mastery, (3) it This behavior can be perfectly healthy
can overburden the helper and leave the and expected when in a mentorship-
original author in a continuous unnatural type situation. But beyond a certain
waiting state. point, rotation is in order.

How to recognize it
Disproportionate Help
You’ll notice this pattern in the same
and Code Review
way you’d realize “Heroing” (Pattern Eng 1 Eng 2
#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.

20 patterns to watch for in your engineering team 16

What to do Lastly, the stronger of the two is
showing natural leadership and coaching
Bring additional engineers into the
tendencies. Look for opportunities
code review process. A side effect
to feed this more broadly to the
of this solution is that by increasing
whole team.
the distribution of reviews, you’re
strengthening the team’s overall
knowledge of the codebase (see One note of caution: be mindful when
Knowledge Sharing). the two engineers are friends or were
colleagues at a former employer. Making
light of a friendship or teasing them can
Cross-train and assign both engineers to
be incredibly damaging and hurtful. Go
different areas of the codebase.
the extra mile to keep it professional.
Assign the senior engineer a very
And, as always, be transparent. You’re
challenging project. The idea here is to
not trying to split up friendships. It’s the
give them challenging projects where
manager’s job to ensure that knowledge
they don’t have the time or energy to
of the codebase is distributed evenly
review their colleague’s work.
across the team and to ensure that
people are honing their craft and
growing their careers.

20 patterns to watch for in your engineering team 17

PATTERN 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 WORK FOCUS TEAM

AVG.
code adjacent to the code the engineer
New Work 31%
is working on, is a fantastic pattern to
encourage. Legacy Refactor 52%
Help Others 6%
“Fixing” work certainly doesn’t get the Churn 11%
attention that “feature” work does, in
part 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 What to do
recognizable than working on new code, Recognize this engineer’s work publicly
this engineer’s contribution is invaluable. and use it as a model for other team
members to work towards. Regularly
acknowledge it in sprint retrospectives
How to recognize it and standups, even after you first
“Clean As You Go” refers to when an observe the pattern. Consistent
engineer contributes new code and acknowledgment lets everyone know
also mends adjacent code in the you value this effort.
codebase. Consequently, you’ll notice
these engineers writing new code while Encourage this engineer to formalize
also showing higher levels of legacy their work pattern with documented
refactoring, that together usually exceed coding standards (e.g., naming
the expected scope of change for the conventions, getter/setters, preferred
assignment at hand. patterns for ORM work, etc.)

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

PATTERN 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 and Collaboration reports will show this

an endurance sport. To create lasting pattern over time, and they can be used
enterprise value, you must show up to support the story (e.g., “six weeks of
every day and produce quality work. committing code every day is something
Real value creation can take years. to admire”).

It’s tempting to think of this as a person

COMMITS PRs TICKETS
and not a pattern. However it’s useful
to depersonalize this engineer’s work
as a pattern — it’s easier for others to Eng 1
model discrete behaviors than it is to
model a person.
Eng 2

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

20 patterns to watch for in your engineering team 21

PATTERN 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 H I G H I M PACT

engineer 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 CHURN CHURN
for making the change.

They may be losing steam and Could be Stuck

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

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

20 patterns to watch for in your engineering team 23

PATTERN 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

A R E A S O F S P E C I A L I Z AT I O N
shies 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 Busy Body
a long period because these engineers
end up without a strong sense of
ownership. There’s nothing for them to DOMAIN KNOWLEDGE

point at and say, “I made that.” Even if

they can solve a wide range of problems,
lacking something that they own can What to do
lead to attrition.
Give these engineers something to
own top to bottom. Whether it’s a
module, a new feature, or a large
How to recognize it project, ask them to do more than just
Engineers exhibiting this pattern will ‘get it done’. Ask them to become an
show high levels of Impact and lots expert in that particular area or on that
of small pull requests without any specific project.
identifiable home base in the code.
They’ll show a high level of Involvement Then, double down on their strengths
in the review process. And because they in that area: assign them the 1.1 version,
typically spend their time building and the bug fixes, the unit tests, and the
spend less time bug fixing their own documentation, then give them the 1.2
work, they’ll show high levels of new and 1.3 versions as well. Allow them the
work and relatively low churn. opportunity to get to know their domain,
to work with it, to teach others about
These dynamics are often first identified it, and to develop a mastery. Ask them
in the Player Card report or in the team’s to give a presentation on the project
Submit and Review Fundamentals. 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
PATTERN 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 team, look to the external stakeholders

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

Using data to make Scope Creep COMPLEXITY

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

20 patterns to watch for in your engineering team 28

PATTERN 12

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 + Frequent

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

PATTERN 13

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

exercise, becomes a wholesale rewrite. Refactoring

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

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

or improved.

n If the team’s estimates or

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

20 patterns to watch for in your engineering team 34

PATTERN 15

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 The Team Collaboration metrics will also
level of seniority in the team, and the provide insight into the time and energy
Reviewer trusts that the work is good that team members are allocating
enough. In other situations, someone toward the review process over any
doesn’t value code review, or everyone given time period. These reports will
just ran out of time and felt the need to help watch and manage the trends in
push the PR through. the long-term.

In any case, the code review process

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

20 patterns to watch for in your engineering team 36

PATTERN 16

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 begin to show signs of Rubber Stamping.

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

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 reviewing
LESS

the Team Collaboration metrics, can

sometimes point you toward the broader C O N C E N T R AT E D DISTRIBUTED
team dynamics at play. For example, KNOWLEDGE

if these engineers only want to work

together because everyone else is slow
How to recognize it
to review their code, consider setting
expectations around Time to First When team members are co-located, a
Comment, and Reaction Time. basic understanding of where people
sit in an office along with an awareness
of any other social bonds can be helpful
When knowledge silos exist for an
indicators as to where silos may form.
extended period of time, they can often

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

20 patterns to watch for in your engineering team 39

PATTERN 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 or biotech companies. Self-merging

merge their own code. In fact, most represents a material security risk to the
companies don’t permit them to: self- company, no matter how talented an
merging bypasses all forms of human engineer is.
review, and can easily introduce bugs.
But even in organizations that don’t
If the code is worth putting on the main enforce review, managers should be
branch, it is worth having someone in the know when these situations do
review it. happen. Reviewing these PRs on a
case-by-case basis, even though they’re
being reviewed after they’ve have been
How to recognize it merged, will help ensure that any bugs
Self-merging is easy to see because or problems are not going to get buried.
the submitter and the reviewer are the
same people. In Pluralsight Flow these If the commit was trivial, you might be
instances will show up in the team’s able to give QA a heads-up to take a
Unreviewed PRs metric as well as in their close look at it. If the unreviewed pull
Review Workflow. requests are non-trivial, walk those back
if the circumstances allow it and require
PR Opened PR Merged a code review.

Reducing the frequency of unreviewed

Unreviewed
and 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
What to do getting the review process or at least
clear on expectations. If they’re more
Many organizations prevent self-merging
senior, encourage them to follow the
PRs by configuring their build systems
best practice of getting code thoroughly
to reject them. Enforced review is most
reviewed by others, so other engineers
common among companies that work
will model that behavior.
under regulatory compliance, like fintech

20 patterns to watch for in your engineering team 41

PATTERN 18

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 If you see a few back-and-forth

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

To manage this pattern in the long-

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

PATTERN 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
members that need to get hit by a bus Index to get a high-level understanding
before your project is doomed to fail. and then drill down into specific team
dynamics. If the Index is trending
Having a low bus factor is risky. A High downward, check to see if team
Bus Factor means that there is a greater members are getting into a cycle of only
distribution of knowledge and know- reviewing each other’s work.
how about the code across the team.
When more than one engineer knows 100%
KNOWLEDGE SHARING
about each area of the team’s code,
there’s more optionality for managers to
assign tasks and more people that can 50%
provide substantial reviews, reducing the
possibility of bottlenecks to a release.

For example, if three engineers know 0

TIME
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 experience What to do
working in the billing system, the Knowledge distribution can be achieved
manager will have difficulty assigning when team members are making small
those tasks to any other engineer. and frequent commits, and there’s a
healthy level of collaboration and debate
in reviews from everyone on the team. It
How to recognize it can be helpful to keep this in mind when
A team’s distribution of knowledge providing feedback in 1:1s and when
can be visualized with the Knowledge onboarding new hires to the team.
Sharing Index. It’s best to use this
report within teams that you would When you see a low Sharing Index
expect to review each other’s work. A (i.e., a low bus factor, higher risk), see
low Index means that there is a lower the Review Radar for opportunities to
distribution of knowledge across a get team members more involved in
team, representing a higher bus factor the review process. When you see the
risk. This also means there may be behavior you want to see in the review
silos forming; a high Index represents process, consider recognizing that in a
a greater distribution of knowledge team-wide meeting.
across the team.

20 patterns to watch for in your engineering team 45

PATTERN 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 What to do

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

 With the 2019 acquisition of GitPrime, Pluralsight Flow gives
you the confidence you need to accelerate velocity and visi-
bility into and across your software engineering teams.

01. Engineering leaders have 02. Flow turns the lights

been operating in the dark. on with objective data.

For many organizations, software Flow generates actionable metrics to

engineering is one the most expensive and optimize release processes, improve
mission-critical departments. Companies collaboration workflows and remove
invest millions of dollars in software bottlenecks, while creating unprecedented
engineering without a feedback loop to visibility for all levels
understand how well we’re doing or where of management.
to focus on improvement.

03. Get deep visibility into 04. Turn workflow data into
your development process. operational improvement.

Flow instruments the tools in your Flow gives software leaders a fact-based
development workflow—from commit view of effectiveness and performance—
data, pull requests, tickets, and more—to with prescriptive metrics to drive process
provide actionable insight into individual improvement. The end result is improved
and team workflows. quality, more time spent coding, healthier
distribution of knowledge, and faster time
to market.

About Pluralsight
Pluralsight gives you confidence you have the skills and insights you need to execute
your technology strategy. You can upskill your teams into modern tech roles, improve
workflow efficiency and build reliable, secure products. We are the technology skills
platform.

By leveraging our Skills product, which includes expert courses, skill assessments and
one-of-a-kind skills and role analytics, you can keep up with the pace of change, put the
right people on the right projects and boost productivity. With our Flow product, you can
debug your development processes with objective data, identify bottlenecks and keep a
pulse on the health of your software teams.

Used together, they empower you to develop, measure and deploy critical skills at scale
and improve engineering effectiveness.

Visit pluralsight.com/business to learn more