►
From YouTube: TT102: People of Technology
Description
This is a Tanuki Tech session on 7/26/2021.
For more on Tanuki Tech, see here: https://about.gitlab.com/handbook/marketing/revenue-marketing/sdr/tanuki-tech/
For more on the speaker, see here: https://www.linkedin.com/in/christopher-wang-0835b226/
===
"Sales Stories" is a podcast where we spotlight sales leaders and share their stories and career advice. "Sales Stories" is part of the instructional materials for Tanuki Tech.
For more on Tanuki Tech, see here: https://about.gitlab.com/handbook/marketing/revenue-marketing/sdr/tanuki-tech/
For more on Christopher Wang, see here: https://www.linkedin.com/in/christopher-wang-0835b226/
A
A
How
we're
going
to
do
this
is
we
need
to
talk
about
the
different
types
of
people
that
we'll
be
speaking
with
we'll
explore
what
they
care
about,
what
their
desires
are
and
we'll
figure
out
how
we
can
tailor
our
approach
to
maximize
success
with
each
type
of
audience,
and
so
for
those
of
y'all
that
aren't
as
familiar
with
they
call
this
entire
thing:
persona
based
messaging
right.
A
The
basic
idea
is
that
we
have
to
go
tailor
our
approach
and
our
messaging,
depending
on
who
we're
talking
to
and
as
a
great
example
of
that
on
a
basic
level.
If
I'm
working
with
children
like
in
a
volunteer
capacity,
which
I
do
then
I'm
going
to
treat
that
individual
very
differently
than
if
I'm
talking
to
an
adult
right,
so
my
body
language
will
be
different.
My
language
itself
will
be
different.
The
things
that
I
say
will
be
different
and
so
on
and
so
forth,
and
this
is
the
exact
same
thing
with
sales.
A
So
this
is
also
compounded
by
the
fact
that
get
lab
is
extremely
broad
and
what
I
mean
by
that
is,
we
actually
have
different
use
cases
that
are
important
for
different
types
of
people
in
different
roles.
So
what
I
mean
by
that
is,
if
you're
speaking
to
a
director
who's
in
charge
of
development,
the
pieces
and
functionality
of
our
product
that
would
resonate
with
this
person
would
be
different
than
if
you're
talking
to
a
director
of
security,
and
so
because
gitlab
does
so
many
different
things.
A
A
So
one
thing
that
I
want
to
say
is
they're
more
influential
with
title
you're
not
going
to
get
one
of
these
like
tool,
selection
projects
unless
you're
senior
or
principal
level
or
a
team
lead,
and
the
other
thing
is
that
as
organizations
expand
out,
these
people
generally
have
less
influence.
A
And
so,
if
you're
prospecting
into
a
large
enterprise
organization
or
public
sector,
then
you're
going
to
have
less
luck
targeting
a
lot
of
these
technical,
individual
contributors,
what
they
do
on
a
day-to-day
basis,
they're
responsible
for
technical
implementation
of
projects
so
developing
a
new
website
making
it
faster,
making
it
more
secure-
and
the
last
thing
I
want
to
talk
about
is
that
there's
many
different
types.
A
So
I'm
going
to
give
you
an
example
of
this.
If
you
ever
want
to
know
what
engineers
think
about
some
sort
of
technology
or
tool,
you
can
just
check
out
what
they're
saying
on
reddit,
because
this
is
one
of
the
places
in
which
technical,
individual
contributors,
they
just
discuss
technology
and
so
over.
Here,
there's
an
actual
article
someone's
asking
a
question
about
this
thing:
called
devsecops
and
the
engineers
are
actually
making
fun
of
the
marketing
language
that
people
are
using
right.
So
basically,
what
they're
saying
is
that
this
stuff
is
nonsense.
A
Like
I
hate
this
language,
this
is
ridiculous,
that
people
are
saying
this
in
the
first
place.
So
that's
why
it's
really
really
really
important
to
be
aware
of
the
language
that
we're
using.
I
completely
use
a
different
set
of
language
if
I'm
talking
to
a
technical,
individual
contributor
versus
someone
who's
in
business
leadership.
A
So
that
being
said,
one
of
the
great
things
that
we
can
do
to
take
advantage
and
engage
them
more
is
the
fact
that,
because
these
people
are
responsible
for
technical
implementation,
they're
generally
really
into
learning
right,
they
love
learning
about
the
newest
thing
in
technology
a
lot
of
times.
People
in
these
technical,
individual
contributor
roles,
they're
very
excited
about
technology.
A
They
love
learning
new
things,
and
so,
if
we
take
a
more
of
a
consultative
approach
where
we're
teaching
them
about
new
trends
and
new
capabilities
and
new
features,
and
that's
a
really
great
way
in
which
we
can
engage
them,
the
last
tip
that
I
have
is
try
to
talk
to
them
using
their
own
language.
So
we're
not
pretending
to
be
engineers
here.
But
what
I
mean
by
this
is
that
I'm
not
going
to
use
business
talk
like
return
on
investment,
our
time
to
value
our
things
like
that
with
a
technical,
individual
contributor.
A
So
this
is
a
chart
that
I
really
want
you
to
internalize
and
it
has
to
do
with
how
I
tailor
my
language
and
the
assets
that
I
give
out,
depending
on
whom
I'm
talking
to.
If
I'm
talking
to
a
technical,
individual
contributor,
I
really
want
to
paint
in
their
mind
that
there's
exciting
new
ways
that
you
can
do
things
that's
going
to
improve
your
life
and
that
git
lab
has
many
of
these
features
built
in.
A
If
I
ever
stand
out
a
case
study,
then
it's
going
to
be
around
things
like
speed
and
efficiency,
but
what
I'm
not
going
to
talk
about?
Is
I'm
not
going
to
talk
about
some
of
these
things
that
you'd
hear
in
a
business
class
so
like
return
on
investment
time
to
value
culture
or
stuff
like
that
in
terms
of
the
assets,
I
really
want
them
to
understand
and
see
our
product
in
action
and
how
it
can
basically
make
their
lives
easier.
A
One
thing
that
I
want
to
talk
about
is
this
is
a
really
great
sales
book.
If
you
haven't
read
it
in
the
past,
but
one
of
the
things
about
many
technical,
individual
contributors
is
that
a
lot
of
times
they
have
they're,
really
excited
about
learning
new
technology
and
if
we
can
teach
them
something
new
and
then
they're
going
to
be
really
likely
to
engage
with
us
and
so
talking
about
new,
exciting
ways
of
doing
something,
new,
exciting
practices.
A
This
is
a
great
way
to
get
engagement
with
technical,
individual
contributors.
So
I
alluded
to
this
earlier,
because
our
product
is
so
deep.
It's
really
important
to
talk
about
features
and
capabilities
that
match
the
audience
that
you're
speaking
with
and
in
general.
What
I
want
to
talk
about
over
here
in
this
chart
is
the
fact
that
there's
different
types
of
engineers
and
they
care
about
different
parts
of
our
product,
so
I'm
not
going
to
go
over
this
slide
from
from
different
types
of
engineers
and
what
falls
under
their
responsibilities.
A
So
now
that
we've
talked
about
technical,
individual
contributors,
I
want
to
start
and
move
to
how
to
engage
leadership.
And
so
this
is
where
we're
going
to
have
a
lot
more
success
in
terms
of
getting
those
sales
accepted
opportunities,
because
these
are
the
people
who
are
the
ultimate
decision
makers.
A
And
so
one
of
the
things
that
we
need
to
start
out
with
is
agreeing
on
definitions
right,
and
so
someone
with
the
title
of
director
is
going
to
be
very
different
in
a
large
enterprise
company
versus
a
company,
that's
just
starting
out
and
maybe
have
10
employees.
And
so
that's
why
I
have
this
picture
of
a
cake
here.
A
As
the
organization
gets
bigger,
then
there's
more
and
more
and
more
levels.
So
what
I
mean
by
that
is
sea
level,
then
senior
vice
president
and
then
regular
vice
president
and
then
senior
director,
regular
director
assistant
director,
so
on
and
so
forth,
and
there's
going
to
be
basically
more
layers
to
the
cake
for
a
smaller
company
like
small,
medium
business.
When
I
worked
for
a
tech
startup
about
40
percent
of
all
of
the
employees
had
a
directory
level
or
higher,
and
so
that's
just
something
that
keep
in
mind,
but
in
these
next
couple
of
slides.
A
Really.
What
I'm
talking
about
is
this
set
of
definitions
for
titles,
so
this
is
really
a
set
of
definitions
that
comes
from
primarily
the
enterprise
and
public
sector.
What
I
mean
by
this
is
that
someone
with
the
title
manager-
these
are
the
people
responsible
for
managing
a
team
of
technical,
individual
contributors.
A
A
director
is
someone
who's
going
to
be
managing,
maybe
five
to
six
managers,
a
vp
typically
manages
maybe
four
or
five
different
directors,
and
then
c-level
is
going
to
manage
an
entire
business
unit.
So
chief
marketing
officer,
chief,
like
engineering
officer,
our
chief
technology
officer
yeah,
so
there's
not
typically
a
chief
engineering
officer,
more
cto,
so
on
and
so
forth.
A
But
that
being
said,
these
roles
they
vary
and
then
so
sometimes
businesses
do
them
differently.
And
the
other
takeaway
point
is
that
as
your
company
gets
smaller,
then
your
director
really
could
not
have
any
direct
reports
right.
It
could
just
be
a
director
who
is
really
an
individual
contributor,
all
right
so
just
talking
about
some
of
these
general
principles.
A
First
general
principle
I
want
to
illustrate
is
the
fact
that
you're
going
to
get
delegated
to
the
level
that
you
speak
to.
So
what
I
mean
by
that
is,
if
I
come
into
a
meeting
with
a
vp
level-
and
I
start
talking
about
all
these
really
granular
and
specific
technical
things,
because
this
vp
doesn't
work
with
a
lot
of
these
things
on
a
day-to-day
basis,
then
that
language
isn't
going
to
resonate
with
the
vp.
A
A
So
that's
why
it's
really
important
to
speak
to
the
appropriate
level
if
I'm
talking
to
c
level
or
vp,
I'm
talking
about
business
level,
goals
initiatives
I'm
talking
about
where
they
see
their
organization
going
in
the
next
two
to
three
years.
Some
of
the
challenges
that
they
have
with
their
competitors
and
what
I'm
seeing
in
their
industry
and
then
as
I
go
down
more
to
the
execution
level,
so
a
level
one
manager
level,
two
manager.
A
A
So
principle
number
one
you
get
delegated
to
the
level
that
you
speak
to.
The
other
thing
that
I
want
to
talk
about
is
sometimes
getting
delegated
down
is
okay
and
the
reason
why
is
because
we
actually
have
a
lot
of
success
when
we
get
delegated
down
and
just
imagine
it
from
the
business
perspective
right.
So
you
come
in.
You
get
a
meeting
with
a
vp.
A
The
vp
basically
says:
hey,
I'm
going
to
set
you
up
with
this
meeting
with
my
senior
manager
in
charge
of
devops,
and
now
that
senior
manager
is
going
to
be
really
really
really
because
it's
a
project,
an
assignment
given
from
the
vp,
the
senior
manager,
is
going
to
accept
your
meeting
and
he
or
she
is
going
to
be
interested
in
hearing
what
you
have
to
say,
and
so
we've
actually
had
good
success
after
we
get
delegated
down
to
different
to
like
delegate
it
down.
A
We
talked
about
tailoring
your
approach
and
so
just
to
re-summarize.
A
What
I
mean
by
this,
if
I'm
talking
to
someone
on
the
executive
level,
I'm
going
to
be
focused
on
the
business,
if
I'm
talking
to
someone
who's
on
the
implementation
level,
so
a
manager
level,
2
manager,
even
a
director,
then
I'm
gonna
talk
about
git
lab
what
they're
trying
to
do
and
how
we
can
enhance
whatever
they're
trying
to
do.
Once
I
get
to
senior
director
level,
then
it's
gonna
be
more
of
a
mix
right.
A
A
If
you
hear
a
customer
trying
to
implement
something
like
microservices
and
add
like
and
into
their
organization,
then
if
we
have
a
great
analyst
report
about
get
lab
enhancing
microservices,
then
that's
definitely
going
to
resonate
with
them
and
once
again,
so
this
language
is
primarily
for
more
the
executive
level
and,
as
you
go
basically
to
those
tier
one
and
tier
two
managers,
it's
more
going
to
be
about
some
of
these
technical
implementation,
things
with
a
little
bit
of
business,
sprinkled
in
so
talking
a
little
bit
about
the
different
types
of
leaders
that
you're
going
to
be
interfacing
with
the
first
thing
that
I
want
to
talk
about
is
the
level
one
managers,
and
so
one
of
the
things
that
I
want
to
talk
about
is
the
fact
that
these
people
a
lot
of
times
they're
under
a
lot
of
pressure,
and
so
I'm
just
gonna
talk
about
this
one
report.
A
So
there's
an
organization
called
the
project
management
institute.
It
found
out
that
14
of
it
projects
fail
across
industry.
But
that
being
said
out
of
those
that
didn't
fail,
31
didn't
meet
their
goals,
43
exceeded
budget
and
49
were
laid,
and
so
it's
really
important
to
understand
that
when
we're
prospecting
out
into
some
of
these
leaders
that
are
responsible
for
technical
implementation,
then
one
of
the
biggest
fears
that
they
have
is
being
late
with
their
projects.
A
A
A
A
Well,
we're
starting
to
talk
with
the
director
level.
These
people
are
often
decision
makers
at
this
point,
so
they're
in
charge
of
a
good
amount
of
budget,
so
landing
at
the
director
level
is
where
we
see
a
lot
of
success
in
the
enterprise
in
the
united
states
and
in
europe
a
lot
of
times.
We
get
our
meetings
through
directors,
and
this
is
where
we
ultimately
get
credit
for
sales
accepted
opportunities.
A
So
my
trick
for
dealing
with
directors
is
it's
now
a
mix
of
technical
implementation
and
business
talk,
so
I'm
going
to
open
up
I'm
going
to
basically
ask
them
what
are
the
things
that
you're
trying
to
do
in
your
organization
from
a
technical
level?
What
are
some
of
the
things
that
are
required
for
you
to
implement
these
business
processes
and
then
now?
Let
me
help
to
explain
how
gitlab
can
help
too
for
you
to
achieve
some
of
these
things.
A
At
this
point
in
time,
you
often
still
have
like
a
director
of
engineering
director
of
security
director
of
devops,
and
so
it's
so
like
once
again
tailoring
our
approach
for
what
they're
responsible
for,
and
sometimes
there
may
not
be
a
director
of
devops
as
well,
but
we'll
talk
a
little
bit
more
about
that
later.
A
Finally,
about
senior
leadership,
so
bp
level
c
level
and
really
what
these
people
are
in
charge
of
is
making
sure
that
their
business
unit
is
competitive
and
ultimately
driving
business
value
for
their
internal
stakeholders,
as
well
as
their
external
stakeholders,
and
so
they
want
to
be
seen
as
a
value
driver
for
whatever
organization
they're
part
of
they
want
to
be
able
to
point
to
these
awesome
things
that
they're
doing
to
drive
success
for
their
business.
They
also
really
want
to
make
sure
that
they're
competitive
across
industry.
A
A
Other
things
is
that
they're,
definitely
the
budget
controllers
and
the
decision
makers
and
then
so.
My
approach
for
these
folk
is
how
can
get
lab
help.
You
to
transform
your
business,
what
are
the
things
that
you're
trying
to
do?
What
are
some
of
the
bottlenecks
in
your
organization
today?
A
How
does
git
lab
help
you
to
implement
best
practices
in
your
organization?
Also
things
like
cultural
changes,
so
a
lot
of
times,
you
may
hear
we're
a
very
siloed
organization.
We
have
too
many
silos
in
engineering
and
what
that
really
means
is
that
we
have
lots
and
lots
of
teams
and
they're
not
communicating
with
each
other,
because
they're
not
communicating
with
each
other,
people
are
reproducing
work,
they're,
missing
deadlines,
so
on
and
so
forth.
So
how
do
we
help
with
collaboration?
A
Agile
is
a
best
practice
for
businesses
around
the
world,
and
so
really
what
that
is
is
how
do
you
have
good
flows
for
work
in
your
organization,
so
over
here
is
an
example
of
of
one
of
the
issue
boards
that
we
offer
for
our
product
and
so
over.
Here
you
can
think
about
this
as
a
great
way
of
grouping
and
organizing
all
of
the
work
in
your
business.
A
So
every
single
thing
that
your
organization
is
working
on,
it's
one
of
these
tickets
or
issues
in
get
lab
and
as
people
start
working
on
it
and
you
can
see
that
their
little
icon
appears
on
it.
So
this
person's
now
been
assigned
a
leader
can
now
go
and
see
what
everyone's
working
on
at
any
given
point
in
time
and
who
is
responsible
for
implementing
each
of
these
things.
A
As
these
issues
get
done,
then
what
ends
up
happening
is
that
they
end
up
in
the
closed
column,
and
so
all
of
this
work
is
flowing.
These
issues
start
out
in
the
open
column,
and
then
they
move
to
the
right
into
the
closed,
follow
close
column
and
then
so
now,
if
you're,
a
business
leader,
you
have
a
visual
for
figuring
out,
what's
happening
in
the
flow
of
work
in
your
organization.
A
A
One
of
the
things
to
really
know
about
forget
lab
is
that
when
you're
in
software
development,
then
there's
all
sorts
of
little
small
things
that
you
have
to
do
that
are
oftentimes
manual,
and
so
all
of
this
stuff
is
slowing
you
down
a
lot
of
times.
It's
boring
and
so
get
lab.
Allows
these
engineering
groups
to
automate
a
lot
of
these
tasks
out,
to
save
you
time
and
ultimately
to
allow
you
to
become
more
efficient.
A
So
as
an
example,
here
is
an
example
of
our
automation
every
time.
So
let
me
actually
start
out
from
here
so
over
here,
one
of
our
developers
is
trying
to
implement
a
change
they're,
adding
in
all
this
green
text,
they're
removing
this
red
text
and
then
so.
This
is
basically
the
process
of
software
development,
they're
editing
these
code
files,
because
this
developer
is
trying
to
hand
in
new
work.
All
of
this
stuff
has
now
happened
in
an
automated
fashion.
A
There's
over
a
hundred
thousand
tests
that
were
run
as
part
of
this
code
submission
and
then
other
things
that
we
do
is
we
make
sure
that
this
code
is
secure,
so
we're
going
to
scan
it
for
security
vulnerabilities,
as
you
can
see
here,
and
let's
now
take
a
look
at
some
of
the
things
that
are
being
done
in
our
automation,
so
we're
preparing
an
environment
setting
things
up
other
things
that
software
build.
A
The
test
section
is
where
a
lot
of
the
value
of
our
automation
comes
in,
as
you
can
see,
there's
around
maybe
30
different,
individual
jobs
that
are
here
that
we're
testing
for
specific
things,
and
all
of
this
is
ensuring
that
our
customers
are
operating
efficiently
and
that
we're
saving
them
time.
So
all
in
all,
we've
probably
automated
around
50
to
60
different
things
as
part
of
this
get
lab
automation
and
once
again,
this
is
another
best
practice
of
having
automation
in
your
organization,
which
is
allow
you
to
become
more
efficient.
A
Let
me
give
you
an
example
of
that
so
over
here
in
these
issues
that
we
took
a
look
at
one
of
the
great
things
that
all
of
your
different
team
members
are
on.
The
same
platform
is
the
fact
that
you
can
have
better
cross-functional
collaboration.
A
A
This
allows
you
to
break
down
some
of
the
silos
in
your
organization
and
allows
you
to
basically
there's
a
lot
of
business
benefits
but
long
story.
In
short,
people
communicate
better
with
each
other
and
then
ultimately,
people
may
have
insights
that
help
out
other
people
that
they
weren't,
aware
of
because
we
have
this
better
cross,
functional
collaboration.
A
So
this
is
a
collaboration
in
the
issue
level.
When
people
are
handing
in
code
a
similar
thing
can
happen.
So
here's
a
code
submission
this.
This
engineer,
andrew
trying
to
add
in
these
green
lines
of
text,
take
out
these
red
lines
of
text
and
one
of
the
things
that
they're
really
doing
over
here
is.
We
could
have
better
cross-functional
collaboration
over
here.
We
could
have
developers
from
other
groups,
security
people
test
people
all
chiming
in
and
ultimately
this
is
going
to
allow
people
to
create
a
better
code
submission.
A
A
Then
it's
very
easy
for
me
to
see
what
each
business
unit
is
doing
in
our
organization
and
so
over
here,
even
a
group
like
sales
development,
it's
very
easy
for
me
to
see
what
everyone's
working
on
and
it's
easy
to
see
the
progress
that's
being
made,
and
so
I
can
go
filter
by
different
organizations.
I
could
filter
by
marketing.
I
could
filter
by
sales
operations,
human
human
resources,
but
it's
just
a
really
great
way
to
see
what
is
happening
in
each
organization,
because
we
are
one
shared
work
platform.
A
A
Last
thing
I
want
to
talk
about
is
process
flow
optimization.
So
this
is
what
we
call
value
stream
analytics,
and
so
what
value
stream
analytics
is
this
basically
shows
you
how
much
time
all
of
these
different
stages
in
your
software
development
takes.
So
how
long
does
it
take
for
your
product
managers
to
create
work?
How
long
does
it
take
for
your
developers
to
code
the
next
code
request?
How
long
does
it
take
for
your
code
test
process
to
take?
A
Without
these
types
of
metrics,
you
may
not
be
spending
your
time
and
your
money
on
the
right
things,
and
so
what
we
have
given
over
here
is
the
visibility
into
basically
seeing
what
each
stage
in
your
software
development
process
is
taking,
and
so
the
other
thing
that
we
do
is,
let's
just
say
that
you
had
some
major
initiative
that
started
90
days
ago.
It
was
a
two
million
dollar
initiative
bought
some
new
tooling
hired
some
new
people,
some
consultants.
A
I
want
to
see
how
this
impacts
my
business
efficiency
so
90
days
ago.
Where
are
my
numbers
at
now
30
days
ago?
Where
are
my
numbers
at
all?
The
way
to
last
week
have
things
improved,
and
so,
as
a
business
level
leader,
I'm
constantly
looking
for
ways
to
improve
these
numbers,
and
so
by
surfacing
these
numbers,
I
now
have
visibility
into
my
organization.
A
All
right,
so
that's
it
for
business
leaders.
The
next
type
of
prospect
that
I
want
to
mention
is
architects,
and
so
these
are
really
important
to
understand.
These
are
senior
technical
influencers,
and
so
what
I
mean
by
this
is
that,
ultimately,
if
you're,
a
director
or
vp
a
lot
of
times,
you
have
an
architect
or
chief
architect
that
reports
to
you
and
so
for
a
lot
of
the
technical
implementation
decisions.
A
Let's
just
say
that
you
are
a
senior
director
in
a
large
business
every
once
in
a
while
you're
going
to
be
in
charge
of
some
large
initiative.
That
initiative
is
going
to
have
technical
components,
but
because
you've
been
busy
operating
on
the
business
side
for
the
last
15
years,
you're,
actually
not
the
best
person
to
figure
out
some
of
these
more
granular
technical
decisions.
A
Some
of
the
things
that
they
choose,
which
technologies
do
we
want
to
invest
in,
how
do
they
work
together
and
they
often
directly
report
the
leadership.
So
that's
architects.
The
only
other
thing
that
I
want
to
talk
about
is
that
you're
really
looking
for
someone
like
a
transformation
architect
cloud
architect
even
like,
but
what
you
don't
want.
Is
you
don't
want
a
solutions
architect
because
solutions?
Architects
are
sales
engineers
generally
so
they're,
not
they
don't
function
in
this
role,
all
right.
A
A
It's
really
important
to
have
a
process
here
for
trial
and
error,
and
what
I
mean
by
that
is,
if
you
talk
to
someone
on
your
team,
that's
having
a
lot
of
great
success,
implement
a
lot
of
the
things
that
they're
doing.
Then
you
could
get
completely
different
results
because
your
region
may
be
different.
Your
industry
may
be
different
because
things
are
ultimately
changing
all
the
time.
That's
why
it's
really
important
to
have
some
process
for
trying
new
ideas
and
seeing
which
ones
are
working
and
which
ones
aren't
working.
A
There's
no
universal
advice
in
sales
development.
What
works
for!
You
is
not
going
to
necessarily
work
for
someone
else
on
your
team,
an
example
of
this
in
terms
of
embracing
iteration.
So
here's
one
of
the
pilot
studies
that
I've
done
connected
blind
leak
with
people
on
linkedin
had
a
20
success
rate,
and
then
I
sent
out
message
a
and
after
I
sent
out
message
a
I
got
a
44
conversion
rate
after
I
started
sending
out
message
b.
A
I
got
only
a
15
conversion
rate,
and
so
this
is
the
message
that
I
stuck
with
so
having
things
like
this
were
constantly
iterating
and
improving
in
our
craft.
This
is
basically
going
to
be
how
you
ultimately
level
up
as
a
sales
development
professional
here
at
gitlab.
A
The
other
thing
that
I
want
to
talk
about
is
finding
the
devops
decision
maker
and
the
reason
why
I
want
to
mention
this
is
because
a
lot
of
businesses
don't
have
someone
with
necessarily
where
it's
like
director
of
devops
vp
of
devops.
In
their
title,
there
are
some
organizations
in
which
they
do
have
a
director
of
devops,
but
from
what
I've
seen
this
is
the
minority.
A
A
But
if
it
does,
then
this
person
is
the
devops
decision
maker
and
finding
the
devops
decision
maker
is
going
to
be
one
of
the
number
one
ways
in
which
you're
going
to
save
time.
You
have
a
finite
amount
of
time.
So
if
you
prospect
out
to
a
lot
of
these
people
that
aren't
in
charge
of
devops,
they
might
have
an
opinion
you
might
be
able
to
get
a
meeting,
but
ultimately
it's
the
devops
decision
maker.
That's
going
to
generally
buy
our
product,
that's
not
always
the
case,
but
in
generally
that
is
the
case.
A
So
some
of
the
best
practices
on
the
enterprise
side
we
often
land
with
directors,
vp
and
architects.
So
these
are
the
three
titles
that
we
get
a
lot
of
our
success
with
ultimately
once
again,
finding
the
devops
decision
maker,
whether
or
not
that's
a
director
or
whoever
in
your
organization,
and
so
this
is
the
top
down
approach.
A
So
that's
the
bottoms
up
approach.
Some
people
have
success
with
that.
If
you
are
an
enterprise
sales
development
representative,
here,
you
should
collaborate
with
your
sales
counterpart
to
figure
out
which
approach
makes
the
most
sense
for
your
accounts,
and
the
other
thing
that
I
want
to
talk
about
is
if
you're
talking
on
the
enterprise
level
generally
avoid
technical,
individual
contributors,
unless
they
are
architects,
because
at
this
point
these
businesses
often
are
so
large
that
they
may
have
reduced
influence
on
the
mid-market
smb
level.
We
can
land
higher,
so
bprc
level.
A
So
once
again
we
can
land
higher.
But
ultimately
the
goal
is
the
same.
Find
the
devops
decision
maker,
and
the
other
thing
to
sort
of
point
out
is
that
a
lot
of
times
in
a
s,
smaller
engineering
business,
a
lot
of
people
have
to
wear
many
hats
right
and
then
so
your
product
manager
may
actually
be
responsible
for
devops
too.
Just
because
that's
what
he
knew
about
in
a
past
life.
That
was
actually
the
case.
A
When
I
was
an
engineer
when
I
worked
for
a
startup,
our
product
person
was
actually
doing
devops
too,
and
once
again
it's
just
an
example
of
how
people
have
to
wear
many
hats,
and
so
your
title
may
not
necessarily
be
what
you
are
actually
doing
in
an
organization
like
that,
so
so
starting
to
wrap
so
wrap
up
the
presentation.
A
So
it's
really
about
asking
relevant
questions
to
reveal
pain
and
help
our
customers
to
understand
their
situation
from
a
different
perspective,
and
so
what
I
mean
by
this
is
I'll.
Give
you
a
example.
A
One
of
our
competitors
jenkins,
is
pretty
much
a
de
facto
choice
for
many
of
our
customers,
and
so,
if
you
ask
them
up
front
if
they
like
their
jenkins,
they'll
say
like
it's
okay,
but
then,
if
I
ask
probing
questions
like
all
right,
how
much
time
do
you
spend
maintaining
your
jenkins
server?
Has
your
jenkins
server
ever
broken
down
on
you
at
some
sort
of
really
important
time
in
the
development
cycle?
Have
you
ever
been
late
for
a
project
because
of
problems
with
your
jenkins
server?
A
Then,
all
of
a
sudden
we've
helped
our
customer
to
understand.
Wait
there
actually
was
a
problem
now
I
want
to
go,
find
out
more
about
what
solutions
could
be
and
so
ask
intelligent,
probing
questions,
and
so
you
can
start
off
with
something
like
what
are
some
of
the
initiatives
that
you
have.
What
are
some
of
the
challenges
that
you're
facing
tell
me
more
about
that
right.
One
of
the
great
things
that
we
can
do
and
a
general
rule
of
thumb,
is
that
your
prospect
should
be
speaking
at
least
50
of
the
time.
A
And
here
are
the
number
one
and
number
two
complaints
that
buyers
have
by
survey.
Data
number
one
is
that
sales
people
don't
do
a
good
enough
job
of
listening
and
that
the
number
two
most
common
complaint
is
that
sellers
ask
questions
that
don't
add
value,
so
we
want
to
add
value.
So
how
do
we
ask
questions
in
a
way
that
helps
to
contribute
in
this
manner?
A
So
here
are
some
examples
of
some
questions.
I'm
not
going
to
go
through
all
of
them.
The
slides
once
again
will
be
shared,
but
really
what
I
want
people
to
understand
here
is
the
fact
that
these
questions
change
as
I
go
from
technical,
individual
contributor
to
level
one
manager,
and
then
they
start
changing
again
to
become
more
business,
focused
as
I
get
to
the
vpnc
level
and
so
from
a
technical,
individual
contributor.
It's
all
about
features
functionality.
What
can
gitlab
do?
A
How
can
it
do
it
better
than
than
other
tools
and
things
like
that?
How
can
gitlab
help
the
people
who
are
in
charge
of
implementation
to
speed
up
their
process
and
achieve
their
goals
so
things
like
speed,
efficiency,
demos,
case
studies?
A
A
So
how
can
git
lab
help
these
managers
to
do
their
job
better
on
the
director
level,
now
starting
to
talk
more
about
best
practices
like
automation,
talking
about
software
silos,
talking
about
how
gitlab
can
help
your
teams
to
communicate
better
as
a
group
and
then
now
for
senior
leadership
questions?
How
do
we
help
what
are
some
of
the
things
that
you're
trying
to
implement
for
your
entire
business
unit?
What
are
some
of
the?
What
is
your
three-year
plan
right?
What
are
some
of
the
bottlenecks?
What
are
some
of
the
technologies
that
are
involved?
A
What
are
some
of
the
cultural
changes
that
you
may
working
on?
So
that
you
can
have
a
great
and
winning
team,
so
other
things
is
customer
references
what
their
peer
organizations
are
doing
great
asset
to
give
someone
in
senior
leadership
all
right,
great.
So
just
trying
to
summarize
everything.
I
know
that
we
talked
about
a
lot
of
things
today.
A
A
One
of
the
big
groups
that
we
have
is
whether
or
not
you're
talking
to
someone
who's
a
technical,
individual
contributor
or
someone
in
leadership
also
the
fact
that
it's
also
going
to
vary
between
someone
who's,
a
level
one
manager
and
someone
who's
on
the
vp
level.
So,
once
again,
as
we
go
higher
in
the
organization,
I'm
going
to
be
talking
more
about
these
business
level,
goals
number
two:
finding
the
devops
decision
maker
your
times
valuable.
So
how
do
you
maximize
your
time?
A
A
That's
a
presentation
for
day,
looking
forward
to
seeing
you
in
the
next
session.
Thank
you.