►
Description
Presented by:
John Witchel
President/COO, GitPrime
You’re good, but how do you know you’re good? How does your manager know you’re good? How does your team know you’re good? GitPrime walks you through a series of use cases for measuring productivity to demonstrate how productivity is measured in software engineering and why KPI’s matter to developers.
At Satellite 2017, attendees came to exchange cutting edge practices on how to bring together the people and tools you need to build great software. Watch the recordings to find out what GitHub's been working on, and hear how other teams use the GitHub ecosystem to customize the way they work.
We'll be getting together again in San Francisco on October 10th-12th for GitHub Universe. We hope you'll join us for three days filled with the creativity and curiosity of the largest software community in the world.
For more information, go to githubuniverse.com.
A
A
That's
a
big
number
I
think
the
answer
is
yes
and
I'm
going
to
spend
a
little
bit
of
time
today,
trying
to
show
you
how
we
think
that
happens
so
get
Prime
is
in
the
business
of
productivity
metrics
for
engineering
teams
for
the
purpose
of
creating
a
for
the
purpose
of
creating
a
more
productive
engineering
team
we've
been
around
for
three
and
a
half
years.
We
have
a
number
of
notable
clients.
A
So
what
is
the
problem
that
get
prime
solves
fundamentally
get
prime
is
dealing
with
a
difficult
problem,
and
that
is
that
the
black
box
of
engineering,
the
black
box
of
engineering,
is
an
expensive
and
largely
saw
unsolved
problem
today
and
at
the
heart
of
that
problem
is
the
fact
that
tracking
developers
is
a
surprisingly
difficult
problem
and
it's
ironic,
because
developers
are
the
ones
that
help
track
virtually
every
other
group
in
the
enterprise
today,
we're
the
run,
we're
the
ones
that
wrote
the
software
that
became
Salesforce.
We
did
it
for
marketing.
A
A
How
much
of
last
month's
work
went
to
paying
down
technical
debt
very
difficult
question
to
answer
today
right
and
by
a
percentage
of
your
total
burn
of
your
group.
You
know
how
and
the
last
one,
how
do
you
show
others
that
your
team
is
working
hard
I,
think
we've
all
been
on
teams
where
everybody's
busting,
you
know
busting
their
ass
and
they
and
you
just
can't-
seem
to
get
credit
for
all
the
work
that
you're
doing.
A
So,
rather
than
continuing
to
talk
about
how
you
know
conceptually
how
we
do
that
I
want
to
drop
right
into
a
series
of
animations
of
our
product
and
I'll
talk
through
it
and
I'll
talk
through
sort
of
how
we
do
what
we
do
and
how
to
use
this
tool.
So,
let's,
let's
start
with
the
first
one.
This
is
so
these
are
looping
animations.
So
you
can
just
if
you
don't
quite
catch
it.
The
first
time
just
wait
about
10
seconds.
It'll
start
looping
again.
This
is
our
sort
of
our
entry
point
into
our
product.
A
This
is
a
commit
workflow,
and
what
you
see
here
is
a
consolidated
view
of
all
of
your
repos
and
and
just
as
a
quick
note
of
background.
What
get
prime
does
is
we
take
all
the
repos
in
your
enterprise?
Read
them
all
in
parse
them
produce
a
huge
set
of
metadata
and
then
produce
reports
on
these
get
is
the
primary
source
of
all
of
our
information,
and
so
what
you
see
here
on
the
upper
left
are
teams
all
the
different
repos
on
off.
A
A
Anybody
want
to
come
up
and
argue
that,
okay,
but
in
context
by
somebody
who
knows
how
to
read
this
report,
seeing
how
big
and
how
regular
the
commits
are,
can
be
a
good
indicator
of
whether
somebody
is
succeeding
or
struggling
or
needs
a
little
help
or
most
commonly
should
be
left
alone.
So
if
we
look
at
Allen
up
at
the
top,
what
we
see
here
is
not
Jarrod
Allen
is
a
very:
is
a
person
who's
lightly
committing
compared
to
his
other
two
teammates.
He
looks
like
he's
a
problem
he's
actually
not
a
problem.
A
He's
working
on
a
very
difficult
engineering
problem,
he's
tuning
some
sequel,
I,
don't
really
expect
more
than
one
or
two
commits
over
a
couple
of
weeks,
given
the
difficult
nature
of
his
problem,
Nathan
here
checking
in
tons
of
stuff
he's
doing
a
early-stage
part
of
the
project,
Peter
down
here,
tons
and
tons
of
merges
when
I
get
rid
of
all
of
his
merges.
Yeah
he's
still
in
pretty
good
shape
and
by
using
a
simple
little
search
feature
up
here.
A
I
can
check
whether
or
not
the
people
who
are
supposed
to
be
doing
work
on
my
ticket
are
actually
doing
work
on
my
ticket
without
interrupting
them,
and
that's
this
very
special
thing,
because
I
think
we
all
know
that
an
interrupted
engineer
is
an
engineer
who
is
dropped
to
almost
zero
productivity.
How
many
times
have
you
all?
We
all
sat
there?
I've
had
15
variables
in
my
head,
I'm
and
then
somebody
goes
hey.
Man
can
I
just
get
a
second
of
your
time,
you're
like.
A
A
Get
Prime
has
a
whole
set
of
metrics,
some
of
which
will
feel
familiar
to
you,
some
of
which
are
new,
and
we
can
rank
order,
people
by
various
data
points
and,
most
importantly,
we
can
mark
where
you
are
relative
to
your
rolling
average
or
your
your
typical.
So
let's
take
this
column
right
here.
This
is
churn.
Now
everybody
churns
churning
is
when
you
write
a
line
of
code
and
then
you
rewrite
a
line
of
code.
A
So
if
you
look
at
Katherine
at
the
top
of
the
churn
pile,
that's
terrible
90%
of
her
code,
she
rewrote
in
the
last
three
weeks,
that's
very
problematic,
except
for
the
fact
that
she's
in
prototyping,
in
which
case
that's
totally
normal
behavior,
so
I
can
look
and
although
she's
normally
at
38
percent,
give
or
take
I
also
know
she
was
just
put
on
that
project
two
weeks
ago.
So
I'm
actually
gonna
ignore
that
dataset
Luke.
Here,
however,
he's
gotten
the
number
two
for
those
of
you
in
the
back
he's
actually
got
a
problem.
A
He's
turned
sixty
percent
of
his
code
in
the
last
seven
days,
he's
normally
down
at
low
single
digits
and
I
know
what
he's
working
on
he's
working
on
a
standard
admin
feature
he's
just
rewriting
some
pages.
Why
is
he
doing
that?
I
don't
know,
but
as
a
manager
I
need
to
sit
up
out
of
my
chair,
I'm
gonna
leave
Katherine
alone
I'm
gonna
leave
Marc
alone
I'm,
going
to
leave
Alexandre
alone
and
I'm
just
going
to
go
check
in
with
Luke.
A
A
Okay,
not
a
very
interesting
statistic
as
a
point
in
time,
taken
over
a
long
period
of
time
for
certain
engineers
in
a
certain
class
of
work
that
ends
up
being
an
outstanding
indicator
of
productivity
right
for
people
who
are
doing
largely
new
features.
People
who
are
working
in
fast
moving
parts
of
the
code
front
end
HTML
errs
this
ends
up
being
an
excellent
area
to
signal
that
somebody's
gotten
stuck
now
again.
A
I
can
ignore
some
of
these
guys
because
I
know
they're
doing
tuning
or
they're
doing
some
area
where
I
wouldn't
expect
a
tremendous
amount
of
output.
But
if
I
told
you
that
John's
see
down
here
at
the
bottom
of
the
pile
is
an
HTML
or
who
only
writes
new
features
on
prototyping
I'm,
not
saying
john
c
has
a
problem,
but
I'd
go
check,
makes
sense,
yeah
it's
a
whole
lot
better
than
walking
around
an
office
and
going
hey
man
how's
it
going
well
good,
good,
okay,
cool,
hey
man,
how's
it
going
really
good
good.
A
Nobody
ever
admits
to
it,
not
going
good.
If
you
ask
any
engineer
in
the
middle
of
their
day,
how's
it
going,
they
will
always
say
good
and
you
have
to
probe
and
you
have
to
push
and
that
whole
time
that
you're,
pushing
and
nudging
and
asking
and
trying
to
uncover
problems,
you're
wasting
his
time
or
her
time,
you're
taking
productivity
away
from
your
team.
A
So,
in
the
upper
right
hand,
quadrant
you
have
politicus.
These
are
people
who
output
a
tremendous
amount
of
work
with
very
little
rewrite
on
the
bottom.
You
have
people
who
turn
everything
and
have
a
net
output
of
very
little,
usually
problematic.
Sometimes
you
can
visit
that
quadrant.
Don't
stay
there
very
long
on
the
lower
right-hand
corner
very
commonly
you
see.
A
Managers
sort
of
halftime
team
leads
people
who
aren't
necessarily
supposed
to
be
doing
high,
throughput
lots
of
work,
but
what
they
do
do
tends
to
be
little
bits
of
work
that
are
touch
up
and
they're
generally.
You
know
generally
very
small
and
precision
in
nature.
We,
you
know
or
more
commonly,
they're
perfectionists
right
and
in
the
upper
left.
You
have
the
Explorer
quadrants.
These
are
people
who
are
churning
a
ton
and
they're
putting
a
ton
of
work
out.
A
You
see
this
most
commonly
in
developers
who
are
writing
HTML
ss
front-end
JavaScript,
where
they'll
write
some
code.
They'll
show
it
to
an
internal
stakeholder
write.
Some
more
code
show
to
the
stakeholder
again
very
common
pattern,
and
it's
okay
to
be
in
that
quadrant.
If
that's
the
work
that
you're
doing
makes
sense.
A
You
put
all
that
together
and
you
get
trends
all
right
in
this
case
I'm,
showing
a
impact
work
volume
impact
impact
is
a
measurement
of
essentially
the
cognitive
load
of
your
code.
It
is
a
function
of
how
much
code
you're
laying
down
across
how
many
files
spread
across
the
file
itself.
If
you
think
about
that
for
a
second
generally,
if
I
was
just
going
to
go
in
and
touch
up
a
method,
maybe
fix
a
helper
method.
You
know,
then,
maybe
tie
that
out
to
some
front
end
piece.
A
All
my
code
would
be
fairly
concentrated
across
the
entire
file
base
right,
but
if
all
of
a
sudden,
a
guy
comes
in
and
I
touched,
15
files
all
over
the
map,
I've
got
a
couple
lines
of
code
up
it.
You
know
lines
1
through
20
and
then
I've
got
edits
down
in
line
300
right,
there's,
there's
a
fairly
high
load.
There
all
right
commit
volume
same
exactly.
That
sounds
like
it's
a
more
sophisticated
method
of
measuring
raw
output
of
the
team,
and
we
can
look
at
trend
lines.
A
One
of
the
things
that's
very
very
common
is
we
can
because
we
can
drop
in
because
we
can,
because
we
can
drop
in
events
on
to
our
reports.
We
can
drop
in
events
on
our
reports.
We
can
see
things
that
are
driving
productivity.
Normally,
that's
a
release
right
could
also
be
Burning
Man.
It
could
also
be
the
loss
of
a
key
player
on
the
team,
resignation
or
the
joining
of
a
key
player
on
the
team,
and
it
becomes
very
easy
to
see
what's
making
a
difference
on
your
team,
we
measure
and
look
at
commits.
A
This
is
an
extremely
helpful
data
point
or
report
for
people
that
are
trying
to
see
that
last
mile
get
through
the
door.
All
right,
Samantha
opened
up
a
PR
five
months
ago.
It's
still
out
I,
don't
know
what's
going
on
there,
but
let's
either
kill
the
PR.
Let's
just
take
it
off
close
it
out,
get
rid
of
Samantha
I,
don't
know,
but
it's
not
okay
for
a
PR
to
be
out
for
five
months
period.
Full
stop,
and,
of
course
this
is
rank-ordered.
A
You
can
scroll
down
and
you
would
see
the
oldest
ones,
and
you
also
get
a
sense
of
on
the
upper
right.
How
hard
and
fast
this
release
is
coming
in
1881
thousand
lines
of
code
for
review.
I,
don't
know
who
made
this
slide
sort
of
a
worst
case
scenario,
but
if
you
have
81
thousand
lines
of
code
out
for
review
and
you're
a
week
out
from
lockdown,
you
can
bet
that
that
release
is
going
to
go
badly
like
I.
A
A
It's
just
a
better
tool
for
communicating
with
other
engineers,
very
quickly
getting
feedback
looping
that
feedback
in
getting
peer
review,
and
that
is
again
intrinsically
good.
It's
a
you
know,
it's
a
good
thing,
but
it's
important
to
understand
the
flow
of
commits
if
one
person
on
a
large
team
carries
the
unnatural
load
of
commits
of
commit
review
and
commenting,
that's
a
sign
of
low
productivity
right.
A
A
We
spent
this
entire
time
talking
about
inside
the
black
box,
but
it's
really
really
hard
to
talk
about
what's
inside
the
black
box,
if
you
don't
also
acknowledge
that
a
huge
function
of
productivity
around
the
black
box
is
the
inputs
garbage
in
garbage
out
cliche
one
two,
three,
four
five,
so
we've
developed
this
new
idea,
which
is
the
first
time
I'm
talking
about
it
publicly
called
ticket
jitter.
Okay,
it's
a
ticket
jitter.
What
is
that
in
a
perfect
world,
when
a
ticket
is
marked
to
start
implementation?
A
That's
the
last
time
anybody
should
post
up
anything
on
that
ticket,
except
for
work
done
check
in
close
out,
go
to
production
now
in
practice.
Of
course,
that
doesn't
actually
happen.
There's
always
a
small
amount
of
communication
on
every
non-trivial
ticket.
Point
of
clarification
should
it
be
blue.
Should
be
bright
blue?
Do
you
want
it
this
way?
Do
you
want
it
that
way,
all
right,
but
if
there's
too
much
of
that
noise
post
begin
implementation,
it
is
a
strong
signal
that
that
ticket
is
screwed
the
pooch
right.
A
This
brings
that
up
it
surfaces
that
reality
that
we
all
live
with,
and
so,
if
I
see
that
the
number
one
person
who
creates
the
most
ticket
jitter
is
Erica
and
Sanjay
is
the
engineer
who's
getting
hammered
by
that
ticket
jitter
I'm,
pretty
sure
that
his
release
is
going
to
go
badly
and
it's
probably
Erica's
fault,
and
so,
let's
just
get
in
there
and
talk
about
it.
Let's
go
in
and
see
why
that's
happening.
Why
is
that
happening?
A
Did
the
original
requirements
get
poorly
written?
Did
the
CEO
come
in
and
change
everything,
but
we
can't
hold
Sanjay
responsible
for
a
difficult
ticket
if
30%
of
that
ticket
change
from
the
time
he
started
working
on
it
to
the
time
he
finished
it?
We
think
that
this
is
going
to
be
a
compelling
report
that
will
change
the
conversation
between
product
and
engineering
because
it
now
begins
to
measure
the
inputs
I.
A
Got
a
couple
more
Streak:
this
is
just
a
good-looking
report.
John
I
love
this
book
when
you
manage
large
groups
of
engineers,
yet
100
engineers
are
more
right.
These
are
big
teams.
You,
you
tend
to
manage
them
by
by
large
directional
changes,
and
one
of
the
most
common
directional
changes
is
I.
Need
you
to
commit
every
day,
one
of
the
things
that
we
get
asked
a
lot
as
we're
as
we're
onboarding
customers
is
well
if
you've
instrumented.
A
All
of
this,
isn't
it
easy
to
game
the
system
can
I
game
all
your
reports,
the
answer
that
question
is:
yes,
you
can
absolutely.
In
fact,
we
wrote
a
whole
blog
post
about
exactly
how
to
game
it
in
the
way
that
you
gain
it.
Is
you
write
small,
regular
commits
that
get
reviewed
and
approved
and
go
to
production
and
don't
get
rewritten?
A
If
you
do
that,
you
will
get
high
marks
on
our
system,
and
so
you
should
streaks
are
a
way
to
measure
people's
progress
towards
that.
In
this
case,
remit
AI
has
a
running
best
score
of
what
are
we
measuring
on
this
one
record
streak
on
the
street
rat.
This
is
active,
commits
yeah.
It's
daily
commits,
can't
see
where
it
is.
This
is
active,
commits
right,
and
so,
if
we
want
people
committing
every
single
day,
this
is
a
great
report
to
show
them
how
to
do
that.
This
one
is
one
of
my
new
favorites.
A
How
long
does
it
take
on
average
to
get
a
pull
request
out
the
door?
It's
like
an
AR
aging
report
on
a
financial
system
which
may
not
mean
a
whole
lot
to
engineers,
but
it
means
a
whole
lot
to
people
in
finance,
and
so
what
this
report
is
showing
is
that
five
percent
of
all
of
our
commits
are
getting
done,
are
getting
excuse
me,
PRS
are
getting
done
in
24
hours,
22
percent
are
getting
done
one
to
three
days,
and
this
big
dotted
line
is
the
50
percent
mark.
A
So
now,
if
all
your
PRS
are
getting
done
somewhere
inside
a
week-
and
it's
probably
no
big
deal,
but
some
of
this
stuff
out
here
is
pretty
problematic,
and
if
these
bars
get
too
big,
you
probably
want
to
start
taking
that
pretty
seriously.
This
is
again
a
great
way
to
measure
productivity
as
a
team
as
the
whole
before
there's
a
serious
problem,
and
you
can
see
it
coming
as
24
as
as
you
move
through
the
buckets
and
those
bars
rise.
A
And
this
is
feature
costing
so
feature
costing
has
been
around
pretty
much
as
long
as
software's
been
around.
There's
there's
actually
whole
books
written
on
how
to
how
to
price
and
estimate
the
cost
of
a
feature
or
piece
of
software
going
back
to
the
60s.
Some
people,
hopefully
around
here,
read
the
mythical
man-month.
A
That
book
was
written
in
1975
all
right
and
feature
costing
is
very,
very
precise
and
a
very
effective
way
to
do
things
as
long
as
you're
willing
to
put
your
engineers
on
a
timer
and
make
them
record
their
time,
and
we
think,
as
I
think
most
of
the
industry
does
today
that's
a
terrible
idea
unless
you're
billing
for
time
and
you're
in
a
consulting
business
but
in
terms
of
general
high
throughput
productivity.
It's
too
much
overhead,
but
you
still
want
to
figure
out
how
to
cost
features.
A
I
used
to
work
for
a
company
that
had
a
CEO
that
every
single
week
you
would
come
in
with
a
brand
new
breakthrough
idea
that
was
going
to
game
change.
Everything
and
you
need
to
drop
what
you
are
doing.
Do
the
thing
that
he
wanted
you
to
do.
We
called
it
the
Imperial
feature
and
you
actually
all
the
engineers
knew
about
the
Imperial
feature
because
on
the
ticket
on
the
ticket
title,
we
put
a
period
at
the
end
of
all
Imperial
features,
which
meant
when
you
got
to
lockdown,
no
matter
what
happened?
A
Don't
let
that
feature
drop
off
the
release,
even
if
you
had
to
kill
everything
else.
So
now,
when
that
guy
produces
an
imperial
feature
and
it's
an
absolute
game
changer,
we
can
come
in
and
show
that
that
was
a
$50,000
feature,
because
we
looked
at
all
your
commits
all
the
lines
of
code,
all
the
churn,
all
the
rework
bundled
it
all
up,
took
the
total
amount
of
mounted
cost.
A
It
cost
to
run
the
whole
engineering
team
and
get
a
pretty
good
cut
at
what
that
feature
cost,
and
we
can
show
how
much
it
took
cost
to
support
that
feature
downstream.
This
is
the
first
of
our
features
that
will
go
outside
of
git
itself
and
also
start
looking
at
ticket
data.
I
guess
a
couple.
The
others
will
too,
but
this
is
the
big
one.
Where
will
now
start
looking
at
git
github
or
get
data
and
ticket
data?