►
From YouTube: Monitor:APM Weekly Meeting
Description
Weekly meeting for the Monitor:APM Group. Discussed the Monitor product vision, how we do demos, demo projects, and issues that moved into 12.4.
A
A
B
A
All
right
sounds
great
well
looking
forward
to
working
with
you
good
luck
with
all
your
onboarding
tasks
and
all
right.
So
thank
you.
Everyone
for
adding
things
to
the
agenda
beforehand.
It's
great
to
see
so
I
know
Miguel's,
not
here,
but
we
could
talk
a
little
bit
about
so
Sid
posted
a
video
about
monitor
in
the
direction
of
the
monitor
area
or
the
monitor
stage
within
get
lab.
The
links
there,
but
I
want
to
see
if
anyone
had
thoughts,
I
think
that's
what
Miguel
was
looking
for.
A
C
I
think
it's
great
that
he
took
the
time
to
talk
about
the
vision,
I
think
it's
a
good
place
to
start,
and
currently
we
are
walking
on
our
vision
about
Milito
in
the
division
statement
that
we
have
on
the
handbook
and
when
once
we'll
have
some
sort
of
a
plan
to
communicate
to
the
team,
I
think
we
will
have
right
now.
The
immediate
action
that
I
think
we
need
to
do,
which
will
likely
to
impact
a
bit
12.4,
is
that
there
is
one
issue
around
the
authentication
of
Jaeger,
which
we
discussed
me
in
my
discuss.
C
That
probably
needs
to.
We
need
to
limit
the
scope
to
the
amount
to
the
extent
of
just
putting
a
warning
message.
This
is
what
Sid
asked
and,
let's
replace
the
whole
thing
with
see
how
we
can
embed
the
a
girl
UI
within
and
within
the
gate,
lab
tracing
tab
and
by
doing
that,
I
think
we
won't
invest
in
this
in
this
iteration
on
tracing
for
now
and
we're
likely
to
focus
more
on
metrics
and,
of
course,
some
logs.
A
Ryan
you
already
moved
those
issues.
Is
that
right,
yeah,
so
the
authentication
issue
we
moved
out
to
back
to
the
backlog
pulled
in
the
iframe
one.
We
might
have
to
talk
about
it.
A
little
bit
around
I
think
that's
more
front-end
heavy,
the
iframe
one.
So
we
can
talk
through
that.
Outside
of
this
call,
though
Kenny
you
had
a
yeah.
D
D
A
bit
of
color
a
couple
things
that
Dave
and
I
talked
about
this
this
week.
So
first
of
all,
I
can't
remember
if
Sid
explicitly
said
this,
but
I
happen
to
be
CEO
shadowing
with
him
when
he
was
doing
some
of
the
investor
conversations
for
the
series
II
round-
and
you
know
it
came
up
a
lot-
that
people
understand
the
monitoring
space
as
a
very
lucrative
text-based
place
where
technology
vendors
are
willing
to
spend
a
lot
of
money
and
cities
really
I.
D
Think
chow
has
to
be
more
ambitious
and
I
will
fault
myself
for
on
a
couple
of
occasions.
It's
my
caveat
that,
like
product
managers
have
to
juggle
between
I've
got
a
specific
roadmap
and
I
got
to
be
really
diligent
about
only
focusing
on
the
most
important
thing,
but
that
we
need
to
paint
a
long-term
vision
and
what's
not
lose
sight
of
the
fact
that
you
know
four
years
ago,
if
you
said
get
lab,
is
going
to
be
the
Gartner
Magic
Quadrant
leader
in
CI
people
would
have
said.
D
That's
a
joke
and
we're
we're
going
to
do
the
same
thing
in
ops
right
in
and
monitor,
specifically
we're
going
to
be
the
data
dogs
in
this
plunks
of
the
world.
It's
hard
to
have
a
vision
for
that
now,
sitting
where
we
are,
but
I
want
to
make
sure
that
I
also
emphasize
to
the
team
that
I'm
faulting
myself
here.
We
need
to
make
sure
we
think
from
a
perspective
of
abundance
right.
We
that's
our
mission.
D
We
need
to
go
figure
out
and
ask
for
the
resources
that
we
need
in
order
to
go
deliver
on
that
mission.
We're
gonna
have
to
be
diligent
and
efficient
in
our
pursuit
of
it.
But
let's
not
let's
not
let
ourselves
set
our
bar
lower
I
guess
is
what
I'm
trying
to
communicate
and
I'm
I'm
Dovan
I
are
gonna,
be
doing
that
in
this
vision.
Update
but
I
want
to
make
sure
everybody
understands
is
a
real
opportunity
that
the
company
wants
to
proceed
to
to
go
after
and
I'm
excited
about.
It.
D
E
F
F
E
It's
great,
it
would
be
great.
You
know,
because
we've
constantly
were
you
know
going
to
sumo
going
to
you
know:
New
Relic
going
to
grow
phonic
going.
You
know
to
all
these
different
places
to
to
find
things
and
bring
into
in
what
was
going
on
in
the
incident.
So
if
we
can
bring
if
we're
talking
about
you
know.
E
You
know
owning
the
instead
of
management
and
the
tools
and
in
the
way
that
we
document
and
are
able
to
go.
You
know
enable
the
ops
folks
to
detect,
recalls
and
and
and
document
all
that
it'd
be
great
and
it'll
make
make
ops
folks
daily
daily
job
a
lot
easier
so
having
the
integration
is,
is
great,
but
but
I
think
you
know
the
from
the
flip
side
of
that
is
somebody
newly
coming
in
to
get
lab
now
going
to
toss
out
there
sumo
or
their
new
relic
or
their.
E
D
And
I
think
that's
a
like
it's
a
very
I've
never
worked
at
a
place
quite
like
it
lab
on
a
lot
of
levels,
but
we
we
challenged
ourselves
to
be
both
our
own
worst
best
critics
as
well
as
boundless
ambition
right.
So
we
need
to
be
able
to
look
squarely
at
ourselves
and
say
these
are
the
places
were
deficient?
I
think
we
do
a
good
job
of
that
when
we
talk
about
our
maturity
and
our
current
state
of
our
tools,
nothing
wrong
with
that.
D
But
we
also
need
to
make
sure
we're
saying
putting
the
flag
in
the
SEM
that
we're
not
going
to
settle
for
some
mediocre
middle
State
where,
after
the
big
goal,
I'll
say
I'm.
Also
thinking
about
this
in
the
context
of
going
through
our
2021
fiscal
year,
planning
which
Dovan
I've
already
talked
about,
is
going
to
propose
a
very
significant
increase
in
our
monitoring
investment.
So
part
of
us
painting
that
vision
is
to
be
able
to
use
to
use
that
vision
as
a
justification
for
here's.
D
Why
we
need
the
team
size
that
we
need
to
go,
pursue
this
opportunity
and
the
last
thing
I'll
comment
down
and
don't
mention
this,
like
dopes,
there's
an
issue
linked
to
that
product
issue
at
merge
request
that
dothe
has
a
kind
of
like
an
open,
mr
for
updating
the
monitor
revision.
That
vision
page
feels
like
it's
something
that
only
product
managers
can
touch.
That's
not
the
case.
All
of
you
can
and
should
I
think
I've
said
this
a
number
of
times,
but
I'll
continue
to
repeat
it.
D
Everyone
can
and
should
propose
Mrs
to
that
at
any
time.
It's
a
place
for
us
to
develop
our
car
shared
understanding
of
where
we're
headed
not
for
product
to
dictate
our
shared
understanding
products
through
a
responsible
individual,
but
it's
not
like
only
the
domain
and
only
a
product
manager
can
update
it
and
if
there's
something
that
you
wants
to
add
to
that
document,
you
can
open
an
mr.
C
And
regarding
your
comments,
David
yeah
I
agree
that
you
know
going
after
the
dynaTrace
and
the
data
dog
of
the
world
might
be
daunting,
but
still
I
do
believe
that
we
can
progress
really
quickly
and
provide
really
clear
flows.
We
know
without
all
the
bells
and
whistles
that
they
have,
but
enough
to
have
enough
content
and
enough
value
for
customers
to
start
using
our
tools
for
monitoring.
So,
yes,
it's
challenging,
but
we
can
identify
those
flows
and
I.
A
G
I
can
present
this
as
well
Miguel,
okay
and
I
hope
them
presenters,
I'm,
actually
not
sure,
and
can
everyone
hear
me:
okay,
I'm
on
my
wife,
I
just
cut
out
so
I'm
on
mobile.
Let
me
know
if
you
have
troubles
I
I'm,
not
sure
so
much
that
this
is
well
I
guess
this
is
up
for
discussion,
whether
we
should
consider
this
instead
of
our
demo
hour
or
whether
we
still
find
value
in
the
demo
hour
and
want
to
add
this
or
whether
we
just
don't
want
to
add
this
at
all.
G
But
I
think
this
touches
more
on
regularly
doing
the
development
demos,
the
link
there
is
under
point
C
about
regularly
touching
base
and
demoing
the
features
that
we
have
I
think.
The
idea
here
that
he
was
presenting
was
that
we
get
to
test
these
things
when
doing
the
demos
and
kind
of
get
to
keep
a
pulse
on
our
feature
set
and
make
sure
it's
working.
So
I'll
just
start
the
discussion
there.
If
anyone
has
any
input,
feel
free
to
jump
in
on
that
I.
G
Think
I
guess
I
think
my
input
would
be
that
as
far
as
like
the
testing
of
features,
I,
think
probably
we
should
actually
just
make
sure
our
tests
are
where
we
want
them
to
be
and
start
including
integration
tests
and
then
doing
testing,
and
all
of
that
so
I
don't
know
that
we
want
to
use
the
demo
as
a
way
to
test
stuff
necessarily
I
guess
it
is
a
could
be
considered
a
bonus.
But
my
my
personal
vote
is
that
I
think
the
demo.
G
E
E
What's
your
environment,
like
you
know
what
what
kind
of
things
do
you
lean
on
most
often,
that
would
kind
of
help
me
say:
okay,
yeah
I!
Don't
need
to
underneath
it
on
this
path,
because
that
I'll
never
be
able
to.
You
know
test
blah.
You
know
feature
or
implement
blah
feature
without
you
know
doing
a
GED
cave,
you
know
cluster
or
something
along
those
lines.
E
It's
it's
super
helpful,
everytime,
I've
paid
with
somebody
and
said:
okay
show
me
what
you
do
and
it
we
both
come
away,
knowing
a
lot
more
about
how
to
be
more
effective
with
our
development.
You
know,
and
that's
not
necessarily
demo
in
a
particular
feature,
but
it's
like
you
know,
making
sure
we're
all
kind
of
on
the
same
page
from
a
tool
standpoint.
A
A
I
think
there
is
a
place
for
and
I
think
hey
Julie
can
mention
this
into
your
comment
as
you're
typing
here,
but
I
think
there's
a
place
for
this
kind
of
more
formal
process
or
demo
too.
Maybe
it's
not
a
regular
meeting
or
anything.
Maybe
we
need
to
just
have
kind
of
ad
hoc,
like
bigger
overviews
of
demos,
of
like
here's,
here's,
what
tracing
looks
like
in
Gil
a
band.
That's
not
a
great
example,
because
it's
pretty
not
I
really
fleshed
out
but,
for
example,
say
hey.
A
This
is
what
it
looks
like
here's
a
demo
of
it
record
it
and
then
that's
kind
of
where
we
are
for
today
and
then
that's
a
good
thing
we
can
share
with
as
new
people
are
coming
on,
we
can
put
it
in
our
maybe
in
our
documentation,
the
handbook
and
other
places,
but
we
can,
if
we
have
some
not
like
every
week,
but
have
some
kind
of
demo
that
we
can
share
it
with
people
the
show
this
is
what
the
APM
team.
These
are
the
features
we
work
on.
A
A
A
H
Absolutely
so
I
noticed
that
quite
a
lot
of
folks
and
teams
have
their
own
demo
projects
and
my
my
idea
was
to
have
one
dedicated
demo
project
that
everybody
has
access
to
it's
kind
of
like
a
shared
project
and
then
that
demo
project
would
kind
of
be
like
our
showcase,
so
you're
showcasing
all
the
capabilities
of
ATM
and
help.
Maybe
one
of
the
benefits
of
this
is
that
currently
because
everybody's
help,
they
don't
demo
projects
they're
using
up
resources
from
gke
and
the
reason
I
started.
H
This
is
because,
when
I
was
trying
to
create
a
process
for
myself
through,
that's
the
particular
feature,
I
realize
I
couldn't
create
another
gke,
because
we've
crossed
the
limit,
so
I
thought
it'd
be
nice.
If
we
all
use
one
demo
project,
it
would
be
like
art,
you
know,
CD,
machine
sort
of
and
that'll
be
our
one
source
of
truth
and
everybody's
kind
of
into
the
same
project
and
I
hope
they'll
have
a
project
on
Telecom
and
also
from
the
staging,
so
that
we
know
when
we're
raffling
or
will
be
very
verifying
a
particular
issue.
H
H
D
I
ask
just
one
the
B
so
for
B
that
I
added
is
not
a
demo.
It's
just
a
live
project
that
happens
to
be
public,
so
we
can
have
access
to
it.
I
don't
know
if
that
does
that
solve
any
percentage
of
the
use
cases
where
we're
kind
of
trying
to
say
what?
How
do
we
interact
with
this
feature?
Does
it
need
to
be
something
where
you
can
like
maybe
have
more
administrative
control
than
you
would
get
in
something
like
that.
H
H
Like
that,
just
within
the
one
space
but
yeah,
something
like
that
and
also
another
thing,
I
notice-
is
that
there's
a
lot
of
knowledge
gaps
like
as
I
said,
everybody's
creating
their
own
projects.
Nobody
knows
if
there
is
a
project
you
go
ask
somebody
just
points
to
their
own
project
and
it's
just
it's
it's
everywhere
and
we
Knights
are
going
to
put
everything
together
in
one
place:
I'm
gonna
focus
on
that,
but
yeah
I'm,
just
like
the
link
to
your
poster
of
there.
Something
like
that.
D
And
I
guess
it
comes
down
to
you.
Are
we
trying
to
just
show
the
capabilities
or,
like
you,
couldn't,
set
up
alerts
on
this
and
you
couldn't
go
see
the
performance
results
from
a
from
a
merge
request,
but
there
are
just
like
I
want
to
look
at
dashboards.
You
could
probably
do
that
on
this.
It's
not
in
staging,
but
anyway,
I
I
agree
that
we
should
have
some
consolidated
demo,
I'm
willing
to
say
Sarah
had
proposed
having
one
at
least
central
for
the
product
team
in
in
her
project,
I'm
willing
to
say
like
no.
D
H
Oh
Jose
had
has
a
project,
consider
two:
what
we
have
out
there
and
I've
been
working
with
was
a
incremental
kind
of
move
that
project
onto
the
month
work
space
and
we've
got
that
done
so
we're
trying
to
create
another
project
and
staging,
and
so
once
all
of
the
tests
done.
Plan
is
troop
allowances
and
the
team
meetings.
H
C
I
guess,
while
why
we're
building
this
and
whoever
is
building
it
and
working
on
that
make
sure
to
open
issues?
If
you
see
some
things
about,
like
the
onboarding
experience,
I
mean
we
talked
about
it
with
several
people
from
the
team
here
that
it's
really
hard
to
set
up
at
least
was
for
me
at
the
beginning,
was
really
hard
for
me
to
set
up
a
like
a
demo
environment
for
monitoring
is
simple
one,
and
if
it
was
hard
for
me
I
guess
it's
even
harder
for
our
users.
So
any
old.
C
G
G
Think
that's
probably
where
the
developers
well,
please
correct
me
somebody
if
I'm
wrong,
but
I
think
that
maybe
a
large
majority
of
where
developers
interest
in
this
comes
is
that
we
need
to
actually
verify
these
features
in
production,
which
means
that
we
may
be
adding
alerts
to
charts
or
something
like
that
and
I.
Don't
know
how
that
all
work
with
you
know.
If
we,
if
we're,
adding
a
dummy,
alert
and
then
triggering
emails
to
everybody,
maybe
that's
not
the
I,
don't
know.
G
D
E
E
Just
don't
forget
that
the
the
gate
lab
community
at
large-
you
know
the
Watergate
lab
community
may
need
to
you
know,
contribute
to
the
monitoring
and
a
p.m.
area.
So
we
need
to
make
sure
that
the
development
story
is
easy
to.
You
know,
to
get
involved
with
and
and
then
make
contributions
to
and
and
I
think
some
of
these
projects
and
instructional
instructional
projects
would
help
in
that
respect,
as
well.
D
C
C
So
I
think
it
would
be
good
if
we
will,
on
the
issue,
maybe
put
a
note
about
the
level
of
effort
that
is
left
for
this
task,
because
to
some
some
issues,
I
believe
that
if
they
didn't
cut
in
12
the
tree,
maybe
you
know
they.
They
should
not
move
immediately
to
12.
As
for
and
maybe
you
need
to
discuss
them
and
of
course,
if
there
isn't
a
lot
of
work
to
be
done
yet.
C
So
it
is
a
lot
of
work
to
be
done
then,
maybe
we'll
just
you
know,
complete
it
and
then
and
close
them.
But
I
would
like
to
see,
if
possible,
the
level
of
effort
that
got
left
so
I'll
be
more.
You
know
understand
more
about
the
peyote
here,
because
I
think
that
the
amount
of
issues
is
still
extremely
high.
C
G
D
C
Yes,
both
I
mean
the
weight
and
the
Delta,
because
if
there
was
like
a
lot
of
work,
that
was
invested
already
in
the
future
and
let's
and
doesn't
remain
a
lot
of
work
to
do
then
make
sense.
So
for
me,
in
order
to
walk
on
that
offline,
the
amount
of
level
of
effort,
then
plus
the
weight
which
makes
sense
and
then
I
guess,
is
something
that
I
need
to
put
in
also,
and
it's
something
that
will
allow
me
to
walk
async.
G
D
G
E
D
C
G
G
G
H
Yeah
I
know
we
recently
started
with
meetings
and
everything
so
there's
more
of
a
suggestion.
I
think
it
would
be
beneficial,
especially
for
me
if
we
started
weekly
meetings
but
I
like
the
roadmap,
the
epic
level
features
what
we're
targeting
for
the
next
four
releases,
and
then
we
go
dive
into
the
smaller
details
as
to
what
missed
the
deadline
or
what
did
not
work.
Many
features
so
starting
off
with
something
like
this
link
that
country
earlier
me.
The
other
day
was
pretty
used,
I'm
just
looking
at
the
big
picture.
What
are
we
really
shipping?
D
Start
this,
and
then
I
mean
is
dove,
is
for
you
to
respond,
but
I
just
want
to
say
that
that
link
you
provided
I,
don't
think,
is
valid
information
and
as
a
result
of
the
fact
that
I
wasn't
doing
a
good
job
of
planning
using
epics.
So
just
don't
look
at
that
and
think
those
are
the
themes,
though,
if
you
want
to
start
organizing
issues
into
epics
and
then
making
this
an
actual
correct
representation
of
what
the
team
is
working
on,
so
be
it.
But
yeah.
C
C
G
Think
some
of
it
should
be
accurate,
like
I
put
some
I
think
I
made
a
bunch
of
these
epics
as
well.
So
maybe
it's
not
accurate,
because
if
dome
hasn't
looked
at
it
and
Kenny
hasn't
looked
at
it,
then
we
should
throw
it
out,
but
I
think
at
least
some
of
the
issues
I
mean
what
I'm
saying
is
I
think
the
like.
Some
of
them
are
actually
organized
by
what
issues
go
in
when
and
so
the
actual
timeline
of
releases
should
be
okay
on.
D
D
Yeah,
if
you
just
change
the
label
on
that
to
geo,
need
to
tell
you
the
specific
one
there's
at
p.m.
he's
done.
This
pretty
well
suggest
geo
group
geo
you'll
see
what
I
would
consider
like
a
more
robust,
complete
roadmap.
I
think
that's
what
you
can
strive
to
communicate
with
this
roadmap
feature
in
our
product,
but
I'm
just
saying
like
there's,
none
of
that
level
of
organization
by
the
product
team
by
that
horrible
product
team
we
had
before
today.
E
H
D
It's
so
dry,
so
perfectly
I
think
it's
like.
We
have
this
tool.
It's
super
useful.
It's
a
great
way
of
providing
that
context.
We
should
talk
about
it
start
of
every
meeting
it
dov
can
talk
about
any
updates
and
kind
of
what
he's
thinking.
What
he's
seeing
it's
important
for
the
product
organization
to
be
communicating
that
in
this
call
it's
perfectly
valid
ass,
word
I'm,
just
just
it's
tongue-in-cheek!
You
know
we
all
do
our
best.
So.
A
C
A
A
C
D
C
C
A
Well,
I
might
just
move
it
regardless,
but
similar
alternating
times,
but
maybe
I'm
just
a
different
day
of
the
week.
So
if
that
happens,
you
won't
be
surprised
and
then
the
last
thing
just
I
kind
of
want
to
bring
this
up
at
the
end
of
every
meeting,
just
to
reminder
to
everyone
that
we
have
this
asynchronous
retrospective,
it's
only
going
to
provide
value
if
people
contribute
to
it.
A
So
I'm
just
gonna
remind
everyone
every
week
to
bring
that
to
and
add
anything
to
that
I
put
the
link
to
the
current
one
that
we
have
open
well
shortly.
We
will
open
it
a
12.4
version
of
that
we
kind
of
closed
the
kind
of
leave.
Last
time
last
release
we
closed
the
like
12.2
one,
a
little
bit
too
early
I
think
cuz
people
were
still
reflecting
on
that
release
and
they
had
to
put
some
of
those
comments
in
this
12:3
retrospective.
A
So
we
can't
talked
about
leaving
it
open
for
a
week
after
milestone,
so
we'll
do
that
and
then
we'll
open
a
12.4
one,
but
regardless
of
whichever
one
it
is,
please
use
that
tool
and
then
we
can't
talked
about
it.
A
little
bit
last
time,
but
it
might
be
worthwhile
for
our
team
to
kind
of
review
some
of
the
highlights
of
that
retrospective
document.
Maybe
in
this
meeting
or
we
can
think
of
a
good
way
to
do
that.
But
we
can
discuss
that
offline
too
I
just.
G
D
G
Okay,
there
I
fixed
it.
Alright,
sorry,
my
wife
is
crazy
right
now,
okay,
so
my
question
is
about
our
stand-up
meetings.
I
have
lately
been
finding
and
I
know
that
it's
already
in
the
12
3
retro,
which
is
what
reminded
me
of
this-
that
we
might
want
to
consider
splitting
the
retro
are
the
stand-ups
into
APM
and
health,
which
I
think
is
a
good
start,
but
I'm
also
not
really
finding
the
questions
very
helpful
and
it's
not
I,
don't
know
that
it's
anyone's
fault
I
think
it's
just
that
the
questions
are
general
and
I.
G
I,
don't
know
more
directly
focus
on
the
information,
that's
that
we
really
want
to
surface
in
the
standup,
because
I
think
you
know
most
of
the
time.
We
all
know
that
one
another
is
we're
all
working
on
our
current
milestone,
deliverables
and
doing
all
that
kind
of
stuff
it
you
know
I
mean
not
that
it's
bad
to
know
that
it's
just
I'm
wondering
if
other
people
are
finding
it
helpful
and
if
they
are
then
I'll
leave
it
alone.
But
if
not,
then
I
will
I
think
I
want
to
spend
some
time.
A
A
A
A
A
A
J
Know
how
in
I
don't
know
if
you
know,
if
you
can
hear
me,
I
tried
to
talk
before,
but
my
microphone
was
not
working,
yeah,
I,
think
I
think,
probably
eventually
and
probably
soon
we
have
a
new
UX
designer
starting
on
Monday,
so
I
think
we're
probably
gonna
be
splitting.
So
that
would
be
a
short-term
problem
and
yeah.
J
It
does
seem
like
I,
would
agree
with
what's
been
said
that,
like
it's
getting
to
be
a
lot
of
people
to
keep
track
of
every
day,
though
I
would
be
sad
to
miss
hearing
about
everyone's
up
to.
It
does
seem
like
at
my
time
just
to
separate
our
stand-ups
and
also
in
the
infrastructure
lounge.
They
have
like
our.
It
seems
like
a
randomly
generated
question,
which
is
always
funny,
and
the
answer
is
that
they
get
are
really
surprising.
So
maybe
something
like
that
could
be
fun
and
just
putting
that
out.
There.
E
A
A
D
Either
this
item
hot
off
the
presses,
we're
starting
the
F
ride,
2021
planning
process.
The
issue
I
linked
is
just
for
the
up
side
that
just
created
that
issue,
but
all
links
it's
a
related
issue,
but
all
links
the
broad-based
one,
there's
a
company-wide
one
sure
I
thought
people
might
generally
be
interested
in
how
we're
approaching
this
problem.
This
is
just
our
current
thinking,
we'll
probably
update
the
tasks
and
process
there,
but
the
ops
issue.
D
I
have
some
specific
questions
like
one
of
the
things
we're
trying
to
ask
is:
are
gearing
ratios
correct
in
order
like,
and
that
is
that
we
use
word
gearing
ratios
to
talk
about
our
default
back-end
engineers
to
engineering
manager.
Back
in
the
engineer,
the
front
end
number
of
product
designers
per
group
number
of
QA
per
back
in
that
you,
like
those
tens
of
ratios
that
form
a
product
group
I'd
like
to
get
teams
input
on
if
they
feel
like
those
numbers,
are
correct
for
your
specific
area.
D
I,
don't
even
know
what
the
current
numbers
are,
but
maybe
just
think
about
the
team
today,
which
wants
to
adjust
it.
If
we
were
to
have
many
more
teams
and
then
the
other
one
is
we've
kind
of
stay
focused
within
a
year
on
a
certain
set
of
categories,
but
this
planning
period
is
the
time
to
think
about.
Should
there
be
whole
new
categories
that
were
pursuing
so
I
love
team's
thoughts
on
there
are
other
categories
in
the
monitor
stage
that
we
should
be
going
after
just.