►
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
B
Yeah
thanks:
does
anyone
have
examples
of
following
the
vision
strategy
right
launch
by
ticket
lab
individual
bits
of
advice
in
this
chapter
felt
applicable
to
my
work,
I'm,
an
application
security,
but
the
overarching
chapter
didn't
it
felt
quite
Big
Bang.
This
is
small
iterations.
A
So
this
chapter
stood
out
to
me
as
kind
of
aligning
a
lot
with
what
we
have
with
our
blueprints
and
so
I
think
we
use
those
in
the
product
side,
but
I
think
other
departments
usually
use
that
kind
of
idea
as
well
like
I,
know
in
infrastructure.
We
have
things
kind
of
like
blueprints,
but
they
aren't
necessarily
on
the
list
that
I
linked
here
and
so
in
those
docs.
It
says
a
blueprint,
describes
a
technical
vision
and
a
set
of
principles
that
evolve
as
we
move
forward.
A
So
that
certainly
sounds
like
the
vision
and
strategy
kind
of
bundled
up
to
an
extent,
and
there
is
a
list.
I
haven't
spent
too
much
time
browsing
through
the
blueprints
in
my
time
here,
but
it
does
look
like
those
are
heavily
influenced
by
all
the
principal
plus
engineers
and
then
there's
some
staff
engineer
names
in
there
as
well.
A
C
Yeah
I
was,
on
the
rate,
limiting
blueprint
working
group
and
to
simplify.
We
had
three
proposals
and
there
was
one
that
was
sort
of
very
iterative,
very
kind
of
kind
of
a
very
logical
progression
from
what
we
had
have
currently
for
our
rate,
limiting
there
was
one
that
was
a
bit
more
medium
term
and
there
was
one
that
was
more.
C
This
is
the
ideal.
If
we
could,
you
know
snap
our
fingers,
it's
a
bigger
project,
there's
more
involved,
but
overall
it
has
the
potential
to
be
the
best
outcome
or
I
won't
say
it
that
way.
There's
advantages
to
this
that
are,
that
involve
structural
changes.
C
C
C
The
idea
is
that
you
do
have
a
small
working
group
that
generates
them.
I,
don't
know
if
that's
a
rule
necessarily
or
if
that's
something.
Historically,
that's
always
happened.
E
I
think
there
was
recently
some
debate
and
redoing
of
the
blueprint
process
about
that,
like
whether
it
should
be
related
to
a
working
group,
there's
even
like
I
think
Marshall
was
advocating
to
change
it
more
to
an
RFC
style
process,
and
that
didn't
happen,
but
I
think
that's
in
flux
or
at
least
open
to
change,
given
that
it's
changed
recently,
if
nothing
else.
F
There
there
is
an
example:
I
shared
there's,
a
link
there
to
blueprint.
We
actually
were
working
in
verify,
so
this
actually
didn't
come
out
of
a
working
group.
This
was
really
just
a
technical.
Debt
need
to
burn
this
down
large
tables
that
needed
to
be
partitioned
so
started
as
a
blueprints.
F
It's
been
iterated
on
since
last
year
and
actually,
what
ended
up
happening
was
it
didn't
initially
didn't
get
a
lot
of
adoption,
so
we
didn't
weren't
able
to
actually
staff
this
initiative,
but
with
you
know,
they
talk
about
sponsorship
as
well.
I
think
this
is
where
it's
really
key
is
you
know
with
more
Sports
a
sponsorship.
We
since
turned
it
into
its
own
initiative.
We
were
able
to
even
get
a
database
engineer
to
join
us
on
this
effort
so
which
is
really
cool.
F
It
is
a
year-long
initiative,
so
I
feel
like
this
is
probably
rare
that
this
ends
up
being
the
case
where
you're
able
to
have
basically
it's
basically
like
a
working
group,
but
it
is
a
year-long
initiative
with
a
specific
group
of
people.
F
A
From
the
infrastructure
side,
so
in
the
delivery
group,
we've
had
the
idea
of
self-service
or
I
forget
what
we're
calling
it,
the
self
or
yeah
independent
deployments
or
self-service
deployments,
and
this
was
the
doc
that
kind
of
started
it.
A
And
it's
very
like
it
very
much
kind
of
sits
in
that
Vision
category
of
we
don't
really
describe
a
lot
of
how
things
are
going
to
happen,
but
more
what
we
want
and
kind
of
at
a
high
level
of
what
it
will
solve
and
what
it
will
look
like,
and
so
that's
kind
of
like
that.
First
step
of
the
vision
of
putting
those
thoughts
together
in
a
in
an
organized
way
and
then
taking
the
next
step
of
eventually
diving
into
the
more
strategy
side.
G
Yeah
sure
it
was
just
an
example
of
something
similar,
but
not
quite
that
that
entire
process
of
going
from
Vision
to
strategy
to
writing
and
then
launching,
but
it
was
about
three
years
ago
that
we
came
up
with
a
road
map
which
is
a
technical
strategy
document
and
I.
G
Think
if
we
continued
to
work
on
that
or
could
or
or
try
to
move
this
forward
now,
we
would
probably
use
the
architecture
workflow
a
bit
more,
even
though
we're
not
working
on
product
features,
I
think
still,
some
of
that
workflow
will
still
be
relevant
and
we
certainly
need
to
get
buy-in
at
all
levels
for
getting
all
Engineers
on
board
with
the
same
sorts
of
processes
in
the
same
view
of
quality.
G
But
the
implementation
didn't
really
go
to
plan
and
I
think
we
kind
of
had
Mecca
as
a
champion,
but
then
no
one
else,
keeping
things
organized
and
updated
and
moving
things
forward.
So
when
Matt
became
a
lot
busier,
he
wasn't
able
to
be
both
champion
and
dra
and
organizing
all
the
work.
So
the
rest
of
us
in
quality
kind
of
did
the
bits
of
work
at
the
start
and
then
lost
sight
of
the
big
picture,
so
yeah
I
think
I.
G
Think
there's
a
challenge
for
me
and
any
other
SATs
on
the
staff
track
lots
of
opportunity
there
as
well
I
mentioned
it's
a
yeah
good
foundation
for
working
forward,
and
we
also
have
a
vision,
I
think
the
book
described
Vision
says
maybe
just
a
paragraph,
something
a
bit
more
in
depth
and
yeah.
We
have
the
mission
statement
there
and
I'm
sure
that's
similar
across
other
departments
and
groups,
yeah,
so
I
think
we
have
a
couple
of
examples
here.
A
I
would
often
see
like
the
product,
visions
and
and
align
myself
with
those
and
and
it's
I
like
how
this
chapter
kind
of
split
out
that,
like
you,
should
also
have
the
sort
of
like
technical
Vision
or
how
it
can
be
helpful,
at
least
at
times,
to
have
a
technical
Vision
in
addition
to
that
product
Vision,
because
it's
easy
to
not
like
it's
easy
to
just
not
always
think
about
both
because
or
it's
easy
to
always
think
about
the
product
side,
because
it's
kind
of
like
what
you're
doing,
not
necessarily,
let's
be
honest,
I.
H
E
I
think
it's
looking
at
this.
It's
it's
apropos
chapter
because
just
today
we're
having
a
discussion
about
remote
development,
which.
D
E
But
looking-
and
we
had
exactly
this
discussion
like
what
level
of
detail
should
we
document
should
we
put
in
the
the
dots
around
this
and
me
coming
from
an
agile
background,
it's
like
as
little
as
possible
and
have
the
code
really
good
being
self-explanatory
and
have
the
tests
really
good
at
all
levels
of
the
testing
pyramid
and
just
describe
the
high
level
architecture
and
from
an
engineering
perspective.
If
people
want
to
learn
about
how
it
currently
works.
E
Hopefully,
there's
institutional
knowledge
of
that
and
the
team
is
still
there
and
when
you
bring
people
on,
they
can
learn
through
osmosis
and
through
pair
programming
and
stuff.
Like
that,
because
any
anything
you're
right
technically
is
is
a
lie
waiting
to
happen
and
the
the
higher
level
stuff
that
you
stick
to
is
is
going
to
be
the
most
accurate
that
was
my
take
on
it.
But
you
have
to
write
something.
C
It's
a
good
feature,
but
you
know
that
you
know
the
the
code
above
the
diff
is
often
hidden
and
it's
a
good
idea
to
like
expand
that
out
once
you're
fine
with
the
code
and
be
like
Oh.
Is
there
a
comment
here
and
is
that
comment
still
current
and
that's
kind
of
the
UI
can
kind
of
work
against
that
and
I?
Think
that's
one
of
the
reasons
that
comments
tend
to
age
a
bit
faster
than
maybe
they
would
normally
is
because
you
know
they
don't
they're,
not
locked
with
the
code.
C
G
A
live
voice.
My
next
point,
yeah.
A
G
Cheers
yeah
the
Overton
window
is
a
concept
that
I
only
learned
about
fairly
recently
during
the
elections.
Recent
elections,
probably
the
last
two
elections
here
in
Australia
and
at
the
time
my
wife
had
said.
That
is
a
concept
that
does
apply
quite
a
lot,
and
so
it
was
yeah.
It
was
really
cool.
G
I
thought
it
was
really
cool
to
see
it
mentioned
in
in
the
book
in
an
organizational
context
as
a
way
of
understanding
how
well
new
ideas
or
different
ideas
will
be
received
across
the
organization
and
how
different
organizations
with
different
cultures
might
be
more
or
less
open
to
different
kinds
of
ideas,
and
so,
when
proposing
a
new
idea
or
change,
it's
important
to
be
aware
of
how
well
that
will
be
received,
and
if
it's
going
to
be
seen
as
something
that's
a
bit
too
out
there
or
yeah,
or
are
you
in
an
organization
where
a
bit
too
out
there
is
within
the
realm
of
reasonable
propositions,
so
yeah
I
found
it
really?
G
Cool
I
was
wondering
if
everybody
would
agree
that
gitlab
we're
relatively
open
to
a
wide
range
of
ideas.
I
was
thinking
that
our
preference
for
boring
Solutions
might
constrain
that
a
bit,
but
I
suspect
we
would
at
least
have
discussions
about
more
crazy
ideas
than
you
might
get
away
with
in
some
other
places,
but
still
then
end
up
arriving
at
something
that's
more
of
a
boring
solution.
If
there
was
one
available
anyway,
over.
A
To
everybody,
yeah
I
think
gilab
is
pretty
receptive
to
ideas
and
and
I
think
it's
kind
of
like
it's
interesting
how
it
can
act
on
different
levels,
depending
on
where
you
raise
the
idea
like
like
it's.
It's
that's
another
thing
of
being
aware
of
how
you
communicate
is
you
know,
raising
an
idea
and
brainstorming
with
your
team
is
different
than
raising
an
idea
in
like
a
staff
meeting
where,
like
I've
had
the
experience
of
like
oh
I've
got
this
idea.
A
I'm
gonna
bring
this
up
in
the
working
group
or
something
and
and
then
the
response
is
a
good
idea
how
to
like.
How
do
we
do
it?
A
If
you
don't
know
how
to
do
it,
then
bring
it
up
once
you
know
how
which
it
was
an
interesting
kind
of
like
experience
of
just
like
sort
of
learning
how
to
how
to
communicate
at
the
different
levels
like
what
different
levels
you're
looking
for
I
guess
in
terms
of
what
you
want
to
accomplish,
but
starting
to
ramble
a
little
bit,
but
the
overall
idea
was
was
that
yeah
I.
Think
overall
git
lab
is
never
like
against
people
bringing
ideas
to
any
conversation
from
what
I've
seen.
C
We
do
have
some
things
that
are
just
we
we
do
are
our
outside
of
our
overtone.
Window
I
mean,
if
you
say,
like
let's
break
out
the
monolith
right,
you're
not
going
to
get
a
lot
of
traction,
it's
just
not
where
we
are
as
an
organization,
whether
it's
right
or
wrong,
whether
that's
ultimately
good
or
bad.
This
isn't
something
weird.
C
You
know
you
can't
you
can't
propose
it
I
mean
if
you
could
write
a
proposal
that
does
that
you're,
an
incredible
writer
I
would
say
that
much
but
I
think
about
you
know
it's
not
just
people,
but
also
there's
a
there's,
a
technological
overtone
window
as
well.
So,
if
you
think
about
you
know
early
a
mid
mid
to
late
1800s
like
steam,
power
really
took
off,
and
you
know,
did
a
lot
of
work.
C
We
just
didn't,
have
the
Machining
to
really
take
advantage
of
that,
so
I
think
that's
something
to
consider
as
well
and
if
you
think
of
a
mortgage
computer
science
example
with
like
the
Difference
Engine
That,
Charles
Babbage
designed
you
know
again,
it
was
you
can't
machine
these
parts,
so
we
can't
do
it
so
I
think
there's
also
a
technological
overtime
window
that
you
have
to
have
prerequisites.
H
And
somewhere
in
our
values,
page
about
decision
making,
we
talk
about
how
one
of
the
reasons
why
we
work
as
transparently
as
possible
is
to
you
know,
open
it
up
for
people
to
add
ideas
and
feedback,
and
that's
also
one
of
the
reasons
why
we,
you
know
encourage
diversity
is
that
we
get
diverse
perspectives
and
opinion.
H
H
Solutions
or
you
know,
ways
to
resolve
issues
within
us.
I
would
say
probably
within
like
a
certain
window
of
perspective,
but
that's
different
I
think
from
the
window
of
what
we
would
accept
as
a
proposal.
H
A
Yeah
and
I
think
that
kind
of
goes
along
with
that
idea
of
the
you
know:
we're
not
looking
for
agreement,
we're
looking
for
consensus
or
if
we
got
actual
like
exact
wording,
but
I
think
that
goes
a
long
way
with
with
large
groups,
especially
where
we
need
to
move
forward.
So
being
aligned
is
more
important
than
you
know
having
everyone
agree,
but
on
that
same
idea,
the
thing
I
thought
of
with
ideas.
Bringing
ideas
is
you're
right.
It's
the
like.
A
We
can
bring
up
ideas
as
much
as
we
want
like
we
could
go
to
an
AMA
and
propose
the
monolith
being
broken
up,
and
no
one
would
really
be
that,
like
surprised
by
it-
or
you
know
anything,
but
at
the
same
time,
in
terms
of
realistic,
what
would
we
actually
do?
I
probably
wouldn't
get
any
movement
without
a
lot
of
additional
evidence
and
backing,
but
it
is
nice
that
we
have
that
that
sort
of
platform
to
bring
things
up
and
kind
of
just
get
things
in
people's
minds.
I
guess.
E
You
know
follow
along
with
that
specific
topic:
I
guess
yeah
talking
about
the
monolith
and
trying
to
tie
it
to
this
chapter,
and
maybe
the
Overton
window,
like
maybe
a
a
not
so
acceptable.
Maybe
radical!
You
know
end
of
the
overturned
window.
Criticism
is
like
I,
don't
think
we
have
a
well-structured
model.
If
we
don't
have
clear
domain
boundaries,
they're
not
clearly
enforced,
even
though
we
say
we
do
we
don't
and
what
what
can
we
do
about
it?
E
E
You
would
have
to
pick
one
and
you
would
have
to
dedicate
like
large
numbers
of
Engineers
for
years
to
do
something
about
that
and
like
is
that
an
investment
we
want
to
make,
given
that
we're
trying
to
you
know,
move
as
fast
as
we
can
to
capture
this
market,
and
that's
that's
where
I've
come
to
here.
It's
like
well,
okay,
as
a
putting
on
taking
off
my
engineer,
hat
and
putting
on
my
Sid
hat
is
like
well
yeah.
Is
that
an
investment
we
want
to
make
at
this
time?
E
Maybe
not?
We
want
to
capture
the
market,
we
want
to
do
new
features
and
then
putting
money,
engineer
yeah
back
on
I'm
like
well
how
long
before
we
were
just
stuck
in
that
mass
of
mud
with
unscalable
walls
on
each
side,
then
we
can't
move
forward
on
the
features
and
how
do
you,
you
know,
assess
the
the
weight
of
those
risks
of
not
swimming
forward
versus
not
cleaning
things
up
and
yeah?
E
Those
are
the
the
questions
are
away
about
my
pay
grade,
but
I
think
where
what
happens
at
gitlab
is
like
there's,
regardless
of
the
ideas
or
how
well
they're
presented
with
this.
You
know
unless
the
decision
is
made
to
make
that
level
of
significant,
sustained
investment,
and
we
just
don't
have
that
across
the
engineering.
Maybe
maybe
that
will
change
with
a
new
CTO
who
knows.
B
B
You
see,
someone
else
has
already
thought
of
it
and
you
can
work
with
them
to
like
pick
it
up
again
and
be
like
I
think
the
same
as
you
so
I
think,
there's
like
a
pro
endicon
right,
like
anyone
can
make
a
proposal,
doesn't
mean
anything
will
happen,
but
by
documenting
it
at
least
someone
else
can
come
to
it
later.
A
I
loved
the
the
overall,
like
example,
that
was
given
the
whole
I
think
it
was
the
sock
company
and
I
love
how
that
really
Illustrated?
How
like
all
those
kinds
of
discussions
and
decisions
work
when
you're
looking
at
what's
been
done?
A
How
come
certain
things
have
worked,
haven't
worked
before
and
like
working
with
the
ideas
that
already
exist
versus
bringing
in
your
own
I
feel
like
like
I've,
read
a
lot
about
like
strategy,
ideas
and
and
Vision
before,
but
like
seeing
this
concrete
example
of
like
what
it
actually
looks
like
in
an
engineering
organization,
was
super
helpful
because
it
gives
examples
of
that
of
like
this
person
worked
on
this
a
year
ago.
A
So
when
you
go
talk
to
them
about
it
to
make
sure
that
they
still
kind
of
want
to
be
involved
in
all
of
that,
and
it's
very
different
than
what
you
initially
or
at
least,
when
I,
initially
imagined
of
like
I'm,
going
to
write
a
strategy.
So
I
thought
that
whole
section
was
really
really
helpful.
A
C
Yeah
just
quickly
I
I
did
like
how
it
called
out
like
deciding
what
not
to
care
about
basically
deciding
what
problems
you
you
want
to
have
so
I
think
so
much
software
engineering
or
technology
in
general
is
like
some
of
the
things
I
like
to
think
of
when
making
sort
of
larger
decisions
is
like
well,
no
matter
what
we're
going
to
have
problems
opportunities,
so
what
problems
would
I
want
to
have
you
know
what?