►
Description
What are the different approaches to building effective developer experiences, despite the challenges linked to growing organizations and increasingly global teams? In this session, you’ll get real world insights on how to accelerate high-quality software development.
Join Annagreth Flierl, Director of Customer Success at GitHub, and Jonathan Pritchard, Customer Success Architect at GitHub, as they facilitate a discussion between Martin Reynolds, Head of DevOps at Advanced, and Rob Tuley, Head of Engineering at Flutter Entertainment, to learn about how they empower developers to collaborate, share best practices, deliver faster, and continuously improve.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
Dina
appreciate
it
so
welcome
everyone
very
excited
to
have
you
joining
us
for
the
fireside
chat
today,
where
we
will
hear
about
how
advanced
in
flutter
entertainment,
align
culture
and
technology
to
accelerate
software
delivery.
Quick
introductions
to
your
hosts
today,
we're
joined
by
jonathan
pritchett,
who
is
a
success
architect
in
our
maya
organization
here
at
github.
A
B
C
Thank
you.
Thank
you.
So,
yes,
I'm
rob.
Tully
and
flutter
is
a
well
it's
a
it's.
A
group
of
gambling,
successful
gambling
companies,
who've
consolidated
together
and
and
we've
got
offices
based
all
over
the
world,
and
I've
worked
and
within
this
industry
for
well
over
a
decade
now
and
through
various
different
roles,
and
my
current
role
is
as
inner
source
lead
and
so
really
that's
helping
to
promote,
sharing
between
a
number
of
different
kind
of
merged
companies
and
which
is
always
relatively
challenging,
and
I
always
describe
my.
C
C
B
D
Sure,
hello,
everybody
so
yeah,
I'm
martin
reynolds.
I
I
currently
work
as
a
head
of
devops
for
a
group
that
advanced
and
I've
been
in
the
software
industry
for
more
years
than
I'd
like
to
admit,
but
around
around
30
years.
At
this
point,
starting
as
a
developer
and
working
through
multiple
different
roles
in
multiple
different
sectors
to
ultimately
landed
advanced
about
11
years
ago,
it's
actually
the
company.
I've
stayed
with
the
longest
in
my
career.
I've
never
stayed
anywhere
11
years
before
and
hopefully
you'll
get
to
hear
about.
D
But
you
know,
generally,
we
like
to
sum
up
the
company
with
one
word
which
would
be
possibility,
because
that's
that's
what
we
want
to
represent
to
our
customers
and
you
know
internally.
We
we
generally
try
to
drive
things
by.
You
know
human
imagination,
ingenuity
endeavor.
You
know
to
bring
solutions
that
that
make
a
difference
to
our
customers
and
and
make
a
difference
to
people's
lives.
B
That's
awesome,
thank
you.
So
much
rob
thank
you,
martin
and
now
we're
in
the
metaphorical
campfire
section
of
our
fireside
chat
here
so
got
my
coffee
with
me
and
I
just
wanted
to
ask
firstly
to
rob
and
then
to
martin.
So
you
touched
a
little
bit
on
this
in
your
intros.
But
how
do
you
create
a
culture
of
sharing
both
within
and
across
teams?
Firstly,
to
you,
rob
and
then
we'll
go
to
you.
Martin.
C
C
I
think
it's
important
to
sort
of
state
it,
and
I
you
know,
I
also
think
it's
really
it's
quite
telling
what
people
celebrate
in
their
companies-
and
you
know
like
when
you
launch
a
new
feature
or
something
then
there's
obviously
usually
a
bit
of
a
fanfare,
and
you
know
celebration
of
that.
But
if
you
really
value
sharing,
then
what
happens
when
you
like
reuse?
That
feature
there's
a
really
nice
example
going
around
in
in
where
we're
in
flutter.
C
At
the
moment
where
one
of
our
brands
and
betfair
has
done
like
a
feature
which
improves
cash
out-
and
actually
you
know,
there's
a
bit
celebration
of
that,
but
actually
one
of
the
other
brands
has
just
reused
it
and
and
I've
seen
almost
more
celebration
of
that
reuse
than
the
original
feature,
because
in
some
ways
it's
better
value
because
it
was
so
cheap,
so
cheap.
You
know
and
it
gets
the
same
impact.
Everyone
knows
it
works,
and
so
I
think
you
know
do
you
celebrate
sharing.
C
Is
you
know
a
really
interesting
question?
And-
and
I
guess
the
final
point
for
handover
to
martin
would
be-
I
think
you
kind
of
need
to
make
it
easy
and
particularly
for
us,
we've
got.
You
know
a
lot
of
different
companies.
You
know
multiple
different
identity
systems
and
actually
just
being
able
to
talk
to
other
people
or
see
their
calendars
is
and
has
been
at
times
a
challenge
and
that's
taken
quite
a
bit
of
work
to
try
and
resolve
so
yeah
lots
in
that
last
point.
But
anyway,
martin.
D
We
do
a
lot
of
acquisitions
so
anyway,
getting
to
the
point,
I
would
actually
echo
a
lot
of
of
what's
been
said,
and
you
know
you
do
need
to
be
explicit
about
that-
that
goal
of
sharing
and
and
reason
we
we
sort
of
do
that
in
multiple
different
ways.
So
I
I
would
say
kind
of
on
the
sharing
success
and
sharing
approaches.
D
We
have
multiple
ways
of
doing
that,
so
we,
for
example,
we
have
regular
lightning
talks,
which
I
I
spoke
about
these
at
another
event
recently,
but
one
of
the
fun
things
about
them
is
when
we
started
them.
We
started
them
and
said:
okay,
we
need
to
have
10
right,
we'll
we'll
plan
10,
we'll
find
10
people
who
can
come
and
talk
for
15
minutes
about
their
success.
D
Now,
if
you
want
to
celebrate
your
success,
you
know
you're
joining
a
queue
of
people
and
it
might
be
three
months
before
you
can
get
a
slot.
You
know
and
because
it's
become
self-propelling,
we
we're
also
really
big
on
building
cross-functional
communities.
You
know,
and
we
have
multiple
vehicles
for
that,
so
we
have
like
communities
of
practice,
but
we
also
run
things
like.
We
have
something
called
coffee
ops,
which
we
run
on
a
regular
basis
in
a
monday.
You
know
and
people
turn
up.
D
We
have
a
section
specifically
to
talk
about
what
people
are
drinking
because
that's
important,
but
we
also
you
know
people
bring
their
questions
or
their
topics
that
they
want
to
discuss
and
we
discuss
them
openly.
You
know,
but
I
would
also
the
last
thing
I
do
is
echo
that
celebrating
success
again,
because
you
know
internally
to
help
drive
that
success.
D
D
You
know
and
and
quite
often
those
things
are
are
driven
out
of
the
work
that
they
do
and
the
you
know
the
success
that
they're
driving
and
and
often
you
know
it's
when
we
give
those
things.
It's
not
like,
oh
here
is
a
thing,
and
you
know
about
it.
We
genuinely
publish
those
out
through
our
internal
comms.
Let
people
know
you
know
they're
on
our
internet,
they're
in
our
friday,
update
emails
that
we
get.
You
know
for
friday
talk.
So
it's
all.
A
Yeah,
that's
fantastic.
I
do
know
we
had
another
question
actually
that
we
wanted
to
ask
right
now,
but
I
feel
jp
like
this
question
about
measuring
and
communicating
communicating
success
within
the
engineering
group
and
then
across
the
business
rob
is
there
anything?
Maybe
you
want
to
add
to
that
and
go
into
a
bit
more
detail
as
well,
because
in
previous
conversations
with
martin,
I
was
actually
quite
impressed.
A
A
C
C
You
know,
there's
lots
of
evidence
behind
it,
whether
that's
you
know,
there's
lots
of
stuff
from
dora
and
that
sort
of
thing
around
you
know
which
things
are
good
to
measure.
I
think,
broadly,
what
we're
trying
to
do.
The
top-level
metrics
is,
you
know,
be
efficient,
so
we're
looking
at
things
like
cycle
time
for
that
sort
of
thing,
we're
looking
to
be
predictable.
C
You
know,
obviously,
quality
needs
to
feature
somehow,
and
I
think
that's
you
know
the
quality
areas
where
I
think
you
see
a
lot
of
different
metrics
in
a
lot
of
different
ways
and
it's
not
clear
and
what
should
when
they're,
there's
no
really
leading
candidate,
and
if,
for
us
we
tend
to
look
at
things
like
you
know,
and
it
feels
quite
old
old-fashioned
in
some
ways
and
like
like
bug,
counts
and
defect
rates,
and
things
like
that.
But
you.
A
C
They
do
tell
a
story
and
they
they
are
helpful
and-
and
I
guess
the
the
last
point
there
would
obviously
be
you
know,
stability
and
which
I
thought
sure,
martin
you
could-
and
you
know,
go
on
on
about
for
for
quite
some
time,
but
I
think
top
level
there
for
us.
It's
around
recovery
time
really,
and
you
know,
we've
got
different
businesses
in
different
states.
Really,
we've
got
you
know
over
in
the
u.s
there.
C
Metrics
and
the
growth
and
the
acquisition
of
customers
and
the
the
growing
feature
set
is
more
important
to
them.
So
so
they'll
place
different
emphasis
around
the
place,
whereas
in
like
the
australian
or
the
uk
market,
with
big
established
players
with
over
50
of
the
market
and
therefore
any
mistake
is
expensive
so
that
that
kind
of
stability
point.
C
Trump
everything
else,
but
so
I
think
also
we
see
you
know
different
emphasis
places
on
different
areas
in
terms
of
measurement
and
what
we
don't
really
get
across.
The
entire
group
is
have
a
consistent
way
of
sharing
that
measurement
and
communicating,
I
think,
that's
you
know
I
think
that
will
come.
I
think
that's
just
a
matter
of
you
know
us
growing
into
it.
If
you
like,
after
the
recent
acquisitions.
A
D
D
Currently
I
you
know
I
said
I've
been
with
the
company
11
years,
and
I
remember
there
was
a
point
at
which
we
said
you
know
we're
moving
from
advanced
1.0
to
advanced
2.0
and
from
2.0
to
3.0,
and
you
know
we're
currently
working
on
advanced
4.0
and
and
that's
kind
of
to
do
with
how
we
maturing
as
a
company,
how
we
work,
but
the
a
lot
of
the
way
we
measure
those
those
kind
of
metrics.
Is
we
actually
set
up
standards?
D
So,
for
example,
if
I
take
you
know,
I
know
code
quality.
For
example,
you
know
we
have
a
which
includes
things
like
you
know,
test
coverage
and
various
other
metrics
around
security
of
code.
But
what
we
do
is
we
actually
have
standards
that
we
set
out.
So
we
have
like
an
advanced
bronze
standard,
an
advanced
silver
advanced
gold,
advanced
platinum.
You
know
that
that
cover
those
various
different
levels
and
we
encourage
teams
to
put
that
that
against
their
you
know
their
products.
D
So
you
know
I'm
working
on
this
product
and
we're
advanced
silver,
but
we're
moving
to
advanced
gold
right.
So
what
we're
trying
to
do
is
drive
consistency
and
you
know,
but
also
make
it
aspirational
and
and
gamify
it
a
little
bit.
You
know
to
do
that
and
we
do
that
across
multiple
things.
So
it's
not
just
you
know,
code
quality.
We
do
that
in
things
like
ci,
cd
maturity.
D
D
We
probably
have
a
product
that
is
in
that
coding
language
I
mean
hey.
We
still
have
40
year
old
coal
year
old,
cobalt
code
running
in
containers
in
the
cloud
you
know
this
is
kind
of
the
you
know,
the
variance
that
we
have.
That
doesn't
mean
that
we
can't
drive
to
those
same
standards
though,
and
we
do
very
much
drive
towards
those
those
kind
of
sharing
standards
like
shared
standards,
shared
goals
and
shared
way
of
recognizing.
D
You
know
that
that
people
have
an
aspiration
to
move
to
that
next
level
to
get
to
that
level
of
improvement.
The
other
thing
I
wanted
to
mention,
and
is
it's
less
on
the
code
metrics,
but
just
more
on
the
measuring
how
successful
our
the
impact
of
our
communities
are
and
stuff.
We
do
explicitly
go
out
of
our
way
to
to
kind
of
measure
the
engagement,
so
we
work
with
our
internal
marketing
team
they're,
actually
called
people
excellence.
Recently
rebranded.
Since
between
when
we
spoke,
we
don't
have
hr
anymore.
D
What
we
have
is
people
excellence
which
I
like
you
know
so,
but
essentially
you
know.
We
work
with
them
to
make
sure
that
we're
getting
engagement
across
all
the
teams
that
our
messages
are
being
seen.
You
know,
and
we
do
have
a
feedback
loop
around
that
to
say
you
know,
is
this
communication
channel
working?
Is
this
group?
Is
this
community
practice
working?
Is
it
reaching
all
the
parts
of
the
organization
that
we
wanted
to
do
you
know
so
we're
very
much.
D
You
know
engaged
that,
and
it's
not
just
a
you
know
it's
not
just
an
engineering
thing.
It
is
a
company
thing.
You
know
it's
a
company
culture
that
we're
trying
to
build
and
drive
and
we're
trying
to
drive
success
across
the
business,
because,
ultimately
you
know
our
internal
success
is
also
our
customer
success
and
that
drives
in
the
revenue.
A
Yeah,
thank
you
so
much
martin,
I
mean
I
think
in
the
conversations
prior
to
today,
it
sounded
like
extremely
elaborate
actually
and
you've
come
extremely
far
in
the
company.
You
mentioned
advanced
4.0,
deliberate
step
back
actually
to
assess
what
the
company
wants
to
stand
for,
how
you
connect
to
the
business
goals,
the
valley
chain
to
the
business
schools.
So,
yes,.
D
D
Yes,
yes,
I
did
yeah
so
yeah.
I
will
quickly
mention
that
so
one
of
the
things
that
there
was
a
feature
this
year
of
our
advanced
4.0
move
is
this
change
from
here's,
a
fixed
objective,
that
you
must
reach
to
a
matrix
of
15
priorities
for
the
business,
here's
our
priorities
and
actually
then
we
tie
everything
back
now
to
those
priorities
rather
than
a
you
know,
you
must
increase
sales
by
10
or
you
know,
mps
score
must
go
up
by
this.
What
we
actually
have
now
is
you
know
core
priorities
around
customer
success,
standardization.
D
You
know
automation
and
these
are
at
a
company
level,
so
not
just
engineering,
and
then
we
tie
our
engineering
goals
to
those
15
core
priorities
so
that
we're
getting
a
consistent
drive
towards
those
same
priorities
for
the
business,
so
that
was
quite
an
exciting
change
for
us.
I
you
know
I
was
very
excited
by
that
internally,
because
it
was
a
change
of
direction
for
us
again.
You
know
part
of
this
advanced
4.0,
but
also
it
was.
It
was
kind
of
nice
to
have
that
freedom.
D
B
Very
much
so
thank
you
so
much
for
sharing
that
and
we're
actually
going
to
move
around
in
space
and
time
a
little
bit
like
doctor
who
and
we're
going
to
go
to
our
second
question,
similar
theme
about
the
customer
success
which
is
dear
to
anna's
in
my
heart.
But
we're
going
to
take
this
in
a
direction
about
the
technology
journey
that
you've
gone
on
and
how
that's
been
successful
too,
so
to
rob
first.
B
C
Yeah,
I
think
you
know
in
particular
in
terms
of
of
sharing
across
the
entire
group.
We've
really,
you
know,
we've
kind
of
got
two
tools
that
are
that
are
shared
and
that's
slack
and
github
and
and
and
everything
else
is,
you
know,
kind
of
a
a
silo
within
a
particular
company.
So
you
know
I
think
in
the
first
case,
what
we've
done
is
try
and
optimize
off
the
back
of
of
what
we've
got
available.
C
I
think
in
you
know
in
particular
to
to
improve
delivery.
I
think
you
know
in
my
mind
that
kind
of
ci
pipeline
is,
is
always
a
good
spot
to
to
look
at
and
to
go
at
and
and
so
that's
where
we've
been
trying
to
concentrate-
and
you
know
it's
been
it,
you
know,
we've
been
finding
that
actually
moving
workloads
from
things
like
jenkins
to
github
actions
has
been.
C
C
What's
like
who's
responsible
for
it,
what's
going
on
with
it
and
all
that
sort
of
stuff,
you
know,
I
think,
there's
quite
a
lot
of
similar
similarity
with
some
of
the
stuff
that
we're
doing
internally
to
if
you
look
at
tools
like
spotify's
backstage
and
that
sort
of
stuff
as
well.
So
so
you
know
because
I
think
often
with,
like
you
know
often
with
this
sort
of
piece,
it
is
important
to
connect
the
human
aspect
to
the
technology
bit
so
you're
like
oh
well.
C
And
so
yes,
that's
I
guess
that's
a
couple
of
things
we've
been
doing.
I
think
you
know
we're
just
dipping
our
toes
in
the
water
to
get
up
code
spaces
at
the
moment,
which
I
think
it
was.
You
know
really
interesting,
because
I
think
you
know
how
do
you
like
you
know?
How
do
you
improve
software
delivery?
There's
there's
sort
of
loads
of
answers
to
that.
You
know
clown,
agile,
lean.
You
know
all
the
kool-aid
things,
but
in
some
ways
I
think
what
what
you
know.
C
One
of
the
things
that
I'm
looking
at
more
and
more
is
you
know
from
that
developer.
Experience
side
that
you
know,
I
think,
there's
some
actually
quite
simple
changes
that
you
can
do
to
improve.
You
know
you
know
all
our
lives
as
an
engineer
and
which
really
should
make
a
big
difference
from
a
delivery
point
of
view.
So
I
guess
on
that
note
I'll
I'll
stop
and
hand
over
to
martin
to
see
what
his
opinion
is
in
this
area.
D
I've
been
doing
it
longer
than
the
company,
but
you
know,
however
github
is
you
know
when
I
talk
about
you
mentioned
git
have
been
kind
of
core
and
it
was
interesting
because
you
know
I
was
recently
talking
with
the
pmo
office
who
we're
looking
at.
You
know
where
we
needed.
So
we
wanted
to
get
some
extra
extra
metrics
out
and
he
was
coming
in
so
going
so
how
how
many
get
have
reposters
do?
D
We
have
you
know,
and
I
was
like
well
it's
more
than
two
and
a
half
thousand,
so
you
know
when
we
say
it's
core
to
our
business.
It
is
you
know
that
is
where
all
our
critical
stuff
is
and
and
like
you
guys,
we've
actually
been
moving
sue
from
you
know,
jenkins
and
others,
but
we
have
quite
a
lot
of
jenkins
and
we've
been
making
that
journey.
You
know
to
have
actions,
you
know,
like
you
heard
me
mentioning.
We
have
you
know
somewhere
in
the
region,
140
odd
products.
D
Currently
you
know
we
have
about
18
products
that
are
left
on
jenkins
and
and
the
rest
of
will
move
to
github
actions,
and
it's
actually,
I
I
will
call
out
a
couple
of
things
that
have
been
incredibly
flexible
and
powerful
for
us
in
relation
to
that.
So
you
know
some
of
it
was
that
you
know
the
scalability
and
reliability
factor
and
actually
the
load
for
my
tool.
Chain
team
in
terms
of
jenkins
is
broken
again
and,
and
that
isn't
a
thing
anymore
right.
D
You
know,
in
fact
we
had
one
team
that
had
jenkins
o'clock
because
for
some
reason
their
jenkins
server
always
died
at
3
p.m.
On
a
on
a
daily
basis,
you
know
and
that's
gone
now.
You
know
we
have
elastic
scalable
workflows
that
are,
you
know,
are
delivered
automatically,
but
then,
beyond
that
you
know
the
other
part
which
has
been
really
powerful
for
us.
Is
that
ability
to
extend
it?
You
know
where
we
have
something.
That's
long
running.
You
know
like
some
of
our
integration
tests.
D
You
know
we
can
have
our
own
github
action
runners
in
our
own
estate
that
spin
up
and
run
those
long-running
integration
tests.
You
know,
but
still
having
that
one
place
to
be
able
to
track
where
it's
all
happening.
You
know-
and
you
know
so-
that's
been
incredibly
useful,
but
another
thing
and
this
loops
back
to
that
sharing
thing
in
the
in
the
first
thing.
D
So
one
of
the
things
that
we've
been
driving
around
is
kind
of
having
some
guard
rails
around
the
architectures
that
we
use
and
and
various
other
things
like
that
now
one
of
the
benefits
of
that
is
that
we've
been
able
to
drive
reusable
ci
pipelines
within
within
our
products.
So
you
know
we'll.
Have
we
have
a
github
actually
a
couple
of
repositories
that
have
you
know
shared
pipelines?
In,
for
example,
we
use
a
lot
of
serverless.
We
build
a
lot
of
serverless
apis.
D
We
have
a
standard
pipeline
for
that
and
it's
reused
multiple
times
and
maintained
once
they
just
pass
a
co.
You
know
attach
that
shared
repo
in
you
know
into
the
step
and
it
just
goes
ahead
and
does
all
the
build
and
the
publishing
and
the
you
know
the
deployments
and
it's
one
pipeline
used
by
multiple
teams.
You
know
across
the
business
you
know
and-
and
we
internally
talk
about
that-
something's
not
reusable
until
it's
reused
three
times
you
know,
and
you
know,
because
that's
where
you
start
to
get
the
values,
that's
real.
D
We
we
think
that's
a
three
times
multiplier.
You
put
a
little
bit
of
extra
investment
in
up
front,
but
once
it's
been
reused
three
times,
you've
you've
got
your
investment
back,
and
so
you
know
and
we've
seen
that
extensively
now
across
our
workflows
and
it
it's
become
a
drive
across
the
teams
to
kind
of
say
we
built
this.
We
think
it's
a
you
know
it.
D
It
ties
up
with
this
common
architecture
that
we
use,
whether
that's
like
containerization,
let's
reuse
this,
and
so
now
we've
got
like
a
you
know,
building
at
the
library
so
that
that's
really
great
and
the
other
thing
I
would
also
touch
on
is
code
spaces.
So
a
colleague
of
mine
who,
who
was
specifically
responsible
for
developer
experience,
you
know
he
loves
co-spaces
and
we
were
both
on
me
and
him
and
a
few
others.
D
Those
were
on
the
beta
and
we
were
very
keen
to
get
it
in
in
the
organization
and
and
we've
been
working
towards
that
we
do
have
some
teams
that
are
using
it
now.
But
the
big
exciting
thing
for
us
is
that
you
know
we.
We
run
an
annual
hackathon
which,
which
generally
involves
kind
of
four
to
five
hundreds
of
our
developers.
We
have
a
like
a
common
ui
platform
that
we
want
them
to
put
the
hacks
in.
D
So
you
know
this
year.
What
we're
doing
is
we've
built
out
a
code
space
for
that,
so
that,
when
it
comes
to
hackathon,
all
they
have
to
do
is
just
bring
up
visual
studio
code,
and
you
know
it'll
go
to
the
repo
connect
to
it
and
it
will
spring
up
with
everything
ready
with
all
the
ci
cd
associated
to
that
code.
Space
and
everything
it'll
all
be
ready
to
go.
D
So
you
know
what
we'll
actually
have
is
a
bunch
of
teams
that
don't
have
to
go,
and
I
remember
our
last
hackathon
because
we
had
a
group
of
people
who
are
around
24
hours
going
yeah,
your
node
installation
isn't
quite
right
or
you
haven't,
got
this
thing
installed
or
yeah.
You
need
to
get
standard
js
installed
globally,
whatever
it
was.
You
know
that
took
time
and
took
time
away
from
the
teams
being
able
to
innovate
this
time.
We're
super
excited
because
we
love
this
one
click.
D
You
know
it's
one,
click
you
go
to
the
repo,
you
click
once
and
they're
ready
to
go,
and
it's
so
fast
and
just
configurable.
So
we're
super
excited
about
that
and
generally
you
know
we
we're
planning
to
roll
out
co-spaces,
more
and
more
and
and
another
reason
why
that
helps
just
quickly.
I'm
trying
to
keep
it
short.
Another
reason
why
that
helps
is
you
know
we
have
product
teams,
but
we
also
have
shared
technology
centers.
D
So
we
have,
like
you,
know
a
dot
net
check
term
not
since,
and
a
node.js
technology
center
and
those
guys
move
projects.
You
know
maybe
every
three
four
months
they
might
get
assigned
to
a
different
project
depending
on
the
you
know,
the
features
that
or
you
know
the
investment
criteria
around
particular
products.
So
we
need
some
flexibility
in
the
workforce.
D
We
see
co-spaces
as
a
way
to
empower
those.
You
know
it
speed
up
the
onboarding
of
those
resources
as
they
move
from
project
to
project,
because
if
they
can
go
to
the
projects
and
just
connect
up
to
the
co-space
and
not
have
to
do
any
setup,
that's
specific
for
that
project.
That
means
they're.
You
know
time
to
value
in
working
and
onboarding
in
that
project
is
dramatically
reduced.
You
know,
because,
on
average,
when
we
were
looking
at
that
metric,
we
were
losing.
D
You
know
one
to
two
days
just
for
them
to
get
set
up,
so
they
could
run
the
application
locally
and
test
it.
And
now
you
know
the
goal
is
that
we
move
most
of
those
to
co-spaces,
because
we
believe
that
they
will
be
set
up
in
minutes
and
ready
to
go.
You
know
with
their
local
testing
environment
and
ready
to
go
and
set
up
for
whichever
application
they're
working
on.
So
that's
the
goal
overall,
because
it's
you
know
it's
an
enabler
for
us
as
a
business.
B
This
is
brilliant
to
hear
martin
rob
like
github
we've
been
on
that
journey
as
well:
dog
fooding
and
improving
code
spaces,
for
the
very
same
reason
whether
that's
developer
onboarding
using
it
in
our
interviewing
process
for
engineering
roles.
I
think
it's
a
really
exciting
feature
for
us
to
dig
into.
A
A
C
Yeah,
I
think,
there's
probably
there's
probably
a
couple,
and
I
think
you
know
so
you
know
if
you
thought.
Oh
weird
job
title
at
the
start,
when
you
saw
my
job
in
source.
Lead
is
because
you
know
my
particular
role
is
to
encourage
encourage
sharing
in
this
kind
of
in
the
source
model
internally
here
at
flutter,
and
I
think
you
know,
I
think,
we've
learned
a
lot
over
the
last
couple
of
years
in
trying
to
really
drive
that
sort
of
sharing.
C
What
you
really
need
is
you
need
all
the
artifacts
around
the
code.
You
need
to
be
able
to
see
that
and
execute
that
ci
pipeline.
You
need
to
be
able
to
execute.
You
know,
test
suites
against.
You
know
something,
and
if
that
something
is
a
test
environment,
that's
hidden
away.
Over
here
then,
it's
no
use
just
moving
the
code
and
the
test
suite
code.
You
kind
of
need
to
move.
All
of
that,
and
I
think
you
know
if
we
repeated
that
migration.
C
But
I
guess
you
know
I
I
guess
I
think
probably
my
hindsight
advice
would
be
we'll
choose
a
strategy
and
stick
to
it
rather
than
sort
of
go
well
yeah.
I
can
see
the
argument
for
that.
Okay.
Well,
let's
create
another
wall
over
here
and
that
sort
of
thing
so
yeah.
It's
probably
those
two
things
that
spring
to
mind,
but
we.
C
D
Okay,
so
it's
probably
become
apparent
that
as
an
organization,
you
know
we
do
go
through
iterations
of
change.
Quite
quite
regularly.
You
know-
and
I
I
I
don't
want
it
to
sound
like
it's
every
five
minutes,
because
it
isn't.
You
know
it's
it's
over
years.
If
you
see
what
I
mean
rather
than
you
know,
and
it
I
think
it's
like
a
journey,
it's
a
journey
of
maturity,
a
lot
of
the
time
you
know.
Well,
we
did
this
and
learned
that,
so
maybe
we
can
do
it
better.
D
There's
a
couple
of
things,
though,
over
the
years
and
over
those
multiple
you
know
changes
through
the
versions
of
advanced
and
the
way
we
work
and
the
way
we
operate
it
and
all
of
those
things
there's
a
couple
of
things
that
I
that
that
I
kind
of
I
would
do
differently
and
some
of
those
are
really
around.
You
know
partly
to
do
with
the
way
we
attacked
some
of
the
the
bigger
projects.
D
I
think
you
know
what
we
didn't
do
is
do
that
agile,
you
know,
or
let's
go.
Iterate
fix,
iterate
fix
it's
race.
What
we
did
is
try
to
build
some
giant
plan
that
then
we
executed
on
that
was
that
was
actually
painful.
You
know
it
was
harder
to
do
that
way
and
and
since
then,
we've
done
similar
projects
where
we're
kind
of
saying
you
know:
okay,
we
we're
here
we
want
to
get
to
here.
D
What's
let's
take
lots
of
small
steps,
and
I
know
I'm
just
saying
you
know
do
agile,
basically
right,
but
actually
I
you
know
we
find
more
and
more
that
that
applies
to
all
sorts
of
different
things,
and
certainly
when
we
do
things
like
rollout,
tooling
and
and
all
of
those
things
our
plans
are.
You
know
we
kind
of
have
those
objectives,
but
we're
doing
things
in
kind
of
you
know:
let's
try
it
right
and
then,
if
it,
if
it's
successful,
then
that's
it.
If
it's
successful,
let's
expand
it
out.
D
I
think
sometimes,
we've
been
so
tied
into
like
an
objective
to
meet
something
that
we're
scared
to
fail
and
that
you
know
the
fearless
is
actually
one
of
our
company
values
and-
and
I
think
in
the
past
you
know
we
were
so
worried
about
those
objectives
and
things
that
we
didn't.
Really
we
weren't
really
fearless.
We
were
tentative,
but
actually
I
think
that
being
fearless
and
and
not
being
afraid
to
fail
fast
and
just
kind
of
move
forwards
it.
D
D
You
know,
because
we
have
to
be
fearless,
execute
the
pace
and
you
know
be
one
advanced,
because
we've
we've
called
advanced,
but
the
website's
one
advanced,
but
b1
advanced.
You
know
which
is
around
that
kind
of
collaboration
and
engagement,
and
I
think
sometimes
we
have
the
value,
but
they
were
abstract
and
actually
making
them
part
of
the
culture
would
have
would
have
helped
us
with
those
those
journeys
where
people
were.
You
know
afraid
of
change,
because
which
is
the
other
thing
right.
D
Change
always
brings
worry,
and
you
know-
and
I
think
doing
those
small
but
fast.
You
know
iterations
of
what
succeeds
and
what
fails
it.
It
makes
the
change
less
scary
for
people
and
you
can
bring
them
on
the
journey
with
you.
You
know,
because
that's
what
you
really
want
to
do
you
want.
You
want
to
bring
people
with
you
because
generally
change
fails.
D
You
know,
and
it's
something
that
we've
certainly
I've
got
better
at
and
I
think
we
as
an
organization
have
got
better
at
as
well.
You
know
that
kind
of
maturity
around
managing
change,
especially
because
we
do
constantly.
You
know,
you
know
we
say
we're
doing
this
now,
but
how
can
we
do
better?
And
then
how
can
we
do
it
better?
Which
means
there
is
continual
change.
You
know,
and
I
think
businesses
that
stand
still
ultimately
fail.
You
know
because
the
markets
move,
you
know
technology
moves
as
we
all
know
at
a
rapid
pace.
D
You
know,
and
I
think
we
have
to
move
along
with
it,
and
that's
that's
true
about
you
know
the
the
you
know
the
way
that
we
implement
stuff
and
and
the
way
that
we
manage
that
change,
especially
you
know
the
last
two
years
everything
has
changed.
You
know
we
were
mostly
office
based
and
now
we're
you
know,
a
very
big
mix
of
home
and
office
and
and
wherever
else
people
work
from.
So
you
know
it
is
a
very
changing
world.
A
Yeah,
it's
really
good
insight
into
how
people
culture
technology-
it
all
really
is
connected,
isn't
there
and
then
I
guess
also
speaking
to
the
psychological
safety
right
permission
to
fail.
It's
expected
that
you
do
fail
as
long
as
you
learn
and
we
reiterate
jointly
and
it's
okay
management
is
behind.
You
got
your
back
as
well.
It's
a
really
good
example
there.
Thank
you
for
sharing
that
martin
rob.
B
Yeah,
maybe
let's
let's
stay
here,
because
I
think
that
theme-
and
I
think
the
unifying
theme
between
both
of
your
businesses
is
the
brands,
the
products,
the
complexity
and
then
the
the
pace
of
change
that
is
required
as
martin
was
saying
there.
So
maybe
let's
touch
on
this
idea
of
how
you
manage
the
complexity,
both
with
the
people
side
of
things
and
the
technology
like
rob
earlier?
You
were
touching
on
about
that
idea
about
discoverability.
B
How
do
you?
How
do
you
know
what
another
part
of
the
organization
is
doing
so
that
you
can,
as
martin
said
earlier,
get
to
the
point
where
you
can
reuse
three
plus
times
to
get
the
value?
I
was
wondering
if
you
have
any
lessons
there
from
the
inner
source
perspective,
perhaps
rob
about
how
how
you've
been
successful
in
that
journey.
C
B
D
C
Optimum
and
how
mine
was
saying:
oh,
that's,
that's
come
down,
you
know
in
their
organization.
I
was
thinking,
oh
actually
in
ours.
What
we
tend
to
see
is
different
groups,
and
different
areas
are
in
quite
different
places
and
often
this
there
you
know
I
I
always
think
the
the
the
step
size
tends
to
reduce
the
the
more
sophisticated
you
get,
because,
basically
you
know
in
the
beginning.
It
is
quite
obvious
that
you
should
do
x,
because
you
know
everyone
else
has
told
you
so
well.
C
You've
got
an
expert
who's
joined
you
who
has
done
this
10
times
before
and
it's
finally
like
okay.
Well,
let's
just
do
that
step
because
that
will
be
faster
just
to
jump
to
a
better
position
that
is
very
well
known,
whereas
as
soon
as
you
get
more
to
the
edges
of
of
what's
what
might
work
in
your
organization,
then
then
you
kind
of
need
to
reduce
your
step
size,
because
it's
effectively
more
experimental
and
it's
more,
you
know
it's
more
likely
to
fail.
So
you
kind
of
want
to
fail
fast
and
fail
small
right.
C
So
I
think
I'm
going
off
on
a
bit
of
a
weird
tangent
here,
but
I
was
just
thinking:
oh
martin,
how
it
you
know
how
it
how
it's
interesting.
I
think,
there's
also
an
effect
over
time
that
you
tend
to
want
to
reduce
your
step
size
as
well.
You
know,
as
you
get
more
sophisticated
with
stuff
in
in
terms
of
in
managing
complexity.
C
C
So
so
you
know
the
only
way
you
can
really
make
that
work
is
it.
You
know
effectively
come
behind
those
standards
and
make
their
adoption
like
incentivize
their
adoption
and
on
the
basis
of
well
there's
there's
value
in
those
standards,
because
if
you
obey
this
standard,
then
effectively,
then
xyz.
All
these
things
suddenly
start
working
for
you
and
your
job
becomes
easier.
You
know
and
then
and
then,
when
teams
don't
you
know,
follow
that
standard.
You
can
start
asking
really
awkward
questions
on
the
lines
of.
C
C
Spend
no
time
doing
this
because
they
follow
this
standard
and
then
a
bunch
of
these
standard
internal
tools
work
for
them.
So
you
know,
and-
and
so
you
know
and
that's
the
I
guess-
that's
the
you
know
fairly
well
known
concept
of
you
know,
laying
playing
paths,
golden
paths
whatever,
but
you
know
I
think
that's,
but
you
know
I've
seen
that
work
again
and
again
and
again
and
there's
a
really
successful
approach
to
standardizing.
C
And
if
you
want
to
reduce
your
kind
of
overall
complexity,
then
I
think
that's
what
you
need
to
think
about
doing
in
terms
of
driving
that
forward.
So
I
guess
from
an
inner
source
approach.
You
know,
there's
a
bunch
of
complexity
there,
but
you
know,
and
but
really
what
we're
trying
to
do
is
is
is
effectively
set
a
set
of
like
familiar
language
and
standards
around
that
and
and
so
that
it's
you
know,
people
understand
what's
going
on
quickly
and
easily,
you
know
so
some
of
that
might
be
saying.
C
Well,
actually
you
know
we
have.
For
example,
you
know
we
have
an
inner
source
pyramid
and
three
different
sharing
models
and
we
say
well,
look.
You
know
you're
in
one
of
these
sharing
models
and
that
helps
different
teams
talk
to
each
other
and
when
they
talk
to
each
other,
you
know
they'd
be
like
well.
What
sharing
model
do
you
support?
Am
I
happy
with
that
or
not,
and
they
don't
have
to
have
this
long
conversation
about
it?
They
can
just
tell
them
the
name
of
it
and
they
understand
that
name.
C
So
you
know
some
of
that
is
common
language,
and
you
know
in
other
areas.
It
might
be
things
like.
You
know,
standardization
of
that
ci
pipeline
or
simple
things
like
just
naming
conventions
on
on
repositories.
You
know,
so
it's
really
interesting
to
hear
about
martin's.
You
know
kind
of
standard
building
blocks
of
a
ci
pipeline
thing
like
that.
You
know.
That's
not!
You
know,
that's
not
really
where
we're
at
yet,
but
that's
that's.
C
Definitely
the
direction
that
that
we're
heading
so
yeah
that
would
be
you
know,
I
think
that's
where
I'd
step
first
to
reduce
complexity
is
okay,
well,
think,
standards.
Okay
standards
are
hard
because
no
one
obeys
them.
Therefore,
how
do
you
add
value
around
those
standards
that
people
will
actually
obey
them?.
B
Super
interesting
and
standardizing
the
language
I
think
is
that
is
the
bit
that
came
out
for
me,
so
that
you
don't
have
that
preamble,
that
you
have
that
safety
net
as
well
as
anna
mentioned,
and
you
know
that
oh,
we
fall
in
these
different
groups
and
this
is
the
paved
pathway.
As
you
mentioned,
rob,
and
I
think
you
and
I
think
we're
all
keen
to
hear
what
martin
has
to
say
there
about,
because
you
were
talking
about
the
different
standards
and
the
the
certifications
in
it
in
a
way.
Martin
yeah.
D
It's
interesting,
so
I'm
going
to
kind
of
cover
in
a
couple
of
different
ways,
but
I
did
want
to
talk
about
that
kind
of
discoverability
part
and
the
you
know
how
how
we've,
because
that
was
difficult,
so
having
a
common
way
to
discover
stuff,
was
actually
difficult
for
us,
because
we
were
very
much
at
disparate
sets.
You
know
if
I
go
back
six
seven
years,
you
know
we're
almost
like
you
know
a
bunch
of
separate
businesses
that
just
happen
to
all
be
called
advanced
rather
than
rather
than
one.
D
You
know,
joined
up
organization
if
that
makes
sense,
and
and
we've
gone
through,
multiple
iterations
and
we've
used
various
different
tools.
But
ultimately,
what
we've
come
up
with
is
a
standard
way
for
kind
of
handling
things
like
developer
documentation
around
our
tooling
around
our
platform.
You
know
and
getting
that
common
language
in
place
around
how
we
use
it,
but
also
for
us,
the
some
of
that.
The
key
of
that
was
around
empowering
our
developers
to
use
it,
and
so
what
I
mean
by
that
is
actually
kind
of
saying.
D
D
D
It's
also
a
place
where
people
can
search
for
the
reference
architectures
that
we
have,
and
you
know,
pull
out
those
or
so
and
know
that
these
are
the
pipelines
that
are
associated
that
reference
architecture.
And
actually,
if
you
just
do
this,
you
know
we
have
goals
around
kind
of
being
able
to
build
composable
infrastructures
and
essentially
being
able
to,
if
you
like,
have
a
hello
world
within
you
know,
within
a
day
or
within
an
hour
or
within
10
minutes
of
being.
You
know
so
like
speeding.
D
Those
adoptions
up
to
make
it
easy
for
developers
to
do
you
know,
and
so
now
we
have
that
in
there
and
we
have
you
know
and
it's
we
made
it
searchable,
but
ultimately
it's
a
github
repo
and
everybody
goes
to
get
a
repo.
You
know
if
they
want
to
contribute
and
they
go
to
one
end
point
you
know
and
we've
been
extending
that
out
with
our
you
know,
for
example,
from
a
brand
side
and
the
ux
ui
and
our
user
experience
stuff,
which
I
won't
go
extremely
mad
on.
D
But
you
know
all
of
our
design
system
essentially,
and
everything
is
also
it's
done.
The
same
way
right.
It's
a
github
repository
people
can
contribute.
It's
one
place
that
people
go
to
it's,
you
know
they
can
find
that
and
use
it.
You
know
and
that
again
that
kind
of
fits
into
that
levels,
because
in
the
same
way
we
have
levels
for
you
know,
maturity
of
you
know,
code,
quality,
testing
etc.
As
we
talked
about,
we
also
have
that
for
brand.
You
know
unbranded.
C
D
Know,
etc,
etc,
etc.
So
we
have
those
same
levels.
We
constantly
try
and
build
in
these
aspirational
levels
that
people
can
get
to
so
they
can
get
from.
I
know
I'm
here,
but
the
goal
is
to
be
here.
You
know,
and
it's
you
know,
and
what
I'm
talking
about
there
with
the
brand
is,
you
know
we
acquire
companies
often
and
we
want
their
products
to
look
like
all
of
our
other
products
right,
so
that
people
are
having
that
same
experience
when
they
use
our
products.
D
D
You
know
across
our
products,
so
you
know
again,
but
we
do
that
through
levels
right,
you're
here
and
you
drive
it
and
it's
you're
trying
to
achieve
the
excellence
which
is
at
the
top.
So
that's
that
that's
kind
of
why
we,
you
know
why
we
do
it
and
how
we
do
it
and
we
do
it
constantly
and
it's
iterative.
You
know
and
the
the
final
point
I
would
make
about
those
levels
is:
there
has
to
be
governance
and
review
for
those
levels
to
work.
A
C
D
You
know
the
time
to
value
because
a
feature
can
get
from
you
know
from
dev
to
production
faster,
because
we
have
better
code
quality
and
better
testing
in
our
ci
cd.
Maturity
means
that
that
time
to
value
for
us
as
a
business
and
for
the
customer
is
shorter
and
then
sharing
the
success.
So
do
it
with
one
team
share
the
success,
you
know
tell
everyone
hey
we
moved
up
from
here
to
here
it
reduced
this,
and
now
we
get
our.
You
know
our
features
to
our
customers.
D
You
know
in
in
one
sprint,
instead
of
two,
you
know
whatever
it
is,
but
actually
sharing
that
success
that,
because
then
you
know
business-wise
not
just
engineers.
Your
product
managers
want
that
success
too
right
and
your
sales
people.
They
want
that
success
too,
because
they
want
to
be
able
to
say
hey.
Now,
we've
got
all
these
new
shiny
things
that
make
us
go
yay,
so
you
know
so
you
know.
Sharing
the
success
is
how
you
you
know,
sharing
the
value,
which
is
what
rob
was
talking
about,
is
actually
how
you
drive
some
of
that
success.
B
Yeah
good
marketing
there
as
well
yeah.
I
love
that
and
actually
we've
brought
that
to
a
sort
of
natural
conclusion
and
actually
we're
going
to
talk
about
the
key
takeaways
here
and
it'd,
be
interesting
very
briefly,
to
hear
if
we
agree
with
these.
So
thinking
about
the
key
takeaways,
the
themes
that
we've
heard
from
yourself
martin
and
rob
a
lot
about
the
value
of
devops
and
the
value
chain.
In
terms
of
how
does
the
software
delivery
align
with
the
businesses
aims?
And
how
do
we
communicate
that?
B
How
do
we
intentionally
go
slow
to
go
faster
later,
just
now
and
at
the
top
of
the
session
as
well,
we
talked
about
communicating
success,
sharing
those
stories
being
very
deliberate
about
those
those
leaders
and
then
encouraging
the
fast
followers.
We
talked
a
lot
about
the
principles
of
sharing
knowledge
of
the
transparency
behind
that
about
the
organizational
design
and
the
apparatus
which
encourages
a
meritocracy
across
different
teams
and
products,
and
they
can
be
globally
distributed
as
well.
B
B
Yes,
but
I
think
a
summation
there,
so
that's
absolutely
perfect,
and
that
just
brings
us
to
our
next
section
there,
with
the
q
a
actually-
and
it's
been
a
little
bit
quiet
today
so
far,
because
I
think
everybody's
been
enthralled
by
the
discussion
so
we'll
just
briefly
cover
one
which
and
will
only
go
to
one
of
you
on
this
one
in
terms
of
time.
But
martin
asked:
how
do
you
combine
sharing
with
least
privileged
access
and
maybe
we'll
go
to
to
to
rob
on
this
one?
If
that's
okay,.
C
You
do,
and
you
know
what
access
they
have
so
most
the
time
from
a
sharing
point
of
view,
what
you
really
want
to
do
is
share
read
access.
You
want
to
share
like
a
really
low
set
of
privileges,
and
you
know,
or
if
you're,
looking
after
a
contribution
model,
you
want
to
share
slightly
more
elevated
privileges,
but
you
still
want
to
have
a
really
small
subset
of
people
who
are
you
know
looking
after
and
reviewing
and
approving
contributions
to
kind
of
key
branches
that
make
it
further
on
in
the
kind
of
production
chain.
C
So
you
know,
so
I
think
from
that
point
of
view.
Actually
what
you're
doing
from
a
sharing
point
of
view
is
you're
actually
expanding
your
low-level
privilege
group-
and
I
think
you
know
what
I've
personally
observed-
is
that
actually,
what
you
tend
to
see
is
an
improvement
in
the
overall
security
posture,
because
you
know
if,
for
example,
you
know
that
you've
got
3
000
engineers
with
read
access
or
or
potential
access
to
your
repository.
C
It
sharpens
your
mind
in
terms
of
well.
You
know,
I
really
need
to
think
about
quite
carefully
the
flows
through
this
repository.
How
you
know
who's
got
what
access,
where,
how
do
I
you
know
and
and
what
it
tends
to
do,
is
sharpen
that
mind
around
thinking.
Well,
actually,
I
really
need
to
think
about
access
control,
different
levels
of
permissions
and
that
sort
of
thing
versus
actually,
if
you've
got
a
group
of
you,
know,
50
engineers,
who
you
know
the
natural
temptation,
I
always
think
is
just
oh,
let's
just
all
give
them.
C
You
know
elevated
privileges
over
here,
which
is
it's
obviously
very
bad.
So
so
you
know,
I
think
in
some
ways
you
know
that
that
is
possible
to
link
those
two
things
together
to
your
own
advantage,
but
you
know
it
tends
to
come
up
quite
a
bit,
certainly
when
you're
talking
with
security
teams,
or
certainly
when
you're
doing
like
kind
of
iso
2700
stuff
like
that,
where
actually
some
of
those
things
are
much
more
embedded
around
well,
actually,
what
is
just
the
numbers
of
access
and
that
sort
of
thing
so
yeah.
A
Thank
you
rob
and
martin.
Well,
we've
come
to
the
end
of
our
time.
Here.
Really
it's
been
a
pleasure
both
of
you
thank
you
for
joining
us
today
and
really
taking
us
on
your
journey
very
inspiring.
I
think
for
all
of
us
here
that
listened
everyone
in
the
audience
really
appreciate
you
being
there
with
us
today
and
we'd
love
to
hear
your
feedback,
any
questions,
feedback,
follow-up,
here's
a
nice
qr
code.
Let
us
know
what
you
think
and
we
hope
to
see
you
again
soon.
There's
one
little
announcement.
A
next
slide.