►
From YouTube: Metrics Pages Clarity Meeting
Description
In this meeting, Emilie Schario, Data Analyst, and Sid Sijbrandij, CEO, discuss the best way to organize the Metrics pages in the company handbook. They discuss the benefits and disadvantages of the current Metrics page structure, what the next iteration of storing metrics definitions should look like, and what the next steps for addressing this problem are.
A
And
relax
good
morning
said
this
meeting
is
meant
to
get
some
clarity
around
organizing
the
metrics,
the
company
metrics
in
the
handbook.
So
there
have
been
a
lot
of
discussions
back
and
forth
about
the
what
best
way
to
organize
this
information.
I
do
think
one
page
for
the
entire
organization
is
best
but
I'd
love
to
hear
what
the
ideal
organization
method
in
your
mind
is
yeah.
B
Let
me
first
try
to
articulate
the
benefits
of
a
central
organization
for
all
metrics.
The
advantage
is
that,
if
you
need
a
metric,
it's
very
clear
where
to
go.
The
advantage
is
that
if
a
metric
is
shared
between
multiple
departments,
it
automatically
is
shared
resources
like
that
it
will
be
almost
impossible
to
create
duplicate,
'iv
items
for
the
same
thing,
and
it's
much
easier
for
other
teams
that
have
to
keep
check
on
our
metrics,
like
the
data
team,
to
kind
of
become,
for
example,
code
owner
there.
B
So
any
change
on
the
page
has
to
be
approved
by
them.
Those
are
I,
think
two
major
advantages.
I
think
the
disadvantage
is,
and
this
is
something
we
seem
to
occur
again
and
again
and
again
is
that,
in
order
to
have
a
single
source
of
truth,
you
get
to
choose
only
one
way
of
organizing
a
hierarchy
like
pages
in
the
handbook
or
not.
You
don't
have
labels
where
you
could
say.
B
So,
for
example,
if
there's
a
metric
that
has
to
do
with
recruiting
the
apply
to
accept
time,
a
very
important
metric
for
a
recruiting
team,
I
think
it
should
be
on
the
recruiting
page
and
what
you
see
if
you,
for
example,
I
have
one
metric
page
for
the
entire
company
is
a
lack
of
kind
of
ownership.
Of
that
page.
B
They
didn't
care
about
any
terms
relevant
in
engineering
and
they
would
read,
read
their
sales
pages,
but
they
route
would
not
read
the
glossary,
because
80%
of
the
terms
that
they
had
to
know
about
were
not
relevant
to
them.
So
I
think
at
our
skill.
It's
already
cleared
at
a
centralized,
metrics
page,
won't
work,
I
think
there's
still
something
at
our
skill.
B
If
you
talk
about
the
recruiting
process,
have
the
metric
right,
there
doesn't
matter
whether
it's
a
department,
it
just
matters.
What
is
this
page
about?
And
we've
seen
that
for
I'm
advocating
now
for
definitions
of
data,
but
we've
also
seen
it
with
just
regular
definitions
like
what
are
abbreviations
but
anything
multi-format,
so
I
see
kind
of
metrics
as
a
format.
I
see
abbreviations
as
a
for
it,
but
I
also
see
video
and
courses
as
a
format.
So
I
went
through
the
same
process.
B
We
started
with
courses
at
get
lap,
hi,
Michael,
awesome,
we're
gonna,
have
a
courses
page
with
all
the
courses
there
and
guess
what
happened.
There
was
a
lack
of
ownership
and
the
people
that
on
board
didn't
see
the
courses
relevant
to
them
because
they
were
not
on
the
pages
of
their
organizational
units.
So,
although
it
is
kind
of
annoying,
maybe
for
the
data
team
to
have
the
metrics
spread
around
I
do
think
we
have
to
optimize
for
the
people
that
use
it
day
to
day
so.
B
I.
Don't
have
a
good
solution
for
that,
but
I
do
know
that,
as
we
scale
like
we're
gonna
more
than
double
this
year.
The
most
important
thing
is
for
people
onboarding
to
have
the
relevant
information
in
whatever,
whatever
the
format
is
that
that
they
use
and
there's
a
lot
more
people
onboarding
like
outside,
of
the
data
team
and
outside
of
legal,
then
insight.
So
hence,
let's
put
them
where
the
department
is
I.
A
I
personally
see
the
data
team
really
owning
that
page
and
that
that
page,
then
it
becomes
not
just
that
the
definitions
and
the
methodologies,
but
it's
also
linking
to
the
dashboards
where
the
those
metrics
are
calculated
and
the
dashboards
can
also
link
to
that
definition
stage,
where
you're
getting
additional
clarity
around.
What
you're,
looking
at
I
understand
that
it's
okay
to
make
more
of
a
hassle
for
the
data
team,
where
it's
gonna
serve
more
of
the
company
to
have
these
metrics
throughout
the
organization.
But
I
worried
that
we
are.
A
Then
you
know
if
we
have
2,000
pages
in
the
handbook,
which
is
what
I
think
it
was
a
year
ago
now
we
have
to
look
across
2,000
pages
to
find
the
where
the
definition
is
calculated,
and
then
we
have
to
pester
people
to
figure
out
where
hey.
Where
is
the
definition
that
you've
been
working
with
already?
B
That's
that's
a
hard
problem.
I
do
see
the
problem.
I
don't
have
a
solution
for
it.
We
could.
We
could
explore
that,
but
think
for
imagine
like
we're.
Gonna
have
a
foul
and
dashboard
soon
it
was
our
link
from
a
single
page
and
no
one
can
that's
not
gonna,
be
very
fun
page
to
navigate
you're
gonna,
organize
that
by
Department
etc.
But
the
right
thing
to
do
is
put
the
dashboards
where
people
need
them
put.
A
B
Hiring
could
put
the
fat
the
cash
flow
thing.
It
should
be
right
next
to
what's
the
process
to
improve
this,
like
that,
should
be
below.
What's
the
process
to
improve
this
who's
responsible.
What's
our
process,
so
you
should
go
from
hey
I,
looked
at
the
dashboards,
it's
pretty
bad,
like
it's,
it's
trending
the
wrong
way.
You
should
close
that,
but
go
back
where
the
page
you
came
from
and
see
it
look
at
the
process
and
then
fix
that
and
I
think.
B
But
this
is
I'm
not
sure
I
think
you
want
the
metrics
owned
by
the
departments
and
it's
going
to
be
more
messy,
but
I
think
that
data
team
you're,
not
the
end
response
world
and
responsible
for
a
metric.
Are
these
departments
and
you
should
consult
them.
You
should
advise
them.
They
need
a
lot
of
hand-holding
to
get
to
the
right
metrics,
but
in
the
end
you
want
them
to
feel
ownership
for
that
metric
they're,
the
ones
who
have
to
improve
it.
B
They
don't
want
to
have
to
define
it
without
from
the
data
team,
and
everyone
should
know
that
they
suits
get.
Your
approval
on
metric
rests
to
change
the
definition
I.
Don't
that's
not
been
a
problem
so
far
you
actually
like
have
to.
The
problem
has
been
lack
of
ownership.
People
not
defining
their
metrics
so
putting
them
somewhere
where
they
don't
care,
because
it's
not
their
problem,
I
think,
although
it
makes
it
easier
for
you
to
find
them,
I
think
the
big
problem
is
for
them
to
feel
ownership
of
it.
Mm-Hmm
I.
A
Think
that
makes
a
lot
of
sense.
Could
we
could
we
iterate
our
way
to
having
the
metrics
in
place
right
now
by
having
functional
metrics
metrics
page,
where
there
is
one
metrics
page
for
people
I've
seen
one
for
sales
and
then
perhaps
one
for
the
whole
company
that
supports
cross-functional
metrics
and
then,
as
the
team
grows,
as
analysts
become
specialize
and
they
understand
you
know-
maybe
I'm
the
expert
on
people
offs
data
I
know
exactly
what
the
recruiting
metrics
are
and
where
they
are
in
the
handbook,
then
they're
really
living
in
place.
B
Really
because
the
same
conversation
you've
been
having
I've
been
having
with
every
individual
member
of
your
team.
This
is
such
a
counterintuitive
thing.
There's
such
a
strong
urge
to
have
a
glossary
page
to
have
a
course
page
to
have
a
abbreviations
page
to
have
a
metric
space
that
I
don't
want
to
keep
doing
that
like
right.
Now,
it's
500
people
I
have
to
talk
with
it
becomes
it
becomes
a
hard
thing.
I
think
the
right
thing
to
do
is
to
put
the
apply
to,
except
not
on
the
people,
ops,
definition
page.
B
It
should
be
on
the
hiring
page
and
I.
Think
what
you'll
find
is
that
there's
a
lot
of
pages
missing
a
lot
of
departments
aren't
taking
ownership
of
their
pages,
including
in
finance
where,
like
it's
unclear,
who's
the
owner.
There's
there's
not
a
clear
link
to
the
pages
that
are
then
the
organizational
structure
and
that's
gonna,
make
things
harder,
but
I
think
it's
the
right
thing
to
do,
because
it's
the
only
only
thing
that
keeps
the
handbook
scalable
and
that's
one
of
the
most
important
initiatives
this
year.
So.
A
B
B
And
where
we
have
a
shared
metric,
one
of
the
department's
should
define
it
and
the
other
should
just
link,
no,
not
even
a
sure
definition
just
put
in
the
link,
like
our
P
average
revenue
per
user,
probably
relevant
for
finance
and
sales.
What's
the
most
relevant
for
one
IC
sales,
but
up
to
up
to
you
how
you
deal
with
that
and
then
just
make
sure
there's
one
definition,
the
other
one.
That's
across.