►
From YouTube: 2020 07 07 Manage Import Weekly
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
A
A
Well,
I
have
a
few
first
few
items
in
the
agenda.
It's
great
to
see
everyone.
It's
been
a
while,
since
I've
seen
this
group
but
I'll
be
helping
support,
while
harris
is
out
for
the
next
few
weeks,
so
I
will
be
support
doing
everything
I
can
from
a
product
standpoint
to
to
support
you
all,
and
I
wanted
to
start
by
getting
a
pulse
check
on
kind
of
planning.
Readiness
for
13
3.
A
harris
went
ahead
and
created
the
13-3
planning
issue,
which
is
which
was
great
to
see,
but
I
I
wanted
to
get
a
pulse
check
from
this
group
to
see
kind
of
what
needed
to
be
accomplished
to
make
sure
that
we
have
the
groomed
issues
ready
for
that
milestone
to
me
it
looks
like
we
do
have
a
good
chunk
of
issues
ready
to
development,
but
the
direction
issues
could
use
a
little
bit
more
refinement.
A
A
So
I
wanted
to
start
with
the
group
migration
issue,
because
I
think
that
is
probably
one
of
the
more
important
direction
issues
and
when
I
click
into
this
thread
here,
it
seems
like
we're
still
kind
of
in
discussion
in
terms
of
kind
of
how
to
handle
that.
We
have
this
vision
here
on
the
full
group
migration
solution,
and
we
had
a
couple
of
we,
like
george,
had
a
ton
of
information
here,
which
is
awesome
and
harris
had
a
couple
of
suggestions
here.
So
I'll
shut
up
for
a
minute
liam.
C
Yeah,
that's
a
good
question.
I
see
harris
has
just
joined
us
as
well,
okay
harris
so
I
I
spoke
terrorists
about
this
in
our
one-on-one
last
week
and
I
think
the
so
the
outcome
we
came
to
is
there's
two
ways
to
approach
this.
One
is
there's
just
a
whole
technical
vision
which
I
think
we're
still
trying
to
build,
which
is
the
idea
of
that
brainstorming
issue,
but
at
the
same
time
I
think
there's
quite
a
clear
path.
We
want
from
a
product
point
of
view
with
this.
C
It
just
does
something
and
that's
something
I
think
can
be
defined
it
can
be.
It
tries
to
replicate
the
current
process
that
we
have
now
or
it
could
be
something
really
really
lightweight.
C
So
you
have
like
a
take
me
to
the
cloud
button
and
it
will-
and
we
kind
of
decided
whether
that
should
exist,
for
example
in
your
self-managed
instance,
or
on
gitlab.com,
and
all
it
would
basically
do
is
it
would
take
some
parameters
such
as
the
endpoint
and
maybe
some
authentication
information
and-
and
it
would
just
basically
do
something
really
simple
like
kick
off
the
group
import
export
api
and
do
nothing
more.
C
So
it's
just
like
a
really
really
simple,
first
step
to
like
prove
how
it
could
work
from
a
from
a
customer
point
of
view,
and-
and
I
guess,
as
it's
all
sort
of
ui
based
at
the
moment.
We
can
then
iteratively
over
time
make
all
the
technical
changes
that
we
want
to
in
the
background,
and
so
I
I
think
in
terms
of
what
we
do
in
13
3.
A
D
Jeremy,
just
want
make
sure
you
guys
hear
me,
because
I
have
really
glitchy
video
at
this
point
good,
so
I've
I've
proposed
two
different
approaches
and
in
that
issue
that
you're
laying.
D
One
is
sort
of
improv
and
that
is
taking
the
current
capabilities
that
we
have
and
just
wrapping
them
into
a
user
experience.
That
is
more
like
the
other
importers,
so
taking
that
file
based
migration
and
just
wrapping
in
a
nicer
kind
of
a
ux
and
the
other
approach
is
what
you're
describing
and
that
is
making
the
smallest,
the
thinnest
slides
that
we
can
take
across
using
a
new
framework
so
building
a
framework
that
is
not
file
based.
D
That
is
kind
of
an
api
to
api
and
I've
sort
of
described
both
of
those
as
possible
nbc's,
and
what
I've
proposed
is
to
actually
do
both
of
those
I
would
like
for
us
to
in
the
first
place,
or
in
the
first
couple
of
iterations,
try
both
approaches,
see
which
one
works
better.
What
the
pros
and
cons
are
each
one
of
them,
because
this
is
a
very
big,
very
big
project
and
we
can
now
ahead
of
trying
anything
is
the
right
kind
of
technical
approach
we
should
take.
D
So
I
I'd
be
willing
to
entertain,
try
a
couple,
different
spikes,
trying
multiple
approaches
at
the
same
time
and
then
either
picking
a
winner.
Picking
what
seems
to
be
working
best
like
you
know,
it's
possible
that
you,
like
one
or
the
other
better
or
talking
about
how
to
combine
the
two
approaches
and
what
you
learn
from
from
both
to
come
up
with
some
hybrid
approach.
It
makes
more
sense
for
us,
so
I
feel,
like
all
of
that
is
still
open
up
in
the
air.
A
D
C
C
And
so
I
think
that's
a
that's
a
great
idea,
but
in
terms
of
those
sort
of
both
those
two
approaches,
I
guess
we
do
do
we
want
to
clarify
kind
of
like
what
the
spike
should
be
or
do
we
want
to
leave
that
to
kind
of
like
be
as
part
of
the
exploration.
So
what
I
mean
by
that
in
the
first
example
we
can
we
can.
C
We
can
wrap
up
the
current
experience,
but
we
can
do
that
in
multiple
ways.
Right,
we
can
decide
that
the
process
is
initiated
from
the
target
instance
or
we
could
basically
say
the
process
starts
at
the
origin
instance
and
then
probably
the
same
thing
goes
to
the
second
one,
whereby
we're
talking
about
creating
a
very,
very
simple
importer
based
on
the
api.
Only
approached
what
do
we
start
with
there?
Do
we
start
with
just
as
jeremy
said
users?
Do
we
start
with
just
groups?
D
Yeah,
so
I
think
we
should
like,
if
we're
going
to
two
approaches
before
we
do
two
approaches,
and
one
is,
you
know,
just
wrapping
up
wrapping
the
file
based
experience.
You
know
a
better
user
experience
and
then
also
doing
the
approach
where
we're
gonna
pick
one
object
to
come
up
to
come
across,
but
using
the
new,
and
you
know,
like
reliable
re,
restartable,
better
framework
that
we
talked
about.
D
I
think
one
of
those
should
be
a
push
and
whether
there
should
be
a
pool.
So
one
of
those
should
be
take
me
to
the
cloud
experience
the
other
one
should
be.
I
have
somewhere
else
files
or
things
that
are
left
behind
and
I'm
in
a
new
instance
now
and
I
want
to
pull
those
across.
So
I
think
you
know
having
those
two
spikes
going
into
different
directions
might
teach
us
about
each
one
of
those.
What
we
want
to
know
so
that
we
can
pick
the
right
thing.
D
What
I
have
pro
proposed
and
I'm
open
differently
to
changing.
This
is
issues
so
I
said
something
for
the
thin.
You
know,
let's
just
pick
one
small
thing
that
we
know
how
to
do.
I've
suggested
we
just
mimic
the
come
separate
value
importer.
D
The
csv
importer
just
brings
the
title
and
description
across
so
that
that's,
I
think,
okay,
for
a
spike
to
do,
because
these
are
really
simple,
and
you
know
I
don't
expect
any
kind
of
issues
to
arise
from
that.
I
actually
like
the
idea
of
users,
which
already
mentioned,
because
that's
something
that
we
don't
have.
D
I
am
a
little
afraid
of
that
being
the
first
spy,
because
I
know
there's
some
sensitivities
around
users
and
usernames
and
I
feel,
like
the
spike,
may
be
wrapped
up
into
things
that
are
not
technical
in
nature,
but
more
of
just
process
and
answering
questions.
D
So
that's
my
take
on
it
again
like
I,
but
really
when
I'm
here
like
what
do
you
think
is
feasible
within
a
milestone
like
how
many
or
what
things
can
be
accomplished
in
a
milestone
so
that
at
the
end
of
13
3,
we
have
learned
some
things
and
we
can
paint
sort
of
a
better
path
forward.
A
That
makes
sense
to
me
harris,
like
users
is
probably
not
the
right
place
to
start.
If
your
goal
is
simplicity
in
the
first
iteration,
so
I'll
go
ahead
and
create
that
engineering
spike
issue
I'll
take
a
crack
at
it
and
then
I
can
I'll
share
it
with
you
asynchronously
we
can
kind
of
refine
together,
but
we'll
that'll.
That
sounds
like
a
great
next
step.
A
Cool,
I
also
had
a
question
around
internationalization
automation,
jazzy.
I
really
appreciate
your
take
here
in
that
issue.
The
last
comment
that
you
had
was
you:
it
sounded
like
progress
was
previously
kind
of
stalled
because
there
wasn't
an
api
available
from
crowded
that
we
could
use.
Are
there
any?
Has
that
changed
in
the
five
months?
Are
there
other
issues
we
could
tackle
in
the
meanwhile?
What
is
your
take
and
kind
of
the
next
step
here.
E
So
check
the
api
is
still
in
beta,
but
I
think
the
points
that
I
put
in
the
second
comment
are
all
still
valid
and
those
are
little
things
that
we
could
tackle.
That
would
help
speed
up
the
process
anyway.
Well,
looking
at
it
today,
I
was
thinking.
Maybe
we
should
have
a
spike
first,
because
these
are
mostly
guesses
of
things
that
I
think
will
speed
up
the
process.
I'm
not
actually
sure
how
you
would
run
a
script
like
this
outside
of
project,
so
that
would
be
something
that
needs
investigating.
D
D
I
was
thinking
those
manual
steps
that
we
have
to
do
every
time
we
pull
things
across
where,
like
the
comment
like,
is
it
a
commit
title
or
commit
comment?
That
is
the
correct
format
and
it
creates
like
60.
You
know
dangerbot
warnings,
so
things
like
that
that
we
can
potentially
change
would
be
good
to
attack.
I
just
want
to
keep
making
progress,
how
they
want
to
stall.
So
if
these
are
things
we
can
do
now,
I'd
like
to
pick
up
one
or
a
few
of
those.
E
D
E
A
Thanks
a
lot
josie
that
was
going
to
be
the
next
question.
I
really
appreciate
it
cool.
So
that's
that's
awesome.
I
just
want
to
also
verify
my
understanding
on
our
process.
It
sounds
like
the
goal
is
to
pull
ready
for
dev
issues
out
of
the
next
1-3
into
13-3.
A
I
was
a
little
confused
about
how
many
issues
we
pull
in.
If
that
is
the
case,
whether
or
not
we
do
that
based
on
team
velocity,
but
here
since
you're
here
you'll
definitely
know.
A
Liam
dennis
what
what's
your
take
on
that.
D
F
So
what
we
did
the
last
releases
was
basically
based
on
the
the
historical
team
velocity
plus
the
idea
of
not
over
over
peak
issues,
to
avoid
having
x-ray
issues
at
the
end
of
the
release.
So
I
think
we
had
a
comment
somewhere.
I
don't
remember
in
what
issue
now
that
for
this
time
we
would
try
to
to
to
leave
some
space
for
work
and
issues
outside
of
what's
planned.
F
So
it's
something
it's
it's
a
complex
equation
that
goes
historical
velocity,
minus
open
space
for
non-planned
issues
and
something
like.
A
That
that's
super
helpful
thanks
casio
I
sounds
like
I
got
it
mostly
right,
but
that's
that's
great
to
know
that
we
have
some
space
for
unplanned
issues.
C
Yeah
we've
been
fairly
consistent
over
the
last
few
milestones
in
terms
of
number
of
issues,
we're
actually
discussing.
I
think
in
last
week's
team
meeting
we're
probably
at
a
point
now,
where
we've
collected
enough
weight
data
as
well
to
see
how
that
kind
of
marries
up
and
whether
we
should
start
using
that
instead.
C
So
so
I
I
can,
I
can
look
into
that.
I've
I'll
talk
a
bit
more
about
it
in
a
minute
actually,
but
I've
started
to
build
some
dashboards
to
make
some
of
this
stuff
easier
as
well.
So
that's.
F
A
Great
point:
keep
that
in
mind
cool
thanks
for
the
discussion.
I
really
appreciate
it.
Y'all.
Are
there
any
other
issues
that
we're
aware
of
that
kind
of
need
some
product
involvement.
C
Yeah,
sorry,
sorry,
sorry,
jeremy,
having
spoke
to
harris
last
week,
I
think
one
of
the
things
we
spoke
about
in
terms
of
directional
issues
was
what
we
can
do
and
with
regards
to
some
of
the
github
importer
stuff,
so
that
we're
in
a
better
position
a
couple
of
months
down
the
line
when
we
need
to
invest
hopefully
more
more
time
in
that.
I
think
at
the
moment,
there's
some
issues
around
kind
of
like
performance
dealing
with
some
some
bucks
and
things
like
that
that
we'll
probably
try
to
pull
in.
C
As
far
as
I'm
aware,
I
think
most
of
them
are
sort
of
ready
to
be
to
be
picked
up.
I
don't
think
there's
a
huge
amount
of
involvement
needed
in
the
moment.
A
Yeah
that
that's
I,
I
also
feel
like
they're
ready
to
be
picked
up,
but
I'll
take
another
pass
of
them
and
start
moving
them
into
the
13-3
milestone
as
kind
of
that's
kind
of
needed.
Amanda
are
you?
Are
you
good
on
your
end.
G
Yeah,
I
can
briefly
talk
about
what
my
plan
is
for.
Actually
the
rest
of
this
milestone,
as
well
as
13.3,
so
I'll
be
working
on
the
pagination
and
search.
So
if
there's
anything,
I
need
to
do
from
a
ux
standpoint.
G
A
D
We
have
issue
or
the
github
importer,
so
that's
the
one
that
we
were
trying
to
get
into
thirteen
three,
and
that's
that's
one
of
the
issues
that
I
think
liam
dennis
could
help
me
with
making
sure
that
we
do
get
to
that
is
getting
the
github
importer,
imagination
implemented
and
that's
important
for
our
scaling
of
the
github
importer,
which
is
going
to
be
needed
for
our
big
project
soon
to
be
able
to
handle.
D
You
know
like
4
000
projects
being
loaded
into
into
a
possible
list
of
projects,
for
you
to
pick
from
that
issue
has
actually
been
broken
up
into.
I
believe
four
or
five
different
issues
and
they
are
very
in
various
stages
of
ready,
so
some
of
those
may
get
picked
up,
not
all
of
them
may,
depending
on
how
far
we
get
with
refinement.
I
would
prefer
if
we
could
refine
them
all
and
then
during
the
planning,
see
if
we
can
actually
load
them
all
into
the
same
milestone
or
is
the
dependency?
D
Are
they
really
hard
dependencies
where
we
need
to
wait
it's
another
miles
for
those
dependencies
to
be
sold?
I
know
there
are
dependencies
between
some
of
those.
I
just
don't
know
if
they
could
be
like
sequenced
into
a
milestone,
or
does
it
require
two
milestones?
I
think
that's
where
we
are
with
that
big
big
issue,
and
I
don't
have
sorry.
I
don't
have
the
issue
with
me,
but
it's
been.
D
It's
been
definitely
broken
up
and
it's
in
the
right
spot
for
everybody
to
refine
each
individual
pieces
of
front
end
piece:
there's
a
backend
piece
to
use
the
github
api
instead
of
our
own
back
end
for
paging,
so
that
we
would
only
pull
from
the
github
api
what
we
need
as
opposed
to
pull
everything
and
then
we
kind
of
sort
down
our
end
and
then
there
is
the
issue
to
finally
implement
the
vagination.
So
all
of
those
are
linked
in
the
planning.
D
I
think
they're
linked
off
of
the
planning
issue
4133
and
since
I'm
talking
and
again
you
know
I
seem
to
have
a
good
connection,
I'm
a
little
disappointed
in
the
team,
not
having
corrected
the.
What
jeremy's
I'm
going
to
correct
you
as
a
matter
of
process,
the
team
will
pull
issues
into
13-3
during
the
planning
call.
You
said
you
would
be
putting
issues
into
thirteen
three,
but
that's
really,
you
know
as
part
of
our
process.
D
A
H
Yeah,
just
since
I'm
working
on
the
front-end
part
of
the
making
pagination
for
github
importer
right
now,
it's
just
my
feeling.
It
seems
too
risky
to
try
to
pull
everything
in
the
one
milestone,
because
it
will
require
a
number
of
backhand
work,
number
of
front-end
yoke
and
obviously
some
effort
to
glue
things
together,
and
I
believe
it's
very
easy
to
miss
the
milestone.
H
If,
for
example,
the
backing
block
will
take
up
to
the
end
of
milestone
and
we
will
simply
have
no
time
to
make
sure
that
things
are
properly
tied
together
with
front
end
and
back
end
because
right
now
we
are
doing
some
changes
from
the
front
end
part.
This
is
planned
for
this
milestone,
it
will
be
delivered.
B
A
Got
it
so
as
a
new
person
to
the
process?
How
should
we
handle
that
planning
that
that
process
next?
Should
we
maybe
next
import
meeting
when
we
have
this
kind
of
a
full
meeting,
should
we
handle
that
then
synchronously
or
do
we
should
we
handle
that
asynchronously
like
what
what's?
What's
the
recommendation
here.
C
Yeah
so
historically,
we've
always
had
a
dedicated
call
to
go
over
plan
and
I
think
it's
that's
been
quite
helpful
and
one
of
the
things
that
we
have
spoke
about
recently.
C
I
think
it's
mentioned
in
most
recent
retrospective-
was
we
we're
at
a
point
now
where
we
should
probably
try
to
do
more
of
kind
of
like
the
plan
in
readiness
asynchronously,
so
that,
on
the
call,
it's
more
of
a
review
more
of
a
call
out
anything
that
you're
concerned
with,
maybe
then
to
a
bit
of
detail
on
some
of
the
bigger
directional
issues,
but
it's
more
about
kind
of
like
final
comments,
rather
than
kind
of
like
a
continuation
of
the
process.
C
So
I
I
mean
I,
I
would
suggest
that
we
put
a
call
in
and
we
have
kind
of
like
we
don't
change
too
much
from
how
we've
been
working.
So
we
put
a
call
in
next
week
if
we
can
do
anything
ahead
of
time
great
and
then
we'll
kind
of
just
close
things
out
during
the
during
the
call.
B
B
I
would
definitely
agree
on
trying
to
have
a
little
bit
more
planning
readiness
ahead
of
time,
because
we've
spent
a
lot
of
time
during
the
planning
meeting,
which
I
think
was
typically
30
minutes,
but
can
extend
to
itself
into
an
hour
and
we'll
well
during
that
planning
meeting,
actually
be
refining
issues
for
for
certain
things
that
our
priority
that
we
wanted
to
try
to
get
into
that
milestone.
B
A
Cool
thanks
very
much
harris.
Would
you
mind
trying
to
see
if
we
can
find
some
time
this
week
to
be
able
to
meet
maybe
on
friday.
D
I
can
move
the
meeting
to
friday
and
don't
make
sure
that
everybody's
okay
with
you
know
having
just
a
few
more
days
to
refine
everything
you
need
to
refine.
So
just
speak
up
now
or
in
a
in
the
planning
issue
to
call
out
anything
that
might
that's
directional
and
we
thought
was
important
but
might
not
be
able
to
be
refined
by
friday.
And
then
we
can
maybe
put
some
message
from
that.
B
D
C
Perfect,
thank
you.
I
mean
I'll
just
quickly
run
through
this,
with
the
two
minutes
that
we
have
spare
a
few
people.
Who've
already
have
seen
this
and
I
created
a
dashboard
as
well
for
access
that
was
actually.
The
reason
for
creating
in
the
first
place
was
to
get
a
better
view
of
the
security
backlog
in
access,
and
I
spent
a
bit
of
time
earlier
this
afternoon
and
take
off
kind
of
modifying
it
so
that
it
would
work
for
import
as
well.
C
It's
quite
hard
coded
at
the
moment,
so
I
need
to
kind
of
play
around
with
filters
and
stuff
and
I'm
trying
to
get
like
a
common
view
that
we
can
use
and
maybe
check
in
like
once
a
week
on
the
on
the
weekly
call
just
a
quick
like
30
or
60
second
overview
as
to
where
we
are
to
make
sure
that
things
like
the
security
backlog
is
actually
going
down
and
not
going
up
and
to
call
out
whether
there's
any
concerns
with
with
throughput
or
kind
of
like
long-running
merge
requests.
And
things
like
that.
C
C
It's
a
good
reminder
for
everyone,
probably
like
there
are
like
long
running
mrs
open
and
maybe
things
that
we
can
talk
about
in
the
in
the
retrospectives
as
well
also
related
to
this,
and
I
don't
think
we're
gonna
be
able
to
go
into
too
much
detail
with
a
minute
left,
but
one
of
the
akrs
was
set
for
this
quarter
was
around
increasing
throughput
across
all
of
the
teams
and
groups,
and
but
one
of
the
ones
that
I
set
specifically
for
import
was
to
move
up
from
5.6
to
9.1.
C
So
it's
a
20
increase.
Actually
it
was
more
than
that
for
the
import.
I
think
it
was
a
20
increase
for
access,
but
I
felt
as
if
import
should
probably
get
to
the
same
level
as
as
access,
I
don't
think,
there's
any
reason.
Important
should
should
have
lower
throughput,
and
so
I
think,
throughout
throughout
the
next
weeks.
I
I
don't
given
the
numbers
given
where
we
were
last
month.
I
don't
think
we're
going
to
achieve
that.
But
I'd
say,
let's
use
the
next
few
weeks
to
think
about.
C
Maybe
why
that
is
and
to
think
about
what
we
could
do,
what
we
could
do
differently,
and
this
has
been
a
conversation.
I've
had
in
access
as
well
like
if
there's,
if
we're
working
on
some
like
proof
of
concepts
that
don't
make
it
through
to
dot
com,
they
don't
get
merged,
then
obviously
that's
not
going
to
count
tools
through
it.
But
now
I
don't
think
that
counts
as
wasted
time
and
but
at
the
same
time,
in
fact
very
much
the
country.
C
The
whole
point
of
those
is
to
hopefully
sort
of
save
us
time
and
add
value
later
on,
but
are
those
initiatives
kind
of
like
meaning
that
we're
not
able
to
hit
those
throughput
numbers
and
is
there
anything
else
we
need
to
do
or
need
to
consider
to
to
start
kind
of
seeing
an
increase
towards
that?
Or
do
people
just
think
it's
completely
unrealistic
and
if
so,
like,
I
ask
everyone
just
to
call
it
out
and
we
can.
C
We
can
have
a
conversation
as
to
as
to
why
that
is,
and
so
maybe
just
something
to
have
a
think
about
like
throughout
july,
in
terms
of
while
we're
trying
to
hit
that
goal,
if
we're
not
able
to
then
kind
of
what's
what's
preventing
us
from
from
doing
so,.
A
Liam,
maybe
we
should
just
create
an
issue
in
the
manage
general
discussion
about
this
and
then,
if
you
could,
maybe
over
the
you
know
as
the
as
the
month
wraps
up,
consider
posting
some
statistics
in
there,
because
I'd
be
really
curious.
A
If,
like
some
groups
are
hitting
this
like,
I
know
that
compliance
is
very
productive,
and
so,
if
some
groups
are
doing
really
well,
maybe
we
can
learn
from
them
and
start
iterating
towards
what
they're
doing
right
and
can
use
that
their
process
and
how
they
work
as
inspiration,
but
just
a
just
a
thought.
It's
something
we
can
kind
of
optimize
across
the
whole
stage.
B
B
So,
if,
if
anything,
you
know
it's
still
good
to
be
aspirational
to
try
to
improve
the
groups
throughput
by
20,
but
if
we
find
that
you
know
these,
these
pocs
were
necessary
and
we've
already
done
the
necessary
time
boxing.
That's
just
that's
just
a
good
takeaway
to
have
I'm
not
you
know,
I'm
hesitant
to
say,
like
you
know,
compliance
is
more
productive
or
to
say
that,
because
you
know,
I
think,
we're
still
being
productive
and
to
william's
point
we're
trying
to
do
those
proof
of
concepts
to
to
avoid
any
overwork
or
wasted
work.
A
B
C
Yeah
definitely-
and
I
think
you're
right
dennis.
I
think
when
this
first,
when
we
first
started
measuring
this
quite
a
while
ago,
we
just
called
it
productivity.
We
didn't
call
it
throughput
and
there
was
quite
a
lot
of
negative
feedback
around
that
for
the
reason
that
you
you
just
said,
but
at
the
same
time
there
is
an
expectation
that
all
teams
are
going
to
have
like
the
the
same
throughput,
which
is
kind
of
set
as
a
company-wide
okr.