►
From YouTube: Digital Transformation & Resilience for Public Sector
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
And
in
fact,
in
many
ways,
digital
transformation
has
been
something:
that's
been
disrupting
organizations
for
a
long
time,
either
industries
or
agencies
of
bringing
in
new
ways
of
working,
and
in
fact,
if
you
think
about
it,
a
lot
of
organizations
that
had
been
on
the
leading
edge
of
dealing
with
and
preparing
for
digital
transformation
were
very
well
prepared
for
the
pandemic
when
it
started
to
happen
because
they
pivoted-
and
this
was
just
another
disruption
that
they
were
reacting
to
and
and
so,
if
you
think
about
digital
transformation,
if
you
look
at
it,
you
know
world
economic
forum
published
a
fantastic
study
that
defines
this.
A
This
is
a
the
the
the
executive
summary
is
80
pages.
You
know
so
take
that
for
what
it's
worth,
it's
a
it's,
a
really
very
good
read
actually
because
they
detail
out
industry
or
industry
and
sector
by
sector.
What
are
the
impacts
of
it,
but
it's
about
developing
and
delivering
new
customer
experiences.
That's
exactly
what
we're
talking
about
it's
about
new
efficiencies!
It's
about
entirely
new
business
models
like
ubereats,
which
harold
mentioned
earlier.
It's
really!
How
do
we?
A
How
do
we
change
and
how
do
we
transform
and
how
do
we
get
better
and
in
fact,
if
you
think
about
digital
transformation,
it's
a
huge
deal.
I
mean
we're
this.
I
need
to
update
the
slide
it's
2.4
trillion
this
year.
I
need
to
get
the
more
current
data
on
this,
but
it's
it's
a
massive
massive
change
and
really
it's
about
resilience,
it's
about.
A
How
do
we
improve
and
make
ourselves
more
resilient
to
change
whether
that
changes
a
pandemic
or
whether
that
change
is
a
new
entrant
in
the
market
or
a
new
expectation
from
our
citizens
or
a
new
change?
You
know
globally
that,
as
an
agency
we
have
to
deal
with
all
of
this
gets
into
us
being
able
to
respond
and
react
to
it,
and
it
gets
to
this
other
idea
about
digital
transformation,
which
is
about
being
able
to
adapt
as
we're
on
our
journey.
A
It's
not
as
if
we're
building
something
or
developing
something
that
we're
going
to
build
the
whole
thing
and
in
fact,
what
we're
trying
to
build,
maybe
the
wrong
thing
by
the
time
we
get
done,
if
we
don't
adapt
and
really
we
have
to
have
the
ability
to
iterate
and
we
have
to
have
the
ability,
which
is
what
we
talked
about
earlier
to
iterate
and
learn
and
adapt
to
what
really
is
needed.
This
is
how
we
listen
to
the
voice,
you
might
say,
voice
of
the
customer.
A
How
do
you
listen
to
what
the
employees
and
customers
really
need,
not
by
what
they
tell
you,
but
by
what
they
do?
This
is.
This
is
really
what
we
have
to
learn
how
to
do-
and
this
is
this
is
indeed
difficult
right.
This
is
not
easy,
it's
much
easier
to
say.
Oh,
I
want
to
build
something.
We
draw
the
blueprints
from
what
we're
going
to
build
and
go
build
it,
but
in
fact
oftentimes
we
don't
really
understand
the
exact
needs,
and
so
we
have
to
really
think.
A
Then,
how
do
we
break
down
and
adapt
our
culture?
So
that
way,
we
are
able
to
be
dynamic
and
listen
to
the
changing
conditions,
which
means
we
have
to
collaborate
from
team
to
team,
not
only
team
to
team,
but
also
across
the
boundaries
between
us
and
our
customers.
We
talked
about
earlier
people,
leaders
at
all
levels
have
to
be
empowered.
They
have
to
be
empowered
to
try
to
drive
the
change
in
order
to
implement
those
changes.
They
have
to
be
able
to
work
and
have
visibility
across
the
whole
life
cycle.
A
As
to
what
they're
doing
it's
one
thing
to
make
changes
when
you're
doing
things
in
a
vacuum
or
in
a
silo
but
the
reality,
we
need
to
give
people
the
visibility
into
the
entire
workflow.
So
that
way
they
can
make
those
changes,
and
you
want
to
make
it
easy.
We
talked
about
in
onboarding
employees,
government
employees.
A
It's
about
being
able
to
react
and
respond,
and
I
think
it's
velocity
is
one
of
the
key
things
that
are
core
to
resilience,
and
with
that
you
know
I
I
want
to
share
at
least
a
little
bit
about
what
I've
learned.
You
know
as
an
I.t
leader,
because
I'm
a
developer
and
it
leader
plus,
I
also
work
at
gillab
as
an
it
leader.
A
A
But
one
of
the
things
we
do
is
we
really
do
believe
in
this
idea
of
true
cross-functional
collaboration
across
the
organization.
You
know
at
the
core.
We
believe
everyone
can
contribute
and
we've
been
building
our
processes
and
our
tools
and
our
approach
to
enable
people
to
collaborate
and
to
contribute
some
of
the
ways
we
do
this.
For
example,
in
all
of
our
meetings
and
all
of
our
work,
we
use
private.
We
use
shared
documents
to
document
agendas
to
work
collaboratively.
A
Every
single
meeting
has
an
agenda
where
we
are
live,
editing
the
agenda
and
taking
minutes
and
take
typing,
as
we
go
all
of
it's
public
into
the
company
internally
and
in
many
cases
we
share
them
publicly
outside
of
the
company.
So
it's
it's
it's
about
sharing
and
collaboration.
Then
it's
about
how
do
we
document
capture?
What
are
the
issues
and
what
are
the
work
streams
coming
out
of
this
in
a
way
that
allows
everyone
to
have
complete
visibility
about
what
we're
working
on
and
so
in
this
example?
A
This
is
a
screenshot
from
about
a
year
ago,
where
we
were
actually
had
a
public
board
planning,
one
of
our
releases
for
for
the
agile
planning
parts
of
gitlab
and
the
team
is
doing
this.
It's
all
entirely
public
and
open
to
the
community
to
collaborate,
and
the
reason
this
is
so
powerful
is
not
only
do
we.
We
all
have
visibility
in
what's
happening,
but
we
also
have
we
also
break
down
the
barriers,
and
you
know
this
is
a
comment
that
a
customer
a
prospect
even
made
up.
A
He
says
a
potential
gitlab
customer
user
chiming
in
here
asking
for
a
feature
and
a
capability
about
cumulative
flow
diagrams.
What's
powerful?
Is
it's
this
collaboration
and
sharing
that,
because
we're
open
and
transparent
because
we're
bringing
the
customers
and
the
users
into
this
discussion
we're
able
to
also
iterate
in
the
direction
that
makes
sense?
And
speaking
of
iteration
I
mean?
I
know
we
talked
about
tesla,
but
this
is
an
example
of
what
happens
when
you
iterate
in
this
case
these
are
really
large,
iterations
but
think
about
iteration
differently.
A
I
want
you
to
think
about
iteration
in
a
way
that
I
think
is
really
powerful,
which
is
this
size
matters
and
harold
talked
about
minimum
viable
product
earlier,
but
the
size
of
your
iteration
matters
and
get
that
we've
embraced
this
idea,
not
a
minimum,
viable
product
or
minimum
viable
function,
but
we
believe
in
minimum
viable
change.
We
try
to
break
our
changes
down
into
the
smallest
change.
A
That
makes
things
better
if
I
can
implement
a
change
to
a
website
or
if
we
implement
a
change
to
the
application,
that's
better
then
that
qualifies,
we
should
keep
going
and
the
faster
we
put
it
out
and
get
feedback,
then
that's
better.
It
doesn't
have
to
be
perfect.
This
is
requires
a
fairly
high
degree
of
cultural
shift
of
saying,
oh
gosh.
You
know
I'm
so
used
to
having
to
publish
things
that
are
perfect.
The
perfect
first
draft.
A
This
is
a
case
in
which
the
outline
is
good
enough
to
publish
it
and
get
feedback,
and
this
becomes
a
key.
The
way
we
work.
The
other
thing
that's,
I
think,
key
to
the
way
we
work
that
we've
embraced
is
the
power
of
our
pipeline
and
the
power
of
a
pipeline
to
really
embed
security
and
quality
and
compliance
into
a
way.
A
That's
automated
to
make
it
easy,
and
so,
as
we
work
on
developing
and
delivering
code,
we've
embedded
security
scans
and
automated
testing
and
container
scans
we've
embedded
the
best
practices
of
how
we
do
deployments
and
how
we
do
configuration
all
into
a
single,
automated
pipeline.
So
that
way,
when
a
developer
makes
a
change,
they
get
almost
immediate
feedback
about
the
quality
and
the
security
of
the
change
they've
made,
rather
than
the
way
it
was
the
way.
It's
typically,
it's
historical
that
you
wait
till
the
end
until
way.
A
At
the
end,
when
security
takes
a
look
at
a
change
to
give
you
feedback
this
way,
the
developer
gets
it
right
away
powerful,
because
we
can
go
much
faster
and
manage
the
risk.
We've
embraced
infrastructure
as
code
we
can.
We
can
go
farther
into
all
the
power
of
this,
but
what
it
really
means
is
that
we
don't
wait
for
environments.
We
don't
wait.
We
we're
able
to
see
temporary
test
environments
of
everything
we
do
and
test
it
and
review
it.
A
We're
able
to
use
containers
and
kubernetes
to
deploy
faster
and
manage
that,
and
then
we
also
embrace
this
idea,
and
we
talked
about
it.
I
think
a
little
bit
earlier
on
the
call
and
it's
something
I
think
that's
really
at
the
core
of
the
way
we
work
is
this
idea.
We
may
not
say
kaizen
a
lot
internally,
but
the
idea
of
continuous
improvement
is
something
that's
at
the
core
of
what
we
do
and
as
we
implement
minimum
viable
changes
as
we
adopt
processes.
As
we
do
things
at
getlab,
we
publicly
talk
about
what
we
did.
A
This
is
a
public
live
stream
of
a
release
retrospective.
We
do
it
every
month
actually-
and
in
this
in
this
image,
you
see
everything
from
directors
to
engineers
all
engaging
and
having
a
conversation
about
what
worked,
what
didn't
and
getting
feedback
from
the
community
as
well,
it
comes
back
to
then
we
publish
we
publish
everything
into
our
handbook.
It's
like
3000
pages
long
of
how
we
work
the
things
we've
learned.
We
publish.
We
write
it
down
that
way.
We
know
what
we're
supposed
to
do.
A
We've
agreed
to
do,
and
so
in
summary,
the
five
things
I
think
that
we're
doing
is
we've
broken
our
silos
down.
We
don't
have
silos
between
our
customers.
We
don't
have
silence
between
each
other.
We
work
very
collaboratively.
Small
changes,
minimum
viable
change,
that's
really
powerful.
We
automate
as
much
as
we
can,
including
how
we
manage
infrastructure,
which
we
treat
infrastructures
code
we
embrace
and
we
embrace
continuous
improvement.
That's
allowed
us
to
do
some
stuff,
that's
pretty
cool
right.
A
A
If
you
didn't
know,
we
covered
the
entire
devops
lifecycle,
everything
from
how
you
plan
and
manage
your
work
to
how
you
manage
your
code,
to
do
the
automated
testing
to
doing
security
scanning
and
deploying
into
production
we're
trying
to
be
effectively
a
software
factory
in
a
box
to
make
it
easy
for
teams
to
stand
up
and
do
the
right
processes
and
to
do
the
right
thing
with
devops
practices
really
built
in
from
the
beginning.
We've
been
doing
it
since
2011,
we
incorporated
2014
we're
an
open
source
project.
We've
got
lots
of.
A
We
had
lots
of
really
really
powerful
recognition
from
lots
of
organizations
and
people
and
great
customer
case
studies
across
the
public
sector
as
well.
I
think
that's
pretty
much
the
end
of
my
content
that
I
want
to
try
to
get
through
and
share
at
least
a
little
bit
about
what
we're
doing
and
how
we're
helping
with
resilience.