1

Table of contents

Introduction 3
Bit Fiddling 4
Pinpoint commits 6
Code And Clean 8
Domain Expert 10
Code Hoarding 12
The Hero 14
High Churn Rates 16
The Overhelper 18
Zoning In 20

2
Introduction

Effective engineering managers view their teams as holistic systems that

react to input and create output accordingly. When the output isn't as
expected, great managers approach the problem with data and are driven to
find the cause. They track code reviews, visualize work patterns, spot
bottlenecks, or process issues. Clearing those increases the overall health and
capacity of their team.

By searching for the cause, they discover how their teams work and what is
the correct way of solving the problems. We aggregated a collection of work
patterns that we’ve observed by working alongside thousands of engineering
managers. We hope that you will use this handbook to gain better visibility of
how your team works, identify roadblocks, advocate for your team members,
and manage your team using concrete data.

3
Bit Fiddling
Bit Fiddling happens when an engineer gets stuck. Even though
they tried every solution at hand, it seems that they are not
making any progress.

Bit Fiddling can be identified when an engineer is steadily focused on a

particular area of the codebase for a long period of time. They are making
some minor changes, but no notable progress results. This usually happens
because the engineer didn’t understand the problem clearly or the context of
the change is vague. When an engineer is bit fiddling, they are at risk of losing
motivation.

4
How to identify it

An engineering manager can identify when an engineer is bit fiddling with

code by looking at their Developer Summary report; particularly looking for
high churn rates. The key is to group repetition and refactoring with
uncertainty or indifference in code review, over an extended time frame.

For example, watch for a standard library call getting refactored into
customized code for some optimization that is difficult to articulate. Another
example would be to watch for code that gets polished and refactored
multiple times with disinterest — light code review and pull requests with
generic submitter comments, followed by generic reviewer comments. The
Review Workflow report can help you spot generic contributions in pull
requests.

What to do

Explore ways to revitalize the engineer with a new project. Find a ticket, even a
small one, that will lead to new and interesting areas of the code — even if it
might negatively impact the team’s productivity in the short-term. Creative
people thrive when tackling new and challenging issues, even if they are
reluctant to work outside their area of expertise. New challenges lead to
learning something new - a process that most engineers enjoy.

5
Pinpoint commits

This work pattern usually goes unnoticed in most teams due to it

being a common occurrence. Pinpoint commits are done by
understanding the problem, breaking it down into smaller
pieces, and submitting nearly perfect code.

Of course, not all the commits in the project will be Pinpoint commits, but the
ones that are, generally carry a small to moderate impact and were carefully
reviewed and approved on the first try. Recognize these small wins!

6
How to identify it

Pinpoint commits can be spotted by looking at the time they were submitted
compared to the deadline, the manner in which they were reviewed, and their
overall impact. Normally, the commit was completed before the deadline,
with an insignificant amount of churn, and its impact was small to moderate.
The Developer Summary report will help you identify this type of commits,
along with the Review Workflow feature, which will assist you in measuring
the thoroughness of the code review process.

What to do

You can recognize a pinpoint commit in a daily stand-up, or just privately

acknowledge it: “Good job on that commit!” It’s important to show your
engineers that their contribution is appreciated and their work doesn’t go
unnoticed - it will help you make pinpoint commits a repeatable pattern.

If an engineer constantly makes pinpoint commits, it may come in handy for

other team members to understand how they approach tasks. You can ask
the engineer to start providing feedback on other team members' work in the
code review process.

7
Code And Clean

An inherent trait of codebases is that they evolve continuously,

but not evenly. An engineer that falls within this work pattern will
detect and make improvements, even though they might not be
crucial at that time.

The pattern of continually paying off personal technical debt is an excellent

habit, and it should be encouraged. Refining code is not as flashy as
developing new features, and it is generally less visible and recognizable, but
such contributions are the ones that enable codebases to move forward.

8
How to identify it

An engineer that falls within the “Code And Clean” work pattern contributes
new code, while also fixing legacy code in the codebase. Their commits
usually carry a high amount of Legacy Refactoring, together with a fair
amount of New Work. You can see an overview of their commits in the Work
Log, then dive deeper using the Developer Summary report. Engineers that
follow this work pattern can be spotted as the top performers in Legacy
Refactoring, in the Project Timeline.

What to do

Publicly recognize contributions that fall into the “Code And Clean” archetype.
Use them as an example to reinforce this habit amongst other team
members - daily stand-ups and retrospectives are a great occasion to do so.
Consistently acknowledge such efforts to let your team members know how
important these are. Support “Code And Clean” engineers in documenting the
process that they follow. Other engineers will be able to abide by the same
pattern, ultimately minimizing technical debt throughout the team.

9
Domain Expert

The Domain Experts are masters of particular codebase areas.

They know everything about their domain: from algorithms to
classes and methods.

Truthfully, they probably created most of the code in that area. The Domain
Expert is not just “the engineer that knows a framework by heart”. Domain
Experts only work in their areas of expertise, every time, every day.

Being specialized in a particular aspect is important and inspiring, but only to

a certain extent. Even engineers that are expected to be seasoned in a
specific domain can fall into the trap of doing “too much of the same thing”.
The managers must guide engineers towards a balance between targeted
expertise and various knowledge.

How to identify it

Domain Experts will always contribute to the same area of the codebase. You
will also notice the tendency of perfectionism - they will be rewriting their own
code all over again. The Developer Summary report can help you identify this
pattern. By looking at Churn and Legacy Refactor percentages, you will be
able to tell whether an engineer falls into the Domain Expert model.

Being extremely familiar with their domain, they will submit small and
frequent commits, and their impact will be above the team’s average. Since
these engineer archetypes are the most knowledgeable of their domain,
there’s not much feedback that other team members can provide in code
review. In consequence, the team will experience a lower receptiveness in
integrating review feedback. Engineering managers can check their team’s
receptiveness in the Review Collaboration report.

Domain Experts will never appear blocked. In the short-term, this is productive
and beneficial for the team, but it’s not sustainable in the long-term, and can
often lead to attrition.

10
What to do

Assign low-risk tickets of new codebase areas to them. Naturally, some

engineers are comfortable with staying in their area of expertise - it is
delightful to do tasks that you are good at. But, challenging an engineer to
work that they find difficult is where engineering managers can help them
grow.

Start by acknowledging their domain expertise. Encourage them to

participate in code reviews when other team members check-in code in their
area of expertise; support them in sharing their domain knowledge with
others. Then, talk to them about what they would enjoy doing. Finally, ask
them if they want to take on a new, small challenge outside of their domain.
Doing this will help them broaden their areas of expertise while sharing best
practices with their colleagues.

11
Code Hoarding

A common work pattern is to deliver one huge chunk of work at

the end of the iteration instead of delivering incremental
contributions throughout the sprint.

It may come naturally for engineers to wait until the work is done to push it to
the Git repository. Even though this is against Agile practices, there are some
factors that prevent engineers from frequently committing. The most
common factor is that engineers fear that others might judge their work in
progress.

The problem with code hoarding is that it doesn’t enable code collaboration,
which is a crucial aspect of software development. The habit of working
privately doesn’t just slow down individuals - it also affects the velocity of the
project. Submitting one giant chunk of code doesn’t create any collaboration
opportunities throughout the team. Moreover, another team member will
have to review that code in a short period of time, which naturally leads to
lower code quality.

An engineer is not necessarily hoarding code if they sometimes commit big

chunks of code at once. Looking for repeating patterns is key to determining
whether this is a work habit or an extraordinary event.

How to identify it

The most common indicators that an engineer is code hoarding are rare,
large commits. You can identify this pattern in the Work Log, but it can also be
spotted in the Review Workflow report. These types of pull requests pop up
during the late stages of the sprint and are larger than usual. The PR
Resolution report is also designed to indicate, on a higher level, if such
outlying pull requests correspond to a habit or an exception.

12
What to do

First of all, you need to empathize with the engineers. Chances are that you’ve
spotted this pattern just before the end of a sprint, or after the end of one, so
these engineers are most probably worn out, stressed, and tired. Ensure that
they receive the time and space necessary to recover. This could also be a
good time for a one-on-one with the engineer. Look back at the sprint and
learn from them what went well, what didn’t, and recognize their wins. During
the one-on-one, let them know why hoarding code doesn’t help the learning
process. When working collaboratively, team members learn from each other
and move faster in finding solutions to the problems.

13
The Hero

Hero engineers tend to fix other team members’ work right

before a release. They always seem to be finding a critical defect
to save the release.

Having such an engineer in the team is certainly helpful, but if this becomes a
regular occurrence, it can have negative consequences on team dynamics
and discipline. Otherwise strong engineers can develop self-doubt over time,
the feedback loop gets damaged and ultimately the growth process stops.

How to identify it

One of the sure ways to spot this pattern is to analyze the top performers for
the Help Others metric in the Project Timeline report. These individuals will
dominate it, mostly with late coming check-ins, which you can see in the
Work Log.

In the code review process, Hero engineers tend to self-merge PRs right
before the deadline. You can spot self-merged PRs in the Review Workflow
report. Their pull requests will usually display a very low level of engagement,
which is understandable given the changes made late in the sprint.

14
What to do

Instead of focusing on the Hero, focus on the code review process. You can
set up a target for your team to make small and frequent commits, and
identify such commits by looking at the risk metric in the Work Log. Smaller
commits are tagged as low-risk, therefore, you should watch out for
high-risk commits.

Once your team has made a habit out of submitting small and frequent
commits, they will become open to participate in the review process. By
incorporating these changes into your team’s workflow, everyone, including
the Hero, will develop healthier collaboration patterns.
Coach the Hero to provide actionable feedback to their teammates, instead
of ‘fixes’.

15
High Churn Rates

Churn is a natural part of the development process. However,

unusually high churn rates are an early indicator that an
individual may be struggling with an assignment.

Testing, refactoring and exploring various ideas are part of the development
process, and churn rates vary between people, projects, and phases of the
project cycle. Getting accustomed to your team’s regular churn levels is
required before identifying unusually high churn rates.
High churn rates aren’t a problem per se. They are caused by an array of
external factors, such as hassling with a task, perfectionism, or external
stakeholders.

How to identify it

By checking the top performers in churn, in the Project Timeline report, you
can get a pulse of who might be struggling with an assignment. Zoom in to
your team members’ efficiency in the Developer Summary report to see if
this is an ongoing issue. We recommend correlating churn spikes with the
stage of the project to get a better understanding of their struggles.

16
What to do

Churn code is a regular occurrence in situations like redesigns and

prototypes. It’s important to take into account if the churn is caused by
routine or there is a particular issue at stake. After ruling out routine,
determine whether the issue is caused by an external stakeholder, and have
the engineer confirm this.

If so, show the data to the stakeholders, and explain how last-minute changes
are negatively impacting the velocity and quality of the project. Alternatively,
you could pull the ticket from the sprint, or decide on an MVP and split off the
additions into a refinement sprint.

If an external stakeholder is not the driver for high churn rates, we

recommend asking a fellow engineer for a pre-submission code review,
having a more senior engineer to assess the quality of the code in the context
of the project, or bringing in another engineer to pair program.

17
The Overhelper

Overhelping happens when one engineer spends an unusually

large amount of time to help other engineers get their work done.

The overhelping pattern works like this: one engineer submits their code, then
the Overhelper engineer cleans up their code repeatedly. This is a common
pattern among project-based teams, but if this becomes a habit, that is an
issue.

Constantly cleaning someone else’s work takes away one’s time to work on
their own assignments. It also damages the original author’s learning
opportunities, independence, and sense of ownership.

18
How to identify it

An Overhelper can be spotted by analyzing the Review Collaboration report,

particularly the collaboration network graph. You will notice that these two
engineers are constantly reviewing each other’s work.

While this pattern is normal in a mentorship relationship, a rotation should

happen beyond a certain stage. The Overhelper will display high Helping
Others values, and low values for New Work and Legacy Refactoring, while
comparing to the team average in the Developer Progress report.

What to do

Adding more engineers into the code review process will even out the review
distribution. Doing this will also lead to a broader knowledge of the codebase
for the whole team. Another recommendation is to cross-train and assign
these engineers to different areas of the codebase.

You can assign the senior engineer to a more challenging project, ensuring
that they won’t have the time or energy to review another team member's
work. The Overhelper is inclined towards leadership and coaching. As a
manager, you can offer them the opportunity to join a mentorship program.

19
Zoning In

This work pattern is defined by delivering consistent, reliable,

high-quality work.

Software development is all about consistent output, showing up every day,

and delivering quality work in order to create value for the organization.
Treating this as a pattern, rather than an individual's quality, is more useful in
the long run, as it enables you to model these behaviors and make future
predictions easier.

How to identify it

When zoning in, engineers have the habit of organizing their schedule in a
way that eliminates distractions and allows them to focus solely on delivering
business value. Their Active Days are constantly above average, their churn
rates are commonly lower than average, and they score high on Impact in
their Developer Summary profile.

Their pull requests, which you can track in the Review Workflow report are
timely, decently sized, and uniformly paced. They also participate in the code
review on a regular basis.

20
What to do

Acknowledging this pattern, publicly or privately, will help build a team culture
that values consistency and cadence in work. The Work Log can help you
identify this pattern and support the story.

If you want to increase your overall team velocity, you can start helping the
other team members find their ‘zone,’ by looking at the Activity Heatmap
report, which is designed to highlight your team members’ peak productivity
hours. By using the Activity Heatmap report, managers can schedule
non-disruptive meetings, so that engineers can focus on delivering value.

Making small changes in the schedule and reducing interruptions as much as

possible will help your team zone in more often, deliver the code at a good
pace, and avoid burnout.

About Us

Our mission is to provide engineering leaders with a way of measuring the

performance of their engineering teams. We strive to help the technology
industry move towards a data-driven agile development methodology and
make decisions supported by data.

Visit waydev.co to learn more

21