►
Description
Developer productivity is an important metric that can be difficult to quantify and define. But perhaps an easier question to answer is: what gets in the way of developer productivity? For many organisations, things like tech sprawls, lack of collaboration, and time-consuming manual processes prevent developers from focusing on what matters most—shipping new and innovative features. Learn from Kaushik Mukherjee, Head of Software Engineering at UDAAN, Helen Lau, Chief Engineer at CBA, and Craig Wilson, Platform Engineer at Iress, on how they removed roadblocks and increased developer productivity in their organisations. They’ll also discuss how they’re able to meet their business goals by shipping new features and product innovations faster and at a higher quality.
Stay up-to-date on all things GitHub by subscribing and following us at:
YouTube: http://bit.ly/subgithub
Blog: https://github.blog
Twitter: https://twitter.com/github
LinkedIn: https://linkedin.com/company/github
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
All
right
kicking
things
off
hello,
everybody
and
thank
you
very
much
for
joining
us
in
this
session
today,
I'm
very
much
looking
forward
to
kicking
things
off.
Let's
start
with
a
bit
of
an
interaction
about
myself,
my
name
is
Pierre
Luigi
cow
I
am
Regional
director
for
field
services
in
the
Apec
region
for
GitHub
I
have
been
a
GitHub
for
about
five
years.
I
have
a
background
in
software
engineering
and
later
as
an
engineering
manager
and
Tech
lead
prior
to
joining
GitHub.
A
My
first
commit
on
GitHub
is
from
2011.,
so
it's
been
quite
a
while
that
I've
been
in
a
way
connected
to
to
this
company,
mostly
as
a
developer.
In
the
start
and
and
later
having
been
part
of
the
team.
In
today's
session,
we
will
be
focusing
on
how
to
increase
efficiency,
Drive
collaboration
and
deploy,
secure
and
compliant
code
using
enterprise-ready
tools,
developer
productivity
is
an
important
metric
and
it
can
be
pretty
difficult
to
quantify
and
Define
it.
A
So
perhaps
an
easier
question
to
answer
is
what
gets
in
the
way
of
developer
productivity
for
many
organizations,
things
like
text,
Pros,
lack
of
collaboration
and
time-consuming
manual
processes
really
prevent
developers
from
focusing
on
what
metals
knows.
Shipping
new
and
Innovative
features
tooling
itself
plays
a
crucial
role
in
the
successful
rollout
of
a
modern
application.
Development
strategy
and
developer
satisfaction
significantly
impacts
productivity.
A
So
today
we
will
be
hearing
directly
from
Top
industry
leaders
about
their
experiences
and
Lessons
Learned
in
their
quest
to
accelerating
development
life
cycle
in
complex
environments
before
we
get
right
into
it,
I'd
like
to
share
a
few
tips
for
an
optimal
experience
in
today's
session.
First
of
all,
we
would
like
to
hear
your
questions.
So
if
you
have
any
questions,
there
is
a
dedicated
tab
on
the
right
side
of
your
screen.
Q,
a
so
click
on
that
and
feel
free
to
drop
your
questions
in
that
in
that
chat
box.
A
A
Lastly,
if
you
at
any
point
in
time,
hear
anything,
that's
interested
interesting
to
you
or
you
would
like
to
talk
to
our
GitHub
experts
feel
free
to
click
the
button
at
the
top
of
the
screen
to
request
a
demo
or
to
schedule
a
meeting
with
us
we'd
be
delighted
to
reach
out
to
you
in
terms
of
the
actual
viewing
experience.
We
recommend
using
a
modern
browser
on
your
desktop.
A
If
you
are
having
issues
with
the
stream,
try
refreshing
the
page
that
usually
helps
it
fixes
it
if
you're
still
experiencing
problems,
maybe
you're
on
a
VPN,
so
try
to
sit
in
the
VPN.
And
lastly,
if
you're
still
experiencing
issues,
there
is
a
document
in
the
docs
section
on
the
side
of
this
website,
where
you
can
find
additional
troubleshooting
information
and
also
try
to
interact
in
the
chat.
A
We
will
keep
an
eye
on
the
chat
as
well
now
before
we
jump
into
the
speaker,
I'd
love
to
introduce
our
panel,
of
course,
but
I
would
like
to
start
a
poll
first,
as
I
would
like
to
know
where
you
are
joining
us
from
today.
So,
let's
bring
that
on
the
screen,
please
select
your
your
option
from
the
poll.
We'll
take
a
look
after
we've
introduced
our
speakers.
So
let
me
do
that.
A
Okay,
fantastic,
as
I
said,
we
have
an
amazing
roster
of
panelists
today,
I'm
extremely
excited
to
be
here
and
to
have
a
chat
with
them,
so
we'll
hear
from
from
them
how
they
actually
removed
roadblocks
and
increase
developer
productivity
in
their
organizations.
They'll
also
be
discussing
how
they're
able
to
meet
their
business
goals
by
shipping
new
features
and
product
Innovations
faster
and
at
a
higher
quality.
A
B
All
right,
thanks
PC
for
having
me
I'm
kaushik
I,
am
dialing
from
Bangalore
or
India
I.
Had
software
engineering
at
uran,
which
is
a
e-commerce
platform,
initially
started
with
catering
to
a
lot
of
B2B
side
of
things
and
my
rules
of
responsibilities.
I
I
take
care
of
the
core
and
the
infrastructure
side
of
things,
as
well
as
the
sdlc
side
of
things,
which
leads
to
a
developer
productivity.
A
D
E
Hi
everyone,
my
name,
is
Helen
Lao
and
I
am
one
of
the
chief
engineer
in
Commonwealth
Bank.
So
for
people
outside
of
Australia,
you
might
not
know.
Commonwealth
Bank
of
Australia
is
one
of
the
largest
bank.
I
have
close
to
20
years
of
Industry
experience
across
technical
Consulting
software
engineering
architecture
and
management
background.
E
So
I've
only
been
with
the
bank
just
over
a
year
prior
to
the
bank,
I
always
with
Microsoft
as
the
ATS,
which
is
account
technology,
strategist
and
I,
was
looking
after
the
largest
Azure
account
in
Australia
and
doing
a
lot
of
cloud
adoption.
Digital
transformation,
sustainability,
implementation
across
the
organization
for
the
client
and
prior
to
Microsoft
I
was
the
head
of
digital
in
caltex,
Australia
or
ampol.
Australia
I
was
leading
the
Innovation
lab
and
across
digital
software
development,
big
data
and
productivity
applications.
E
So
I'm
here
representing
CBA,
basically
CVA.
My
team
is
the
central
engineering
team
across
the
bank,
so
I,
look
after
all
the
tooling
or
the
engineering,
devops
sort
of
text
stack
for
the
bank
and
that's
all
you
know,
keeping
the
banks
running
is
the
back
end
of
the
back
end
is
my
baby.
I?
Will
hand
over
to
you
fizzy
awesome.
C
Sure
my
name
is
Tim
Dunley
I'm,
the
CEO
of
KPMG
ignition
Tokyo,
which
is
a
engineering
team
within
KPMG
here
in
Japan,
I've
spent
the
last
10
years
or
so.
Building
engineering
teams
inside
of
Professional
Services
firms
to
service
both
the
firm
itself,
as
well
as
our
clients,
with
with
new
modern
Technologies
based
on
the
engineering
discipline
I'm.
C
Also
one
of
the
Prime
responses
of
a
global
initiative
here
within
KPMG
that
we
call
KPMG
code,
which
is
really
focused
on
how
do
we
provide
the
best
possible
environment
for
our
Engineers
to
not
only
get
their
day-to-day
work
done,
but
actually
to
connect
with
the
rest
of
the
engineers
across
KPMG
in
the
in
a
sourcing
approach?
To
you
know,
crime
do
less
reinvention
of
things
and
actually
spend
more
time
building
cool
stuff.
A
Okay,
so
I
see,
there's
quite
a
few
folks
dialing
in
from
India
amazing,
southeast
Asia,
coming
in
at
SEC
on
second
place
and
then
Australia
New
Zealand,
but
we
do
have
obviously
quite
a
few
more
from
other
parts
of
the
region.
So
that
is
amazing.
Thanks
again
everybody
for
joining
us,
okay,
beautiful
so
without
further
Ado,
I
would
say
we'll
kick
right
into
this
conversation
and
I
would
love
to
start
by
maybe
sending
a
bit
the
tone
around
productivity
right.
A
This
is
a
very
simple
word,
which
I
think
hides
a
ton
of
complexity,
a
little
bit
of
like
a
nice
Bird
right,
very
easy
to
think
about,
but
also
very
hard
to
measure
very
hard
to
make
sure
that
we're.
You
know
we're
also
measuring
the
right
things
that
are
not
introducing
artificial.
You
know
artificial
metrics
that
don't
really
help
actually
achieving
our
goals
as
complex
organizations.
A
E
Thank
you
all
star,
so
productivity.
How
I
we
see
it
in
CBA
is
how
long
does
it
take
from
ideation
to
production,
as
in
the
features
available
to
our
customers?
That's
what
we
mean
by
productivity,
how
fast
we
can
deliver
our
features
to
our
customers
and
across
the
bank.
We
actually
run
one
of
the
largest
bank
in
Australia,
so
we
have
many
different
sector
area
in
our
in
our
business
unit,
in
terms
of
this
retail
banking,
this
business,
banking
and
so
on
so
forth.
E
E
D
B
B
D
B
B
That
sort
of
tell
us
how
productive
we
are,
as
systems
grow
over
time
they
inevitably
become
complex.
Hence
it's
important
to
look
at
those
metrics
and
try
to
make
sure
that
if
any
of
your
micro
Services
are
leading
to
a
Slowdown
on
productivity,
that's
a
proxy
towards
understanding
that
certain
systems
need.
B
D
B
B
A
Yeah
thanks
coaching,
very
interesting,
and
you
know
it
finally
rephrase
a
little
bit.
It
sounds.
Obviously
you
know
time
to
Market
seems
to
be
a
shared
approach
to
that
and
I
like
the
fact
that
that
is
a
team
level
metric
to
begin
with
right,
so
we're
not
necessarily
focusing
too
much
on
the
individual.
You
know
amounts
of
commits,
or
things
like
that
which
actually,
in
our
experience
you
know,
we've
published
several
studies
and
and
service,
and
we
find
ourselves
to
be
yeah
in
line
with
that.
B
Let
me
just
add
one
other
thing:
I
think
at
an
individual
level,
it's
still
important
to
ensure
that
you're
keeping
your
PR's
concise.
You
don't
necessarily
want
to
end
up
having
a
PR
that
you
know
is
pretty
thousands
of
lines
because
it
at
that
point
in
time,
you're
innovatively,
compromising
on
the
quality
you're,
really
just
lucky
that
something
has
not
broken
in
production
or
maybe
a
and
and
the
hard
words
are
those
which
have
a
deferred
impact.
B
A
C
So
so
I
was
thinking
about
the
the
way
I
look
at
productivity
is
almost
in
two
lenses.
So
what
one
is
is
very
much
what
we're
talking
about
here
in
kind
of
the
time
to
value
and
and
ensuring
that
we've
we're
able
to
release
things
that
have
value
in
in
the
shortest
possible
time,
so
that
we
can
continue
to
maintain
that
velocity
and
the
second
one
is,
is
a
little
bit
closer
to
that.
Second
part,
which
is
really
around.
C
You
know,
environment
in
which
they're
trying
to
get
their
work
done.
So
they
can
actually
focus
on
and
accelerating
the
time
to,
Value
and
and
absolutely
the
the
tooling
and
automation
is
is
where
that
starts
to
come
in,
as
well
as
I
think
is
the
ability
to
leverage
tools
to
discover
shortcuts
so
yeah
anywhere
anywhere
I
can
give
a
developer
access
to
something
that
lets
them
say
well,
I,
don't
want
to
be
focused
on
this
particular
part
of
that
path
to
production.
A
Yeah
I
think
you
also
mentioned
earlier.
You
know
the
magic
word
which
is
inner
Source
right,
so
the
idea
that
organizations
can
replicate
that
same
sort
of
let's
say
those
same
best
practices
and
patterns
that
have
emerged
in
the
open
source
community
in
terms
of
collaboration
transparency,
so
I'd
like
to
maybe
ask
about
that
like
how
is
that
Journey
right
is
that
being
part
of
your
journey
in
and
now
you've
approached
a
sort
of
a
modern
development
sort
of
approach.
Yeah.
C
It
definitely
is,
and
KPMG
is
a
relatively
unique
organization
in
that
we're
a
very,
very
big
Federated
network
of
of
member
firms
around
the
world
and
what
it
means
is
that
we've
got
pockets
of
engineering
all
over
the
place
and
they're
all
building
great
stuff.
That
can
help
other
engineering
teams
around
our
network,
but
often
they're
not
being
able
to
get
access
to
that
either
because
they
don't
know
who
those
people
are,
or
they
don't
have
the
right
tooling
to
actually
give
them
access.
C
The
other
really
important
aspect
of
this
for
KPMG
is
really
around
compliance
and
risk
management.
So
you
know,
if
you
think,
about
the
brand
of
of
KPMG
and
the
drive
around
trust,
it's
been
really
critical
for
us
to
be
able
to
not
just
share
things
but
also
share
the
the
construct
around
security.
C
A
A
E
Think
of
your
how
you
automate
your
environment,
scap
folding
for
your
sit
and
so
on
so
forth,
and
we're
looking
now
at
the
at
the
moment
is
pipeline
minus
CO,
as
well
as
approval
Auto
approval
along
the
way,
because
our
vision
is
basically.
If
the
developer
is
working
on,
something
is
already
existing
application,
then
the
pipeline
should
be
established.
E
The
process
approval
should
be
established
and
the
risk
posture
for
that
should
be
lower
because
as
long
as
we're
not
dealing
some
some
radical
change
because
we're
trying
to
make
it
small
change
and
as
frequent
as
possible
to
production
rather
than
you
know
those
we
call
it
quarterly
or
monthly.
You
know
releases
which
it
would
touch.
You
know
probably
100
or
50
applications
that
you
will
require
a
lot
of
approval.
Customer
service
support
to
you
know,
review
may
make
sure
the
cost
center
is
in
form
make
sure
everyone's
standby.
E
Those
days
are
what
we
realize
is
we.
We
actually
need
to
walk
away,
because
now
we've
competing
with
the
tooling
with
automations,
we
can
actually
put
them
in
a
box
side
and
the
wrist
postures
and
the
blast
radius
is
quite
contained,
and
that
will
allow
us
to
basically
every
day
to
shoot.
You
know
as
many
changed
into
production
as
possible.
E
Just
give
context
like
in
terms
of
built
from
our
CI.
We
do
over
a
thousand
to
two
thousands
a
day.
So
if
I
had
two
saying
bundle
that
to
be
a
monthly
release,
that's
crazy!
So
we're
looking
at
you
know
every
day.
What
can
we
ship
to
production
like
each
team
will
work
according
to
the
agenda,
but
what
we,
how
we
do
this
is
through
automation
through
test
coverage.
E
You
know,
through
all
the
order
approval
provided
that
gut
railers
are
met,
so
that
doesn't
mean
that
we
allow
Engineers,
you
know
finish,
cutting
the
code
and
then
ship
to
production
straight
away
is
actually
to
go
through
all
these
stage
gate
rather
than
a
manual
stage
gate
we're
trying
to
automate
these
approval
and
checking
process.
For
example,
you
know
secret
vulnerability,
ability
checking
those
should
be
fundamental
101
as
part
of
the
pipeline.
E
You
know
as
part
of
your
either
your
commit
your
PR,
that
we
invoke
this
process
and
and
auto
approve,
provided
these
criteria
are
met.
You
are
now
safe
to
go
to
production
with
your
change,
and
that
doesn't
mean
that
we
bypass
any
of
these
stage.
Okay,
it's
it's
actually
to
automate
all
this
checking,
so
we
don't
have
to
do
it
manually
and
that
over
time
will
actually
bring
our
take
that
down,
because
sometimes
we
might
do
things
you
know
to
to
quit.
You
know
delivery
to
production,
but
it
will
be
a
shortcut.
E
We
might
need
to
come
back
and
fix
it
later.
But
by
doing
an
automated,
you
know
checking
process
in
New
York.
The
engine
is
actually
totally
shift
with.
They
see
these
blockage
right
at
the
diff
or
the
test
stage
already
before
they
hit
the
production
release,
because
what
I
observed
throughout
my
you
know
careers
a
lot
of
times,
engineers
finished
doing
coding
testing
when
they
get
to
a
production
release.
They
face
a
huge.
You
know:
station
gate,
either
by
a
cyber
or
change
to
release
team
or
service
management
team.
Have
you
done
all
these
stuff?
E
So
that's
sort
of
the
shift
right
approach,
but
with
the
tooling
and
automation
that
we
have
today,
you
know
on
actions
on
the
GitHub
ecosystem.
Things
like
that
we
can
leverage
a
lot
of
these
vulnerability,
checking
secret
scanning
things
like
that
that
can
back
into
our
solution
as
part
of
the
automation,
so
I'm,
100
sort
of
you
know
what
we're
thinking
aligned
with
what
Tim
mentioned
on
automation,
yeah.
A
Thanks
for
that
Helen,
and
maybe
as
a
Segway,
you
know
and
ask
a
similar
question
to
Takashi
I'd
love
to
hear
you
know
what
you
just
walked
us
through
is
really
the
eternal
struggle.
You
know
between
velocity
and
security,
slash
compliance
right,
like
a
lot
of
organizations,
of
course,
want
to
accelerate.
They
want
to
hit
the
market.
You
know
as
soon
as
possible,
but
without
sacrificing
secure
security,
and,
as
you
said,
you
know
the
shift
left
approach.
A
As
a
software
engineer
where
you
know
my
work
was
done,
as
you
know,
hopefully,
before
a
Friday
right
like
on
a
Thursday
afternoon,
I
was
ready
to
to
click
deploy
and
then
you
know
there
came
the
the
dreaded
security
report,
which
meant
going
back
to
square
one
and
starting
from
scratch,
usually
without
a
lot
of
guidance
which
wasn't
obviously
a
great
experience.
You
know,
as
a
software
engineer,
your
job
is
already
hard
enough,
and
then
you
know
if
you,
if
you
add
security,
expertise
on
top.
A
Yes,
it's
the
Spectrum
becomes
even
even
more.
You
know
broad.
So
so
so
that's
the
cops
inner
Source
automation.
All
these
things
I
think
end
up
playing
a
major
role
in
in
how
we
can
really
help
the
industry
right
as
a
whole,
accelerate
software
development,
so
maybe
kaushik.
How
is
that
looking
like
for
you.
B
Sure
so
I
think
I
think
all
good
points
in
terms
of
automation
that
others
talked
about
specifically
when
it
comes
to
security.
The
way
we
look
at
it
at
Udan
is
you
know
it's.
It's
almost
I
mean
security
is
by
Design
in
this
sense
that
you
know
it's
not
an
afterthought.
So
it's
a
lot
more
control
centrally
through
Central,
constructs
and
tooling,
actually
tells
you
if
there
are
violations
of
those.
B
B
That,
when
it
comes
to
productivity,
right
right,
I
think
it's
important
to
make
sure
that
you're.
Looking
at
engineering
experience,
you
want
to
take
away
the
anxiety
that
an
engineer
has
that's
your
North
Star
right
and,
of
course,
you
sort
of
have
some
amount
of
measures
for
that.
What
you
do
is
you
want
to
take
away
the
anxiety.
C
B
B
And
a
lot
of
those
learning
scheme
for
us
through
our
RCS,
where
we
realized
certain
kinds
of
mistakes-
Usual
Suspects,
if
you
may,
their
Engineers
were
making,
and
then
we
lintered
them.
So
even
if
you
were
to
make
a
mistake,
because
you
did
not
know
the
right
way
to
do
an
implementation
of-
let's
say
some
threading
in
a
particular
programming
language
that
was
already
taken
care
of
you.
E
B
B
But
what
what
we
did
is
we
created
that
you
know
system
in
place
that
led
the
engineers
learn
from
those
mistakes
without
creating
too
much
damage
to
the
product
overall
right?
So
that's
the
that
that
was
the
tenant
and
was
that
we
did
a
bunch
of
things
with
in
the
building
Canary
we
had
can
be
deployments.
We
introduced
chaos
in
the
network
like,
for
example,
we
introduced
partitioning.
We
introduced
Jitters
to
see
how
certain
use
cases
perform
and
that's
the
journey
that
we
continue
with.
D
B
B
B
Towards
you
know
saying,
looks
like
this
is
going
to
break
in
production
not
immediately,
but
in
the
next
15
days
you
might
as
well
change
certain
things
right.
So
that's
the
tenant
a
lot
of
those
a
lot
of
things
around
productivity.
What
you've
done
is
by
Design.
It's
not
really
an
afterthought
right.
So
that's
how
we
sort
of
approached
this
problem.
Pc
thanks.
A
Coach
that
yeah,
that
makes
a
lot
of
sense
and
very
interesting,
also
thanks
for
actually
bringing
another
element
into
this
conversation
right.
When
we
talk
about
devops,
the
focus
usually
immediately
goes
to
tooling
and
automation,
which
is
obviously
a
big
part
of
that.
But,
let's
not
forget,
there's
also
two
other.
You
know
very
important
aspects,
which
is
the
cultural
aspects,
like
you
said,
the
blameless
environment,
where
developers
can
really
you
know,
learn
from
each
other,
learn
from
their
experiences
and,
of
course,
tools
play
a
major
part
in
giving
developers.
A
You
know
a
an
experience
that
is,
is
satisfying
and
as
much
as
possible
on
you
know,
padded
by
guard
rails.
Obviously,
but
there's
also,
you
know,
processes
and
improvements
that
can
be
made
in
terms
of
in
terms
of
yes
in
terms
of
your
development
sort
of
life
cycle
right
in
general,
maybe
Tim.
This
is
probably
you
know
something
that
I
wanted
to
ask
you
as
well.
There's
seems
to
me
that
there's
also
another
element
around.
You
know
the
Innovation
that's
coming
into
the
space
right
around.
A
Obviously,
there's
trends
that
are
helping
us
move
and
accept
sort
of
you
know
the
move
towards
the
cloud,
even
in
regulated
spaces,
as
of
late
We've,
also
seen
the
introduction
of
you
know:
Revolution
revolutionary
tools
like
generative
AI,
like
GitHub
co-pilot,
name
to
name
one,
but
obviously
you
know
how
are
you
maybe
how?
How
are
you
and
your
team
sort
of
impacted
by
these?
You
know
these
Trends,
and
maybe
these
Investments
is
this
something
you
are
investigating
or
what's
what's
your
story
in
that?
In
that
sense,.
C
Yeah
I
mean
it's
definitely,
we
need
to
stay
ahead
of
the
curve
and
the
curves
move
in
quicker
than
it
ever
has
before.
So
it's
it's
absolutely
critical
that
we
that
we
do
that
and-
and
it
does
come
back
to
it
in
order
to
ensure
we
have
the
best
possible
environment
for
our
Engineers
to
work
in,
we
have
to
give
them
access
to
the
best
Technologies
and
that
needs
to
come,
irrespective
of
what
the
potential
risks
might
be.
C
So
we
need
to
be
able
to
break
those
down
understand
what
they
are
and
address
them
in
as
rapid
a
way
as
we
possibly
can,
and
that's
that's
where
the
the
mindset
and
cultural
element
comes
into
it
and-
and
it
really
is
about
having
a
an
attitude
and
almost
a
predisposition,
to
understanding
the
risk
that
the
business
is
willing
to
take
and
therefore
being
able
to
talk
in
meaningful
terms
across
all
aspects
of
the
teams
to
the
the
risk
proposition.
That's
there
for
for
the
business.
C
So
you
know,
if
we
think
about
it
in
terms
of
almost
the
the
SEC
devops
approach,
having
an
equal
amount
of
input
from
the
security
expertise
on
the
team
versus
the
operational
expertise
on
the
team
versus
the
developers
and
having
that
Fleet
free
flow
of
information
amongst
the
team
in
a
facilitated
way,
which
for
us
is,
is
a
right.
Now
is
a
combination
of
GitHub
in
terms
of
Automation
and
and
understanding
where
things
are
Azure,
devops
and
and
being
able
to
really
kind
of
track.
C
What's
happening
in
in
the
teams
and
bringing
all
those
things
together
and
make
sure
that
all
those
all
those
various
views
and
opinions
and
and
approaches
are
actually
represented
in
the
conversations
and
and
doing
that
in
an
effective
and
efficient
way,
actually
accelerates
the
the
teams,
whereas
previously
I
think
when
you
start
to
bring
you
know
your
cyber
and
risk
people
into
a
conversation.
It
actually
slowed
things
down,
we're
actually
seeing
that
that
becomes
almost
the
opposite.
C
A
Yes,
yeah
and
basically
I
shared
the
sort
of
responsibility
model
where
developers
and
Security
Experts
really
bring
they're
like
I,
said
their
core
expertise
to
the
same
table
and
and
actually
focus
on
the
right
outcomes.
Beautiful,
okay,
I
have
I,
there's,
there's
quite
a
lot
of
activity
in
the
Q.
A
A
so
I
definitely
want
to
make
sure
we
have
time
for
our
audience
to
ask
you
all
questions,
but
I
have
one
last
one
that
I'd
love
to
touch
on,
which
is,
if
you
want
to
share
any
tips,
Lessons
Learned
with
our
audience.
You
know,
there's,
obviously
for
those
in
the
audience
who
want
to
medium
embark
on
a
similar
sort
of
transformation
and
a
similar
Journey.
What
would
be
your
top
Pro
tips
or
or
maybe
a
lessons
learned
that
you'd
love
to
share
with
them?
Let's
see,
let's
start,
maybe
with
Helen.
E
E
It's
not
that
it's
actually
within
the
gut
rail
that
you
give
them
the
flexibility
to
innovate,
to
test
and
learn
to
do
your
research
and
development.
So
in
a
safe
environment
they
can
fail
and
they
can
make
mistake.
The
autonomy
is
like
you
can
try
any
tool.
You
want
any
software,
you
want
and
then
provide
it.
You
know
select
the
one
that
will
maybe
few
that
works
for
the
organization,
then
look
at
how
we
scale
and
Implement
that
across
you
know
the
group,
so
autonomy
is
very
important.
E
What
I
found
is,
if
we
don't
give
our
Engineers,
you
know
sort
of
the
freedom
Choice
autonomy
is
what
they
found
it.
It
becomes
like
a
steering
committee
to
make
every
single
decision,
so
it
takes
forever
for
them
to
just
even
evaluate
with
what
is
or
select,
Define
the
right
solution
to
implement.
That
is
taking
a
lot
of
the
time.
E
It
depends
on
the
business
and
the
nature
that
you're
in
so
it's
not
one
size
fits
all
and
even
across
the
bank
we
actually
have
gut
routes
in
terms
of
all
the
tests
and
Loan
we've
actually
create
an
environment
and
a
space
for
them
to
do
anything
that
they
want,
but
that
does
not
touch
any
of
our
production
data
or
production
system,
because
we're
running
a
bank
we
cannot.
We
our
risk.
Postural
appetite
for
you
know
leaking
customer
data
is
zero.
E
A
Amazing
sounds
like
if
you
allow
me
to
rephrase
right.
That
seems
like
the
key
ingredient
here
is
to
try
as
much
as
possible
to
find
that
that
happy
middle,
like
that,
that
sweet
spot
right
that
allows
organizations
to
as
much
as
possible
standardize
on
common
approaches
and
maybe
a
common
platform,
but
also,
at
the
same
time
acknowledging
the
need
for
teams.
A
You
know
with
different
Focus
areas
to
to
have
their
own
needs
of
their
own
additional
requirements,
and
so
finding
a
platform
like
GitHub
or
you
can
integrate
things
together
and
will
help
you.
You
know
in
general
achieving
that
that
balance
kaushik,
how
about
yourself?
What
would
be
your
Pro
tip
for
the
audience
so.
B
So
one
of
the
things-
and
this
might
be
this-
might
be
slightly
controversial
but
I.
Well,
it's
the
power
of
the
collective.
There
is
no
one
team,
there
is
no
devops
team
or
there
is
no
secops
team
that
is
responsible
for
uptimes
or
for
for
engineering
experience
at
Rhode
Island
we've
been
majorly,
successful
in
full
Industries.
Also
to
about
GitHub,
where
you
know
you
would
have
everybody
contribute
to.
You
know
different
a
variety
of
problem
statements.
There
are
no
wall,
Gardens
right,
you
face
a
problem.
B
B
There
isn't
an
engineer
who
would
say
that
you
know
this
is
not
my
problem.
Of
course
there
are
people
who
end
up
creating
those
guardrails.
There
are,
you
know,
Gatekeepers
to
each
of
these
systems,
but
every
single
individual
contributes
towards
making
this
this
safety
net
more
and
more
Rovers
toward
time.
So
that's
my
recommendation
and.
A
B
Yeah,
that's
a
great
point
right,
I
think
it
does.
What
you
should
also
be
doing.
Is
you
know
creating
an
environment
where
people
feel
excited
about
these
problems
right
and
they
are
exciting
problems.
They
are
hard
problems,
but
then
you
end
up
learning
so
much
from
it.
You
create
an
environment
that
Rewards
these
behaviors
right.
B
D
C
A
Interesting
yeah
and
we
do
find
that
correlation
between
you
know,
developer
happiness
and
productivity
right
and
the
two
things
are
very
connected
and
there's
studies
out
there,
including
they
call
foresgren's
latest
space
framework
analysis
which
I
recommend.
Maybe
we
can
drop
a
link
in
the
chat
for
those
who
are
interested
anyway.
Great
conversation
I
think
we
could
go
on
for
way
way.
D
Thank
you
so
much,
it's
been
a
fantastic
conversation
so
far,
and
the
first
question
that
I
wanted
to
ask
that
is
coming
from
the
chat
is
actually
you
just
mentioned
the
word
about
two
seconds
ago:
PG,
which
is
this
idea
of
Happiness
right
developer
happiness.
So
one
of
the
questions
coming
from
the
chat
is:
how
do
we
ensure
we
have
that
developer
Happiness
by
ensuring
we
have
a
stress-free
development
life
cycle?
So
how
do
we
get
that
stress,
feed
development,
life
cycle.
C
B
In
some,
in
terms
of
you,
it's
not
allowing
mistakes
to
happen
if
they're
regular
mistakes,
it
sort
of
takes
care
of
not
making
those
mistakes
to
happen.
So
reducing
anxiety
right,
one
is
a
sense
of
purpose
and
then
the
other
aspect
would
be
to
reduce
anxiety.
As
you
go
about
doing
what
you're
doing
I
would
imagine.
These
two
would
lead
to
a
better
engineering
experience
and
thus
lowering
the
stress.
E
What
personally
I
I
would
find
it
really
annoying
if
I
get
a
ticket
to
just
built
this
feature,
but
without
understanding
what
am
I
building,
who
am
I,
building
it
for
who's,
going
to
use
my
software
on
all
the
character,
upright
that
happiness
is
a
culture
thing
we
make
sure.
Basically,
our
engineer
is
basically
almost
like
touching
or
feeling
how
our
end
user
using
our
product
is
going
to
fill
and
how
we
make
an
impact
to
the
end
user
through
our
customer
or
client
at
that
point
in
time
and
I
tied
that
back
to
next.
E
D
I
love
those
ants
they're,
so
good
I
think
another
way
that
we
can
have
developer
happiness
and
reducing
stress
is
to
ensure
we
have
really
good
productivity.
There's
a
lot
of
questions
in
the
chat
about
productivity,
especially
being
a
panel
about
efficiency.
So
one
of
the
questions
is
around.
How
do
we
plan
to
have
that
really
good
productivity
throughout
the
development
life
cycle.
D
B
B
B
Look
at
when
you're
looking
at
measuring
productivity,
but
again
these
are
just
metrics.
Ultimately,
what's
important
is
once
your
feature
actually
goes
to
production?
Does
it
really
do
what
it
was
supposed
to
do
right?
Does
it
really
solve
the
problem
that
it
was
supposed
to
solve
for
from
a
functional
standpoint?
Does
it
scale
as
a
basis,
whatever
contracts
that
were.
E
B
B
D
I
think
that's
really
good
that
you
mentioned
the
word
metrics
and
measurement.
So
I'll
ask
a
follow-up
question,
which
is
also
coming
from
the
chat
page.
How
do
we
actually
measure
the
efficiency
of
these
tools?
You're
talking
about
you
know,
we
need
to
measure
to
ensure
our
productivity.
How
do
we
measure
the
efficiency
of
these
tools
and
I?
Guess
one
of
the
follow-up
questions
to
that
too.
Also
coming
from
the
chat
is
how
does
GitHub
help
in
measuring
the
productivity?
C
If,
if
the
the
customer
Drive
is,
you
know
something
has
to
be
released
on
a
particular
cycle
and
the
timelines
are
most
important,
then
you
know
we
need
to
know
what
those
metrics
are
and
be
able
to
measure
against
that
and
make
sure
that
we
understand,
if
it's
you
know,
have
to
get
everything
totally
totally
sorted
in
terms
of
security
and
and
and
reviews
before
we
can
move
into
the
next
step
and
there's
a
clear
gating
process
and
the
guard
rails
around
it.
Then
we
need
to
understand
what
those
what
those
metrics
are.
C
What
we've
started
to
do
is
work
really
in
a
portfolio
context,
where
each
team
has
a
clear
set
of
kpis
that
are
driving
the
whole
project
and
the
whole
team,
and
then
each
of
the
the
disciplines-
and
you
know
if
we've
got
an
engineering
team
and
a
tech
lead
and
and
then
you
know,
a
devops
component
of
that
project.
They
each
have
their
own
measures
that
are
related
directly
to
the
overall
team
measures
that
they're
able
to
track
and
measure
their
performance
against.
C
Without
that
Clarity
It
all
becomes
a
bit
of
a
muddy
mess
of
the
blame
game
around.
Well,
you
know,
I
I
did
my
thing,
but
someone
else
over
there
didn't
do
it
right
and
now
it's
broken,
and
we
actually
need
to
get
out
of
that
that
individual
mindset
and
actually
think
about
productivity
as
a
team
and
bring
that
back
into
the
to
the
tooling
to
to
be
able
to
measure
it
and
keep
it
visible
for
everyone
all.
E
E
We
should
track
what
we
learn
from
the
behavioral
and
and
to
Tim's
points
like
what
matters
so
now
we're
actually
measuring
what,
from
you
know,
picking
up
that
ticket
saying
I
need
to
build
feature
blah
acceptance,
criterias
ABCD
and
to
actually
commit
first
commit
PR
like
into
GitHub
in
terms
of
the
code
to
when
they
release
into
production.
That's
what
I
mean
by
you
know
when
you
actually
cut
it
to
When
You
release
it
that's
we're
measuring.
E
How
long
does
it
take
and
how
many
bugs
that
are
picked
up
in
system
test
unit,
test
performance
tests
and
stuff
like
that,
and
how?
How
many
times
do
we
have
to
go
back
with
this
feature
on
user
story
to
keep
on
rebuild
refactor
the
code
to
get
it
right
before
we
shipped
to
production?
That's
what
we
measure
productively,
because,
if
we're
pulling
in
taking
one
slice
of
metrics
and
not
measuring
the
end
to
end
value,
what
it
could
create
is
the
gamma
fine.
E
You
know
behavior
of
saying:
hey,
I've
deployed
this
10
times,
I've
built
this
100
times,
I
compile
this
code
whatever
whatever
and
I
raised,
you
know,
10,
PR
or
five.
You
know
20
PR
a
day
I'm
hitting
my
checkbox,
that's!
Actually
what
we're
saying
is
the
wrong
thing
to
measure.
The
right
thing
to
measure
is
based
on
this
sort
of
distance
requirement,
or
it
could
be
a
Tech
Deck
ticket,
because
we
tactic
that
and
requirements
same
it
doesn't
matter.
Is
it's
basically
picking
up
this
workload
you?
E
How
long
does
it
take
before
the
engineers
finish,
addressing
the
issue
or
built
with
a
new
feature
or
resolve
a
fix
or
whatever
and
ship
that
into
production?
That's
how
we
measure
it.
How
long
up
does
it
take
for
us
to
get
to
the
final
outcome
and
the
result
on
top
of
that
I
want
to
add
on
is
on
the
metric
space
we
actually
adopt.
You
know
the
SRE
principal
across
the
bank.
Measuring
you
know.
Things
are
running
in
production,
but
if
something
happened,
which
it
does
every
day
right,
nothing's
always
perfect.
E
How
long
does
it
take
for
us
to
restore
the
servers?
Like
your
mtti,
your
you
know,
all
those
Dora
metrics
we're
measuring
that
as
well
from
SLO
SRI
SOA
perspective,
as
in
how
it,
how
happy
is
our
customer
using
our
product
and
services
rather
than
how
fast
just
we
ship
stuff
into
production?
That's
productivity
is
important.
You
know
velocity
is
important,
but
what
if
quality
was
suffering?
You
know
by
increased
productivity,
that's
something
we
don't
want
to
see.
E
So
we
always
take
the
balance
as
in
what
is
the
right
level
of
you
know,
governance,
control
and
checking
we
need
to
have,
and
also
what
is,
the
availability
and
resilient
we
should
have
in
production.
These
are
the
stuff
that
we
constantly
need
to
measure
on
the
end-to-end
value
and
and
the
business
impact.
A
A
You
know
purpose
right,
so
they're
having
a
sense
of
shared
purpose
between
the
teams
and
the
individual
developers
to
to
bring
it
all
back.
But,
yes,
we
do
have,
of
course,
capability
built
in
in
GitHub
to
help
measure
things
like
what
Helen
was
calling
the
mttr.
So
the
mean
time
to
remediation
as
part
of
GitHub
Advanced
security,
it's
possible
to
track
how
we're
doing
when
things
go
wrong,
which
they
do
so
there's
no
there's
no
way.
A
We
can,
probably
you
know,
look
at
security
as
a
as
something
that's
ever
going
to
be
a
completed
challenge.
It's
always
going
to
be
part
of
I.
Think
of
the
software
development
life
cycle.
So
the
question
is
really
more
around.
How
long
does
it
take?
You
know,
for
a
developer
to
you,
know,
identify
and
resolve
a
security
incident,
but
also
just
in
general.
You
know
the
the
general
Dora
metrics
as
well.
You
know
we
heard
about
mean
time
to
Market,
or
you
know,
from
ideation
to
production.
A
How
can
we
measure
the
actual
effects,
effectiveness
of
our
development
teams
and
definitely
GitHub
as
a
built-in
insights
and
other
features
that
help
I
would
say,
product
managers
or
engineering
leads,
keep
an
eye
on
this
from
from
an
overview
sort
of
perspective
and
yeah
happy
to
share
more.
Maybe
after
this
call,
if
you're
interested.
D
Sounds
good
I
would
love
to
ask
so
many
more
questions,
because
there's
a
lot
coming
through
the
chat
but
I
wanted
to
end
on
this
question
because
I
think
it
ties
everything
together
really
nicely
and
that
question
is
around
creativity,
ideation
Innovation.
Now
we
know
that
development
teams
are
often
on
time
constraints.
So
how
do
we
actually
maintain
productivity,
perhaps
within
their
time
constraint,
but
also
allow
for
ideas
to
flow
and
flourish
like
what
are
your
thoughts
on
those
things,
Tim,
Curry
and
Helen?
Before,
as
we
wrap
up
this
fantastic
chat.
E
I'll
I'll
start
first
across
the
organization
as
part
of
the
engineering
transformation.
I'll
show
my
t-shirt,
we're
actually
promoting
the
20
engineering
time
across
all
our
Technologies
up
in
the
bank
and
that's
what
we
want
to
drive
Innovation
and
ideation
and
creativity.
So
the
20
time
is
not
just
there.
E
You
know
you
do
whatever
Pet
Project
you
want
is
actually
we're,
encourage
the
collaboration
across
teams
so
across
the
bank
like,
even
though
I'm
on
retail
banking,
but
I
can
collaborate
with
someone
on
business,
banking
and
so
on
so
forth,
to
work
on
a
challenge
that
the
business
you
know
face
and
and
come
up
with
ideas.
So
that's
what
we
mean
by
Innovation
creativity.
We
don't
have
boundary
on
that,
but
we
give
basically
the
20
time
to
our
Engineers
to
come
up
with
these
ideas
to
tackle.
E
D
C
I
definitely
think
it's
about
giving
people
time
and
my
my
argument
to
management
is
that
it's
always
been
to
management.
That
engineering
is
a
creative
discipline
and
people
need
the
the
the
bandwidth
to
be
able
to
be
creative
and,
and
so
it
has
to
be
baked
in
to
our
estimations
that
people
need
that
flexibility
to
be
able
to
do
it
and
there's
lots
of
ways
to
do
that.
20
and
you
know
we
take
time
out
kind
of
on
a
quarterly
basis.
D
A
Fantastic,
thank
you
so
much
Mish
for
helping
us
with
the
Q.
A
and
also
I
would
like
to
obviously
thank
our
panelists
today.
So
thank
you,
kaushik
Tim
and
Helen.
This
was
a
fantastic
conversation.
So
I
really
appreciate
you
taking
the
time
and
joining
us
today,
as
you
can
see
on
screen
we're
already
towards
the
end
of
this
three-day
series
of
of
conversations
and
sessions
as
part
of
GitHub
Galaxy.
A
I
would
like
to
just
say
that
if
anything
you've
heard
on
this
call
today
sounded
interesting
and
you
wanted
to
have
a
chat
with
us
at
GitHub.
Please
make
sure
to
use
the
book
a
meeting
button
on
the
top
of
your
screen
and
will
get
in
touch
with
you
shortly
and
lastly,
as
we
wrap
the
session
up,
I'd
like
to
also
please
ask
you
all
to
take
a
minute
or
two
to
complete
a
very
short
survey
about
your
experience
with
us
today.
A
You'll
find
the
link
in
the
survey
in
the
documents
tab
on
the
right
or
you
can
scan
the
QR
code.
That's
very
handy
on
screen
right
now.
We
designed
this
program
for
you
I
want
to
be
sure
that
you're
getting
the
most
value
out
of
your
time
here.
So
please
share
your
feedback.
We
do
take
it
seriously
and
we
hope
to
improve,
through
these
learnings,
to
optimize
future
programs
to
continue
to
raise
the
bar
for
you.
So
don't
be
shy.