►
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
So
we're
discussing
the
kind
of
the
chartered
or
the
ownership
of
the
fulfillment
group
and
there's
there's
an
idea
to
say:
hey.
The
fulfillment
group
should
be
responsible
for
kind
of
the
core
billing
infrastructure
and
then
the
growth
teams,
which
we
now
have
can
then
be
responsible
for
other
parts
of
of
everything
in
that,
like
the
the
signups
and
the
workflows
there.
A
The
assumption
underlying
that
is
that
we
can
decouple
those
things
into
separate
applications
or
that
we
can
never
like
separate
applications
or
micro
services
or
that
there's
an
API
in
between
I
disagree
with
that
assumption.
I
do
not
think
that
that
is
the
case.
I
think
we
have
kind
of
one
customer
portal.
I
think
that
the
most
efficient
way
to
do
that
is
one
code
base,
so
that
they
kind
of
display
ting
up
in
different
applications
is
not
ideal
from
kind
of
a
velocity
perspective
like
we'll
just
be
less
efficient
as
a
company.
A
What
needs
to
be
very
clear
is
that
fulfillment
and
the
portal
should
be
run
like
the
rest
of
gate
lab,
where
everyone
can
contribute.
So,
although
they
own
the
application-
and
they
might
be
the
maintainer
zhan
that
and
they
actually
kind
of
merged
merger
costs
that
come
in,
they
are
not,
and
they
and
the
p.m.
of
the
fulfillment
team
prioritizes
the
time
of
that
team
when
there's
contributions
coming
in
that
they
didn't
ask
for
that
is
very
important
to
quickly
kind
of
turn.
Those
around
get
the
merge
to
get
people
feedback.
A
That
we
didn't
schedule
so
and
that's
been
a
lesson
for
us
for
the
PM's
that
PMS
schedule
the
time
of
the
engineering
team.
They
do
not
determine
the
direction
of
the
product.
Apart
from
that
like,
if
there's,
if
there's
other
people
contributing
to
that
and
it's
it
wasn't
or
your
roadmap,
then
that
doesn't
mean
it
shouldn't
happen
and
I
think
that's
a
bit
the
trap
that
we've
fallen
into,
where
we
think
that
the
fulfillment
team
p.m.
should
coordinate
all
of
that
and
that
the
fulfillment
engineering
team
should
make
all
of
that.
That's
not
the
case.
A
Keep
the
fulfillment
team
as
the
code
owners
of
the
portal
application
and
the
other
applications,
but
make
sure
that
all
the
other
teams
know
that
they
can
that
they
can
contribute,
and
then
it's
okay
for
the
PM
for
the
fulfillment
team
to
focus
on
things
that
only
they
can
do
billing
flows.
Things
like
that
and
that
the
growth
team
contribute
to
things
that
are
in
their
goals
and
that
we
maybe
even
change
the
goal
of
the
fulfillment
team
to
have
as
an
explicit
thing.
A
They
focus
on
is
like
making
sure
that
other
people
can
effectively
contribute
and
change
the
application
make
that
a
stated
goal
now.
This
is
besides
any
like
super
major
things
we
have
to
do
like.
If
we
we
need
a
rewrite
or
something
like
that.
That's
a
different
situation,
but
the
solution
of
having
needing
multiple
people
to
contribute
to
be
the
same
thing
should
not
be
to
split
it
up
into
separate
apps.
B
I
have
a
question.
You
said
we
need
to
make
sure
that
the
other
teams
need
to
be
told
that
they
can
contribute
to,
let's
say
the
customer
portal,
so
filmer
doesn't
have
to
do
it
all.
It's
also
true
to
say
that,
like
those
teams
can
just
decide
what
they
do,
because
it's
the
PM
scheduling
them.
So
what
what
p.m.
mr.
Stancil
from
another
area
is
going
to
direct
the
team
that
they
coordinate
with
to
go
work
on
the
filner.
A
A
B
A
Don't
they
don't
in
so
far
as
the
only
the
only
person
who
should
coordinate?
Who
should
who
should
be
aware
of
the
new
situations,
the
PM
of
the
fulfillment
team?
Because
we
now
have
these
growth
teams
that
do
part
of
the
fing
set
they've
been
doing
before
you
should
probably
take
stock
of
what
the
growth
teams
are
doing
and
leave
that
to
their
growth
teams
and
focus
on
all
the
other
stuff,
because
everyone
agrees
there's
enough
to
do.
C
B
Should
do
it,
we
should
do
like
a
near-term
experiment,
then
and
say
okay
for
for
some
period
of
the
end
of
which
were
comfortable.
Judging
success
or
failure.
The
fulfillment
team
is
going
to
make
it
easier
for
other
people,
other
teams
to
contribute
to
their
code.
The
expansion
conversion
acquisition
games
are
going
to
be
told
that
they
can
and
should
have
their
team's
contributing
to
that
area
of
the
codebase.
And
then
we
see
if
we
get
a
different
behavior
at
the
end
of
one
month,
two
months,
a
quarter
what's
reasonable
to
see.
A
I'm
not
sure
for
sure
I
don't
want
to
stop
anything.
That's
in
flight
and
I'm,
not
sure
even
the
fulfillment
team
should
focus
on
make
it
easy
to
contribute.
Maybe
it's
already
easy
to
contribute
and
the
other
teams
just
didn't
didn't
know
that
it
was
allowed.
So
it
really
depends.
I
cannot
tell
I,
don't
have
the
information
the.
D
Growth
team
has
contributed
to
other
parts
of
the
codebase
I.
Don't
think
it's
necessarily,
though
growth
team
is
now
four
different
teams,
so
there
may
be
some
variance
within
those
teams.
We'd
have
to
I
have
to
take
a
little
bit
more
to
make
sure
I
understand
what's
happening
in
this
particular
situation,
which
may
be
a
new
one.
We
at
least
in
one
case
we
contributed
and
that
team
wasn't
engaged
for
proper
review
was
reviewed
by
a
separate
maintainer.
It
was
merged
and
there
was
a
problem
with
it
which
had
to
basically
get
address.
D
So
that's
an
example
where
the
grow
team
wasn't
actually
being
assertive
and
helping
contribute,
but
they
weren't
engaging
in
collaboration
where
we
basically
added
working
across
staging
stages,
where
they
should
really
collaborate
on
that.
So,
if
we're
not
seeing
the
right
level
of
collaboration
with
fulfillment
teams-
and
that
sounds
like
an
issue-
we
should
be.
A
B
It
also
sounds
like
if
your
hypothesis
right
said
then
fulfillment
as
a
backlog,
that's
over
large
right
now,
and
it
would
be
worth
going
over
it
and
pulling
out
issues
from
the
flowing
backlog
and
having
them
on
these
other
teams.
And
if
we
don't
find
anything,
then
we
know
that,
like
okay,
there's
something
else
going
on
yeah.
A
C
Seem
like
the
core
of
Scott's
request
to
me,
is:
if
you
look
at
twenty
four,
a
one,
two,
three
and
four,
like
that's
the
problem,
you're
trying
to
solve
it's
those
things
like
everybody
is
okay
with
saying
yeah.
The
growth
came
owns
these
experiences
in
this
way,
and
this
is
actually
how
we
could
measure
whether
or
not
this
is
successful.
It's
really
easy
for
us
to
say:
okay
did
we
do
we
now
have
a
new
signup
flow?
Do
we
now
have
a
new
trial
flow
yep.