►
Description
GitLab EVP of Engineering (Eric), Engineering IC Leaders, and the Learning & Development team discuss Engineering IC Leadership.
Learn more about Engineering IC Leadership: https://about.gitlab.com/handbook/engineering/ic-leadership/
Learn more about Learning & Development: https://about.gitlab.com/handbook/people-group/learning-and-development/
Topics covered include:
1. What does it mean to be an Engineering IC Leader
2. What are the skills needed to do the job
3. How the role differs from other Engineering management roles
4. Technical credibility versus Technical leverage
5. Applying iteration to everything you do
6. The four archetypes and how they define the work of IC leadership
A
Awesome
well
thanks
everyone
for
joining
us
here
today.
My
name
is
josh
zimmerman,
I'm
the
learning
development
manager
here
at
get
lab
and
I'm
honored
to
be
joined
here
with
eric
johnson
evp
of
engineering,
as
well
as
a
number
of
ic
engineering
leaders
across
the
organization,
and
today
we
wanted
to
talk
about
engineering,
ic
leadership
and
really
get
a
better
understanding
of
what
that
means.
You
know
talk
about
technical
leverage
and
how
engineering
ic
leaders
can
implement
that
into
their
day-to-day
role
at
getlab.
A
B
Well,
I
would
start
to
just
level
set
so
like
in
the
in
the
most
boring
sense.
We've
got
a
bunch
of
titles
out
there,
so
you
can
be
a
intermediate
engineer.
You
can
be
a
senior
engineer
and
then
you
have
sort
of
a
fork
in
the
road
career-wise.
So
where
do
you
want
to
go
next?
Some
people
choose
management.
I've
obviously
done
that.
B
B
We
don't
really
use
those
words
in
terms
of
titles
and
that's
where
you
start
to
see
staff
roles
distinguished
and
fellow
roles
and
not
engineering,
so
we
kind
of
view
those
conceptually
as
two
separate
but
parallel
career
tracks
and
what
I
think
smart
companies
like
us
do
is
we
keep
them
equal
in
terms
of
compensation
and
prestige,
so
there
should
be
no
incentive
to
say
I
want
a
bigger
paycheck.
I
want
to
be
better
respect
in
the
organization.
B
If
you
can
write
the
best
line
of
code
or
if
you
can
make
the
best
architectural
decision
you
can
have
just
as
much
leverage
in
that
decision
as
you
would
managing
people
and
we
want
to
incentivize
people
to
if
that's
what
you're
really
passionate
about.
If
that's
what
you
want
to
do,
we
have
the
positions
to
to
do
that
and
but
what's
interesting
I
think,
should
become
a
topic
for
this
group.
Is
it's
it's,
I
think
more
difficult
than
it
sounds
right.
You
you
say:
okay!
B
Well,
maybe
one
of
the
reasons
you
go
down
there
is
well.
I
don't
want
to
deal
with
messy
people.
Problems.
Management
really
isn't
for
me.
So
I'll
go
down
this
kind
of
other
path,
but
then
you
find
that
well,
it's
not
writing
code
all
day
long!
It's
it's
something
different
than
that,
and
also
you
find
yourself
in
a
position
where
maybe
you've
got
to
convince
100
or
500
engineers
that
some
new
architectural
pattern
is
the
one
to
follow.
But
you
don't
manage
them,
and
so
you
cannot
tell
them
what
to
do.
B
Not
the
manager
should
be
telling
people
what
to
do,
but
you
end
up
having
to
use
a
lot
of
soft
skills
and
communication
skills
and
things
that
are
traditionally
thought
of
as
like
managerial
techniques,
and
so
it's
it's
hard
to
sort
of
wield
that
wield
that
influence
and
and
be
effective
as
a
senior
individual
contributor.
So
I'm
interested
to
get
the
opinions
of
everybody.
We've
got
in
the
call
I
see
andrew
and
jerry
and
felipe
and
others
to
share
how
they
how
they
make
these
things
happen.
C
Up
engineering
leadership
at
gitlab,
but
one
of
the
themes
that
that
I
notice
a
lot
is,
is
communication
and
so
speaking,
to
a
lot
of
people
throughout
the
organization
or
throughout
your
part
of
the
organization,
at
least
whether
they
be
individual
contributors
or
managers
or
people
from
different
teams,
and
then
picking
up
themes
and
and
hearing
the
same
problem
over
and
over
and
over
and
then
integrating
that
into
kind
of
a
narrative.
And
then
passing
that
narrative
back
to
to
the
teams
and
kind
of
building
up
consensus
about
the
way
forward.
C
And
often
what
you'll
hear
from
me
from
individuals
is
kind
of
like
they're
part
of
of
a
sort
of
bigger
problem
and
and
it's
about
listening
to
that
and
sort
of
integrating
all
of
those
different
parts
together
and
then
coming
up
with
the
narrative
and
then
coming
up
with
a
really
good
story
about
how
like.
If
everyone
pulls
in
the
same
direction,
you
can
make
it
better
for
everyone.
So
a
lot
of
it's
listening
and
communicating
and
then
building
up
that
story
and
then
sending
it
back.
B
I
love
andrew
that
you
highlighted
getting
people
on
the
same
page
as
the
problem,
because
what
I
said
was
more
kind
of
about
the
solution,
but
you're
absolutely
right.
If
people
don't
agree
with
the
problem,
is
you're
never
going
to
get
to
the
solution.
So
that's
that's
a
great
thing
to
highlight
as
a
first
step.
E
Thanks
so
like,
from
my
perspective,
it's
kind
of
like
rephrasing
what
andre
said,
but
also
from
slightly
different
perspectives
like
it's
also
about
the
fact
that
engineering
leadership
is
aware
of
a
much
bigger
scope
of
how
the
things
function
and
like
a
lot
of
people,
that
I,
for
example,
like
work
with
they.
They
are
more
focused
on
the
particular
item
and
with
my
heart
we
can
discuss
like
the
impact
of
the
of
their
work
guide
them
like
ask
them.
E
Questions
guide
them
like
through
that
complexity,
how
to
approach
who
to
approach
to
to
much
better
and
much
more
future
proof
solution
that
maybe
is
still
iterative,
but
has
like
much
better
fit
into
the
the
product
in
the
longer
term.
That
may
also
be
like
useful,
not
only
for
them,
but
also
for
other
teams
that
may
be
working
on
like
on
something
very
close
or
maybe
not
close,
or
maybe
they
are
not
yet
knowing
that
they
would
be
interested
for
someone.
A
D
Yeah,
that's
funny,
because
I
think
it's
going
to
complete
what
has
been
said
already
and
we
might
have
a
different
definition
of
what
an
engineer
ic
leader
might
be
at
gitlab.
So
for
myself
I
think
it's
more
about
anticipating
future
challenges
and
preparing
for
the
unknown
meaning.
I
always
have
this
eye
on
the
six
months
line.
Maybe
one
year
line,
maybe
two
year
line,
make
sure
making
sure
that
everything
that
we're
doing
today
will
still
be
relevant
in
this
future
and
we
are
still
following
the
right
direction.
D
So
it's
kind
of
keeping
an
eye
on
the
big
picture
and
making
sure
that
we
won't
be
in
a
position
in
the
future
where
we
are
going
to
miss
something
or
we
took
the
wrong
path,
and
we
would
need
to
to
to
change
that
right
away.
So
it's
yeah
it's
it's
mostly
that
anticipating
and
and
keeping
track
of
what
has
been
done
already
stats.
F
It's
it's
sort
of
the
interlinking
between
managers
and
technical
teams.
So
you
know,
managers
are
focused
on
getting
people
to
do
certain
things
and
making
sure
that
they're
they're
happy
doing
those
things,
and
so
sometimes
the
decisions
they
have
to
make
have
a
lot
of
moving
parts
that
are
technical
in
nature
and
they
don't
need
to
know
all
the
details.
F
So
that's,
I
think
one
aspect,
or
at
least
that's
probably
one
of
the
aspects
that
I
that
I
do
almost
every
day
and
then
the
other,
the
other
important
one
and
again
this
is
based
on
what
I'm
doing
right
now.
There
is
the
grounds
we're
trying
to
solve
now
are
getting
bigger
in
scope.
So
it's
it's
no
longer
a
single
team
or
a
single
team.
F
I've
used
this
terminology,
I
don't
know
how
popular
it
is,
but
I
know
politics
sounds
not
so
good,
but
I
do
think
politics
is
a
necessary
aspect
of
it
and,
and
that
really
is
just
about
kind
of
negotiating
your
way
through
hey.
This
is
really
important
on
that
side
of
the
organization,
and
I
know
you're
not
super
aware
of
it,
but
help
me
hear
her
and
then
later
on,
somebody's
like
hey,
I'm
having
this
problem,
and
I
really
need
your
part
of
the
organization
to
help
me
out.
F
So
you
also
act
as
that
glue
that
just
the
machine
is
engineered
in
a
certain
way,
but
sometimes
you
need
to
make
the
machine
do
things.
That
is
not
that
the
sort
of
the
the
normal
channels
is
not
one
line
to
do
so.
I
think
a
lot
of
us
spend
time
just
sort
of
making
sure
that
those
things
just
the
puzzle
fits
in
the
right
way
in
the
right
way.
B
The
way
I
think
of
politics
is
like
you
know,
nobody
likes
politics.
Politics
are
bad
if
you
kind
of
define
it
as
making
things
happen
through
sort
of
nefarious
means
like
being
non-transparent
or
lying
or
back
channeling,
or
something
like
that.
That's
bad,
but
I
think
what
you're
talking
about
is
like
I've
heard
it
said
like
being
politic
like
with
a
k
which
just
means
being
aware
of
your
surroundings
and
making
those
connections,
and
I
think
then
what
you
say
is
really
apt.
F
B
F
B
C
And-
and
it's
about
the
politic
that
we
do
that's
important,
I
think,
is
about
aligning
people
and
so
sometimes
there'll
be
an
initiative
that
needs
multiple
teams
and
they're
all
sort
of
seeing
it
from
a
slightly
different
angle.
And
then
they
they
sort
of
look
at
what
the
other
people
want
to
do
and
they're
like
no
that's
different.
We
want
to
do
something
different
and
it's
about
communicating
and
sort
of
aligning
everyone
a
little
bit,
and
then
people
work
much
better
together
when
they
all
realize
they're
pulling
in
the
same
direction.
C
B
So
there's
one
particular
story.
I
mean
we're
kind
of
going
to
like
the
second
bullet
at
the
in
the
agenda
at
this
point,
but
like
there's
a
story
that
sid
shares
send
me
frequently,
and
I
was
wanting
to
get
camille
to
talk
about
it
because
it
was
before
my
time.
But
the
way
I
understand
it
is
you
know.
B
Our
strategy
today
is
give
gitlab
is
a
single
application
for
the
devsecops
lifecycle,
but
back
in
the
day
it
was
just
source
control
and
there
was
a
separate
gitlab
ci
and
the
way
he
says
that
it
was
camille
that
really
advocated
hey.
This
should
be
in
the
same
application.
The
initial
reaction
was
no
and
then
but
camille
brought
it
up
again
and
again
and
again
and
finally
got
a
yes
and
now
that
was
the
first
step
down.
What
is
a
major
piece
of
our
strategy,
so
camille
I
was
wondering
when
is
that?
B
E
Probably
I
imagine
her
I'm
looking
for
the
efficiencies
and
it
seemed
like
the
most
efficient
thing
for
me
to
do.
I
like
to
to
persuade
so
I
think,
like
that,
also
about
the
engineering
leadership
is
like
to
fi
to
try
to
find
these
efficiencies
that
gonna
make
everyone
life
easier,
something
that
may
be
not
so
obvious,
maybe
not
so
that
you
would
do
like
on
the
on
the
first
try.
This
maybe
seem
dumb,
but
still
like
reason
about
that
and
try
to
and
try
to
execute
that
try
to
solve
like
the
benefits.
E
In
this
particular
case,
my
thinking
was,
like
I
mean
ci.
There
is
just
a
bunch
of
the
functions
like
show
like
information
about
the
beast,
but
there
is
so
much
other
stuff
that
it's
basically
the
same
authentication
commit
information
like
some
data.
What
what
you
saw,
what
changed,
but
like
all
of
that,
it's
like
it's
additional
effort
that
you
need
to
basically
implement
into
different
places.
So
this
particular
idea
came
out
of
the
efficiency
really
like.
E
I
saw
that
it
can
be
more
efficient
to
really
have
these
two
items
together
and
efficient
for
me
actually
to
work,
because
I
was
actually
doing
the
most
of
the
stuff.
So
I
was
considerate
about
my
efficiency
and
it
turned
out
also
be
pretty
efficient
for
github,
because
we
we
figure
out
that
we
don't
really
have
to
reinvent
the
wheel
so
many
times.
If
we
can
make
these
search
components,
we
truly
search
and
focus
on
providing
value.
On
top
of
that.
F
I
think
all
the
selves
have
been
able
to
self-prioritize
manage,
etc,
etc,
but
the
one
I
find
that
I
use
the
most
is
self-awareness
of.
I
know
there
are
areas
that
are
not
that
I'm
not
super
familiar
with,
but
I
made
it.
I
make
it
important
for
me
to
know
who
I
need
to
talk
to
about
that,
and
so
it's
kind
of
understanding
that
the
quality
of
the
organization
and
and
where
the
skills
are
for
me
to
ask
the
right
questions
to
be
able
to
put
a
whole
picture
together.
F
I
had
this
conversation
with
gregers
a
few
months
ago
of
whether
you
know
someone
who's
who's,
a
senior
ic
leader
should
be
kind
of
like
the
the
robocop
of
of
like
kind
of
like
the
neo
of
the
matrix
right.
I
can
just
do
anything,
and
my
prior
experience
in
in
sort
of
working
for
senior
ic
leaders
is
that
they
knew
enough
to
make
the
right
decisions,
but
they
weren't
the
people
that
could
sort
of
dismantle
the
the
entire
thing
and
and
know
where
every
where
every
nut
went.
F
A
C
Yeah,
I
think
it
sort
of
ties
into
to
jerry's
answer,
but
I
think
one
of
the
attributes
that
really
helps
a
lot
is
being
inquisitive
and
that's
actually
why
I
love
getting
on
incident.
Calls
is
because
there's
always
a
thousand
things
that
I
don't
know
anything
about,
and
it
really
helps
me
to
learn
some
more
of
the
application
and
I
don't
think
you
have
to
like
know
everything.
C
But
you
know
when
something
happens,
just
going
down
that
rabbit
hole
for
a
little
while
and
then
coming
back
out
kind
of
gives
you
this
like
wide
idea
of
what's
happening
throughout
the
application,
and
you
can
only
really
get
that
by
being
inquisitive
and
kind
of
deep,
diving
every
now
and
again
and
then
coming
back
up
for
air.
So
I
think
really
having
that.
Inquisitiveness
helps
a
lot.
A
A
So
I'm
curious,
you
know
why
would
someone
choose
down
to
choose
to
go
down
this
path,
as
opposed
to
just
general
engineering
management?
You
know
I
was
looking
at
the
engineering
ic
page
and
I
was
asking
myself
that
question.
You
know
what
what
are
the
benefits
of
having
a
career
in
icy
leadership.
D
It's
mostly
about
growing
the
others
I
would
say,
but
if
you
want
to
do
that,
you
can
just
rely
on
your
previous
experiences
and
skill,
and
that
means
for
a
senior.
I
see
always
keeping
an
eye
on
everything
that
would
be
new.
That
would
be
helpful
in
the
way
that
we
are
developing
software,
so
everything
that
we
touch
technologies,
methods,
processes
and
all
that
kind
of
things.
So
it's
not
only
about
shipping
new
software
shipping
new
code.
D
D
F
One
of
the
first
things
I
did
was
to
sit
really
close
to
andrew,
and
I
was
I
was
running,
the
management
hat
and
he
was
sort
of
the
not
sort
of
he
was
the
technical
leader
within
infrastructure,
and
so
that
becomes
a
very
powerful
partnership
because
I'm
focused
on
solving
management
problems.
But
then
I
have
someone
who
can
speak
to
the
technical
challenges
so
that
at
least
especially
initially
helped
me
tremendously
to
sort
of
make
certain
decision
of
we're
going
to
prioritize
this.
F
So
we're
going
to
do
that
so
and
then
the
mentoring
aspects
of
it.
I'm
a
huge
believer
in
paid
forward.
I've
been
blessed
with
a
number
of
people
in
my
career
that
have
helped
me
progress,
and
so
now
it's
it's.
I
try
to
do
that
with
other
folks,
so
I
I
do
spend
a
significant
or
I
do
invest
a
significant
amount
of
time
and
just
having
coffee,
chats
or
mentoring,
chats
or
whatever.
We
want
to
call
it
with
other
folks.
E
So,
actually
like
what
I
find
like
the
most
funny
way,
it's
something
that
may
be
actually
counterproductive.
It's
context,
switching
I'm
like
through
the
week.
I
am
exposed
to
so
many
different
discussions
and
like
problems
that
are
facing
that
it's
actually
amazing
learning
opportunity
for
me,
but
also
it's
amazing
leverage
opportunity
for
me,
because
I
can
work
with
so
much.
E
Because
of
that,
because
because
we
had
opportunity
to
work
together
on
something
that
was
way
beyond
like
the
scope
of
like
the
single
group,
or
maybe
it
involved
many
different
teams
or
many
different
groups
in
organizations.
So
I
think
for
me,
like
the
biggest
benefit,
is
context
switching
and
like
the
leverage
that
you
can
get
out
of
that
really,
especially
in
teaching
others
on
being
effective
in
that
because
usually
context
which
is
pretty
severe
in
being
productive.
C
Yeah,
I
think
it's
sort
of
everyone
else
has
touched
on
this,
and-
and
this
for
me
is
one
of
the
benefits
is-
is
in
my
own
way,
I'm
very
much
a
people
person
and
I
love
building
up
relationships
with
different
people
who
have
different
jobs
and
in
this
role
it's
that's
one
of
the
things
that
I
love
is.
Is
you
know
I
talk
to
tams.
C
I
talk
to
customers,
I
talk
to
to
people
in
all
sorts
of
different
parts
of
the
organization
and-
and
I
really
enjoy
that-
and
I
like
building
up
those
relationships
and
one
day
when
we
get
to
have
a
summit
again,
it'll
be
really
great
to
to
see
everyone
face
to
face
and
kind
of
have
met
a
lot
of
these
people
in
in
different
roles
and
and
I
enjoyed
that
that's
definitely
one
of
the
benefits
of
of
being
a
senior.
I
see
to
me.
A
Great
yeah,
those
are
those
are
a
lot
of
great
points
and
I
think
there's
there's
a
lot.
We
can
extract
there
and
include
on
the
page.
You
know
I'm
curious
too.
You
know.
One
thing
I
saw
was
that
you
know
being
technically
credible
is
obviously
a
key
attribute
of
engineering.
Ic
leadership,
but
you
know
another
thread
that
was
brought
up
was
characteristics
around
technical
leverage
and
what
that
really
means
for
ic
leaders.
So
I'm
curious,
you
know
what
what
what
are
the?
B
Yeah
and
thanks
for
asking
this
josh,
because
you're
you're
sort
of
looking
at
our
handbook
with
fresh
eyes,
and
so
if
we
haven't
made
this
clear,
we
could
probably
update
this
and
and
the
technical
leverage
one
is
kind
of
a
new
one,
so
we're
still
kind
of
feeling
this
one
out.
So
I
I
think,
there's
sort
of
two
things
in
their
technical
credibility
to
me
is
you
know
like
for
managers.
We
say
you
know
work
on
small
features
bugs
but
stay
out
of
the
critical
path.
B
That's
for
the
the
ics
who
do
it
all
day
every
day.
That's
that's
sort
of
our
bar
for
technical
credibility
for
managers
and
we
have
a
functional
org.
So
we
want
managers.
You
know
that
manage
backend
engineers
or
ux
managers
to
be
former
ics
in
that
area.
I
think
the
technical
credibility
bar
is
higher
for
senior
ics,
where
they
are
doing
they're
spending
more
time
on
this
stuff,
and
maybe
they
were
the
the
best
engineer
in
their
team
before
they
were
promoted
into
this
position,
but
it's
it's
certainly
higher
than
the
management
bar.
B
E
I'm
actually,
probably
like
one
thing
that
I
learned
a
lot
from
seed
working
in
this
company,
like
don't
be
afraid
of
doing
iteration
and
making
mistakes
like
the
smaller
iteration
you
make.
Even
if
you
make
a
mistake,
it's
much
easier
like
to
correct
that,
because
you
make
very
small
iteration,
and
I
think
that
this
is
out
of
the
technical
leverage.
This
is
something
that
I
also
try
to
like
convey
in
everything
that
I
do
and
with
every
room
that
I
work
with.
E
B
Yeah,
that's
interesting.
I
hadn't
thought
of
that,
but
you're
right
so
for
people
that
are
watching
this
video
iteration
is
one
of
our
core
values.
To
me,
it's
certainly
the
most
counter-intuitive
one
the
hardest
one
for
people
to
learn,
and
it
sounds
like
what
you're
saying
there
is
that
our
our
ic
leaders
have
a
role
in
helping
other
engineers
understand
about
how
to
make
things
small
so
like
I'd
say
like
iteration,
for
us
is
kind
of
a
meta
strategy.
It's
like
even
we
don't
know
what
to
do.
B
We'll
just
do
a
series
of
small
things
and
we'll
kind
of
navigate
our
way
to
the
solution
over
time
or
it's
one
way
to
say
it
is
like.
We
never
make
big
mistakes
because
we
never
do
big
things.
We
make
small
mistakes
all
the
time,
but
you
can
recover
from
small
mistakes
and
as
long
as
you
have
kind
of
a
north
star
like
an
idea
of
where
you
need
to
go,
you
can
iterate
your
way
there.
B
So
that's
really
interesting
that
that,
and
maybe
we
should
highlight
that
more-
that
we
really
expect
our
our
senior
technical
leaders
to
be
helping.
Others
who
join
the
organization
learn
what
what
iteration
means,
because
I
think
people
that
have
been
here
a
while
like
sid,
runs
iteration
office
hours
or
all
of
you,
I've
seen
you
do
it.
Someone
thinks
they've
got
something,
that's
as
small
as
it
can
possibly
be,
and
one
of
you
looks
at
it
and
sure
enough.
B
You
can
strip
80
out
of
it,
and
it's
just
it's
hard
for
people
to
do
that.
It's
it's
a
different
way
than
other
companies
work
where
you
try
to
kind
of
like
hit
the
target
the
first
time,
but
it
takes
forever
and
usually
you
miss
miss
anyway,
and
we
don't.
We
don't
do
that.
But
very
few
people
join
with
what
I
would
say
is
get
lab
level
instincts
of
iteration
and
has
to
be
sort
of
learned
here
over
time.
E
Yes,
so
I
think,
like
the
most
important
aspect
of
that
is
like
understanding
the
implications
of
the
things
that
you
do,
because,
like
the
wrong
change,
would
be
the
one
that
you
are
making
that
you
don't
know
what
you
are
making
and
you
don't
understand
the
risk
associated
with
it
so
kind
of
like
rephrasing.
Under
your
comment
like
as
long
as
you
are
making
a
change,
you
understand
the
implications
of
doing
that
children.
You
understand.
Like
the
recovery
scenario,
I
mean
two-way
door
decision
really,
this
kind
of
thing
it's
actually
the
right
iteration.
C
Yeah
that
I
mean
that's,
you
know
a
lot
of
the
time.
People
come
to
you
with
with
the
with
the
iterative
process
and-
and
I
think
especially
infrastructure,
like
you
say,
there's
a
lot
of
risk
that
can
break
things
in
bad
ways.
It's
it's
taking
the
way
that
people
might
be
iterating
and
maybe
explaining
some
a
different
way
of
doing
the
same
thing,
but
doing
it
in
a
more
risk,
not
risk
averse,
because
you're
not
looking
to
totally
mitigate
risk,
but
do
it
in
a
way
exactly
like,
but
in
a
safer.
C
Exactly
like
we
don't,
we
don't
want
to
be
totally
risk-averse,
but
we
want
to
do
it
in
a
safer
way
and
and
in
a
reversible
way.
So
we
can
make
small
incremental
changes
that
we
can
measure
and
then,
if
we
realize
that
one
of
those
steps
has
gone
wrong,
we
can
roll
it
back
and
like
reconsider.
At
that
point,
and
I
think
a
lot
of
the
experience
that
we
bring
is
is
kind
of
bringing
people
around
to
to
iterating
in
a
in
a
safer
way.
F
It
didn't
dive
super
well
with
infrastructures,
sort
of
scheduling,
but
in
the
end
we
decided
no
we're
going
to
do
this,
because
if
we
hit
the
target
that
product
is
asking
for
and
that
development
wants,
then
it
benefits
everybody
and
the
benefit.
You
know
product
gets
what
they
want
and
then
development
doesn't
have
to
support
an
older
version
of
postgres
and
the
benefit
for
infrastructure
is
if
they're
working
on
addressing
you
know.
F
If
they're
not
spending
cycles
supporting
an
older
version
of
progress,
then
of
postgres,
then
that
means
they're
supporting
new
features
or
supporting
problems
that
are
hurting
gitlab.com,
so
being
able
to
bring
those
three
views
into
play.
Then
it's
how
essentially
you
go
back
to
management
and
say
this
is
a
win-win-win
for
everybody
and
we
should
rearrange
things
to
make
it
happen.
I
think
most
of
the
time
managers
have
more
of
a
a
more
vertical.
E
F
Things
even
though
they
they
do
talk
to
each
other,
but
for
the
senior
ics,
we're
always
sort
of
walking
around
the
entire
field.
So
it's
kind
of
easier,
sometimes
for
us
to
sort
of
see
this
angles
and
then
go
back
to
the
mana
to
the
different
management
layers
and
say
we
should
sort
of
change
direction
to
get
these
things
done,
so
that
the
thing
that
and
it
sort
of
goes
into
the
point
under
was
making
was
risk
mitigation
and
striking
that
balance
between
move
forward.
E
C
I
wrote
this
down
you've
sort
of
touched
on
it
already,
but
I'll
I'll
state
it
again.
I
think
a
lot
of
the
stuff
that
we
deal
with
is
is
is
horizontal
where,
especially
at
gitlab,
it
is
quite
a
vertical
organization
right.
The
way
that
product
and
stage
groups
and
ux
and
and
the
development
teams
all
focused
is
is
quite
horizontal
and
then
you'll
have
problems
like
how
to
get
puma
to
to
reboot
and
it's
a
very,
very
important
problem.
But
it's
very
much
a
horizontal
problem.
D
D
So
that's
that's
the
danger
of
iteration
to
me.
That's
that's
a
great
tool
if
you
know
how
to
use
it,
but
if
you
use
it
the
wrong
way,
you
can
spend
iterations
over
iterations
doing
the
wrong
thing,
whereas
you
can
do
something
that
would
be
much
more.
Simpler
would
solve
the
problem
like
right
away
just
thinking
out
of
the
box,
and
that's
that's
where
the
ic
leadership
is
extremely
important
in
a
an
organization
like
gitlab,
just
to
remind
people
that
there
are
other
ways
to
solve
problems.
D
I
can
come
with
some
example:
some
real
example
and
that
that's
probably
going
to
to
be
beyond
the
scope
of
this
this
meeting,
but
when
we
joined
the
company
with
my
team
that
was,
after
the
gymnasium
acquisition,
the
obvious
way
to
integrate.
Gymnasium,
which
was
a
sas
to
detect,
detect
software
dependencies
and
especially
security
issues
in
these
dependencies.
D
The
obvious
way
was
to
port
everything
that
we
add
to
a
new
service
that
would
be
integrated
into
gitlab.
I
mean,
if
you
ask
anyone
in
the
in
the
product
organization
that
will
tell
you
that
okay,
we
need
a
new
service.
We
need
to
run
that
we
need
a
new
ui
to
interpret
all
of
this,
and
maybe
by
the
next
six
months
from
now,
we
will
have
something
running
and
we
will
be
able
to
ship
something
to
the
customers
and
we
did
exactly
the
opposite.
D
D
What
is
the
minimal
set
of
features
that
we
can
take
and
export
so
that
we
can
have
something
in
the
next
iteration
and
sid
was
extremely,
I
would
say,
cautious
with
a
with
our
thinking
back
in
the
time
when
we
said
we're
going
to
have
something
raining
in
a
month
and
just
by
thinking
out
of
the
box,
not
porting,
that
to
a
service
but
leveraging
the
pipelines
and
and
docker
images
and
all
kinds
of
things
we
managed
to
have
something
up
and
running
one
iteration
later
and
the
iteration.
After
that
there
was
more
features.
D
There
was
more
more
services
that
we
were
able
to
fulfill
so
that
that
that
was
an
example
of
okay.
Just
don't
blindly,
all
the
time
follow
the
direction
that
someone
would
give
you
that's
where
the
ic
leadership
is,
is
supposed
to
just
step
back
a
bit
and
make
sure
that
we're
taking
the
right
decisions,
we're
heading
in
the
right
way
and
we
are
using
the
right
tools,
and
I
see
that
really
really
often,
we
think
that's
if
we
want
to
solve
that
problem,
there's
only
this
direction
and
sometimes
yeah
another
example
would
be.
D
For
example,
we
need
no
part
of
the
security
sub
department.
I
switched
from
the
the
development
department
recently
and
in
the
security
asset
department.
We
need
to
update,
for
example,
the
severities
of
the
vulnerabilities
that
that
are
found
by
the
the
secure
products
the
the
obvious
way
to
do,
that
is
to
create
a
new
api
endpoint
and
something
new
in
the
ui,
so
that
you
can
change
the
stability
and
you
can
update
that
and
that's
that's
a
complete
workflow
that
could
take
three
iterations
now
at
gitlab.
D
So
that's
very
long,
and
sometimes
we
just
don't
have
time
to
to
wait
for
this
kind
of
iterative
work
and
we
just
came
up
with
something
that
was
extremely
simple.
We
were
dealing
with
the
reports
directly
in
the
pipeline
and
just
by
putting
all
the
the
results
of
these
reports
into
jqm
and
tweaking
the
the
output
of
the
report
and
generating
another
report.
That
would
be
the
final
report.
D
It's
it's
a
different
way
to
do
things,
and
we
should
strive
to
do
things
in
in
this
simple
way
all
the
time,
instead
of
trying
to
solve
all
the
problems
at
once
and
trying
to
make
everyone
happy,
this
is
never
going
to
be
the
case.
There's
no
way
we
can
come
up
with
something
that
will
make
our
our
customers
happy,
at
least
in
in
the
first
hit,
or
of
the
two
first
iterations.
B
Yeah,
so
if
we,
when
you
first
started
talking,
I
was
like
oh
we're
gonna
get
far
afield
of
the
topic,
but
you
you
brought
it
back
and
I
think
there's
something
really
interesting
there
so
like.
If
I
could
use
an
analogy
and
kind
of
restate
what
you
said
at
my
last
company,
we
did
a
lot
of
machine
learning
projects
and
some
of
them
were
those
were
generative
algorithms
or
like
darwinian
algorithms.
B
So
they
generate
versions
of
themselves
and
you
can
think
of
like
a
2d
problem
space
and
then
there's
a
boundary
in
there,
which
is
like
the
theoretical
limit
of
efficiency
for
any
one
of
these
algorithms.
When
you're
iterating,
you
can
find
yourself
in
what's
called
like
a
local
minimum,
and
you
can't
get
any
more
efficient
that
doesn't
matter
how
many
generations
you
keep
generating
things.
You
try
you're
sort
of
stuck
in
this
little
valley
and
the
way
you
the
way
one
of
the
ways
my
team
there
got
around
these
problems.
B
Is
you
add
a
stochastic
component
to
that
generation
process.
This
sort
of
randomly
jumps
to
a
new
part
of
the
problem
space
and,
if
you're
at
a
different
part
of
that
limit.
Suddenly
you
find
oh,
I
can
optimize
a
lot
more
and
you
can
get
down
to
a
more
efficient
state,
and
so
if
I
were
to
translate
that
to
kind
of
like
what
you
said
and
this
sort
of
organizational
problem
solving,
sometimes
when
we
iterate
we
get
stuck
in
that
sort
of
local
minimum
and
maybe
we're
missing
an
opportunity
to
do
something
dramatically
more
simple.
B
And
so
you
have
to
do
something
larger
than
our
normal
iteration
to
kind
of
get
there.
And
that's
where
we
rely
on
the
our
senior
ic
leaders.
But
it's
not
a
sarcastic
random
process
right.
We're
relying
on
your
instincts
and
your
vision
to
say:
we've
got
to
get
out
of
this
local
minimum.
We've
got
to
go
way
over
here,
but
we're
going
to
do
it
in
one
iteration
and
then
we're
going
to
have
all
this
ground
or
problem
space
in
front
of
us.
B
So
we
can
keep
iterating
so,
like
you
said,
standing
back
kind
of
understanding
the
whole
problem
space
and
recommending
when,
like
look
we're
stuck,
we've
got
to
do
something
that
we
feel
a
little
bit
uncomfortable
with
and
go
way
over
here.
But
then
you
know
when
it's
when
it's
the
right
decision.
We
take
that
risk.
We
find
ourselves
in
a
sort
of
the
a
lot
more
area
to
kind
of
go
forward
and
improve.
A
Absolutely
those
are
those
are
great
points
and
I
and
I
want
to
be
sensitive
to
time
here.
So
just
really
quick.
You
know
on
the
on
the
four
archetypes,
you
know
the
tech
lead
architect,
solver
and
right
hand
that
are
outlined
on
the
page.
You
know
how
do
those
influence
the
work
of
ic
leadership
and
maybe
influence
is
it
is
not
the
right
word
there?
Maybe
it's
more
defined.
D
Yeah
that
that's
my
comment,
I'm
not
sure
the
influence
of
work
they
kind
of
define
the
work
of
ic
leadership.
We
are
always
switching
between
the
four,
depending
on
the
task
that
we're
working
on
and
that's
also
the
beauty
of
ic
leadership.
You
have
different
hats
and
yeah.
That's
that's!
A
constant
consist
complex,
switch
jerry.
You
want
to
speak
to
that.
E
A
F
B
It
to
me
it's
sort
of
an
indicator
that
there's
actually
a
tremendous
amount
of
latitude
for
people
on
that
senior
ic
track
about
how
they're
effective,
probably
more
so
honestly,
in
management
I
mean
there's
so
much
stuff.
We
do
in
management,
that's
sort
of
standardized,
you
get
to
make
a
lot
of
decisions,
but
it's
it's
oftentimes,
quite
framed
how
you
do
that,
but
at
the
end
of
the
day,
the
people
that
are
making
the
right
decisions
that
are
getting
results
and
the
ic
track.
E
For
example,
I
know
that
gary
is
more
like
the
type
of
person
type
of
person
that
tries
to
like
to
join
many
people,
where
I'm
more
like
into
trying
to
solve
like
these
engineering
challenges
that
are
being
thrown
like
from
different
places.
So
I
think
it's
important
to
like
understand
around
you,
how
you
can
leverage
other
people
which
includes
management,
other
ic
leaderships,
other
ics
and
basically
everyone
to
focus
on
like
something
that
it's
like
the
most
effective.
E
C
Yeah
I
I
really
like
that
point
camille,
like
I
think,
when
I
think
of
the
senior
ics
they're,
all
so
different,
and
if
I
need
to
engage
with
people,
I
kind
of
figure
out
what
the
problem
is
and
then
I
almost
know
who
the
right
person
to
go
to
is
because
everyone
has
a
unique
set
of
of
the
way
they
work
and
a
unique
set
of
skills.
And
so
it's
almost
pretty
obvious
who
the
person
to
speak
to
is
because
they're
all.
B
F
F
A
Yeah,
no,
these
are
great
points
and
I
think
there's
a
lot
of
value
in
having
conversations
like
this
and
bringing
you
all
together
to
discuss
these.
You
know
topics,
so
I
think
we
should
try
to
schedule
another
one
in
the
future
on
another
engineering
topic.
That's
you
know
near
and
dear
to
your
all's
heart,
but
I
I
got
a
ton
of
value
out
of
this
and
I
know
everybody
else
watching
well
as
well.
So
if
there's
anything
else,
you'd
like
to
share
feel
free
to,
but
we
are
at
time.