►
From YouTube: Decoding Five Traits of Successful Engineering Teams
Description
Shipping high quality code quickly and consistently depends not just on the individual but the work of high functioning teams. Join former GitHub Engineering leader and now fractional VP of Engineering, Allison McMillan as she shares her experience and thoughts on the key traits for a strong startup engineering team.
00:00 - Introduction
02:05 - Overview
03:37 - Healthy Turnover
10:54 - Good Code Review
20:00 - Prioritization Clarity
28:03 - Healthy Team Dynamics
37:20 - Low Cycle Time
#GitHub #DevOps #Engineering
Stay up-to-date on all things GitHub by connecting with us.
YouTube: http://bit.ly/subgithub
Blog: https://github.blog
Twitter: https://twitter.com/github
LinkedIn: https://linkedin.com/company/github
Insider newsletter: https://resources.github.com/newsletter/
Instagram: https://www.instagram.com/github
TikTok: https://www.tiktok.com/@github
Facebook: http://fb.com/github
About GitHub
It’s where over 100 million developers create, share, and ship the best code possible. It’s a place for anyone, from anywhere, to build anything—it’s where the world builds software. https://github.com
A
A
B
Absolutely
so
I'm
Allison
McMillan
I
am
a
fractional
VP
of
engineering.
So
what
that
means
is
that
I
work
with
startups,
who
sort
of
need
someone
who's
great
at
solving
those
early
scaling
problems,
the
problems
that
folks
are
just
starting
to
run
into
with
their
engineering
teams
and
they
need
someone
who's
been
a
VP
of
engineering
before
and
who
has
that
perspective?
But
maybe
they
don't
quite
have
the
budget
or
the
scope
to
need.
B
Someone
like
that
full-time
I
also
do
engineering
leadership,
Consulting,
so
I
help
teams
by
planning,
really
amazing,
off-sites
and
also
doing
engineering
team
Health
assessments
as
a
fun
fact,
I
used
to
work
at
GitHub
I
run
the
coding
Department,
which
was
pull
requests,
repositories,
code,
spaces
and
a
handful
of
other
areas,
and
then
I
live
in
Washington,
DC
and
I'm.
A
University
of
Michigan
Alum,
so
go
Blue.
If.
A
Well,
a
couple
of
things
we
heard
there,
so
she
knows
what
she's
talking
about.
She
has
run
GitHub
for
a
number
of
years
in
the
engineering
department
and
she
has
been
a
an
engineering
leader
at
a
lot
of
early
stage,
startups
so
perfect.
To
have
you
on
to
talk
about
the
topic
today,
which
is
decoding
five
traits
of
successful
engineering
teams.
You've
seen
it
you've
been
a
part
of
them,
you've
LED
them.
So
let's
hop
right
in
I'm
super
excited
to
hear
more
about
it
and
I'm
gonna
pass
it
to
you.
B
B
B
There's
also,
there's
quantitative,
there's
also
a
lot
of
qualitative
in
these
sort
of
successful
traits
of
engineering
teams.
I'm
going
to
talk
a
lot
about
qualitative
things,
things
that
you
can
observe
within
your
teams
and
it's
harder
to
assess
because
it's
not
as
clear
cut.
You
can't
just
look
at
deals
made
or
you
know,
other
very
sort
of
straightforward
metrics,
like
you
can
for
other
departments
and
other
teams.
A
B
So
this
one
is
a
successful
trait
as
a
team
that
has
healthy
turnover,
so
there's
a
couple
of
different
aspects
in
thinking
about
healthy
turnover.
The
first
one
is
How
likely
is
it
that
you'll
have
turnover
and
what
happens
when
you
do
so
successful
teams
have
low
turnover.
They
don't
have.
No
turnover
I
actually
think
that
no
turnover
whatsoever
is
an
indicator
of
maybe
not
a
healthy
team,
but
they
have
low
turnover
and
they
have
really
effective
knowledge
sharing.
A
So
you
said
something
that
I
think
is
really
interesting.
I'd
love
to
hear
a
little
bit
more
about
it.
You
said
an
indication
of
maybe
a
not
so
healthy
team
is
no
turnover
whatsoever.
So
what
do
you
mean
by
that?
What
what
kinds
of
things
would
you
see
if,
if
it
was
no
turbo
whatsoever
and
what
kinds
of
things
should
you
be
thinking
as
an
engineering
leader?
If
that's
what
you're
seeing
yeah.
B
So
no
turnover,
maybe
people
are
everybody's
thrilled,
Everybody's,
Fine,
everybody's
great,
but
frequently.
If
there's
no
turnover,
it
could
mean
that
people
feel
stuck,
but
they
don't
want
to
move
on.
It
could
be
that
people
aren't
getting
effective
feedback
and
it
could
also
be
that
that
individuals
feel
like
they
either
have
to
stay
at
the
company
or
the
company
feels
like
somebody
has
to
stay
there
because
they're,
the
only
person
who
knows
so
much
about
about
a
specific
area
of
the
code
base
or
of
the
process
or
whatnot.
B
So
there
there
are
a
couple
of
ways
that
you
can
sort
of.
But
whether
or
not
you
have
a
process
for
healthy
turnover,
one
is,
and
it
again
goes
to
sort
of
like
knowledge
sharing
and
How
likely.
It
is
that
you'll
have
turnover
that
people
will
leave
so
for
the
first
for
the
How
likely
it
is
that
people
might
leave
some
things
that
you
can
look
for
are
like
unclear
expectations
unclear.
B
They're
less
likely
to
feel
fulfilled
in
the
in
the
role
that
they
have
and
they're
more
likely
to
leave
the
company
for
a
different
opportunity
and
then
I'll
just
go
one
more
for
Effective
knowledge
sharing
one
of
the
ways
that
you
can
spot.
That
is
if
there
is
one
person
that
is
like
the
go-to
person
for
all
of
the
fixes
in
a
specific
area.
A
Okay,
so
all
awesome
information,
I
I'm,
looking
again
at
like
the
five
traits
that
you
have
on
here
and
it
says
healthy
turnover
and
the
the
question
that
I
asked
was
around
zero
turnover
at
all.
And
so
is
there
like
a
turnover
rate?
If
you
will
that's
like
maybe
a
healthy
amount
of
turnover
like
what
do
you
think
about
that.
B
B
You
know,
I
think
that
it's
what
structures
are
being
put
in
place
to
retain
people
and
then
again
when
folks
turn
over.
You
know
making
sure
that
they're.
The
reason
why
they're
leaving
feels
feels
like
the
right
reason
feels
like
a
good
reason
and
then
when
they
do
leave
making
sure
that
there's
not
a
scramble.
There's
not.
You
know
that
you
have
effective
knowledge,
sharing
that
no
one
engineer
feels
like
they
have
so
much
of
the
the
company
on
on
their
back
sort
of
thing.
A
Cool
and
one
of
the
things
that
I
think
about
as
well
is
like
when
you
eventually
have
that
turnover,
you
know:
do
you
utilize
exit
interviews
to
help
kind
of
with
the
turnover,
the
healthy
turnover,
knowledge,
sharing
or
understanding
of?
Why
they're
leaving?
How
do
you
think
about
exit
interviews
and
how
you
use
those.
B
B
You
know
I
think
that
some
things
that
some
questions
that
someone
can
ask
themselves
and
I'll
again
talk
about
sort
of
the
retention
piece
for
a
minute,
as
opposed
to
the
sort
of
knowledge
sharing
piece,
but
for
that
retention
piece
things
that
frequently
come
up
in
exit
interviews
are
things
like
do
written
expectations
of
any
kind
exist
right
or
like
do,
managers
or
the
manager?
Whoever
is
managing
the
engineering
team?
B
Are
they
tackling
technically
difficult
problems
or
technically
difficult
problems
that
are
appropriate
for
their
experience
level
and
how
that
how
that
what
that
looks
like
for
the
team
as
a
whole
right
and
not
just
sort
of
are
saying,
like
everyone
seems
fine
and
the
only
feedback
that
folks
get
is
like
keep
doing
what
you're
doing
I
think
that's
really
that's
really
challenging
for
individuals,
and
then
the
last
piece
can
be
like.
Are
there
performance
reviews
of
any
kind
right?
It
doesn't
have
to
be
a
heavy
lift.
B
It
doesn't
have
to
be
a
whole
full,
robust
system,
but
I
think
for
individuals
for
retention
feedback
is
really
really
important.
It's
really
important
that
folks
feel
like
they're
growing
in
their
in
their
careers
and
like
they
know
what
the
next
challenges
that
they're
going
to
look
at,
or
how
what
they're
doing
well
and
what's
a
stretch
for
them
or
what's
something
that
they
have
to
work
on.
A
B
B
B
What's
going
on
right,
there
are
tools
that
can
give
you
metrics
on
like
pull
requests,
who's,
doing,
pull
request,
reviews
comment,
numbers
things
like
that,
but
I
also
like
to
I
like
to
look
at
the
number
of
comments
on
pull
requests
right,
so
is
it
just
like
a
thumbs
up,
looks
good
to
me
ship
it
or
is
there
actual
conversation
in
there
I
like
to
look
at
the
the
tone
of
those
comments,
I
like
to
look
at
sort
of
individuals
that
are
reviewing
the
pull
request
right?
How
many
people
review
it?
B
How
many
required
people
are
needed?
How
many
additional
People
review
who
they
are?
Is
it
the
same
person
who's?
Always
who's,
always
reviewing
the
pull
requests?
Those
are
some
but
I.
Think
good
teams
really,
like
everyone,
makes
time
and
space
in
their
calendar
daily
to
sort
of
hop
on
and
do
you
know,
do
pull
request
review
review
code
and
they
they
review
code,
really
thoughtfully.
A
Have
you
ever
had
an
experience
as
an
engineering
manager
or
an
engineering
leader
where
some
of
the
commentary
wasn't
as
kind
of
robust
during
the
code
review
and
if
you,
if
you
have
kind
of
how
do
you,
how
do
you
pull
that
kind
of
conversation
out
so
that
you
can
start
to
get
a
team?
That's
a
little
bit
more
locked
in
with
each
other
and
having
those
conversations.
B
B
The
first
is
very
little
comments
right,
like
the
looks
good
to
me
with
the
ship
it
you
know
and
where
it
that
is
not
an
issue
when
it's
here
and
there
or
when
it's
just
on
a
few
pull
requests,
but
when
that's
the
regular
Cadence
and
sort
of
what
you
can
expect
to
see
on
a
code
review
from
your
whole
team.
That's,
in
my
opinion,
usually
problem.
It's
not
enough!
It's
not
enough
to
learn
it's
not
enough
to
really
sort
of
understand.
B
On
the
flip
side,
there
can
also
be
too
many
comments
where
a
where
a
pull
request
or
a
code
review
ends
up
going
into
like
a
rewrite,
an
entire
like.
Let's
try
a
different
technical
implementation
where
there's
just
so
much,
there's
so
much
there
that
it's
really
hard
to
it's
hard
to
parse
and
it's
hard
to
figure
out,
and
it's
probably
better
at
some
point
sort
of
take
that
conversation
elsewhere.
B
This
can
also
one
of
the
questions
that
I
sort
of
like
to
look
at
and
ask
is:
is
there
bias
in
the
code
review
process?
For
example,
does
one
person
usually
get
a
whole
lot
of
comments
and
really
sort
of
like
piled
onto,
whereas
somebody
else
always
gets
like
looks
good
to
me
with
a
thumbs
up?
That's
just
an
important
thing
to
note
in
Team
Dynamics
and
then
in
between
too
many
comments
and
too
few
comments.
B
There's
also
ambiguous
comments,
so
where
the
code
review
will
be
will
be,
will
be
good
and
will
be
solid,
but
where
it's
really
hard
for
the
the
person
who
submitted
the
pull
request,
the
person
reading
the
code
review
to
get
a
good
sense
of
which
of
those
comments
are
like
nitpicks
or
suggestions,
or
you
might
consider
doing
this
this
way
and
which
of
them
are
like
no.
This
really
has
to
change
like
this.
This
needs
to
be
addressed
before
this
pull
request.
B
Ships
and
that's
sometimes
really
challenging,
especially
For
Less
experienced
developers
but
I
think
for
Developers
for
engineers
at
all
levels.
It's
really
challenging
to
look
through
a
code
review
and
tell
like.
Okay,
what's
my
priority
order
and
addressing
these
addressing
these
comments
and
addressing
this.
A
B
A
B
You
know
I
think
that
every
team
has
its
own
style.
There's
there
are
a
few
features
in
Hub.
There
is
a
round
robin
there's.
You
can
create
sort
of
reviewer
teams
so
that
either
one
individual
or
multiple
individuals
will
get
pinged
when
a
pull
request
is,
is
ready
for
them
to
review.
I
mean
that's
great,
especially
as
you
have
larger
teams,
with
more
more
pull
requests
going
into
the
same
into
the
same
repository
so
there.
B
Draft
pull
requests
are
a
really
great
a
really
great
place
to
to
go
for
that
so
yeah.
So
there
are
a
variety
of
tools
that
sort
of
make
it
easy
easier
for
you
to
know
when
a
pull
request
is
ready
to
ready
to
review
and
gets
your
gets
your
attention
in
terms
of
best
practices,
I.
Think
the
number
one
thing
is
our
folks
leading
from
a
place
of
curiosity
great.
Are
they
people
do
the
best
work
that
they
can
with
the
knowledge
that
they
have
at
that
time?
B
And
you
know
that's
the
beauty
of
teams
is
that
people
come
with
different
knowledge
with
different
backgrounds,
with
different
experiences
with
different
things,
that
they've
seen
work
and
not
work
at
different
places,
and
so
you
know
when
people
come
to
a
place,
come
to
a
code
review
from
a
place
of
of
curiosity
and
really
lead
with
that.
I
think
that's
so
important,
because
it
means
that
the
phrasing
is
less
I.
B
Don't
understand
why
you
did
this,
that
you
should
do
this
instead
and
more
I'm
curious,
why
you
took
this
approach
or
have
you
thought
about
X?
You
know.
Sometimes
it's
here's,
a
blog
post
about
it
or
here's
a
similar
pull
request.
That
might
be
great
for
you
to
look
through
again
using
good
code
review
as
a
way
to
communicate
and
collaborate
and
learn
and
knowledge
share.
Awesome.
A
B
So
this
is
a
clear
understanding
by
Engineers
of
what
work
to
prioritize
and
why
so,
a
successful
team
will
understand
how
to
prioritize
work
effectively
and
where
to
go
for
escalations
or
Clarity.
The
reason
why
this
is
really
important
is
because
there
are
lots
of
information
inputs
that
come
to
Engineers,
there's
Tech
debt,
there's
customer
requests,
there's
product
features,
there's
bugs.
There
is
also
often
sideways
requests
from
leadership
or
sales
or
other
people
that
go
into
the
DMS
and
are
sort
of
hidden
and
when
Engineers.
B
So
this
isn't
just
Engineers
have
prioritized
work,
but
it's
that
they
also
really
understand
more
of
what
worked
to
prioritize
and
why?
Because,
when
Engineers,
don't
know
how
to
understand
those
different
streams?
All
of
that
information
is
coming
to
them
anyway,
and
they
end
up
bouncing
between
too
many
things
and
losing
so
much
time
to
context.
Switching.
A
B
A
So
when
you,
when
you've,
got
that
as
a
reality
of
like
you
know
that
that
just
happens
right,
so
how
do
you
kind
of
protect
your
engineers
from
prioritizing
those
things
in
you
know,
inaccurately
or
or
how
do
you?
How
how
do
you,
how
do
you
have
them
communicate
to
you
when
these
additional
requirements
are
being
added,
and
then
how
do
you
recalibrate
your
prioritization.
B
I
think,
first
and
foremost
the
I
always
have
my
teams
and
departments
do
two
things
one.
They
understand
where
to
go
for
escalations
right,
so
if
they
are,
if
a
new
thing
hits
them
or
they
even
if
they
see
something
in
a
different
Channel
and
they
think
that
we
should
be
prioritizing
it
they,
they
know
what
that
escalation
looks
like.
They
know
what
that
process
looks
like.
B
So
that's,
first
and
really
important.
The
second
piece,
that's
really
important,
is
that
I
always
really
push
folks
to
if
they
get
a
DM
or
a
direct
message
or
whatever
that
they
really
encourage.
Whoever
is
messaging
them
to
take
it
to
a
public
channel.
So
this
is
obviously
you
know
more
for
remote
distributed
teams,
but
conversations
need
to
be
visible
right.
I
think
that
the
the
worst
outcomes
happen
when
there
are
a
whole
lot
of
sort
of
private
or
hidden
conversations
that
that
happen.
B
That
then,
results
in
maybe
a
change
of
a
changing
course
or
a
change
in
priority
and
frequently
the
way
that
managers
or
engineering
leaders
find
out
about
this
is
through,
like
a
stand-up
update
when
people
mention
the
things
that
they're
working
on
and
something
seems
like,
there's
a
surprise
there
or
something
seems
sort
of
like
they.
It
came
out
from
us
left
field,
and
then
you
touch
base
with
that
engineer
with
that
individual
and
you
figure
out
like
okay.
Why
is
this
on
your
plate?
B
A
A
B
About
about
prioritization
Clarity,
because
there
are
other
places
that
you
can
also
that
you
can
also
see
it
and
other
metrics
that
you
can
look
at
and
questions
that
you
can
sort
of
ask
as
you're
trying
to
assess,
assess
this
and
figure
it
out.
So
aside
from
stand-up
updates,
or
you
know,
a
change
in
course,
after
a
private
conversation,
you
can
also
frequently
see
this
through.
B
Like
repeated
questions
or
repeated
confusion,
you
know,
as
as
a
leader,
it's
important,
that
you
say
it
say
it
again
say
it
again
and
then
say
it
again
and
then
it's
you
know
posted
in
a
few
different
places
to
make
sure
that
you're
really
communicating
effectively.
But
if
they're,
if
you
keep
getting
questions
or
your
managers
or
others,
if
they're
keep
getting
questions
asked
about
how
to
prioritize
something
or
if
there's
confusion,
it
means
that
it
isn't
quite
clear
enough.
It
isn't
digestible
enough
and
it
isn't
sort
of
straightforward
enough.
So
it's
a
good.
B
It's
a
good
sort
of
indicator
to
to
look
at
what's
going
on
with
prioritization
Clarity
and
the
other
piece
is
delayed
ships,
so
things
that
should
ship
frequently
get
delayed.
Sometimes
it's
because
of
technical
complexity,
I
think
frequently
it's
because
a
person
or
a
team
or
whatever
is
they're
pulled
onto
something
else.
B
Some
questions
is
again
I
mentioned
stand-ups,
like
are
you
surprised
by
some
of
the
things
that
your
engineers
are
talking
about
that
they're
working
on?
You
can
also
look
at
how
many
tickets
is
a
single
engineer
working
on
at
once.
Hopefully,
you
have
some
sort
of
visibility
into
the
work
and
what's
what's
on
everyone's
plate,
and
if
somebody
has
four
five,
six,
seven
things
with
their
with
their
name
on
it.
B
Why
piece?
It's
really
important
that
those
that
those
shifts
come
with
communication
and
that
people
sort
of
understand
why
why
things
are
happening?
It
also
relates
to
healthy
turnover
right
again.
If
people
don't
feel
the
impact
of
their
work,
if
they
feel
like
things,
are
just
sort
of
everywhere
all
at
the
same
time,
it's
going
to
lead
to
a
more
frustrating
day-to-day
for
them
and
they're
going
to
be
less
productive.
A
Awesome
now
thank
you
for
the
extra
context,
I
think
and
when
moving
on
to
the
the
next
one,
so
prioritization
Clarity
to
this
next
one
healthy,
Team
Dynamics.
You
mentioned
a
lot
of
things
that
also
carry
over
to
this
as
well,
so
tell
us
a
little
bit
more
about
healthy,
Team,
Dynamics
and
and
how
that
is
the
fourth
of
the
five
traits
for
successful
engineering
teams.
Yeah
again,
okay
for
many
teams
across
the
board
as
well.
B
So
this,
what
healthy
chain
Dynamics
means
is.
It
is
a
team's
interactions
with
one
another
and
it
includes
all
of
the
ways
that
teams
interact.
It
includes
verbal
communication,
written
communication
meeting
Dynamics
there.
There
are
a
lot
of
sort
of
unspoken
or
hidden
dynamics
that
happen
within
teams,
and
so
this
is
also
I
will
say:
it's
the
trickiest
one
to
decode
without
a
bunch
of
practice
doing
it.
B
A
Absolutely
I've
got
maybe
a
selfish
question
for
me,
because
I
used
to
be
a
technical
project
manager,
so
I
would
help
to
do
projects
for
other
teams,
which
involved
engineers
and
the
the
working
with
Engineers.
Sometimes
I've
had
teams
where
they're
receptive
to
that
outside
project
management
and
help,
and
sometimes
not
how
does
like
a
healthy
team
Dynamic
within
the
engineering
organization
or
that
engineering
team
kind
of
translate
to
cross-functional
work.
B
Making
having
welcoming
conversations
creating
space,
paying
attention
to
paying
attention
to
things
like
how
many
public
messages
are
there
versus
private
messages
in
slack,
making
sure
that
healthy
conflict
resolves
successfully
and
that
it
resolves
in
the
right
place
right?
Is
it
in
slack?
Do
you
take
it
to
a
video?
Do
you
take
a
break
and
then
come
back
to
a
discussion?
What
does
that?
B
Look
like
I
think
that
if
a
team
has
a
really
healthy
communication,
Dynamic
and
they're,
treating
each
other
respectfully
and
they
feel
like
everybody
on
the
team
feels
like
all
anyone
can
ask
questions.
You
know
they.
They
thoughts
are
welcome
and
included.
There's
you
know
fun
team,
banter,
Etc.
It's
going
to
automatically
spread
to
anyone
who
sort
of
joins
that
team
and
and
is
part
of
that
team
in
a
cross-functional
way
as
long
as
they
bring
that
same
energy,
that's
also
really
important
it.
B
B
Can
yeah?
It
also
can
frequently
like
change
the
team's
Dynamic,
how
each
individual,
how
each
individual
interacts
with
that
new
person
coming
in
there
are
sort
of
like
four
stages
of
group
or
team
development,
forming
storming,
norming
and
Performing
is
they're
called
and
every
time
that
a
team
gains
someone
or
loses
someone.
The
team
itself
goes
through
all
four
of
those
stages.
Again,
sometimes
those
stages
are
shorter
or
longer,
but
like
every
new
person,
that's
added
or
subtracted
you
have.
You
have
a
new
team.
A
B
How
do
folks
contribute
to
conversations
either
when
it's
happening
or
after
the
fact
right?
And
so
that's?
Is
there
space
for
both
introverts
and
extroverts
to
contribute
to
conversations
and
do
both
groups
feel
comfortable
doing
so?
You
can
also
use
that
same
sort
of
look
for
that
same
Dynamic
with
earlier
career
and
later
career,
folks,
right
folks
that
are
less
experienced
and
folks
that
are
more
experienced.
Everybody
feel
like
they
have
a
place
at
the
table
and
the
ability
to
contribute,
and
are
they
comfortable
doing
that?
B
B
A
B
B
Ooh
best
practice
on
how
to
keep
them,
I
mean
call
out
both
like
individually
and
for
the
group
like
when
people
are
doing.
This
well
right,
like
when
really
healthy
conversations
happen
when
you
know
shout
outs
to
one
another
right,
a
really
healthy
culture
of
people,
sort
of
recognizing
one
another
and
giving
that
credit.
Or
you
know
when
somebody,
let's
say
like
shouts
at
one
person,
and
that
one
person
knows
that
they
worked
with
two
other
people.
A
And
so
that
was
number
four
healthy,
Team
Dynamics
and,
like
I,
said
about
three
and
four,
which
is
prioritization
Clarity
and
healthy,
Team
Dynamics.
Those
are
important,
no
matter
what
kind
of
team
you're
working
with
they're
working
for
whatever
company
those
are
super
super
helpful
tips.
So
thank
you
for
going
through
those
and
the
last
one.
The
last
of
the
five
traits
for
successful
engineering
team
is.
B
B
B
Ooh
I
mean,
like
I,
said
at
the
beginning:
right
I,
don't
I,
don't
love
talking
so
much
about
sort
of
like
quantitative
metrics.
There's
like
you
can
look
at
sort
of
like
pull
request
comments
you
can
look
at
and
there
are
a
couple
of
tools
that
do
this.
Like
Linear
B.
Does
this
code,
climate
I
think
jellyfish
like
there
are
a
few
that
you
can
just
sort
of
like
hook
into
your
system,
and
it
will
give
you
a
nice
dashboard
that
will
tell
you
cycle
time.
A
Awesome
well,
Allison,
we've
got
about
five
minutes
left
and
one
I
want
to
say
thank
you
for
coming
to
join
us
super
helpful
for
not
only
just
our
individual
developers,
but
our
our
startups
that
are
part
of
our
program.
So
just
with
this
five
minutes,
I
want
to
give
you
the
time
to
one
maybe
do
a
quick
debrief
of
of
what
those
five
traits
are.
Just
as
we
leave
and
then
also
tell
us
a
little
bit
about
what
you
do
on
your
on
your
spare
time.
Right
now,.
B
Yeah,
absolutely
okay,
so
in
these
in-thins
are
a
healthy
turnover,
good
code
review,
quality,
prioritization,
Clarity,
healthy
Team,
Dynamics
and
low
cycle
time.
So
here's
what
I'll
say
and
else
you
can
throw
that
last
slide
up.
Yet
thank
you
so
figuring
out
how
to
build
a
team
that
has
these
traits
is
difficult.
It's
difficult
to
put
these
traits
and
habits
in
place
with
an
existing
team
and
it
is
difficult
to
figure
out
and
assess
all
of
the
pieces
of
the
puzzle.
B
Right
I
probably
threw
out
50
different
questions
during
this
session
of,
like
things
that
you
can
look
at
ways
that
you
can
spot
ways
you
can
assess,
and
that
was
for
five
for
five
traits,
so
I
would
love
to
help
again.
I'm
an
engineering
leadership
consultant
I
help
companies
by
providing
engineering
team,
Health
assessments
by
coming
in
as
a
fractional
VP
of
engineering
and
also
by
planning,
really
fun
and
effective
off-sites
that
are
a
great
way
to
accelerate
getting
to
these
traits
successfully
with
your
team.
A
Allison
and
before
I,
let
you
go
we're
going
to
ask
one
more
question.
Maybe
two
we'll
do
an
engineering
related
question
and
non-engineering
related
question,
because
we
want
to
get
to
know
you
a
little
bit
as
well,
so
from
the
engineering
side
of
things.
What
is
maybe
the
craziest
story
you've
had
in
regards
to
one
of
these
five
traits,
whether
it's
like
a
team
that
didn't
quite
get
along
and
you
had
to
kind
of
reel
it
back
in.
A
B
Yeah
I
think
prioritization
Clarity
I
mean
when
I
run
repositories,
pull
requesting
code.
Spaces
like
for
I
will
say
repositories
specifically.
There
are.
That
is
a
huge
piece
of
GitHub
that
all
millions
of
people
use
every
day
and
there
is
just
there's
there's
so
much
and
pull
requests
also
right,
there's
so
much
that
can
be
done
in
that
area.
There's
so
much
that
can
be
done
for
different
customers
and
different
users.
B
There's
different
people
in
leadership
have
different
opinions
on,
and
so
it
was
just
like
that
was
probably
the
place
where
we
had
to
get
prioritization
and
end
escalation
like
down
the
most,
because
there
were
just
so
many
things
to
prioritize
all
the
time,
and
you
know
with
any
engineering
team.
You
can
only
do
as
many
things
as
you
has,
as
you
have
the
people
and
the
ability
to
do
so.
Yeah,
that's
what
I
love
talking
about
prioritization
Clarity,
because
I
have
lived
it
very
intensely
in
that
way.
Awesome.
A
B
Okay,
so
I'll
do
dream,
vacation
and
next
vacation,
okay,
they're,
actually
sort
of
similar,
but
in
very
different
ways.
So
next
vacation
we
I
have
two
kids.
We
are
doing
a
family
vacation
to
the
Adirondacks
at
the
end
of
the
summer.
We
went
last
summer
for
a
week
and
it
is
just
it's
beautiful
up.
There
we
hike
in
the
morning.
We
eat
ice
cream
in
the
afternoon.
B
It
is
very,
very
chill
and
just
like
a
really
wonderful
time
that
doesn't
involve
me
planning
a
whole
lot
of
stuff
and
spending
a
lot
of
time
and
effort
doing
that
and
then
my
dream
vacation
is
to
Patagonia
again
just
like
so
beautiful,
so
amazing.
The
pictures
are
just
I
feel
like
every
time.
I
see
pictures
from
Patagonia
they're
just
wild,
and
you
know
again
just
like
beautiful
hikes,
beautiful
things
to
do
so.
That
100
would
be
my
dream.
Vacation.
A
A
Are
not
happy
well
Allison,
McMillan.
Thank
you
again
for
joining
us.
As
she
said,
we've
got
the
QR
code
up
here
book.
A
free
consultation
check
her
out
on
her
on
her
website
or
shoot
her
an
email
at
Allison
allisonmillan.com.
Thank
you
again
for
joining
us
again.
These
were
the
five
traits
of
successful
engineering
teams
and
we're
happy
to
have
you
here.
Thank
you.