►
Description
What’s most important to you in your business? The answer to that question, and whether or not you can prioritize it, is influenced by your team’s productivity. But for many organizations, things like tech sprawl, lack of collaboration, and time-consuming manual processes prevent developers from focusing on what matters most. In this session, Florin Creanga, Principal Cross-Platform architect at Vodafone will cover how he removed roadblocks from their developer’s workflows and increased developer productivity in their organizations. You’ll also learn how Vodafone is deepening their usage of their developer platform by building a more collaborative culture.
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
Hello,
everyone
and
a
very
happy
Friday.
We're
super
excited
that
you're
joining
us
on
our
final
day
of
GitHub
Galaxy
today,
and
really
hope
that
you
enjoyed
the
last
couple
of
days
of
the
event
in
the
sessions
that
are
happening
today.
We
are
exploring
how
to
supercharge
workflows
with
Enterprise
ready
tools
that
will
improve
productivity.
A
A
If
you
feel
there's
not
enough
time
actually
to
get
some
of
the
most
pressing
questions
and
your
curiosity
answered
and
addressed,
there's
actually
another
button
where
you
can
book
a
meeting
with
us
for
a
meeting
or
perhaps
in
a
bit
more
with
a
bit
more
time
and
with
experts
from
GitHub,
you
can
do
a
separate
Deep
dive
on
some
of
the
topics
optimal
viewing.
We
recommend
that
you
use
the
Chrome
browser
if
you've
got
any
issues
with
that.
A
There's
a
couple
of
guidelines
on
how
to
address
these
most
likely,
and
perhaps
it
just
needs
a
refresher.
If
you
need
assistance
with
troubleshooting,
do
you
have
a
look
at
the
docs
tab?
There
are
help
documents
available
and
hopefully,
with
these
it
shouldn't
be
an
issue
then
to
participate
in
our
session
today.
B
C
Sure
yeah
so
I'm
feeling
a
principal
architect
at
Vodafone
group,
currently
driving
the
definition
and
the
strategy
of
our
trading
strategy.
And
then
let
me
tell
you
something
about
polar
fornic
is
that
their
people
still
have
not
heard
of
Vodafone
Vodafone.
Traditionally
we
used
to
be
in
the
Telco
space.
We
used
to
sell
Mobile
plans,
broadband
and
select
Telco
related,
but
right
now
we're
halfway
through
our
journey
to
become
a
deco
company
and
then,
as
part
of
the
journey.
C
We
are
putting
the
software
engineers
at
the
core
of
everything
we
do,
but
to
build
great
products.
What
cannot
happen
in
silos
and
because
of
that
we've
brought
together
all
the
engineering
teams
across
Europe
under
one
umbrella
and
as
part
of
it.
We
are
also
creating
an
employee
brand
that
we
call
Vodafone
engineering.
Then
you
can
see
in
my
t-shirt
today
and
then
we
want
all
our
Engineers
to
be
part
of
it.
C
Currently,
we've
got
roughly
10
000
Engineers
working
for
us
in
Vodafone
and
the
next
stage,
or
so
we
are
looking
to
go
up
to
17
000
engineers,
and
then
my
role
here
at
Vodafone
is
to
actually
harmonize
the
way
our
developers
write
code,
the
way
they
build
products
and
then
drive
this
digital
transformation
culture
that
we're
so
excited
about.
Then
I'm
excited
to
be
here
and
share
some
of
the
findings
with
you
today.
B
D
D
My
name
is:
oh
I'm,
a
veteran
of
the
devops,
if
I'm
a
little
bit
called
so
don't
judge
me
and
I
work
at
the
nice
call,
which
is
a
multi
National
company
with
roughly
9
000
employees
and
5
000
of
them.
In
balance,
companies
Youjizz
has
a
lot
of
lines
of
businesses
and
the
anti-frauding
world
call
center
solar
security.
It's
very
vast.
It's
very
vibrant.
It's
ever
changing
I'm
managing
a
team
which
is
very
particular
in
the
industry.
D
B
E
B
E
What
a
great
place
to
be!
Thank
you
so
much
for
having
me
here.
In
the
conference
my
name
is
Taryn
Aurora
I
am
the
regional
head
of
software
engineering
and
devops
at
avenard.
I
also
lead
the
modern
app
transformation
which
is
very
much
inclusive
of
cloud
transformation
and
how
to
bring
the
goodness
of
modern
software
engineering
and
devops
practices
into
the
hands
of
developers.
E
My
background's
always
been
software
engineering,
so
very
passionate
about
this
subject.
I
am
also
a
Microsoft
MVP.
An
author
I
often
speak
in
international
conferences.
I
was
at
build
and
I'm
looking
forward
to
the
next
builds
as
well.
It's
it's
a
pleasure
to
be
here
today
and
looking
forward
to
having
some
great
questions
coming
from
the
audience
as
well.
B
Oh
brilliant,
thank
you
so
much
we're
so
fortunate.
Now,
let's
get
started
with
a
little
bit
of
an
exercise
here,
because
we're
here
to
talk
about
developer
productivity
and
efficiency.
We
want
to
know
what
that
might
look
like
for
you.
So
in
a
moment
we'll
start
a
poll
and
what
we
would
like
you
to
do
is
think
about
this
question
here.
So
when
you
think
about
developer
efficiency,
which
areas
are
you
looking
for
your
tooling
to
support
you
in
and
it
could
be
collaboration
and
in
a
source,
it
could
be
to
reduce
that
developer
context.
B
A
B
You
can
see
it's
a
little
bit
of
a
trick
question
as
well.
There
I
always
find
it
interesting
that
when
you
show
the
results
live,
it
changes
people's
behavior,
you
know
I'm
exactly
the
same.
Do
you
hold
back
and
wait
to
see
what
other
people
are
doing
or
are
you
confident
and
you've
got
a
highly
opinionated
answer
already?
B
So
we've
got
a
bit
of
a
share
here
very
interesting.
The
reduction
of
context.
Switching
is
coming
up
quite
hard
there,
along
with
the
interest
in
AI,
but
most
of
all,
all
of
the
above
and
I.
Think
that's
what
our
speakers
here
today
will
likely
be
touching
on
as
well.
So
thank
you
for
your
contributions
and,
let's
get
to
our
chat.
B
C
Yeah,
thank
you
JB,
so
about
80
miles
ago
two
years
ago
we
started
this
very
big
digital
transformation
in
Europe
to
bring
together
all
those
engineers
and
as
part
of
it.
The
initial
step
was,
let's
standardize
and
harmonize
our
developers
tooling.
But
what
do
we
mean
by
developer
tooling,
and
actually
we
did
something
similar
to
what
you
just
did
JP.
We
asked
like
a
survey
to
our
engineer,
saying:
okay,
guys,
what
do
you
mean
by
developer
tooling,
when
I'm
talking
about
them?
C
What
you
understand
and
then
we
started
seeing
all
the
tools
that
they
use,
but
some
tools,
as
you
know,
they
might
support
multiple
capabilities
and
then,
since
I'm
sitting
in
the
Enterprise
architecture,
the
wind
Enterprise
architecture,
we
love,
devote
astronomies
I
started
putting
together
a
tooling
taxonomy,
and
then
we
realized
that
actually,
we've
got
400
cooling
capabilities
in
Vodafone
and
then
we
had
to.
We
had
to
sort
of
like
split
those
into
multiple,
like
value
streams
to
group
them
and
then,
in
the
end,
we
we
ended
up
with
multiple
value
streams
for
our
tools.
C
So
what
we
need
to
make
sure
we
take
it
to
account
is
we
need
to
have
tools
for
like
planning
the
software
buildings
of
the
software,
releasing
it
and
then
afterwards
operating
it,
but
one
area
which
also
it's
apparent.
We
need
to
have
the
same
enablers
and
then,
as
part
of
the
of
the
enabler
we've
got,
chat,
tops
or
or
chat
like
like
Microsoft
teams
or
slack,
doesn't
matter.
C
So
when,
when
I
think,
then
we
think
in
Vodafone
about
the
developer
tooling,
we
think
about
all
the
tools
end
to
end
which
allow
us
to
take
a
software
from
the
idea
to
the
release
to
the
feedback
and
then
go
back
into
the
loop
I
know
some
I
might
mention
agile
without
saying
agile,
but
actually
this
is
really
kind
of
like
how
we
look
into
it.
Because
then,
unless
you
take
into
account
everything,
we
are
not
going
to
be
able
to
have
an
efficient
developer,
tooling
ecosystem.
B
Oh
brilliant,
brilliant!
Thank
you
for
that.
So
I'm
hearing
about
the
consolidation
I'm
hearing
about
the
listening.
First
of
all,
those
are
really
important
themes
and
I'm
hearing
about
the
lines
of
communication
within
the
business
to
you
or
and
then
to
you
next
Taran,
or
does
that
look
similar
to
you
in
your
organizational
context?
Tell
us
a
little
bit
about
that.
If
you
may.
D
Yeah
and
I
would
take
the
first
question
in
a
little
bit
in
an
orthodox
fashion,
if
you
will
in
many
ways
we're
looking
on
it
from
holistic
standpoint
and
also
my
questions
are
going
to
be
holistic,
because
I
think
we
are
in
the
Tech
Community.
We
are
striving
to
think
about
things
more
about
abstracts
and
not
like
technology
oriented.
D
In
essence,
we
are
not
robots,
we
are
human
beings
and,
as
such,
we
have
a
lot
of
mixture
of
things
coming
together
into
one
pot,
and
once
we
started
thinking
that
way,
it
was
very
easy
to
get
into
the
mind
and
heart
of
people
and
try
to
give
them
the
right
technology.
It's
like
a
the
right
passage
for
for
you
to
bring
them
the
technological
Edge
or
what
we're
trying
to
bring
them
as
a
holistic
or
Global
teams
into
the
world
of
needs
and
and
endurance.
If
you
will.
E
Okay,
so
from
my
perspective,
developer
tooling,
is
everything
from
you
know,
planning
collaboration,
execution,
then
observing
and
learning,
and
then
being
able
to
repeat
that
cycle
in
a
far
more
efficient
way
and
with
with
the
sprawl
of
the
spectrum.
Being
you
know,
no
code
low
code
to
the
vast
end
of
cloud
native.
E
So
so,
developer
tooling
is
really
empowering
your
developers
to
be
at
their
best
to
be
able
to
craft
code,
and
you
know,
sort
of
bring
the
skills
that
they
have
to
life
and
and
create
products
that
can
be
enjoyed
by
the
end
consumers
and
deliver
value.
So
so
that
so
that
that's
my
definition
of
developer
tooling,
it
would
involve
anything
from
collaboration.
B
Oh
brilliant
Taran
and
we're
going
to
keep
that
thoughts
in
our
head
there
about
really
that
empowerment
of
the
developer
and,
like
you
said
or
as
well,
that
holistic
approach
to
anything
anything
any
small
gain
to
improve
the
lives
of
the
developer
can
improve
the
lives
of
the
whole
business.
And
that
brings
us
on
to
our
next
question
actually,
which
is
around
that
area
of
productivity
and
business
and
and
what
the
business
itself
is
looking
to
achieve.
With
these
efficiencies.
B
With
these
investments
in
developer,
tooling
and
staying
with
you
Taryn,
and
particularly
in
your
context
here,
Consulting
helping
to
coach
and
guide
customers
on
their
Journey.
How
have
you
found
that
with
the
different
businesses
that
you've
worked
in?
What
does
what
are
the
businesses
looking
to
achieve
with
that
productivity
gain.
E
Sure
so
so
I
personally
feel
that
working
in
the
Consulting
business
I
get
to
see
a
lot
more
customers,
and
you
know
that
amplifies
the
experience,
but
also
shows
you
what
the
trends
in
the
market
are,
and
you
know
looking
at
the
macro
climate
around
us,
there
is
a
squeeze
in
spending.
There
is
a
recognition
that
you
know
that
the
growth
is
starting
to
stop
a
little
bit
and
therefore
there
is
a
need
for
doing
more
for
less
and
when
there
is
a
need
for
doing
more
for
Less.
E
You
want
to
think
about
empowering
your
developers
to
be
at
their
best
to
be
more
productive
than
ever
before,
and
that's
one
way
of
achieving
more
outcome
through
through
the
same
means,
and
you
know
if
we,
if
we
look
at
being
able
to
do
more
for
less
things
that
come
to
mind,
which
you
know
you
touched
on
your
poll
as
well.
Quite
early
on
is
things
like
AI.
E
What
we
want
to
own
up
to
is
writing
good
quality
code
and
therefore
have
tools
that
instill
that
right
from
the
outside
personally.
For
me,
GitHub
does
a
fantastic
job
at
that.
You
know
it's
it's
a
it's
a
Well
integrated
tool
chain.
It
flourishes
in
the
open
source.
It
gets
a
lot
of
the
open
source
contributions
with
improve
the
product
that
Vibrant
Community
drives
the
momentum
forward
on
it,
and
these
advancements
in
AI
coming
first
into
the
platform.
Solving
critical
problems
like
security.
E
Pushing
these
things
left
into
the
development
cycle
are
making
a
huge
change
change
and
that's
what
I
want
to
spend.
Maybe
30
more
seconds
on
is
you
know,
productivity
is
not
only
about
having
you
know
a
platform
that
allows
you
to
cut
code
in
in
a
more
productive
way,
but
it's
also
about
being
able
to
take
on
more
ownership
of
things
that
are
right
in
the
process.
You
know.
Releases
have
generally
been
a
challenge
because
you
know
you've
got
bigger
organization
Place.
E
Their
security
traditionally
has
been
a
barrier
because
gets
involved
right
before
you're
about
to
press
the
button
to
go,
live
and
you're
told
you
can't,
because
someone
hasn't
signed
off
right,
bringing
these
principles
left
into
the
execution
cycle,
you're
empowering
your
developers
to
really
deliver
these
results
quickly
and
with
authority.
So
so
for
me
that
would
that
that's
been
the
theme
that
I'm
seeing
with
customers
at
the
moment.
B
Brilliant,
thank
you
so
much
Taryn
and
thank
you
for
the
shout
out.
You
know
that
is
our
hope
that
we
come
always
with
the
developer,
focus
and
I
hope
that
you
all
in
the
audience
and
that
you
here
with
us
today
that
you
see
that,
in
the
decisions
we
make
in
our
tooling
coming
to
you
next
or
just
to
discuss
this
about
the
the
business
objectives
and
I
believe
that
that
listening
part
in
particular
is
something
that
you've
called
out
before.
How
would
you
like
to
frame
this?
The.
D
Yeah
I
mean
for
so.
Let's
give
the
I
mean.
Terran
was
wonderful
for
me.
I
I
really
liked
it,
but
in
the
cold
world
of
Enterprise,
things
are
very
strict.
You
know
it's
in
the
end
of
the
day,
it's
kind
of
encapsulated
to
time
to
Market,
plus
money
was
cost
reduction,
it
must
cost
awareness
and
in
the
other
day,
this
is
the
driving
factors.
D
It's
like
a
huge
Corp,
so
in
many
ways
and
one
of
the
objectives
that
we
have
now
at
night,
because
we
are
a
multi
National
company
which
sort
of
employees
is
that
the
way
that
we
grow
organically
speaking,
it
was
very
low
and
it's
right
to
essentially
became
an
acquisition-based
company
in
in
various
ways
and
now
we're
trying
to
make
this
what
I
call
Cellular
eradication.
You
know
each
company
that
getting
bought
you
want
to
stay
in
their
own
lane.
D
Don't
give
me
this
Corp
thing:
I,
don't
want
to.
You
know,
get
me
out
of
this.
You
know
hostile
environment
and
one
of
the
things
that
we
are
trying
to
do
in
that
sense
is
to
really
listen
to
understand
from
them.
What
is
their
feel,
what
their
motivation
not
to
congregate,
the
company
and
when
we
start
to
see
that
way
and
understand
their
needs
and
their
fears?
D
We
had
this
social,
let's
say
consensus
that
we
can
push
forward
and
when
we
show
to
the
higher
management
is
also
worthwhile
in
terms
of
kpis.
Everything
is
working
like
magic,
so
I
think
this
is
a
right
blend
between
understanding
the
needs
of
your
clientele,
which
is
for
me
it's
in
internal
and
the
needs
of
the
of
the
hard
needs
of
the
of
the
higher
management.
B
Yeah,
perfect
and
well
said,
and
that
that
organizational
context
of
the
Enterprise
you
know
it
can
be
very
challenging
to
overcome
those
silos
and
to
make
sure
that
we're
bringing
people
along
with
us
Florin
to
you.
Next,
your
journey
of
transformation,
consolidation
of
markets
and
tooling,
that
sounds
like
a
you've,
had
to
do
a
lot
of
insight
there
with
the
business
to
to
bring
them
along
with
you.
C
Yeah
I
mean
I,
look
like
Italian
like
or
it's
a
point
of
view.
Actually
I
think
everyone
over
here
can
agree
with
me.
Actually,
the
most
important
are
set
in
our
companies
is
engineering
hours.
We
need
to
make
sure
actually
we
remove
all
the
roadblocks
from
our
Engineers
to
allow
them
to
write
code
and
folks
actually
what
they
do
best
and
then
we
know
our
developed
persons
they're
like
very
good
at
multitasking.
Sometimes
they
write
code.
Sometimes
they
debug.
C
Sometimes
they
deploy
to
production
and
then,
to
be
honest,
the
number
of
tools,
Technologies
and
Frameworks
in
the
last
few
years
have
exploded.
The
number
of
tools
our
developers
and
Frameworks
they
need
to
learn,
has
increased
a
lot
and
then,
while
this
is
good
also,
we
can
create
again
silos
and
then
our
our
Engineers
can
start
to
waste
a
lot
of
time,
because
maybe
sometimes
the
connectivity
between
these
tools
doesn't
work.
So
actually
we
are
doing
three
fix
in
Vodafone
to
help
with
the
productivity.
C
The
first
step
is
efficient,
tooling,
who
are
looking
to
invest
into
like
the
right
tools,
and
then
this
is
more
about.
If
you
think
about
like
a
best
of
sweet
versus
the
best
of
breed
approach,
maybe
they're
like
the
tools
individually,
they're,
very
good,
but
if
an
engineer
needs
to
require
access
to
five
six
tools
differently,
they
need
to
connect
to
them
they're,
going
to
waste
half
a
day
one
day,
just
to
get
the
environment
up
and
running.
Well.
C
Actually,
if
you
go
for
a
best
of
sweet,
you
might
have
like
95
of
the
capabilities
in
some
of
the
cup
on
on
some
of
the
areas.
But
then,
overall,
your
engineers
are
going
to
be
happier
because
then
they
don't
need
to
context
switch
from
one
tool
to
another.
So
what
we're
trying
to
go
with
platforms
such
as
like
ATO
and
GitHub,
so
at
the
moment
in
Vodafone,
we
use
both
GitHub
or
going
to
github.com.
We
are
very
big
users
of
ATO
as
well.
Our
Engineers
don't
work
platforms.
C
So
at
the
moment
we
keep
all
the
source
code
on
GitHub,
but
then,
when
it
comes
to
all
the
other
capabilities,
they
are
free
to
choose
between
ATO
and
GitHub.
While
looking
to
use
these
tools
more
to
allow
our
Engineers
not
to
have
to
context
switch
from
one
tool
to
another
and
then
link
to
this
one,
the
second
thing
we
are
doing
it
was
streamlining
our
onboarding
process.
Our
Engineers
told
us,
they
love
MacBooks
right
now,
we
are
in
the
process.
C
As
soon
as
an
engineer
joins
the
company,
you
are
able
to
give
them
a
MacBook
to
develop
porn.
But
what
what
I'm
being
told
by
my
leadership
team?
We
want
our
Engineers
to
be
productive
from
day
one.
So,
actually,
what
does
that
mean?
We
need
to
make
sure
they've
got
all
the
tools
they
need
on
their
laptop,
but
also
they
will
get
access
to
the
tools
going
back
a
few
years
ago,
our
developers
had
to
go
to
our
itsm
system.
Race
tickets,
wait
for
weeks
or
amounts
to
get
access
with
pools.
C
But
the
moment
when
we
hire
someone
we
already
know
almost
what
teams
are
going
to
go
to
what
tools
they
need
and
then
we
can
prepare
everything
for
them.
So
the
moment
when
they
join,
we
can
send
the
laptop
to
their
address.
They
put
their
Vodafone
email
address
and
then
all
of
a
sudden
they've
got
access
to
all
the
tools
they
need.
C
So
by
having
this
efficient,
tooling
and
then
like
a
streamlined,
onboarding
process,
we
we
get
a
lot
of
efficiency
and
then
the
last
one
we're
hiring
new
people,
but
at
the
same
time
we
are
also
looking
to
upskill.
Some
of
our
let's
say
like
it
Ops
colleagues,
they
are
looking
to
move
into
engineering
roles
and
then
we
want
to
make
sure
we've
got
the
right
learning
paths
for
everyone,
so
we're
building
like
learning
paths
for
devops,
front-end,
back-end,
full
stack
devops.
If
I
don't
mention
it
everything
and
then
our
Engineers
are
fit
to
do
it.
C
And
then,
when
we're
building
these
learning
paths,
we
are
also
telling
it
to
our
tooling
strategy,
because
then
we
don't
want
a
developer
to
go
on.
One
of
the
learning
platforms
learn
how
to
use
a
different
tool
and
then,
when
they
come
to
their
day-to-day
work,
they
are
using
a
different
tool.
So
are
very.
We
are
making
sure
that
our
learning
paths
are
tied
together
with
our
tooling
strategy
and
then
we're
seeing
a
a
big
increase
in
our
productivity,
which
I
will
touch
on
a
bit
later
today.
B
A
It's
really
exciting
and
quite
evident
from
the
different
topics
you
touch
on
and
focus
on,
naturally,
that
you
all
come
from
very
different
companies
right,
one
company,
where
it's
mandated
from
Top
how
to
go
about
it.
Another
company,
where
you
have
to
fight
and
build
from
the
ground
up
and
then
with
Avana
tarun
you've
got
you
represent
somebody
and
that's
actually
advising
clients
with
the
best
practices,
how
they
should
go
about
things.
So
we're
quite
interested
to
hear
from
all
of
you,
because
we've
been
on
different
transformational
Journeys.
A
E
Sure
so,
from
my
perspective,
Lessons
Learned
is
is
really
important
right
because
ultimately,
it'd
be
it'd,
be
silly
to
make
the
same
mistake
twice.
What
I'm,
seeing
as
a
anomaly
when
I'm
speaking
to
some
of
the
senior
business
stakeholders
who
are
looking
at
transformation
and
evaluating
tooling
they're
thinking
about
metrics
and
metrics,
is
a
very
slippery
slope.
Wrong
decisions
can
lead
to
wrong
behavior,
for
example,
setting
up
a
metric
which
is
based
on
lines
of
code,
written
lines
of
code
change
is
informing
a
behavior
that
we
need
to
create
more
code.
E
We
need
to
write
more
code
and
not
necessarily
writing.
More
code
is
being
productive
in
any
way
and
therefore,
is
that
really
a
metric
worth
version
measuring,
probably
not
right.
So
you
know
this
this.
This
dilemma
of
what
metrics
to
set
up
is
pretty
common
with
customers,
and
we
tend
to
educate
customers
that
metrics
more
and
more
need
to
be
business
outcome,
driven
so,
for
example,
uptime
in
the
platform
time
to
Market.
E
E
We've
seen
that
you
know,
can
I
polish
this
line
of
code
to
the
utmost
I'm
married,
so
it
can
never
be
penetrated
only
to
find
that
that
feature
never
made
it
to
production
right,
because
it
was
canned
right
all
that
effort
wasted,
but
when
we
change
the
dial
and
focus
on
metrics
that
are
business
driven,
then
it
changes
the
behavior.
The
other
thing,
I
would
say,
is
I
touched
on
it
earlier.
It's
the
best
in
isolation
versus
integrated.
E
Your
customers
have
been
in
conferences
where,
on
the
boots,
they
see
this
one
product
that
has
become
a
bit
of
a
gold
standard
in
doing
the
one
thing,
but
when
you
are
looking
at
building
devops
devsecops
within
your
organization,
integrated
tools
will
deliver
more
value
because
having
to
integrate
the
tools,
yourself
comes
with
a
lot
of
unsaid
cost
and
effort,
but
also
the
act
of
having
to
manage
these
tools
over
time.
Patch
them
keep
them
up
to
date
is
quite
a
lot
of
effort,
and
you
know
not
necessarily
do
you
account
for
this.
E
In
your
total
cost
of
ownership,
but
if
you
start
to
do
that,
the
distinction
becomes
very
easy.
The
the
goals,
the
goals
in
Mantra
that
I
tell
customers
is,
you
know,
look
at
integrated,
SAS,
based
platforms
for
your
devops
tool
chain,
but
but
don't
get
hung
up
on
one
tool
hosted
on
on
a
VMS,
because
it's
not
really
going
to
solve
your
problem.
E
I
want
to
I
want
to
go
back
to
metrics
for
a
second
and
touch
on
this
really
brilliant
question.
Marco
asked,
which
is
you
know
what
would
be
a
business
case
for
copilot?
You
know
how
do
we
measure
the
success
of
copilot
and
it's
a
good
question,
because
you
know
whenever
you
go
back
and
ask
for
funding,
someone
would
say
well
what
am
I
getting
back
for
the
money
I'm
about
to
spend
and
I
I.
Think
co-pilot,
like
back
in
the
day,
refactoring
code,
we
had
this
extension
from
jetbrains
right.
E
There
was
always
a
debate.
Should
we
put
the
money
on
the
table
to
buy
it
or
not,
but
it's
all
about
being
able
to
write
code.
That's
more
secure,
more
modular,
you
know
more
testable
and
you
know
a
team
always
comprises
of
senior
developers.
Who've
been
in
the
trenches
doing
you
know,
executing
on
on
difficult
projects
and
Junior
developers
who
are
here
learning
and
hopefully
will
over
time
become
more
mature
in
their
software
development
practices.
E
Github
co-pilot
allows
the
Level
Playing
Fields,
where
at
the
click
of
the
button,
within
your
context
of
the
IDE,
you
have
the
best
practices
available
to
you
not
having
to
waste
time
looking
on
the
internet
for
things
to
dabble
with
and
Tinker
with,
but
real
good
advice
that
that
you
can
apply,
but
not
only
that
right
with
the
recent
advancements
in
the
tool.
It
allows
you
to
write
tests
and
explain
code
which
really
allows
you
know
more
of
the
people
to
act,
a
senior
developer
so
that
productivity
gain
really
the
measure.
E
E
It's
really
easy
to
kick-start
a
program
of
transformation
and
bring
in
tooling
and
when
you
bring
in
tooling,
you
expect
that
there's
certainly
going
to
be
this
hockey
stick
effect
where
everyone
in
the
organization
would
like
to
use
this
tool.
On
the
contrary,
that
never
happens
itself.
It's
about
empowering
the
Champions
within
your
organization
to
take
on
that
product.
E
Take
on
that
tool
set
and
then
start
to
show
value,
building
a
guild
building
a
community
of
practice
around
it
to
drive
it
option
and
once
you
get
to
that
critical
mask
yeah,
it's
it's
the
flywheel
that
turns
itself,
but
until
you
get
there,
it's
a
lot
of
hard
work
and
and
sometimes
organizations
while
they're
invested
in
buying
the
tools
are
not
as
invested
in
seeing
the
adoption
uptake
and
therefore
these
Transformations
aren't
successful.
So
you
know
I
think
this
is
an
important
point
that
people
need
to
consider
when
they're
putting
in
the
time.
E
C
A
And
also
onion
style
looking
at
the
individual,
but
then
what
does
it
mean
for
the
organizational
setup
maintenance
of
tools?
A
really
wonderfully
explained
to
everyone
appreciate
that.
Thank
you
so
much
looking
at
the
individual,
you
were
speaking
about
mandate
right
and
I
think
it
would
be
quite
interesting
now
to
hear
from
all
what
some
of
the
lessons
that
you
learned,
because
you
had
more
of
a
ground
up
approach,
right,
yeah,.
D
Most
definitely
and
we
take
it
from
two
planes,
but
first
of
all,
I
want
to
kind
of
expand
or
adhere
to
what
Taron
was
saying
and
copilot
is
a
very
hot
topic
today,
and
people
like
saying
are
very
vibrant
about
how
can
I
show
it
to
my
boss
really
sincerely.
This
is
the
easiest
task
that
I
ever
had
in
my
life,
I
mean
in
many
ways
it's
just
a
no-brainer.
Of
course.
D
This
is
a
very
easy
product
or
a
tool
to
to
justify
financially
speaking
and
I'm,
doing
it
all
the
time
as
an
enabler
which
I
want.
Maybe
it's
the
stepping
stone
to
my
designation.
The
company
essentially
night,
is
a
very
much
Silo
based
Enterprise.
One
of
the
things
that
brought
me
to
is
to
make
some
sense
in
all
of
those
Commando
based
silos
around
the
world
and
when
I
started
my
job
and
I
thought
I'm.
You
know
as
a
technology
personnel
it
is,
you
know,
coming
with
a
technological
approach.
D
Okay,
I'm
coming
here,
I
will
get
the
best
tool
for
you
in
terms
of
maintainability
and
Integrations,
but
it's
not
about
surely
I
kind
of
understand.
This
season
have
nothing
to
do
with
nothing,
but
mainly
technology.
It
has
to
do
with
understanding
the
needs
of
my
clients
and
their
hardships
and
I.
D
Don't
know
about
you,
but
you
know
I'm
coming
from
an
infra
background
and
in
a
sense
we're
always
thinking
about
ourselves
as
providers
we're
providing
you
amazing
Solutions,
but
when
I
before
that,
I
was
Elite,
consultant
and
I
need
to
go
to
r
d
groups
understand
their
needs
and
more
and
more
I
try
to
understand
it
to
Encompass.
The
the
little
thing
that
I
need
to
do
is
to
come
from
a
product
approach,
which
means
I,
am
a
seller
I'm,
not
a
provider.
D
It
needs
to
be
easy
on
boarding,
easy
maintenance
is
integration
and
easy
repurposing
or
tool.
Bending
of
designation,
for
instance,
with
GitHub
I
had
an
amazing
story
about
it.
I
mean
we
have
like
around
gazillion
cicd
Tools
in
our
company
and
gazillion
code
repositories
and
gazillion
and
randex
and
in
in
GitHub
in
a
way
is
just
amazingly
really
in
that
Source.
It
is
very
easy
to
onboard
very
easy
to
integrate
if
even
very
easy
to
you
know
deal
with
financially.
D
This
is
amazing,
and
one
of
the
things
that
I
really
I
mean
I
saw
the
flexibility
of
the
tool,
and
you
know
we
all
do
in
this
weird
scene
in
in
in
devops
that
we
are
taking
Jenkins,
which
is
a
cicd
tool
and
we're
making
it
to
build
our
operational
platform.
It's
all
the
things
that
you
don't
want
to
do
automatically
just
push
it
to
the
junkies,
and
this
is
not
you
know
between
us.
D
The
usability
of
tools,
visibility
of
models,
the
the
even
the
sharing
of
the
technological
entities
within
the
platform
is
so
easy,
so
well
designed
and
in
that
stand,
I
mean
I
I.
Just
this
is
why
I
want
to
come
here
and
share
this
gospel,
because
this
is
a
very,
very
fine-grained
defined
tool
which
gives
you
a
lot
of
flexibility.
A
Or
thank
you
so
much.
This
is
really
beautiful
is
said
and
I
think
what
you've
highlighted
in
your
response.
There
is
really
the
importance
of
culture.
How
do
you
drive
and
evolve
culture?
It
starts
with
people
they're
working
in
silos,
perhaps
from
an
organizational
perspective,
and
then
how
do
you
get
to
the
hearts
of
them?
Have
them
understand
the
benefits
of
what
you're
offering
what
you
want
to
serve
them
with
by
really
listening
to
them
and
tying
what
they
expected
to
do
to
some
of
what
the
business
is
looking
at
as
well.
A
C
Like
when
I
look
at
my
learnings
to
be
honest,
some
of
them
are
aligned.
I've
learned
some
of
some
of
them
with
other,
so
we
always
had
like
a
tooling
a
devil,
not
always,
but
for
the
last
seven
eight
years
like
a
developed
strategy.
But
if
the
tool
is
not
being
adopted
by
the
developers,
the
strategy
is
useless.
So
actually
what
we
did
based
on
my
beautiful
student
taxonomy
and
then
actually,
we
went
back
to
the
engineers
and
said:
okay
guys,
we
want
you
to
work
with
each
other.
C
What
do
you
think
are
the
most
important
tools
that
you
think
we
should
standardize
on
that
you
can
and
then
for
you
to
be
able
to
communicate
with
each
other,
and
then
we
told
them.
Let's
not
use
any
three
names.
Let's
only
use
the
capabilities,
because
then
every
time
there
is
always
a
religious
debate,
you
don't
know
like
all
or
something.
If
you've
got
this,
there
are
so
many
like
fun
boys
for
one
tool
find
people
for
a
different
tool.
C
It's
like
okay,
let's
remove
all
that
from
the
equation
and
let's
only
talk
about
the
capabilities,
and
then
most
of
the
people
said.
Oh
yeah,
the
source
code
sounds
like
a
good
idea
to
have
one
source
code
platform
and
then,
to
be
honest,
we
were
very
lucky.
You
had
GitHub
already,
you
know
implemented,
but
the
people
were
not
using
it
and
then
all
of
a
sudden
we
started
giving
people
access
to
GitHub
and
they
started
loving
it.
And
then
we
said:
okay,
let's
call
this
type
of
tool
Highlander,
which
means
in
Vodafone.
C
We've
got
only
one
instance
of
this
tool,
so
everyone
in
Vodafone
needs
to
use
this
tool
for
source
code
management.
People
are
not
allowed
to
have
another
source
code
management
platform
out
there
because
he
said.
Okay,
if
you
want
to
be
able
to
communicate
with
each
other
share
code,
we
need
to
put
it
in
the
same
place.
If
not,
you
need
to
give
me
access.
I
need
to
give
you
access,
we
waste
even
more
time,
so
maybe
sometimes
it's
fastest
faster.
For
me
to
write
the
code.
C
Myself
then
said:
okay,
let's
pick
a
few
areas:
tools
that
we're
going
to
call
Highlander.
Then
we
are
going
to
have
a
few
flexible
tools
where
people
can
choose
two
or
three
tools,
but
then
the
aim
is
to
for
these
two
or
three
tools
to
become
a
Highlander,
but
it's
not
a
priority,
because
what
you
need
to
be
mindful
is
we
need
to
balance
the
strategy
with
the
Innovation.
C
We
want
our
teams
to
be
able
to
innovate
while
we
adopt
and
then
standardize,
and
at
the
same
time
we
need
to
give
our
teams
plenty
of
time
to
learn
how
the
tool
works.
Just
imagine
if
tomorrow
I
go
to
work
in
black
guys,
we
decided
to
stop
everything
we
do
here.
There
is
this
new
tool
coming.
We
replace
everything
with
it.
It's
going
to
be
a
mess
and
then,
when
it
comes
to
flexible,
tooling,
I
love
what
automation
with
one
example
flexible
tooling.
It
says
it
did
for
the
pipeline.
C
We've
got
Ado
pipelines,
Jenkins
GitHub
actions
who
are
seeing
more
and
more
people
moving
from
Jenkins
over
to
Ado
pipelines
or
GitHub
actions.
But
at
the
moment
we
are
not
pushing
it.
Our
estate
of
Jenkins
is
so
big
and
then
I
don't
really
mind
as
long
as
they
put
a
code
on
GitHub
I'm
happy
with
that
at
the
moment,
and
then
the
last
set
of
tools
is
free
tools
where
people
can
choose
any
tool
they
want,
and
then
traditionally
this
used
to
be
testing
tool
for
us.
C
Can
you
please
standardize
a
bit
the
testing
tools,
because
then
we
want
everyone
in
the
company
to
have
the
same
at
least
the
same
maturity
when
it
comes
to
the
initial
testing,
like
it's
like
unit
testing
integration
testing
and
as
you
mature
more,
we
can
involve
the
standardizations
of
more
tools
and
then
basically
our
biggest
learning.
Is
that
small
understand
what
the
developers
want
and
then
reiterate?
And
then
it's
always
changing.
That's
that's
the
beauty
of
my
job.
Every
day,
I'll
developer
I
mean
the
technology.
C
Landscape
is
always
changing
that
new
technology
is
coming,
but
we
need
to
be
flexible
but
at
the
same
time
have
a
have
a
few
guard
rails
when
it
comes
to
it.
Even
if,
let's
say
another
source
code
platform
comes
tomorrow,
which
is
going
to
be
GitHub,
it's
very
difficult
because,
because
of
the
open
source
of
GitHub-
but
let's
say
we
need
to
be
mindful
about-
we
can't
move
from
one
tool
to
another.
C
So
for
the
Highlander
tools
we
say
we
use
the
Highlander
tools
for
at
least
a
couple
of
years
to
allow
everyone
to
be
on
it
for
the
flexible
tools
we
can
change
every
year
every
other
year
and
then
for
the
free.
The
team
can
use
any
tool
they
want
for
any
project.
As
long
as
they're
there
to
the
principles
the
guardrails
were
setting,
and
then
at
the
moment
it's
working
for
us
and
then
we
just
need
to
see
what's
going
to
happen
tomorrow
when
it
comes
to
tooling.
A
Wonderful
flooring,
thank
you
so
much
for
sharing
that.
It's
quite
interesting,
because
collaboration
is
a
key
topic
that
came
up
here.
How
do
we
make
people
work
with
each
other?
Make
sure
there's
an
appetite
to
do
that
as
well?
What's
the
benefit
for
that
with
that
I
want
to
hand
back
over
to
JP
for
our
final
question
today.
B
Yeah,
brilliant
and
actually
I'd
like
to
come
to
you
next
time,
because
you
mentioned
that
about
the.
How
do
you
encourage
collaboration?
How
do
you
share
that
knowledge?
It
is
in
a
source,
an
element
in
that,
and
you
also
referred
to
you
referred
to
guilds
and
you
refer
to
communities
of
practice.
How
have
you
found
good
ways
to
build
and
Foster
that
collaboration.
E
Great
question:
so,
a
few
years
back,
the
the
statement
used
to
be
Innovation
happens
in
the
open
source
and
very
quickly.
The
question
became.
You
know.
Why
cannot?
We
replicate
this
model
in
the
Enterprise
to
drive
the
same
level
of
innovation
and
collaboration,
and
and
that's
where
the
concept
of
inner
Source
really
stem
from
right,
so
I'm,
proud
to
say
for
customers
that
I
work
with
Innovation
happens
in
in
our
source,
as
well.
E
Collaboration
happens
in
an
inner
source
and
you
almost
need
to
appreciate
that
your
developers
like
reduced
barriers
to
entry-
and
you
know,
if
you're,
going
to
give
them
tools
that
will
allow
them
to
operate
seamlessly.
Then
that's
going
to
drive
more
collaboration
and
and
what
I
generally
find
is
people
like
to
reuse
code.
E
You
know
no
one
wants
to
read
write
things
that
have
been
written
before,
but
there's
always
this
desire
to
improve
it
and
put
your
stamp
on
it,
as
they
say,
right
leave
your
mark
to
make
sure
you're,
representing
you're,
enhancing
you're,
improving
you're
adopting,
obviously,
and
that
can
that
can
be
done
quite
effectively
within
our
source.
Now
the
the
collaboration
element
of
it
is
is
broader
than
that,
because
from
a
tooling
perspective,
we
want
developers
to
be
sharing
ideas,
not
only
after
they've
finished
writing
the
code.
E
But
during
that
process
as
well
and
pull
requests
have
a
great
play
in
that
and-
and
you
would
see
in
you
know,
software
development
teams,
pull
requests,
have
pretty
much
become
the
norm
in
how
a
developers
work
so
you're
back
in
the
day
we
used
to
have
this
evil
off
code
review.
You
would
print
out
your
code
walk
into
a
room,
and
you
know
I
I,
don't
I,
I
I'm,
not
sure
everyone
in
the
audience
would
remember
that
right,
because
these
are
practices
from
my
time
10
15
years
ago.
E
You
know
where
digital
wasn't
really
the
first.
It
was
very
much.
Let's
print
the
code,
walk
into
your
senior
developers,
room
and
the
door
gets
shut,
and
you
get
lots
of
reviews
on
your
comment
and
you
walk
back
and
try
and
try
and
get
it
back
into
the
system,
and-
and
so
it
doesn't
have
to
be
year
and
after
act
right.
E
That's
collaboration
for
developers
and
again
with
anything
collaboration
happens
at
different
levels.
You
know
you
want
to
be
planning
for
planning.
You've
got
the
right
tools
and
if
you
do
the
outcome
from
your
your
pipe
planning,
your
quarterly
planning
is
recorded
effectively
in
a
tool
that
helps
you
distill,
those
down
into
action
plans
for
the
Sprints
when
you
execute
on
it.
That's
collaboration
as
well.
It's
about
managing
and
Mining
the
knowledge,
and
today,
if
you're,
using
markdown
or
GitHub
gist
or
you've
got
your
own
Jackal
website
running,
which
is
capturing
docs,
then
fill
your
boots.
B
It's
absolutely
brilliant,
and
you
know
thinking
about
the
different
ways
we
can
make
that
easy,
I
loved
what
you
mentioned
there
about
how
exciting
it
is
for
the
developer.
In
that
pair
programming
scenario,
that's
you
know,
live
collaboration
there,
but
then
also
defaulting
to
trying
to
be
transparent
in
the
communication.
So
we
can
all
learn
from
each
other.
B
Thinking
about
your
story
about
senior
developers,
teaching
Junior
developers
I
think
that
open
by
default
is
very
much
the
way
that
I
think
we
see
as
part
of
github's
culture
as
well
practicing
it
internally
that
we
can
foster
that
collaboration
and
coming
to
you
all
next
and
then
Florian
or
how
have
you
managed
to
Foster
collaboration
with
your
role
there
as
the
centerpiece
going
to
meet
these
teams?
How
have
you
found
that
journey
of
collaboration
and
the
promotion
of
inner
Source,
potentially.
D
D
First
of
all,
it
is
always
about.
You
know,
getting
the
trust
and
also
to
get
to
Showcase
I
mean
any
kind
of
POC
and
how
you
can
you
know,
gather
more
successful,
kpis,
that's
fine!
Everybody
knows
that,
but
one
thing
which
is
which
helped
me
a
lot
I
mean
my
background
is
like
I
mean
my
I
mean
by
bringing
house.
If
you
will
Israel,
obviously
and
I
am
I
was
I
myself.
D
The
service
was
in
this
Valley
intelligence
in
a
Computing
unit
with
classified
one
of
the
things
that
they
taught
us
there
is
that
we
never
really.
You
know
nobody
loses
when
you
collaborate,
you
don't
lose.
You
just
grow
the
other
one
and
vice
versa.
It's
all
job
security
mentalities,
so
asinine
foreign
to
me
as
a
human
being
because
of
this
breeding
ground
and
when
you
are
in
to
a
higher
cause.
In
my
case,
it
was
keeping
my
country
intact.
D
All
the
other
things
which
are
personal
kind
of
fading
away,
so
I'm
trying
to
instill
this
mentality
in
the
Enterprise,
which
is
much
harder,
of
course,
because
the
common
cause
a
little
bit
different.
But
when
you
really
showed
when
you're
collaborating
it's
not
a
threat
to
you.
On
the
contrary,
we
are
just
both
of
us
are
growing
in
certain
domains.
Or
you
know
this
is
a
very
powerful
engine
that
can
take
you
through
a
lot
and
overcome
a
lot
of
things
and
further
down
the
road.
D
B
Really
really
powerful
statement
or
and
I
think
what
I'm
hearing
from
you
is
about
collaboration
as
a
foundational
piece
of
culture
and
the
trust
and
the
psychological
safety
that's
needed
for
anybody
in
whatever
field
to
do
their
best
work
and
I.
Think
in
our
context
here
that's
making
sure
people
have
all
the
tools
that
they
need,
that
they
are
that
they
feel
open
to
collaborate
and
are
not
fearful
of
any
repercussion.
B
C
Yeah,
thank
you,
so
I'm
not
going
to
lie
so
at
the
beginning,
a
few
years
ago,
we
artificially
created
this
collaboration.
We
created
the
first
Global
guilds.
We
had
two
initial
guilds,
what
we
call
the
API
Guild
and
the
software
engineering
Guild.
These
were
the
main
priorities
for
us
to
have
standard
apis.
So
then
all
our
channels
can
can
reuse
them
and
then
the
other
one
was
to
actually
have
a
standard,
they're
more
like
devops
practices
across
the
market
and
then
our
markets,
and
then
a
market
could
like
for
Germany,
Vodafone,
Greece
and
so
on.
C
They
could
go
to
the
internet
and
do
it,
but
a
lot
of
times
what
about,
if
we're
going
to
use
each
other
as
a
resource
and
also
sounding
boards.
Okay,
how
are
doing
that?
How
are
doing
that
and
then
start
to
share
best
practices
back
in
the
day.
It
was
not
that
easy
to
find
an
onboarding
guide,
let's
see
for
Jenkins
in
Vodafone.
C
So
basically,
we
started
putting
together
these
people
to
share
best
practices
with
each
other,
and
then
we
got
very
lucky
or
I
got
very
lucky
18
months
ago,
when
we
did
the
reorder
to
bring
together
all
the
digital
across
Europe,
we
already
the
all
the
all
the
developers
sorry
sort
of
like
knew
each
other
across
the
markets
and
then
but
what
we
started.
Seeing
we
started
seeing
a
lot
more
guilt,
communities
of
practice
being
spun
up,
but
then
I
think
one
thing.
C
The
beauty
of
this
is
not
about.
Actually
what
that
I
see
that
tooling,
as
an
enabler
I
want
our
teams
to
collaborate
on
the
customer
facing
Solutions
on
the
end
product,
it's
beautiful
for
me
to
see
all
the
code
on
GitHub,
but
still
until
last
year
we
had
12
versions
of
our
mobile
app.
So
if
you
are
going
to
different
countries
in
Europe
for
Vodafone,
the
application
was
looking
the
same,
but
actually
was
developed
12
times
and
now
by
bringing
all
these
people
together.
Everyone
said:
okay,
what
about
I
build
a
framework?
C
You
build
that
feature
with
that
filter
and
then
we
put
it
in
the
same
space
than
what
we
did
for
all
the
mobile
app
development.
We
set
up
a
GitHub
Organization
for
all
the
childhood
code.
We
put
another
GitHub
organizations,
another
one
for
the
infrastructures
code,
so
then
people
can
start
to
see
with
each
other
and
then
we
can
start
and
then
and
then
we've
got
two
very
simple
principles
before
you
build
something
please
check
if
someone
else
has
already
built
it
and
then
they
use
it.
C
If
not,
please
do
it
in
such
a
way
that
it's
easier
for
others
to
use
it,
and
then
this
could
be
even
basically
like
put
a
readme
file,
create
a
guide
how
to
adopt
that
one.
If
I'm
looking
at
our
repos
right
now,
they
don't
have
these
basic
things
and
then
it's
impossible
for
someone
to
reuse
your
code.
C
If
you
don't
tell
them
how
to
do
it
and
then
maybe
like
another
very
good
example:
a
lot
of
companies
right
now,
they've
got
a
react
component
library
and
then
we've
got
a
ux2id
design
system
and
then
almost
all
the
development
teams
that
are
building
their
own
real
component
library.
But
I
was
like
why?
Because
we've
got
one
design
system
and
then
we're
building
12
15
times
the
same
their
components.
C
We
merge
the
most
advanced
component,
libraries
across
Vodafone
into
one,
and
then
we
intersource
it.
So
then
everyone
in
Vodafone
can
access
it,
and
then
we
created
a
very
basic
support
model
for
it.
Instead
of
if
you've
got
a
problem
with
one
react
component
Library
one
on
their
component,
you
don't
need
to
go
raise
the
ticket.
We
enable
the
Microsoft
team
where
everyone
in
Vodafone
can
access
it,
and
then
they
got
the
guide,
how
to
use
it.
C
And
then,
if
they've
got
a
problem,
they
can
raise
it
over
that
and
then
an
engineer
will
quickly
jump
to
fix
that
one,
because
if
they
fix
it
for
someone
else,
they're
going
to
fix
it
for
themselves
as
well,
and
then
we
are
seeing
lots
more
examples
now
of
inner
source
and
then,
while
at
the
beginning,
I
said
we
kind
of
like
forced
the
collaboration
right
now.
I
can't
even
keep
track
of
how
many
communities
of
practice
you
do
it.
C
Some
of
them
are
very
high
level,
let's
like
digital
architecture,
community
of
practice
to
down
some
very
specific
gifts
like
a
testing
Guild
we've
got
I
mean
we
just
love
it,
because
people
are
sharing
so
much
and
then
sharing
is
important.
But
what's
more
important
for
our
business
is
to
build
the
products
in
a
more
consistent
way
and
then
hopefully
the
biggest
waste
that
we
can
do
right
now
is
to
build
the
same
product
multiple
times.
So
we're
trying
to
reduce
that
waste
by
building
the
product
once
in
a
very
good
way.
B
Really
excellent
answer
Florin
and
actually
we're
going
to
switch
gears
now,
with
the
time
that
we
have
remaining
to
just
have
a
look
at
some
of
your
questions
and
this
one's
interesting
and
from
sander
and
I'm
going
to
expand
it
a
little
bit.
It
was
specifically
about
communication
tools,
but
we've
already
talked
a
little
bit
about.
B
How
do
you
get
the
right
balance
between
enforcing
a
standard
and
allowing
developers
to
make
their
own
developers
and
teams
to
make
their
own
decisions
and
you've
already
touched
on
this
in
different
areas?
So,
if
you
have
a
particular
opinion,
any
of
you
that
you
would
like
to
share
with
us,
please
unmute
yourselves
and
feel
free
to
discuss
this
topic
with
us.
E
I'll
maybe
start
and
then
let
others
chip
into
it
I
find
when
standards
are
quite
hard,
hardly
enforced.
Maybe
that's
not
the
the
thing
I
wanted
to
say
when
standards
are
really
enforced
with
with
the
with
with
developers,
people
find
workarounds
and
and
I
guess,
there's
this
dilemma
of:
how
much
do
you
want
to
push
and
how
flexible
do
you
want
to
be
so?
E
What
I
find
is
we
almost
need
to
empower
our
developers
to
have
the
choice
of
being
able
to
select
between
things
as
long
as
they
can
meet
the
outcomes?
We
expect
classic
debate
around
security
right,
which
tools
best
to
apply
security
and
you'll,
find
the
Enterprise
has
one
View
and
they'll
push
that
down
to
the
developers
and
developers
who
are
keen
on
using
apis
will
find
that
that
tool
doesn't
support
apis
and
therefore
they're
not
going
to
adopt
it.
C
Maybe
just
to
focus
on
the
communication
part
because
then
envelope
on
YouTube,
like
both
slack
and
teams
and
then
our
Engineers,
we
kept
talking
about
chat,
tops
and
then
we
realized
we
spoke
with
them
about
how
to
what
do
they
do
about
chat
tops.
You
know
they're
like
web
hooks.
We
can
trivia
events,
you
can
build
infrastructures
like
to
like
do
like
destroy
infrastructure
and
then
Microsoft
teams
in
the
last
year
or
so
they've
developed
a
lot.
So
Vodafone
is
using
Microsoft
a
lot
and
we're
seeing
actually
how
Microsoft
teams
has
developed
a
lot.
C
So
we
ask
our
Engineers
to
give
it
a
trial
and
then
right
now,
we've
chosen
Microsoft
teams
as
our
product
for
chat,
tops
almost
everything
you
could
do
in
slack.
So
I'm
not
saying
Microsoft
teams
is
better
than
slack
and
then,
but
actually
it's
all
about
picking
one
tool
and
then,
since
there's
a
lot
of
information
in
the
chat,
you've
got
contracts
in
Microsoft,
Microsoft
tips
is
included,
have
a
go
at
Microsoft
teams.
We
are
seeing
almost
everything
we're
doing
in
slack.
C
We
can
do
in
teams,
maybe
what
it
all
our
Engineers
is
to
have
an
open
mind
about
it.
Don't
expect
to
do
it
the
same
way
you're
doing
slack,
but
there
are
ways
you
can
do
it.
You
just
need
to
agree
on
these
new
ways
of
working
which
I'm
not
saying
is
more
convulated
more
complicated.
It's
just
a
different
way
to
do
it,
then.
For
us,
it's
working.
We've
got
third
party
apps
like
GitHub
or
like
observability
tools
installed
Microsoft
at
the
moment,
they've
got
a
very
strong
ecosystem
of
partners
for
Microsoft
teams.
C
So
if
any
of
your
other
vendors
they've
got
is
like
a
third-party
application
and
then
you
can
talk
via
Microsoft
to
push
the
vendor
to
create
a
Microsoft
teams,
extensions
to
get
everything
in
there.
We
also
we've
got
internal
applications,
which
now
are
enabling
our
developers
to
push
via
Microsoft
teams,
and
then
it's
working,
fine,
but
then
it's
just
like
we
mentioned,
find
the
balance
and
then
the
engineers
they
need
to
understand.
C
So,
instead
of
maybe
spending
the
money
on
two
or
three
communication
tools,
we
can
spend
the
money
to
get
them
licenses
for
something
else
and
then
a
lot
of
times.
What
we're
trying
to
do
is
remove
the
licensing
discussion
from
the
engineering
language.
We
are
trying
to
make
it
as
easy
for
them,
so
they
don't
need
to
worry
about
licenses.
So
a
lot
of
time
it
is
I,
would
love
to
use
your
stool
fluorine,
but
how
do
I
get
the
license?
C
I
do
I
need
to
go
to
my
manager
and
what
they're
trying
to
do
internally
said
as
long
as
you're
in
the
Vodafone
engineering,
you
can
use
the
tools.
It's
not
behind
the
scenes,
there's
still
a
cross
charge,
because
we've
got
12
operating
companies.
Each
of
them
has
got
their
own
p,
l,
but
still
it's
seamless
for
the
engineer.
That's
what
I
hear
about
it
behind
the
scenes.
B
Perfect
perfect
and
we're
actually
at
the
end
of
our
time
here
together
now
and
I,
just
wanted
to
take
the
time
to
thank
you
Taryn
to
thank
you
or
thank
you
Florin,
for
your
help
in
discussing
this
hot
button
topic
with
us
and
the
audience
here
today
really
appreciate
your
time
today.
Let's
just
talk
a
little
bit
about
the
remaining
events
today,
Anna
over
to
you.
A
Thank
you.
Everyone
really
fantastic
Insight,
shared
I
hope
everybody
else
enjoyed
it
as
much
as
we
did
be
interested
in
a
bit
more
of
the
practicalities.
Please
do
join
the
demos
and
live
sessions
which
are
going
to
happen
throughout
the
afternoon,
there's
a
mere
specific
sessions,
but
you
can
actually
also
attend
the
ones
that
are
happening
during
U.S
time
and
maybe
even
Pacific
if
you're
interested
in,
for
example,
today
at
3,
P.M,
UK,
4,
P.M
Central
European
time,
we've
got
one
about
reducing
devops
tool,
chain
complexity
with
GitHub.