►
From YouTube: Keynote: How to Win Friends and Reduce Tech Debt with Developer Experience - Amara Graham
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Keynote: How to Win Friends and Reduce Tech Debt with Developer Experience - Amara Graham, Head of Developer Experience, Camunda
Developer Experience (DX) has become a bit of the hot newness in tech with companies scrambling to hire or rebrand existing teams to focus on DX. The truth is, most developer-friendly companies already have a fair amount of DX baked into their culture. Where both companies and projects fail is volunteer investment or maintenance in DX when it’s not considered part of the fully-supported product stack. This kind of behavior breeds unchecked tech debt. Let’s talk through some things you can recognize and some other things you can avoid to enable developers with or without an official developer experience (DX) program.
A
Hi
everyone-
it
is
blindingly
bright
up
here,
so
if
you're
thinking
about
staying
in
the
back,
if
you
want
to
come
to
the
front,
so
I
could
see
you
that
would
be
like
fantastic
any
takers.
No,
no
people
outside
no
all
right,
so
my
name
is
amara.
Graham
I'm
here
to
talk
to
you
today
about
tech,
debt
and
developer
experience
before
I
get
started,
though
I'm
curious.
A
A
So
let's
go
ahead
and
get
started
here,
I'm
going
to
introduce
myself
a
little
bit
more
lengthy
than
just
my
my
bio,
because
I
think
this
is
the
first
time
that
I've
spoken
to
a
ci
cd
devops
audience.
So
you
may
not
know
me
again.
My
name
is
amara.
I'm
leading
the
first
developer
experience
team
at
kamunda.
I've
had
a
number
of
roles
in
developer
relations.
I
think
you
heard
a
little
bit
from
my
bio
that
I
was
a
developer
and
then
kind
of
shifted
away
from
enterprise
and
I.t
applications.
A
It's
really
all
around
making
developers
have
a
more
efficient
time
or
more
successful
time
when
using
products
tooling
things
that
I'm
I'm
familiar
with,
so
sharing
that
that
education
and
then
what's
really
crazy
and
a
quick
side
note
is,
I
have
actually
come
full
circle
in
my
career,
where
I
started:
building
bpm
applications
and
process
automation
tools,
front
ends
for
them.
In
fact,
now
I
am
running
a
developer
experience
team
that
caters
to
those
exact
folks.
A
A
A
I
think
I
guess,
as
an
industry,
we
should
all
come
together
and
decide
like
what
acronym
we're
going
to
choose
and
how
we're
going
to
move
forward.
But
if
you're
confused
about
that,
that's
what's
going
on,
we
all
shift
them,
I'm
going
to
do
it
as
well,
but
for
my
flavor
of
developer
experience
and
what
we're
doing
at
camunda.
A
I
want
you
to
think
external
enablement,
and
I
say
you
know
this
flavor
or
my
flavor
communist
flavor,
because
developer
experience
is
really
in
a
place
right
now,
where
I
guess
you
can
say
it's
a
renaissance
period,
there's
a
number
of
different
teams
who
have
established
that
there's
something
that
we
need
to
do
in
the
developer:
experience
space
or
the
developer
productivity
space.
How
are
we
going
to
name
that?
How
are
we
going
to
brand
that
who
is
going
to
handle
that
work?
A
As
I
continue,
we
report
to
the
cto
via
the
developer
relations
team
again,
depending
on
your
flavor
or
what
you're
doing
at
your
company,
you
may
see
this
shifted
where
you
have
the
developer
experience
team
is
the
overarching
team
and
devrel
reports
up
through
them
again
for
us.
We
report
through
the
developer
relations
team
within
developer
relations.
We
run
a
three
pillar
program,
so
we
have
our
enablement
side,
which
is
is
me
and
developer
experience.
We
have
our
advocacy
side,
which
is
awareness,
and
then
we
have
our
engagement
side,
which
is
our
community
team.
A
So,
together
those
three
teams
make
up
our
our
developer
relations
team.
It's
also
why
you
may
hear
me
say
things
where
you're
like
wait,
but
I
thought
the
you
know
the
advocates
would
do
that
or
I
thought
maybe
the
product
engineering
teams
would
do
that
again,
it's
what
works
for
us,
it's
what
we're
running.
Currently.
A
I
also
mentioned
that
we
report
up
through
the
products
team
products
at
camunda
is
really
all
of
our
technical
folks
who
are
directly
interacting
with
the
products.
So
that's
engineering,
technical
support,
devrel
product
management
and
product
design,
so
it's
not
products
and
just
the
product
managers
like
again
some
companies
do.
A
We
are
focused
on
our
developer
community
and
based
on
the
show
of
hands
that
I
had
in
the
room.
It
sounds
like
many
of
you
are
familiar
with
developer
relations,
so
I
won't
have
to
go
down
that
huge
rabbit
hole
of
what
is
a
developer
community,
but
the
long
and
short
of
it
is.
We
really
are
responsible
for
the
enablement
aspects
for
anyone
and
everyone
who
is
around
the
ecosystem
of
our
our
products.
A
That's
a
really
big
challenge,
especially
in
the
enablement
space.
When
you
start
thinking
about
the
kinds
of
personas
that
you're
trying
to
enable
the
folks
that
you're
trying
to
interact
with
where
you're
bringing
your
awareness
programs,
but
specifically
in
the
enablement
space,
we
try
as
best
as
we
can
to
focus
on
developer
personas,
of
which
there
could
be
many,
depending
on
your
granularity
there.
A
A
There
is
more
to
it
than
that,
but
if
you
can
kind
of
think
about
the
rest
of
the
talk
with
that
as
a
frame
of
reference,
I
think
that
would
be
super
helpful.
You
also
see
here
the
the
three
folks
that
are
on
my
team.
We've
got
a
technical
writer,
a
developer
experience
engineer
and
a
technical
community
builder.
A
So
hopefully,
this
kind
of
sets
some
context
for
where
I'm
going
to
go
throughout
the
the
rest
of
the
slides.
Because,
again,
I
know
there's
a
number
of
different
teams
that
are
talking
about
what
they
want
to
do.
In
the
developer
experience
space,
I'm
seeing
teams
rebranding
themselves
as
developer
experience
teams
and
that
could
range
from
devrel
to
certain
devops
teams,
internal
enablement,
internal
advocacy,
all
kind
of
seem
to
fall
under
this
umbrella
of
developer
experience
tackling
slightly
different
things.
A
A
They
think
we're
only
interacting
with
the
folks
who
are
working
on
our
open
source
or
free
offering.
But
really
it's
everyone,
and
this
last
sentence
that
I
have
on
the
slide.
You
know,
including
educating,
potential
customers
silently
lurking
community
members,
high
impact
contributors
and
more.
It
is
everyone.
A
So,
even
though
we're
just
focused
on
the
developer
persona
or
the
set
of
developer
personas,
it's
everyone
from
the
people
who
know
kamunda
or
know
process
automation
all
the
way
up
through,
or
I
guess,
take
a
step
back
and
say
all
the
way
through
the
people
who
are
like.
I
don't
know
what
kamunda
is.
I
don't
know
what
process
automation
is.
I
just
have
this
problem
and
I'm
trying
to
solve
it
through
to
the
people
who
are
you
know,
ranting
raving.
They
love
comundo,
they're,
telling
all
their
friends
about
it.
A
So
again,
an
interesting
space
to
be
in
because
you
have
a
number
of
folks
that
you're
trying
to
to
cater
content
or
or
these
experiences
to
again,
because
there
was
enough
people
that
mentioned
that
they
knew
something
about
devrel
I'll.
Just
very
briefly
say
that
devrel
supports
long
tail
or
large
funnel
engagements.
A
A
The
more
focused
on
heard
and
supported
that
your
developer
community
is
the
better
your
developer
experience.
So
if
you
want
to
focus
on
a
solid
experience
from
onboarding
to
executing
in
the
eyes
of
the
developer,
that
you
expect
to
work
on
your
product,
you'll
have
more
advocates
more
sponsors
and
more
friends,
more
people
who
are
excited
to
use
your
product
and
excited
to
tell
people
about
your
product.
A
So
you
might
be
asking
yourself
at
this
point.
You
know:
couldn't
the
product
engineering
teams
handle
this?
This
all
sounds
like
things
that
could
be
baked
in
there's
all
things
that
sound
like.
You
know
stuff
that
the
user
experience
team
should
consider
when
they're
building
out
a
user
experience
for
a
developer,
focused
or
a
developer
friendly
tool,
and
I
will
give
the
classic
answer
that
I'm
sure
many
of
you
are
expecting
it
depends.
A
It
depends
on
your
priorities,
what
your
teams
are
doing,
maybe
what
your
product
manager
wants
to
be
done,
or
the
road
map
that
you
have
laid
out
in
front
of
you,
or
maybe
even
the
foundational
ground,
work
that
you've
prepared
for
yourself.
So
I
put
together
a
few
considerations
for
developer
experience
work.
This
is
by
no
means
like
a
comprehensive
list.
This
isn't
everything
that
my
team
is
working
on.
A
I
don't
even
think
this
is
everything
that's
on
like
a
strategy
doc
that
I
have
it's
really
just
kind
of
like
a
sample
of
things
and
again
this
is
specific
to
our
flavor
of
developer
experience.
You
may
have
a
team
that
is
supporting
things
like
sdks
or
things
that
are
product
adjacent
kind
of
similar
to
the
product
adjacent
tool,
section
that
I
have,
but
again
you
may
have
a
slightly
different
list.
This
is
the
one
that's
kind
of
leaning
more
towards
what
we
are
doing.
A
So
with
these
considerations,
I
have
three
buckets
here.
I
have
documentation,
contributor
experience
and
then
this
product
adjacent
tools,
which
is
kind
of
my
catch-all
for
the
things
that
developers
would
probably
love
to
see
and
enjoy,
seeing
you
do
some
sort
of
tender
loving
care
to
provide
so
that
they
don't
have
to
build
that
themselves,
because
of
course
you
could
build
a
really
nice
api.
A
You
could
even
make
a
really
nice
documentation
experience
for
your
api
reference
and
say:
okay,
I'm
done,
but
if
you
want
the
extra
step
of
creating
an
api
wrapper,
a
client,
an
sdk
whatever
you
want
to
call
it,
depending
on
your
programming,
language
or
framework
of
choice
that
makes
developers
feel
welcomed,
it's
something
that
they
don't
have
to
do.
They
can
look
at
examples.
They
can
see
how
other
people
are
using
it.
They
don't
have
to
necessarily
build
it
themselves.
There
are,
of
course,
going
to
be
people
that
say
cool.
A
A
A
Are
you
cool
with
your
product
engineering
teams
working
on
all
of
these
items
on
top
of
new
features?
On
top
of
you
know,
any
sort
of
bugs
and
things
that
come
up,
are
they
going
to
have
the
time
and
if
you're,
a
product
manager
who
I
don't
know
if
we
have
product
managers
in
the
room,
are
you
cool?
We've
got
one.
We
got
one
product
manager,
so
maybe
I'll
talk
to
you.
A
Are
you
cool
with
having
your
engineering
team
work
on
this
and
maybe
prioritizing
it
over
new
features
over
bugs,
or
maybe
things
that
are
coming
in
from
from
high
cost
customers
or
high
dollar
customers?
I
should
say:
oh,
that
was
great.
It's
like
I
planted
you
so
that
if
you
didn't
hear
he
said
I
am
not
that's
why
I
became
a
developer
advocate,
but
from
the
product
managers
that
I've
worked
with
in
the
past.
A
It's
been
really
challenging
to
get
some
of
these
items
above
the
above
the
line,
and
it's
not
because
they
don't
care
about
them.
It's
not
because
that
they
don't
want
to
have
a
solid
developer
experience.
It
just
becomes
very
challenging
to
have
your
teams
that
are
working
on
core
engineering
features
split
their
time
in
other
places.
A
A
Our
engineers
actually
write
our
documentation.
So
if
they're
writing
the
core
features
and
writing
the
documentation,
are
they
really
going
to
have
time
for
mentoring,
contributors
or
supporting
our
maintainers?
You
know
creating
ide,
plugins
and
then
gardening.
All
of
that
in
such
a
way
that
it's
not
stale,
it's
fresh,
it
works.
It
works
with
every
release
of
everything
from
our
product
to
third-party
components.
A
This
is
where
it
kind
of
gets
challenging,
and
this
is
where
I
would
say
it's
up
to
you
asking:
are
you,
okay,
with
volunteer
projects
being
supported
on
a
volunteer
basis?
So
if
you're
going
to
have
something
like
a
client
or
an
api
wrapper?
Are
your
customers
or
are
your
community
members?
Okay,
with
that
being
supported
in
a
volunteer
capacity,
or
is
that
a
place
where
you
could
potentially
breed
or
grow
tech
debt?
A
Because
for
me,
those
are
the
items
that
I
take
a
look
at
and
say
that
makes
me
nervous
that
that's
an
item
that's
going
to
to
be
tucked
at
and
some
of
this
is
is
sneaky.
I
think,
there's
a
number
of
times
where
you've
either
done
a
internal
poc,
or
maybe
you
have
internal
hack
days
or
hackathons,
where
you've
built
a
little
something
you've
shown
it
to
your
team
and
you've
been
like.
Oh,
this
is
super
cool
and
then
someone
saw
it
and
is
like
great.
A
Is
that
a
marketable
feature,
or
can
we
release
that
to
a
customer
or
be
really
cool?
If
we
we
gave
this
to
this
person
and
then
suddenly
it
needs
to
be
on
a
path,
that's
fully
supported,
but
you
don't
have
time
to
fully
support
it.
That's
another
issue
that
comes
up
as
these
like
weird
tech
debt
things.
A
Hey
all
of
this
again
is,
like
I
said,
is
a
breeding
ground
for
for
tech,
debt
and
again
it's
a
choice.
I'm
not
saying
that
it's
absolutely
going
to
become
tech
debt,
but
I
will
say
that
there's
been
a
number
of
projects
that
I've
been
involved
with,
particularly
around
the
developer
experience
space.
Where
I
come
in
and
I
say:
hey
I
looked
out
on
github
and
I
saw
that
we
have
this
project.
A
It's
maybe
an
api
wrapper,
it's
really
cool
because
it
it
you
know,
introduces
our
our
code
or
our
product
into
the
the
react
native
community.
That's
super
cool,
but
I
see
it
hasn't
been
updated
in
a
year
and
the
product
manager
goes
like
so
do.
Are
we
not
gonna
update
that
or
are
we
not
investing
in
the
react
native
community?
A
Again?
That's
that's
a
tech
debt
item
and
that's
one
of
those
things
that
someone
who
is
looking
at
your
products,
specifically
from
a
developer
experience
lens.
If
they
look
and
they
see
you
know
hey,
I
really
want
to
run
your
solution,
a
react,
native
context,
for
instance.
I
can't
do
it
because
the
api
wrapper
that
I
saw
that's
sitting
out
on
your
github
looks
old.
Looks
stale.
Am
I
going
to
have
to
build
my
own?
I
don't
want
to
build
my
own.
A
If
you
just
maintained
it,
you
would
have
won
a
friend
and
made
someone
happy
on
that
note,
I'm
going
to
go
ahead
and
wrap
up.
So
thank
you
so
much
for
hanging
out
with
me
today.
I
hope
you
learned
something.
I
hope
you
took
something
away
from
it,
I'm
all
over
the
internet,
I'm
also
at
the
kamunda
booth.
You
can
come
and
hang
out
chat
with
us
either
about
process
automation.
A
What
you
think
you
want
to
do
with
kumunda
or
what
we
could
maybe
convince
you
to
do
with
kamunda
or
you
can
come
talk
to
me
about
developer
experience
topics.
I
would
love
to
see
more
developer
experience
teams
out
there.
I
would
love
to
know
what
flavor
your
company
is
doing
in
the
the
developer
experience
space.
If
you
are
but
yeah
come,
come
chat
me
up
thanks.