►
From YouTube: [2022-07-12] Next Architecture Workflow - Kickoff
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).
D
A
Okay,
I
think
we
are
at
time
and
have
enough
of
a
quorum
to
get
things
going
here.
I
I
think
most
folks
that
that
are
here
now
were
involved
in
the
previous
working
group.
This
one
is
going
to
largely
be
an
extension
of
the
work
that
was
previously
done.
A
My
my
take
on
the
the
sort
of
current
state
is
like
both
as
a
as
a
former
customer
and
and
user,
and
as
in
the
position
that
I'm
at
at
gitlab
now
I
find
the
architecture
blueprints
to
be
like
one
of
the
best
forms
of
documentation
that
that
we
produce
what
I
really
like
about.
It
is
that
you
can
get
pretty
much
all
the
context
you
need
to
understand.
A
What's
going
on
at
a
high
level
in
a
single
document
granted
those
documents
aren't
super
consistent
between
different
blueprints
in
their
in
their
current
state,
but
I,
I
think
it's
much
easier
to
parse
the
information.
That's
in
blueprints
than
it
is
to
parse
all
the
information
that
can
exist
in
a
hierarchical
set
of
epics.
Plus,
all
the
comments
and
and
discussion
did.
Did
you
want
to
follow
up
with
your
comments?
Phillip.
B
Yeah,
thank
you.
I
tend
to
disagree
with
that,
especially
with
the
way
we
are
working,
gitlab,
the
workflows
and
everything
we
blueprint
seems
to
me
like.
We
are
replicating
a
lot
of
features
that
we
already
have
a
lot
of
workflows.
B
I'd
rather
have
all
the
the
architecture.
Decisions
in
merge
requests
instead
of
a
dock
that
that
will
just
lie
somewhere.
A
good
example
of
that
is
that.
C
B
I
needed
accident
sorry
for
that.
Oh
that's
a
good
example
and
I'm
going
to
make
that
bigger
for
you,
we
have
some
blueprints
in
the
architecture
talk
of
git
lab
and
it's
really
hard
to
understand.
B
What's
the
status
of
this,
if
this
isn't
going,
if
this
is
done,
if
does
if
that
reflects
anything
that
has
been
produced
already,
I
really
struggle
with
that
honestly
and
if
you
take
a
look
at
the
page
that
we
have
for
architecture
and
that's
the
page
that
we
actually
share
with
customers,
we
don't
have
a
link
with
these
blueprints
and
we
end
up
with
this
kind
of
very
high
level
diagrams
or
very,
very,
very
detailed,
very
detailed,
sorry
diagrams
like
this
one,
which
is
honestly
awful,
and
I
I
don't
see
the
point
of
having
blueprints
on
the
side
of
this.
G
Doesn't
mean
that
it's
about
a
blueprint
that
it's
not
well
written
or
about
the
process,
perhaps
because,
if
you
open
the
blueprint
for
a
ci
data
decay,
you
can
see
that
there
is
a
timeline
in
that
blueprint.
You
can
probably
understand,
what's
the
current
state
of
it
at
this
moment,
because
we
keep
it
updated
and-
and
there
are
no
large
diagrams,
because
it's
not
very
readable,
so
it
doesn't
mean
that
the
process
is
flowed
or
just
the
way.
We
are
writing
some
blueprints
and
not
following
them.
A
Yeah
and
I
I,
I
also
think
that,
like
jiao
joust
right
that
the
the
blueprints
are
intended
to
be
more
like
architecture
design
records-
and
I
think
if
we
put
like
it,
blueprints-
are
only
going
to
be
more
difficult
to
produce.
If
we
require
that
you
specify
both
the
entire
state
of
point
a
where
we
are
and
the
desired
state
of
point
b
in
every
single
document.
A
Right
like
that's,
I
don't
think
I
so
I
think
I
think
that
architecture
blueprints
is
a
bit
of
a
misnomer,
because
it's
it's
not
like
a
it
most
of
the
time
it's
going
to
result
in
architecture
changes,
but
I
don't
think
that
that
is
necessarily
the
case,
and
so
I
want
to
make
sure
that,
like
we're
all
on
the
same
page,
in
terms
of
like
what
what
a
what
a
blueprint
is
to
me,
a
blueprint
is
like
how
we're
going
from
current
state
to
proposed
state,
but
but
that
doesn't
have
to
involve
architecture
changes.
A
Necessarily,
it
can
just
be
a
very
complicated
feature
that
has
a
lot
of
combines
multiple
components
within
the
system
right,
so
I
want
to
make
sure
we're.
I
don't
think
we
should
be
trying
to
solve
the
keeping
the
architecture
diagrams
up
to
date
in
the
scope
of
this
working
group
or
or
like
this
process.
A
I
I
think
you
should
be
able
to
update
the
architecture
diagrams
based
on
the
contents
of
these
blueprints.
Right
like
there
should
be
enough
definition
in
the
blueprints
to
know
what
the
implications
are
to
the
architecture,
but
like
yeah,
I
I
don't
think
we
should
be
trying
to
document
that
every
time.
G
Yeah,
I
agree
with
that
and
I
used
to
think
about
blueprints
as
a
map.
I
actually,
I
still
think
that
the
blueprint
is
actually
a
map
of
how
to
get
from
point
a
to
point
b
now.
I
think
about
blueprints
more
like
a
description
of
a
technical
vision
so
that
people
execute
on
that
vision,
know
where
are
we
going
actually
and
how
to
get
there?
G
So,
of
course,
as
we
as
we
move
forward
because
like
shipping,
complex
or
architectural
changes
is
an
evolutionary
process,
we
learn
something
after
every
step
and
as
we
learn
something
new,
we
can
get
back
to
a
blueprint
document
document
document.
New
insights
adjust
our
trajectory
and
in
that,
in
that
regard,
it's
adr
right.
Architecture,
changes
decisions
record,
something
like
that,
but
overall
the
blueprint
is
actually
a
a
technical
map
of
getting
from
point
r.
A
to
point
b
to
me.
E
So
so
jagos
just
to
kind
of
clarify,
but
do
you
do
you
see
them
as
like
a
point
in
time,
or
do
you
see
them
as
an
evolving
document
over
like
an
extended
period
like
because
I
tend
to
think
of
them
as
sort
of
a
more
point
in
time
like
we're
here?
These
are
the
challenges,
and
this
is
where
we're
going,
but
not
sort
of
like
a
document.
That's
necessarily
evolving
over
you
know,
years
or
even
like
multiple
quarters.
Perhaps.
G
So
that's
a
good
question
and
I
guess
that
it
depends
on
who
maintains
a
blueprint,
and
there
are
some
like
there
is
no
consistency
in
how
we
are
doing
that.
I
personally
like
to
keep
my
blueprint
updated
so
that
there
is.
It
doesn't
matter
when,
when
I'm
actually
reading
that,
if
I'm
reading
that
right
now,
it
should
still
provide
me.
Some
valuable
insights
should
explain
why
we
are
doing
something,
and
sometimes
it
requires
me
to
update
it
on
a
regular
basis.
G
Sometimes
I
can
actually
skip
updating
that
if
there
is
nothing
new
to
put
in
there,
but
what
is
important
for
me
that
whenever
someone
opens
the
document
whenever
it
happens,
they
should
not
be
confused
by
what
is
in
there.
It
should
explain
something
to
to
the
people
reading
the
blueprint
and
I'm
following
the
the
principle
of
the
least
surprise
here
that
when
I'm
reading
a
blueprint
or
someone
does
it,
it
should
not
be
confusing
to
them
what
they
see.
There
doesn't
make
sense.
E
You
know,
you've
kind
of
moved
on
and
I
think
having
that
definition
at
the
top
to
say
you
know
these
are
the
problems
that
we're
solving
and
then
almost
more
importantly,
these
are
the
problems
that
we're
not
solving
and
then
and
then
leaving
those
for
like
a
future
blueprints
and
not
trying
to
keep
updating
and
then
when
people
ask,
why
did
you
make
this
decision?
You
can
point
them
to
that
and
they
can
read
through
and
see
what's
in
scope
and
what's
not
so
I
think
scope
is
quite
tied
to
to
that.
A
A
I
think
once
like-
and
this
goes
back
to
what
philip
was
saying
like-
we
really
need
to
make
it
clear
what
the
what
the
status
of
a
given
blueprint
is,
and
I
think
it
would
be
good
to
define
what
those
are,
because
I
I
think
it's
perfectly
reasonable
for
a
a
decision
to
be
made
and
a
blueprint
produced,
but
that
blueprint
is
effectively
backlogged
because
we
don't
plan
to
implement
it
right
now
and
then,
like
once,
some
certain
criteria
is
met.
H
H
If
that's
what
we're
talking
about
it
doesn't
matter
to
me
what
we
call
them
as
long
as
we
keep
in
mind
who
the
audience
wants.
The
blueprints
are
published
in
docs
because
well,
there's
a
long
list
of
reasons
why
they
ended
up
there,
but
the
audience
was
really
more
internal,
now
we're
transparent.
So
we
are
okay
sharing
this
with
the
world,
but
this
was
really
blue.
Greens
were
intended
to
be
able
to
for
very
complex
problems,
to
have
a
single
place
where
people
could
go.
Look
at
this
document
and
say
we
have
this
problem.
H
Here's
some
data
around
it
and
here's
how
we're
proposing
to
solve
it,
and
then
we
need
to
build
staffing
around
them.
I
think
the
current
process
and
I
noted
that
a
little
bit
lower
is
when
we
created
this
process.
Engineering
allocation
didn't
even
exist,
yet
we
were
still
going
through
what
we
call
them
for
that
at
the
time.
H
So
the
thing
that
we
intended
to
do
was
to
attach
blueprints
to
engineering
allocation
and
now
the
new
prioritization
model
that
we're
using,
because
I
think
the
production
of
the
technical
solution
is
something
we've
gotten
really
good
at
and
blueprints
has
have
actually
done.
Okay,
in
that
regard,
you
can
change
that,
but
they've
done.
Okay.
H
How
do
we
put
this
in
the
machine
so
that
we
get
staff
around
it
and
we've
in
some
cases,
we've
done
it
almost
as
a
one-off
right
for
functional
decomposition.
We
put
a
team
together
because
we
really
needed
to
get
that
solved
and
I
think
the
the
challenge
now
is.
How
do
you
go
from?
I
have
a
blueprint
to
there's
a
there
is
a
group
of
people
working
on
that
is
that
is
that
the
problem
we're
trying
to
solve
for
service
with
liquids
are.
A
I
I
mean,
I
think,
that
the
the
the
most
desirable
outcome
of
any
reforms
to
to
this
process
should
be
that
there's
a
a
clear
path
towards
identifying
the
problem
documenting
the
problem,
documenting
the
proposed
solution
and
then
like
getting
that
into
the
work
stream
so
that
it
gets
implemented.
A
I
I
I've
been
talking
to
some
folks
on
this
call
already
about
this.
I
I'm
not
sure
like
what
needs
to
come.
A
First,
whether
we
need
the
the
organization
to
consolidate
around
one
process
that
that
defines
the
roadmap
and
and
and
like
the
the
work
that
needs
to
be
done
or
if
we
can
like
continue
to
iterate
on
on
the
process
that
we
have
and
expect
that
product
can
continue
to
have
their
separate
process,
but
engineering's
process
somehow
gets
merged
into
the
to
the
work
stream
right
I
mean,
I
think,
for
a
lot
of
reasons.
It
would
be
preferable
for
everyone
to
consolidate
on
on
one
process
and
as
we
expand.
A
What
I
think
we
ought
to
be
doing
is
expanding
the
scope
of
the
the
types
of
things
that
we
expect
blueprints
to
be
produced
for
because,
in
my
view,
like
any
non-trivial
enhancement,
probably
ought
to
be
a
blueprint
right
like
when
you
have
really
major
features
like
I,
I
think
the
ci
template
catalog
is
a
is
a
good
example.
A
A
Just
like
engineers
would
to
to
me.
That
makes
sense.
I
don't
know,
if
that's
the
first
step
we
should
take,
but
but
that's
that's
the
direction
I'd
like
to
see
us
go.
E
Just
just
on
that
point
marshall,
like
we,
we
spoke
about
this
the
other
day
and
you
know
often
in
the
in
the
in
the
change
blog
post.
E
There'll,
be
you
know,
a
bunch
of
changes
and
then,
if
you
dig
down
deep
enough
it'll
take
you
to
an
issue
where
that
change
was
discussed
and
it
will
be
an
issue
with
like
a
thousand
notes
on
it,
and
it's
often
really
difficult
to
kind
of
read
that
and
then
understand
sort
of
the
the
what
was
going
on
and
how
people
were
describing
it,
because
it's
just
so
big
at
this
point
and
and
having
something
a
little
bit
more
condensed
into
like
a
blueprint.
A
Yeah
and
even
higher
level
than
that,
I
think,
like
our
the
direction
pages,
that
product
maintains
right,
but
they're
maintained
to
various
degrees
across
different
stages.
Right,
there's
also
like
no
consistent
formatting
across
those
direction
pages
and-
and
it's
just
a
lot
of
a
lot
of
prose
content.
That's
with
links
to
ethics
and
issues
right,
but
it's
it's.
It's
really
difficult
to
get
a
concrete
picture
of
what
our
three
six
12
month.
A
Road
map
is
on
the
product
side
of
the
organization
I
mean,
I
think,
like
our
architecture,
blueprints,
do
a
good
job
of
documenting
what
that
looks
like
from
engineering's
perspective,
and
I
think
that's
that's,
because
they're
they're
in
a
format
that's
sort
of
geared
towards
towards
that
purpose.
So
I
I
think,
there's
opportunity
there
as
well.
A
Did
you
want
to
voice
the
points
you're
making
in
b1
there
eric.
F
Oh
sorry
thanks,
so
you
you
make
it
in
bui.
You
make
a
statement
about
how
we
have
a
separate
product
roadmap
and
technical
engineering
roadmap,
and
as
long
as
they're
separate
the
former
is
always
going
to
win.
I
agree
the
former
has
won
historically,
but
I
I
would
sort
of
attribute
this
something
different.
I
don't
think
we
have
a
traditional
product
roadmap
like
you
hinted
it's
sort
of
very
fragmented.
A
lot
of
this
was
in
pm's
heads
and
whatnot,
so
it
was.
It
was
near
impossible
for
us
to
like
reflect
like.
F
Oh,
this
is
what's
coming.
This
is
what
we
need
to
build.
So
let's
build
a
more
scalable
ci
architecture
or
whatever
it
was
going
to
be
to
accommodate
that
we
were
always
reactive
for
always
downstream
we're
always
sort
of
like
iterating,
and
we
obviously
iterate
ourselves
into
some
holes,
and
then
I
think
we
we
proved
we
can.
F
We
can
do
the
work
to
get
out
of
those
holes,
especially
over
the
last
nine
months,
but
we
need
to
roll
forward
to
a
better
model
so-
and
chad,
like
you,
mentioned
previous,
like
yes,
so
like
we're
about
to
launch
a
new
prioritization
model
called
cross-functional
prioritization.
The
next
prioritization
working
group
is
working
on
that,
but
we
should
absolutely
have
the
room
in
that
model
to
do
architectural
work.
F
It
won't
be
just
I'll
go
back
to
features
until
something
breaks
and
then
we'll
fix
everything
and
mop
up
after
ourselves.
So
it's
intended
to
be
very
a
very
balanced
model
of
product
engineering,
security,
design,
customer
concerns
everything
so
and
there's
a
discussion
on
that.
I
don't
know
if
you
have
time
to
go
into
that,
but
the
number
two,
I
think
is
important,
which
is
like
your
statement
in
bi
is
really
the
closest
in
the
stock.
F
I
see
to
like
a
problem
statement
here
like
this,
this
working
group,
of
which
this
is
the
first
instance.
What
do
we
agree
is
the
problem
to
be
solved
here
and
then
we
should
start
solutioning
and
we're
sort
of
dancing
around
that.
But
I
think
that's
the
most
important
thing
to
spend
time
on.
First.
F
Yeah,
so
the
closest
thing
we
have
to
form
today
is
the
tuesday
engineering
allocation
meeting.
So
that's
for
review
metrics
for
the
help
of
the
systems
and
that's
where
we
track
projects
that
are
going
on,
but
this
was
very
much
like
an
emergency
measure
right.
So
we've
been
doing
this
for
a
while.
This
would
be
the
place
to
propose
things
that
you
want
to
do,
whether
it's
partition
a
table
or
decompose
some
other
functional
area
of
the
database
going
forward.
F
But
it
is
it's
sort
of
a
prototype
right
and
that's
what
we're
looking
to
kind
of
formalize
with
cross-functional
prioritization,
but
it's
gonna
take
a
while
we're
breaking
old
habits
and
we're
gonna
have
to
build
up
new
habits,
and
it's
not
gonna
happen
with
the
launch
of
a
handbook
page
or
because
we
named
a
process
or
something
like
that.
We're
gonna
have
to
kind
of
like
retrain
ourselves
and-
and
you
know
to
be
fair
to
what
I
said
above.
F
Like
you
know,
I,
as
I
say
this,
like
you,
know
the
the
pm
monopoly
on
decision
making
power
like
that
is
true,
but
like
the
other
reason
that
didn't
work
is
because
engineering
the
whole
time
was
supposed
to
be
saying
like
hey.
This
is
broken.
Let's
fix
it.
We
got
tired
of
raising
our
hand
just
stopped
doing
that
right.
So
that's
how
we
intended
to
work.
It
didn't
work
but
like
it's,
it's
both
sides
that
that
sort
of
fell
apart.
So
I'm
not
I'm
not
pinning
that
solely
on
pm
pm
is
is
correct.
F
A
Yeah-
and
I
also
think
like
another-
I
I
do
think
that
that,
like
the
separate
product
and
and
technical
roadmaps
is,
is
very
core
to
what
we
need
to
solve
here.
But,
like
there's,
a
bunch
of
like
other
problems
that
I
think
that
creates
one
of
which
is
that
I
think
it's
just
difficult
for
engineers
to
track
what's
happening
throughout
the
organization
right
and
so
like
there's
an
opportunity
cost
associated
with
that,
where
we
tend
to
build
divergent
solutions
rather
than
convergent
solutions,
because
for
any
given
thing
that
a
product
wants
to
build
you're.
A
Maybe
getting
like
two
engineer
eyes.
Two
two
sets
of
eyes
on
that
before
work
gets
started,
right
and,
and
those
eyes
are
coming
from
the
same
product
group
that
that
the
proposal
is
initiated
from
right.
So
when
you've
got
people
working
on
similar
functionality
or
like
how
we're
going
to
do,
how
we're
going
to
structure,
object,
storage
or,
like
general
purpose,
solutions
for
artifact
storage
of
any
kind
like
there's,
there's
never
an
opportunity
to
get
feedback
from
multiple
parts
of
the
organization
and
then
build
that
that
core
platform
element
that
would
help
support.
F
Yeah-
and
I
think
to
be
realistic,
though,
like
this
unifying
the
road
maps
and
stuff
like
that,
like
just
knowing
where
pm
is
what
they're
working
on
they're
rebuilding
they're
hiring
like
we're,
not
going
to
solve
this
unified
roadmap
problem
in
the
near
term.
But
I
think
there
is
a
very
good
opportunity
now
that
I
think
this
script
should
focus
on
which
is
we're
going
to
launch
this
new
process.
Cross-Functional
prioritization?
F
How
do
we
best
make
sure
that,
like
we're
doing
architecture
like
we're
slotting
into
that
that
we're
doing
architecture
work
as
part
of
that
new
process,
like
that's
an
opportunity?
That's
right
in
front
of
ourselves,
it's
mostly
within
our
sphere
of
control
versus
like
changing
how
product
does
red
maps
is
not
in
our
control
and
and
they're
working
on
other
stuff
trust
me
right
now,
and
I
I
think
that
would
be
the
highest
impact
thing
we
could
work
on.
F
So
if
the
problem
statement
were,
you
know,
make
sure
we're
doing
future
unknown
architectural
changes
akin
to
functional
decomposition
of
ci,
which
we
just
completed
at
or
ahead
of
when
they're
needed
using
the
cross-functional
prioritization
group.
Like
that's
a
that's
a
problem
statement
that
I
think
we
could
start
to
start
to
debate
and
roll
around
and
stuff.
H
Yeah,
I
agree
that
I
mean
a
lot
of
the
stuff
that
has
happened.
Architecturally
is
because
people
are
pushing
and
prodding
and
talking
and-
and
we
should
institutionalize
that-
and
this
was
frankly
an
attempt
to
do
that
right,
although
it
was
more
geared
towards
making
sure
that
any
engineer
could
who
had
an
idea
or
or
saw
a
problem,
could
actually
get
organization-wide
visibility
for
these
problems.
H
But
the
thing
that
I
my
conclusion
about
the
current
process
is
that
it's
not
scalable
and
it's
not
scalable,
because
it
was
always
tied
to
stan
to
me
to
draggers
to
very
specific
people,
and
so
now
that
this
productization
framework
is
is
coming
up.
We
need
to
figure
out.
How
do
you
take
these
artifacts
that
we're
producing
today
that
we
can
iterate
and
improve
by
all
means?
But
how
do
we
make
sure
that
they
get
into
that?
H
G
Yeah,
I
agree
with
that,
and
I
think
that
we
do
have
some
recent
examples
about
the
struggles
with
the
workflow,
for
example
the
ci
partitioning
right.
We
have
a
blueprint,
we
have
a
ci
scaling,
science,
decay
blueprint
written
approved,
and
everyone
says
that
we
should
probably
do
that.
But
we've
been
talking
for
more
than
three
or
four
months.
We
had
numerous
meetings
with
sam
goldstein
with
camille
we've
tuned
about
how
to
actually
implement
that,
and
we
still
don't
know
it.
B
A
Can
somebody
describe
to
me,
like
somebody,
who's
gone
through
the
process
firsthand,
what
the
relationship
with
with
product
is
at
the
very
end,
because
my
understanding
is
that,
in
order
for
a
blueprint
to
get
merged,
there
has
to
be
some
buy-in
from
from
product,
but
it
seems
like
it's
an
informal
commitment.
Nevertheless.
A
G
So
from
from
my
experience,
it's
finding
an
em
who's
going
to
be
a
dri
from
the
product
group
site
and
explaining
to
them
what
the
blueprint
is
about.
G
Eventually,
they
agree
that
it's
a
good
idea,
but
then
there
is
always
some
kind
of
miscommunication
about
the
the
extent
of
the
effort,
the
amount
of
people
we
would
need
to
involve
to
get
it
implemented,
and
then
we
we
usually
collide
with
the
reality
where
we
are
usually
unable
to
get
enough
time
from
engineers
as
they
are
working
on
other
important
priorities
and
yeah
and
then
and
then
nothing
happens
for
a
couple
of
months-
and
this
is
what
has
happened
with
the
graphql
blueprint.
We
get
got
it
merged
more
than
a
year
ago.
G
I
think
18
or
20
months
ago,
and
we
could
never
actually
do
anything
about
about
that
graphql
blueprint
and
it
was
mostly
observability
on
the
infrastructure
side.
We
have
been
unable
to
ship
anything
because
we
couldn't
find
people
who
could
actually
work
on
that
in
the
entire
organization.
H
Right,
so,
what's
missing
is
the
institutional
lever
that
for
any
given
blueprint
proposal
whatever
it
is
that
there
is
sort
of
an
official
decision
made
of
no
we're
not
going
to
work
on
this
or
yes,
we're
going
to
work
on
this
right
now.
Some
things
just
sort
of
wither
and
fade
into
the
background
like
graphql,
and
so
it
is.
It
is
that
mechanism
to
where
access
points,
we're
building
this
nuclearization
model.
H
If
we
don't
do
this,
the
database
will
run
into
a
wall,
and
we
can,
you
know,
kiss
this
goodbye
that
was
sort
of
clear
and
present
danger,
and
so
people
signed
on
to
it.
We
need
a
way
that
it's
it
pushes
that
danger
further
into
the
future,
but
that's
always
a
harder
case
to
make
right.
Well,
if
we
don't
do
this
in
18
months,
things
will
go
sideways,
so
latching
into
this
prioritization
model
is,
I
think,
the
way
in
which
we
we
make
the
next
very
significant
iteration
to
get
these
engineering-led.
A
Yeah,
I
I
mean
the
the
I
think.
Cid
composition
is
an
interesting
case
too,
because,
like
it's
actually
for
a
lot
of
reasons,
some
of
which
you
mentioned
it's
sort
of
like
an
ideal
case
right
because
it
it
is
very
urgent
right
if
we
don't
solve
it,
we
fall
over
but
also
like
it
really
was
within
scope
of
like
one
particular
product
stage.
Right
like
it,
it's
pretty
much
discretely
the
responsibility
of
verify
to
solve
that
problem.
A
D
H
H
So
it's
not
like
we
scare
people
enough
with
the
database
is
because
parts
are
in
our
future.
We
said
this
is
the
way
to
get
there
whether
we
share
or
we
pod
functionally
composition
buys
us
some
runway
and
it
allows
us
to
start
moving
things
in
in
certain
ways.
So
we
we
scored
that
one
which
was
super
critical,
but
because
we
sort
of
piggyback
on
this
parts
ideal
of
where
we
want
to
go,
and
it's
not
it
shouldn't
be
that
way
right.
It
should
be
in
a
more
institutionalized.
H
Systematic
way
of
saying
look.
Engineering
is
telling
you
that
in
18
months
we
really
need
to
finish
this
so
that
we
are
sort
of,
and
is
it
is
it
that
we're
not
good
at
selling
those
predictions.
I
don't
know
I
mean
for
the
most
part,
it
comes
down
to
pushing
and
product
in
different
places
and
convincing
enough
people
to
get
that
on
wet
and
moving
forward.
H
I
I
I
think
it's
like
he
has
to
define,
but
I
also
kind
of
perceive
that,
like
product
prioritization
is
rather
like
a
local
problem
or
like
a
local
optimization,
where
delivery
of
the
blueprint,
if
we
commit
to
that,
it's
like
a
global
problem
because
of
the
severity
and
overlap
and
requirement
requirement
from
many
functions
so,
for
example,
marshall
you
mentioned
the
composition
like
verify
arm,
would
not
do
the
composition
because
of
severe
implications
required
like
severe
amount
of
people
required
from
from
many
functions.
I
So
I
I
think,
like
probably
at
least
from
my
perspective,
like
product
prioritization,
happens
locally,
where
blueprint
prioritization
needs
to
happen
globally
across
organization,
because
it
has
severe
implications
to
the
future
development
of
the
application
and
like
partitioning
is
yet
another
example.
It's
going
to
have
severe
implications,
how
we
partition
tables-
it's
like,
maybe
initially
ci,
but
it's
like
we
like
a
practice
that
we
need
to
apply
moving
forward
graphql.
Maybe
it's
like
a
local
problem.
I
Composible
codebase
is
definitely
like
a
global
problem
and
I
think,
like
time,
decay
for
this
year,
it's
like
maybe
defined
as
a
local
problem,
but
this
is
like
a
general
problem
description
of
how
we
want
to
approach
the
data
retention,
which
is
becoming
more
and
more
problem
of
github
outside
of
the
ci
as
well.
A
So,
like
I
don't
know,
think
if,
if
we
took
that
approach
in
all
such
cases,
it
could
result
in
a
lot
of
churn
with
a
bunch
of
people
changing
managers
all
the
time
right,
particularly
if
the
efforts
are
like
slightly
less
long-lived
than
that
one
in
particular
like
I
can
imagine
us,
get
making
a
lot
of
headway
on
like
the
graphql
blueprint,
for
example,
in
far
less
than
a
than
a
year's
time
right,
like
maybe
like
three
at
the
most
six
months,
and
I
think
we
would
get
a
lot
of
pushback
from
product
if
we
tried
to
change
management
structures
in
order
to
execute
on
that
stuff.
H
If
you
see
a
database
theme
in
development,
it's
because
we
said
this
thing
is
so
important
and
it
consumes
so
many
people
that
we
have
to
have
a
team
that
is
dedicated
to
this.
But
those
have
been
in
our
history
exceptions
rather
than
the
rule,
because
there
is
this
long
collection
of
things.
Graphql
is
one
of
them
that
don't
have
they
don't
belong
in
a
stage
right,
and
there
has
been
discussions
of.
H
Do
you
have
this
sort
of
platform,
group
and
development
as
well
like
we
did
that
in
infrastructure,
because
at
the
time
there
was
no
one
else
who
could
devote
cycles
to
fixing
scalability
problems
with
psychic
with
redis,
and
so
we
created
the
scalability
team
inside
infrastructure.
Andrew
was
leading
the
charge
with
that
and
he
was
very
home.
He
was
part
of
that
team.
D
H
And
you
know,
we've
been,
we've
been
kicking
this
on
and
off
in.
If
like
do
we,
there
was
a
proposal
once
that
the
last
person
that
touches
this
part
of
the
code
base
owns
that
and
that's
a
horrible
idea.
You
don't
want
to
do
that.
You
need
people
thinking
about
these
problems,
so
I
I
think
we
need
to
figure
out
exactly
which
is
the
problem
we're
attacking,
which
is
from
from
this
conversation.
It
sounds
like
the
frustration
around
the
or
on
the
call
is
I
have
this
thing.
H
How
do
I
get
it
implemented
because
I
know
it
has
to
be
to
be
implemented
and
then
focus
on
how
we
make
that
happen,
because
at
the
end
of
the
day,
that
is
the
thing
I
mean.
That
is
the
thing
that
keeps
me
busy
every
day,
just
pushing
buttons
on
on
people's
keypads
to
say
that
needs
attention
and
that
needs
attention
and
that
needs
attention,
and
sometimes
that
happens
successfully.
H
H
And
at
the
end
of
the
day,
you
still
have
to
go
through
the
the
filter
of
product
because
they're,
the
ones
that
are
tasked
with
prioritizing
and
implementing
and
delivering
and-
and
you
know,
sort
of
arranging
people
in
engineering
and
development
and
infra
to
be
able
to
deliver
these
things.
H
H
So
it
sounds
more
and
more
like
we're
looking
for
a
group
of
people
that
can
take
over
these
foundational
things
and
so
we're
either
building
a
case
or
want
to
or
n
teams
and
development
that
can
be
platform
specific
and
not
working
on
features
but
working
on
these
things
or
that
gets
grown
into
more
scalability
and
infrastructure,
or
we
somehow
find
the
magic
formula
to
be
able
to
get
these
things
across
in
this.
In
this
prioritization
model
that
is
being
developed.
E
Jerry,
like
just
one
one
sort
of
point
on
that
like
there
was
a
proposal
a
while
ago,
where
there
was
a
discussion
around
like
engineering
self-allocated
time,
I
forgot
what
it
was
called
and
how
much
time
you
know,
different
engineers
are
basically
self.
E
You
know
basically
figuring
out
what
to
do,
and
there
seems
to
be
some
sort
of
like
connection
between
this
and
that,
because,
like
a
lot
of
this
stuff
is,
is
stuff
that
falls
through
the
cracks
with
product,
but
is
very
important
to
to
engineers
and
like
perhaps
if
there
was,
if
there
was
more
of
a
kind
of
understanding
about
about
self-directed
time
and
and
you
know
putting
together
these
proposals,
engineering
could
kind
of
pick
up
some
of
that.
More
yeah.
G
H
H
I
don't
think
the
mr
was
closed.
I
think
it
was
just
sort
of
frozen
for
a
while
until
we
could
figure
out
what
it
actually
looked
like,
but
I
agree
that
it
wouldn't
solve
this
problem
right.
We
we
have
managed
to
get
things
through
almost
through
people's
heroic
efforts
right,
like
think
about
that
the
ton
of
stuff
you've
done
in
the
last
two
years,
which
has
been
you've,
seen
a
problem
and
and
you've
been
able
to
go,
focus
on
it
and
convince
people.
We
need
to
work
on
it,
but
it
shouldn't
be
like
that.
H
It
shouldn't,
be
you
having
to
jump
on
a
table,
kicking
and
screaming
that
this
is
an
issue.
It
should
be
a.
This
is
an
issue
and
we
put
it
in
this
privatization
machine
and
it
comes
up
with
a
number
of
engineers
and
the
amount
of
time
that
they're
they're,
working
and
in
in
products
defense
that
you
know
where
we
were
two
years
ago
or
four
years
ago
to
where
we
are
today
is
leaps
and
bounds.
Like
we've
made
forward
progress
and
and
more
and
more
product
is
more
and
more
aware
of
these
things.
H
I
mentioned
that
fabian
added
scalability
and
availability
as
a
line
item
in
their
budgeting
stuff.
That's
huge,
I
mean
it's
a
one-liner,
but
that
is
huge
because
now
pms
have
to
sort
of
figure
out.
Oh
I'm
not
just
delivering
this,
because
I'm
gonna
put
this
thing
on
gitlab.com
and
it's
gonna
go
scale,
and
so
I
need
to
the
problem.
Is
there
isn't
a
specific
number
associated
with
outline
items?
H
A
Right,
like
I,
I
think,
there's
significant
risk
in
sort
of
creating
like
a
platform,
a
team
right
that
that
runs
around
and
and
solves
every
scalability
issue
or
like
every
sort
of
cross-functional
effort,
because
you're
going
to
staff
that
with
a
bunch
of
high
context,
people
and
then
that
context
is
going
to
continue
to
get
siloed
in
that
team
over
time.
A
So,
like
my
I
would,
I
would
lean
towards
something
that
allows
us
to
much
like
engineering
allocations
used
to
be
where
we
can
create
some,
like
maybe
long-lived,
but
but
maybe
short-lived,
depending
on
the
use
case.
Structure,
pull
engineers
from
a
different
bunch
of
different
areas
solve
the
problem
and
then
but
like
their,
their
reporting
structure
doesn't
change,
but
I
mean
I
don't
know
well.
H
They
just
solve
a
very
difficult
problem,
and
do
we
take
the
next
problem
and
give
it
to
them,
or
do
we
reshape
that
group
and
send
those
people
who
have
just
now
gotten
a
ton
of
very
advanced
experience
and
sprinkle
them
around
the
organization?
So
they
can
raise
the
level
of
the
organization
and-
and
this
is
kind
of
a
management
question
that
needs
to
be
answered
in
terms
of
you
know,
to
avoid
that
that
the
thing
you're
talking
about
which
is
okay,
only
these
people
are
solving
these
really
hardcore
low-level
problems.
H
H
H
So,
if
you
start
shifting
people
around,
then
that
breaks
that
rhythm,
but
at
the
same
time
you're
also
avoiding
the
you
know,
keeping
them
all
under
the
the
same
sort
of
box,
and
but
I
think
these
are
more
academic
things
at
the
end
of
the
day,
is
how
do
we
justify
funding
funding
to
product
for
them
to
allocate
people
to
solve
these
problems,
like
it's
all
the
academic
stuff
that
we're
talking
about
it
all
makes
sense
like.
I
think
I,
in
a
in
from
an
idea's
point
of
view.
H
This
all
makes
sense,
but
we
always
our
our
wall
is
funding
for
solving
this
problem
and
that's
where
that's
the
the
world
we
need
to
break
and
again
I
I
think
product
has
come
a
long
way
and
helped
me
not
think
about
scalability
as
a
problem
that
needs
to
be
solved.
But
there's
there
are
more
turns
to
that.
To
that
goal
that
we
need
to
make
and.
A
I
think
it's
it's
exacerbated
by
the
fact
that,
like
like,
in
many
cases,
you
almost
need
a
dedicated
resource
to
even
fully
uncover
the
problem
and
even
begin
to.
I
like
come
up
with
with
solutions
right
so
like
there's
a
trust
relationship
that
needs
to
exist
as
well,
where,
like
somebody
can
say,
hey
this
is
going
to
become
a
problem,
and
product
is
immediately
willing
to
give
that
person
the
space
to
evaluate
that
right.
A
H
Be
able
to
say:
okay,
I'm
engineering,
so
I'm
engineer
so
and
so-
and
I
see
this
and
I'm
gonna
yell,
but
no
one's
gonna.
Listen.
So
let's
put
this
thing
together
so
that
we
drag.
You
know
some
senior
technical
people
into
this
and
we
drag
some
smes
up
to
this
and
we
back
some
management
into
this
and
we
drag
product
into
this.
H
H
We've
put
the
blueprint
together,
that
is
the
artifact
that
gets
produced,
but
there's
no
decision
being,
and
so
we
sort
of
go
back
to
how
do
we
plug
in
whatever
it
is
that
we
have
blueprints
epics
whatever
it
is
into
making
sure
that
we
get
a
year
on
a
not
silence
on
the
line,
which
is
what
graphql
has
gotten
over
the
last
two
years
now
one
has
said
we
should
never
do
this.
No
one
has
said
we
will
not
do
this.
H
This
is
sort
of
it
gets
mothballed
and
no
one
talks
about
it,
and
then
you
know
one
day
there
will
be
a
graphql
event
and
then
we
will
go
work
around
about.
We
will
all
go
work
on
it.
So
that's
that
I
think
go
ahead.
Sorry.
I
E
I
But
I
think
we
we
agree
about
the
graphql
being
a
smoking
gun
to
fire
at
very
unexpected
moment,
but
this
is
high
note,
but
the
other
note
maybe
kind
of
approaching
that
from
the
academia
point
of
view.
Maybe
we
just
have
architecture
steering
committee
that
we
kind
of
review
blueprints
and
say:
okay,
graphql,
it's
like
from
from
the
group.
I
don't
know
five
ten
people.
Whoever
is
there
we
pick
we
presented
to
eric
it
always
helped
to
have
eric
or
seat.
I
G
So
I
thought
about
that.
The
reason
why
we
don't
have
the
council
is
that
sid
and
eric
were
very
vocal
about
not
willing
to
have
a
council
and
committee
of
architects
and
the
way
I
try
to
approach
this
problem
of
having
like
more
like
a
group
of
people,
elevating
elevating
the
importance
of
something
I
wanted
to
add
the
section
of
recommenders
to
a
blueprint
so
that
we
have
a
few
names
of
you
know,
people
that
are
supporting
a
given
initiative.
G
We
we
have
them
documented
in
in
the
blueprints.
What
should
make
it
easy
to
understand
that
those
people
believe
that
you
know
it's
it's
important
to
resolve
that.
That
being
said,
I
think
that
basically,
it's
quite
surprising
that
very
often
we
do
have
product
on
the
same
page.
Product
believes
that
this
is
something
that
we
should
do
it's
just.
G
They
are
saying
that
we
don't
have
capacity
to
do
that
and
recently
in
case
of
ci
partitioning,
we
even
had
an
investment
case
with
like
a
case
for
hiring
five
additional
people,
but
it
won't
solve
that
problem
because
we
will
hire
them
probably
like
throughout
the
year.
G
H
So
you
know
for
me
that
means
building
relationships
with
products
so
that
I,
when,
when
people
are
bringing
when
people
bring
things
up,
I
can
sort
of
go
and
go
back
to
the
folks
in
product
that
I
that
I
talk
to
regularly
to
say
we
need
to
get
this
in
the
roadmap
software.
We
need
to
get
cycles
with
it,
but
even
when
I
get
those
people
to
say
yes
when
they
need
to
sign
the
check
they
may
go
like
well,
I
have
five
other
things
competing
for
this.
A
I
think
the
only
real
opportunity
I
see
with
the
next
hooking
into
the
next
prioritization
stuff-
and
maybe
we're
already
too
late
on
this,
because
the
idea
is
that
product
is
required
to
allocate
30
time
to
maintenance
right,
but
they
can
themselves
still
identify
what
is
maintenance
within
their
particular
stage
like
we
could
have
used
this
as
an
opportunity
to
just
straight
up
allocate
30
of
the
prioritization
to
engineering
right
and
then
we
could
have
coordinated
within
engineering
like
what
that
stuff
looks
like.
A
So
maybe
there's
still
an
opportunity
to
do
that
where
we
like,
rather
than
taking
the
approach
that
we're
currently
headed
down,
which
is
labeling
issues
that
are
related
to
maintenance
as
maintenance.
Maybe
we
say
that
everything
that
we're
considering
maintenance
has
to
go
through
this
enhancement
proposal
or
blueprint
process
and
engineering
is
going
to
make
the
decisions
for
which
of
those
items
are
our
priority.
H
I
think
that's
definitely
a
proposal
that
we
can
bring
to
eric
and
say:
can
you
negotiate
this
with
product
for
us
to
be
the
ones
that
own
that
30
in
a
structural
way
right?
So
we
have
this
process
and
it's
it's
like
when
you
show
up
to
the
party
and
say:
hey,
let's
go
do
this,
you
know,
ask
product:
what
would
it
take?
What
do
you
need
from
us
to
be
able
to
for
us
to
move
those
prioritization
levels
within
within
this
model
for
that
30
percent,
because.
A
I
I,
which
I
mean
30,
is
so
significant.
I
would
just
hate
to
see
that
squandered
on,
like
we
need
a
like
minor
version
of
our
jquery
dependency,
upgraded
right
like
yeah.
That
stuff
has
to
happen
too,
but
when
there's
like
such
significant
maintenance
that
that
needs
to
be
done,
having
having
an
individual
product
stage
make
the
decision
that
they
want
to
spend
their
time
on
upgrading
library
dependencies
instead
of
working
on
like
architectural
changes,
doesn't
doesn't
seem
good.
G
The
90
of
maintenance,
in
my
opinion,
is
actually
a
technical
vision
that
is
documented
in
an
enhancement
proposal
or
the
architectural
evolution
blueprint,
and
then
issues
are
being
created
proactively
based
on
on
the
vision
and
that's
how
what
maintenance
actually
is?
You
can't
have
like
a
complete
roadmap
for
a
maintenance
for
the
like
next
five
years.
G
Yeah,
the
maintenance
is
being
a
maintenance,
is
a
process,
and
maintenance
is
not
a
collection
of
issues
that
you
can
like
distribute
amongst
teams
and
just
get
them
assigned.
A
All
right:
well,
I
think
I
think
we've
gone
sufficiently
over
time
for
this
week.
I'll
see
you
all
next
week.