►
From YouTube: [2022-08-30] Next Architecture Workflow
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).
B
Marshall
cottrell
principal,
strategy
and
operations,
(technical):
all
right,,
let's
marshall,
cottrell
principal,
strategy
and
operations
(technical):
go
ahead
and
get
started.
I've
copied
in
the
actions
from
last
week.
The
first
one,.
If
you
want
to.
C
Grzegorz
bizon
principal
engineer,,
ops:
uh,.
I
wanted
to
simplify
the
architecture,
evolution
workload,
a
bit.,
so
that's
uh..
I
see
the
second
merch
request.
um!.
It
is
fairly
simple..
It
just
reduces
the
tldr
section
to
where
new
and
I
think
that
um,.
C
Grzegorz
bizon
principal
engineer,
ops:,
it
might
be
a
sufficient
iteration..
I
I
know
that
you,
marshal,
commanded
on
on
with
the
idea.
practically
you
will
write
that
the
architecture
work
for
from
scratch.,
but
before
we
dive
into
that,
uh,,
I
think
that
either
way
defining
what
the
blueprint
actually
is,
and
what
doesn't
mean
in
the
like
here
at
github..
What
are
we
using
blueprint?
For??
That's
the
first,.
C
Grzegorz
bizon
principal
engineer,,
ops:
and
I've
already
had
a
couple
of
discussions
with
our
engineers.
we've
come
here.
Today,
and
I've
been
different
people
about
what
the
blueprint
is
for
us,
and
we
concluded
that
with
whenever
I
actually
explain
that
to
people
in
the
years.,
um,
I'm.,
I'm
trying
to
explain
that
the
blueprint
is
actually
a
a
vision,,
a
technical
vision
that
makes
it
easier
for
us
to
align
our
iterations,
so
that
a
blueprint
is
something
that
actually,
you
can
read
before
every
iteration,.
C
Grzegorz
bizon
principal
engineer,
ops:,
and
it's
like
our
trails,
or
like
it..
It
makes
it
so
much
easier
to
figure
out
how
the
like
iteration
should
look
like.,
so
that's
primarily
tool
to
align
our
iterations.,
and
I
wanted
to
frame
that
somehow
in
the
in
this
merchandise,.
But
I
might
not
be
actually
doing
a
great
work.
that
so
coming
suggested
that
we
should
not
use
this
like
a
map
of
iterations,,
because
a
map
indicates
something
that
is
very
well
described.
and
uh,.
C
C
B
Marshall
cottrell
principal,
strategy
and
operations,
(technical):
yes,
marshall,
cottrell,
principal,
strategy
and
operations,
(technical):
you
know,
project
planning,,
and
how
we
organize
resources
and
like
what
what?
our
overall
iteration
strategy
is
more
of
like
a
planning,
activity,
right?
and
I
understand
that,
like,.
I
think
what
you're
trying
to
get
at
is
that.
B
B
B
Marshall
cottrell
principal,
strategy
and
operations,
(technical):
things
that
steps
that
are
achievable.,
but
I
don't
think
it
should
be
like
the
overarching
focus
of
the
blueprint..
I
think
I
think
the
focus
of
the
blueprint
should
be
just
like
camille
said,,
defining
like,.
What
we're
trying
to
do.
C
C
C
Grzegorz
bizon
principal
engineer,
ops:,
so
that's
for
me.,
it's
the
most
important
part
of
the
blueprint,
except,
of
of
course,
sharing
what
we
are
working,
on.
why,.
We
are
doing
that
where
we
want
to
go.
um!,
but
it
never
actually
contains
a
detailed
technical
proposal..
It's
more
like
a
technical
vision
that
used
to
align
iterations,.
D
B
D
D
D
D
D
C
Grzegorz
bizon
principal
engineer,
ops:.
I
I
think
that
it's
very
important
to
highlight
the
difference
between
a
proposal
and
a
vision,,
because
for
some
people
it
might
be
the
same
thing
for
me.
in
the
context
of
the
architecture
practice,,
it's
two
different
things:
that
the
proposal
does
not
give
you
a
lot
of
room
for
choice..
A
vision
is
something
that
sets
that
the
direction.,
but
you
can
still.
C
B
Marshall
cottrell
principal,
strategy
and
operations
(technical):,
but
have
that
hurt?
grzegorz,
bizon
principal
engineer,
ops:.
Perhaps
a
blueprint
starts
as
like
a
a
visionary
statement,,
but
in
order
for
it
to
become
something
that
is
workable,,
I
feel
like
it
has
to
be
shaped
into
a
proposal.
Like,.
I
think
that's
the
entire,.
B
Marshall
cottrell
principal,
strategy
and
operations
(technical):
the
point
of
yeah.,
but
it
does
not
start
from
the
start.
as
we
move
forward.
We
refine
the
blueprint,
and
it
becomes
more
and
more
concrete
with
every
iteration
at
the
end
like
this
should
be
not
really
a
proposal.,
it
should
be
a
story
of
what
you
have
done.
C
Marshall
cottrell
principal,
strategy
and
operations
(technical):
yeah,
perhaps,,
but
I
don't
think
we
should
have
the
opinionated
about
like
how
it
it
starts
like.
If
an
engineer
provides
enough
detail
to
considered
a
proposal.,
I
think
that's
still
as
much
a
blueprint
as
one
that
that
that
doesn't
right
like..
I
don't
think
we
should
be
too
opinionated
about
like.
B
B
B
C
Grzegorz
bizon
principal
engineer,
ops:,
so
that's
something
I
I
I
I
think
it's
doubleable,,
because
you
can
have
a
very
complete
proposal
for
the
next
iteration.,
but
how
you
know
it's
all
going
to
look
like
in
like
ten
iterations.
from
now.
You
can
learn
so
much
from
from
them
that
that
the
proposal
will
come
to
be
invalidated.
C
C
Eric
johnson
cto:
uh,,
those
assumptions
we
are
making
right
now
might
be
completely
invited.
after
a
couple
of
iteration,,
because
in
case
of
architecture,
practice
here
at
beetle
and
lucrings,,
we
are
thinking
about
initiatives
that
spun
multiple
iterations..
I
think,
if
there's
something
that
just
requires
a
single
iteration.,
you
can
just
put
that
into
an
issue..
There
is
no
refusing
to
actually
have
the
preference.
D
D
D
D
C
C
C
D
D
Kamil
trzciński
s.d.e:
and
I
think
the
expectation
of
the
snapshot
is
like
to
keep
updating
this
stuff.
so
with
the
latest
information,.
So
it
would
also
indicate
that
if
you
propose
a
yammal
syntax,,
but
during
development,
these
ammo
syntax
changes
to
something
better..
It
would
be
really
advised
to
ddc
amos
index
in
this
proposal,.
One
hundred
and
one.
D
Kamil
trzciński
s.d.e:
to
reflect
the
current
state,
kamil
trzciński
s.d.e:,
because
I
think
that
purpose
of
the
blueprint
is
to
full
time,,
like
one
provider
long-term
reason,
of,
like
the
online
us
and
the
common
design..
But
the
second
provides
a
very
big
access
to
the
current
development.
and
how
we
are
progressing..
So.
D
A
Andrew
newdigate
d.e.,
infrastructure:
jana,
at
marshall,
cottrell
principal,
strategy
and
operations.
(Technical):
sorry
go
ahead.
andrew
newdigate,
d.e.,
infrastructure:,
so
I
was
just
going
to
say
on
that
like
to
me..
What
I
kind
of
imagine
is
that
we
kind
of
start
up
with
a
blueprint.
and
then
all
these
documents
that
we
have
for
like
security,
review
documents
and
production,
readiness,
review,.
E
E
E
Andrew
newdigate
d.e.,
infrastructure:
and
we
might
start
off
with
something
like
willie,
and
kind
of
a
a
vision..
But
ultimately,
what
we
end
up
with
is
is
like
a
a
quite
a
well-defined,,
quite
a
well
structure
document
where
we
have
common
sections
that
are
common
across
all
of
these.
and
and
we
can,
we
don't
have
to
have
one
for
production
and
one
for
security..
That's
that's
kind
of
where
I'm
thinking.,
but
I
think
it
sounds
like
it's
kind
of
different
from.
C
C
B
B
Marshall
cottrell
principal,
strategy
and
operations.
(Technical):
is
the
the
the
firm
decision
not
to
go
in
a
particular
direction.
right
like..
I
think
that's
just
as
valuable
like
an
a
skewed
blueprint
is
just
as
valuable
as
as
one
that
we
do
pursue
right,
because,
like
it
gives
all
the
context
as
to
why
we
didn't.
C
C
B
B
B
B
B
C
B
B
B
B
Marshall
cottrell
principal,
strategy
and
operations
(technical):.
The
first
bullet,
is
that
we
wanted
to
firm
up
the
definition
of
architecture,
or
come
up
with
like
a
better
term,
and
the
past
conversations
led
me
to
believe
that
we
were
trying
to
standardize
on
blueprints
as
the
term
right,,
because
I
think,
like
this.
whole
conversation
is
still
convoluted
by
the
fact
that,
like.
B
B
C
Grzegorz
bizon
principal
engineer,
ops:,
I
mean,,
we
think
that,
starting
building
the
workflow
from
scratch
will
little
in
better
outcome,
just
it
writing
on
the
existing
one,,
because
I
feel
like
I'm,
not
entirely.
certainly..
The
problem
here
is
that
an
architecture
or
the
thermal
group,
and
like
what
what
the
real
problem
is,
and
I
feel
that
uh,
actually.
uh,.
If
we
start
from
writing
the
world.
C
C
C
C
C
C
C
Grzegorz
bizon
principal
engineer,
ops:,
we
defined
some
problems
that
we
believe
we
have
with
the
current
architecture
practice..
But
I
think
that
the
only
problem
that
is
evident
is
that
the
adoption
is
not
very
good,
and
perhaps
by
simplifying
the
workflow,
and
having
higher
adoption,,
we
could
encourage
other
people
to
actually,.
F
F
Dylan
griffith,
principal
engineer:,
the
problems
you
identified.
were
people
are
using
this
workflow,,
but
we're
getting
blueprints,
but
nobody's
executing
on
them,,
and
some
people
feel
like
they're
not
able
to
get
their
their
work
executed,
and
eric
suggested:
okay,
well,
then,.
It
needs
to
be
integrated
with
the
product.
Prioritization
changes
that
are
happening.
Now,.
F
Dylan
griffith,
principal
engineer:,
and
that
was
the
direction
you're
going
in
a
month
ago.
and
then
a
spreadsheet
came
out..
It
showed
how
we
didn't
use
this
dark
blueprint
process
for
some
things
that
were
executed.,
and
then
this
meeting
started
tangentially
looking
at
why
people
are
using
the
process.
F
Dylan
griffith,
principal
engineer:,
so
dylan
griffith,
principal
engineer:,
I
think
it.,
you
might
better
start
picking
one
of
those
two
problems,
right?
what?.
Why
does
it
matter
if
people
are
getting
results,
but
not
using
the
process,,
maybe
solve
that
problem?
second,?
What
about
the
people
that
are
using
the
process
and
not
getting
results.
F
C
B
B
B
B
Marshall
cottrell
principal,
strategy
and
operations,
(technical):,
product
and
engineering
are
are
collaborating
at
the
very
beginning
of
the
process,
and
and
both
product
and
engineering
are
producing
blueprints
that
get
stitched
together
into
a
cohesive
roadmap..
The
the
reality
is
that
product
doesn't
really
leverage
this
process
at
all.
That's
unlikely
to
change.
F
Dylan
griffith,
principal
engineer::
why
is
that?
The
objective
not
results
right?,
because
there
is
exactly
the
opposite
of
the
way.
I
framed
it
before
it's
people
that
are
using
blueprints,,
saying
that
they're
not
able
to
get
results.,
but
now
you're,
suggesting
it's
more
important,
that
everybody
use
blueprints
and
figure
out
whether
how
to
make
blueprints
get
better.
Results.
F
B
F
F
Dylan
griffith,
principal
engineer:
getting,,
you
know,
buy-in
from
the
entire
company..
I
I
just
I
got
to
go
well,,
that's
that's
good..
They
make
them.
they're
making
progress,,
because
I
can
see
too
often
the
alternative
of
getting
by
and
from
the
entire
company,
or
getting,
you
know,
convergence
on
architecture
or
solutions
or
companies..
This
size
of
bit
lab
is
just
so
hard,.
F
Dylan
griffith,
principal
engineer:,
and
it's
so
often
just
kind
of
cripples
progress
that
when
I
see
teams
that
make
decisions
on
like
hard
technical
things,
without
consulting
the
entire
company.,
but
they
still
make
a
good
decision,
and
it
has
trade
offs..
I
think
it's
good
enough.
we're
making
progress.
C
C
Grzegorz
bizon
principal
engineer,
ops:
how
how
well
the
architecture
or
architectural
practice
hearing
that
might
work
in
relation
to
this
managing,,
because
everyone
can
configure
a
framework
that
actually
makes
it
so
much
easier
for
us
to
make
rapid
decisions
and
and
stuff
like
that.
and
anyways,.
I
feel
like.
C
C
B
B
B
marshall,
cottrell,
principal,
strategy
and
operations,
(technical):
and,
and
also
like,
I,
I
think,
there's
still
a
bunch
of
stuff
in
there.
That's
not
going
to
map
cleanly
to
like
our
proposed
definition
of
of
a
blueprint
that
rolls
in
abstract.
and
pr:
reviews
um.,
but
yeah,
we
can..
We
can
address
that
as
we
start
to
flush.
It
out..
I
suppose.
B
Grzegorz
bizon
principal
engineer,,
ops:
so.,
it's
just
difficult
to
reason
about
everything:
that's
there
currently,
plus
the
additions.,
and
so
that
was
my
motivation
for
saying,
like,
hey?.
Maybe
we
just
define
a
new
page
blueprints
and
and
and
start
to
lay
out
what
that
is.,
but
I
think
we
can
get
to
the
same
point
either.
Way.
C
C
Grzegorz
bizon
principal
engineer,,
ops:
uh,,
and
that
might
not
be
necessarily
wrong.
but
there,
there's.
There
are
no
guarantees
that
we
actually
will,
came
up
with
something
better.
if
we
start
from
scratch..
So
that's
the
reason
why
I'm
biased
towards
more,
like
it,,
writing
on
the
content.
We
have
right,
now,
and
starting
starting
over
from
scratch,.
A
A
A
A
A
A
A
A
A
A
B
B
Chad
woolley
senior
engineer,
editor
(he/him):.
I
think
it's
like
orthogonal..
I
mean
it's
related
to
what
we're
trying
to
do.
we're
like..
How
do
we
allocate
some
of
this
bucket
of
life
and
maintenance
work
to
do
these
by
changes,
and
that
there
is
some
earlier
discussion
on
the
aircraft
that
I
have,.
A
A
B
B
B
B
B
B
B
Marshall
cottrell
principal,
strategy
and
operations
(technical):,
regardless
of
whether
it's
an
effective
communication
tool
or
not..
Today,
I
don't
think
that
is
a
super,
effective
communication
tool..
I
think
it's
a
great
communication
tool..
I
don't
think
it's
as
effective
as
it
should
be,
because,
like.
B
B
B
B
B
Chad
woolley
senior
engineer
editor
(he/him):
because
we
just
we,,
we
frankly
just
not
to
get
to
a
point
where
this
process,
or
some
process
like
it.
Is,
is
the
process
everybody
uses
as
they're
as
they're
building
functionality,,
whether
that's
a
large
scale,
architectural
change,,
whether
that's
a.
B
B
C
B
Marshall
cottrell
principal,
strategy
and
operations
(technical):
as
a
first
step
or
like
this
person,
is
already
like
a
principal
engineer,,
so
like,
what
does
that??
What
does
that
mean
to
them
when
what
we
really
want
them
to
do
is
just
produce
good
documentation
for
what?
what?.
Their
plans
are
right..
That
is
the
number
one
thing,
and
that's
why
I
think
we
should
strip
out
all
the
like.
B
C
Grzegorz
bizon
principal
engineer,,
ops:
pollution
coach
was
there
because
of
a
reason.
and
I.
this
reason
is,
that
if
chad
creates
a
blueprint,
or
like
any
other
crg,
or
perhaps
intermediate
without
an
architect,
evolution,
coach.
no
one's
ever
even
going..
Look
at
that
that
blueprint
with
an
organization
with
thousands
of
engineers.
the
architectural
evolution
coach
is
there
to
actually
find
the
importance
of
that
going
to
use
their
conduct.
C
Grzegorz
bizon
principal
engineer,,
ops:
directors,,
and
we
piece
about
the
content,
either
if
they
believe
that
it's
important.,
if
we
remove
that
content,
we'll
end
up
with
something
that
we
had
told
them
like
a
couple
of
years,
ago,
that
we
could
create
the
best
issue
ever
the
most
important
one,,
and
no
one
would
ever
look
at
that.
Until,
like
gd,
there's
a
drop-down.
B
Marshall
cottrell
principal,
strategy
and
operations,
(technical):
yeah,
that
and
that's
that
is
fair
and
I
think
more
important
in
the
context.
where,,
like
you're,
coming
to
the
table
with
with
some
novel
problem
that
you're
solving.,
that's
not
already
roadmap,
but
like
the
reality
today.
Is
that,
like.
B
Marshall
cottrell
principal,
strategy
and
operations
(technical):
we're
going
to
be
producing
a
lot
of
blueprints
for
things
that
are
already
planned
right,
like
the
ci
components,,
is
a
great
example.
That's
already
on
in
some
form,
that's
already
on
products,
roadmap,
right?.
So
it's
not
about
like.
B
C
C
B
B
B
C
Grzegorz
bizon
principal
engineer,
ops:.
I
would
like
us
to
marshall,
cottrell
principal,
strategy
and
operations
(technical):
to
pause
for
a
moment
and
think
about..
What
can
we
do
to
avoid
walking
in
circles
without
any
getting
any
reasonable
regionals
from
this
working,?
Because
this
is
actually
what
I
believe
is
happening
right,
now.
and
um,?
You
know,,
I
mean
uncomfortable
with.
C
Grzegorz
bizon
principal
engineer,
ops:
the
possibility
of
not
getting
any
results
out
of
those
discussions.
uh,.
I
feel
like
that's
the
reason
why
I'm
pushing
forward
concrete
action
points
after
every
meeting
to
actually
move
forward
in
some
way,,
because
we've
had
many
meetings,
many
discussions
about
that,
and
we
still
don't
know
how
to
move
forward..
So
what
do
you
think
we
should
actually
do
to
get
some
results
out
of
those
discussions.
B
Marshall
cottrell
principal,
strategy
and
operations,
(technical):
marshall,
cottrell,
principal,
strategy
and
operations.
(Technical):
think
I
think
we
should
have
a
a.
B
B
C
B
C
Yeah,
grzegorz
bizon
principal
engineer,,
ops:
okay..
I
can
add
a
link
to
a
template
from
the
merchants
of
mine
that
describes
what
uh,.
I
guess
that
the
the
content
in
this
merchandise
will
need
to
be
simplified,
anyways,
it's.,
it's
probably
too
abstract,
and
I
I
can
remove
at
least
a
one
one
from
it.
C
B
B
B
Marshall
cottrell
principal,
strategy
and
operations,
(technical):,
it's
a
proposal,
or
whatever
you
want
to
call
it,
that
we're
then
going
to
refine
into
a
blueprint.
That's
actually
workable,
right?.
So
I
could
just
fill
out
the
summary
section
of
this,
and
that
would
be
a
perfectly
fine,
mergeible
blueprint,.
B
B
Marshall
cottrell
principal,
strategy
and
operations,
(technical):
well,
in
the
long
term,
it's
much
more
difficult
to
like.,
build
tooling
around
that,
like..
If
you
create
a
new
mr.
like,,
you
should
get
your
template
copied
over
for
you
and
all
that,,
so
that
you
can
just
get
started.
Writing.,
but
I
think
it
like
encourages
people
to
produce
blueprints
in
the
same
structure,.
So
that,
like.
B
Marshall
cottrell
principal,
strategy
and
operations,
(technical):,
there's
mental
overhead
in
parsing,
the
marshall
cottrell
principal,
strategy
and
operations
(technical):
the
blueprint
right.
If
they're
in
the
same
structure
every
time,,
then
I
can
kind
of
jump
around
and
know
what
I'm
looking
at,.
B
Grzegorz
bizon
principal
engineer,
ops:,
but
also
like
there's,
there's,
there's
stuff
that
like
assuming
that
we
care
about
like
rolling
in
the
pr.,
ah,
and
and
apps
reviews,.
There's
requirements
there
that
have
to
be
met,
and
there's
sections
of
it
that
have
to
be
signed
off
by
different
people.
right?.