►
From YouTube: Hive KRs and UX KRs
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
have
been
in
an
experiment
for
the
past
two
quarters
on
applying
the
hive
leadership
model,
which
used
to
be
the
united
leadership
model
in
the
verify
stage,
and
the
hive
is
the
extension
of
the
quad,
which
includes
infrastructure
and
security
to
quality
product
engineering
function
inside
of
the
the
teams
and
this
quarter
we
have
different
krs
that
are
set
based
off
of
kpi
attainments
at
the
annual
level
and
in
the
handbook
there's
this
guidance
that
we're
meant
to
have
kind
of
like
an
essentialist
principle
and
we're
supposed
to
be
ultra
focused
on
attaining
these
goals,
and
that
may
mean
trading
off
functional
krs
in
order
to
attain
these
stage
krs.
A
So
I'm
hearing
some
friction
points
and
I
wanted
to
set
a
sync
hanuk
with
you
valerie
and
me
to
kind
of
talk
through.
How
do
we
reconcile
functional
krs
with
the
hive
kr's
and
what
kind
of
conversation
should
be?
Having
is
this
a
normal
trade-off?
Should
this
happen
all
the
time?
What
is
what
is
your
expectation
and
then,
hopefully
we
can
level
set
on
that
and
have
a
cadence
going
forward.
B
Yeah,
that's
a
great
question.
I
think
there
has
to
be
some
obviously,
because
every
team
is
looking
at
how
to
make
that
function,
provide
value,
and
if
we
all
try
to
maximize
each
function,
sort
of
value
contribution,
then
chances
are.
We
are
not
doing
a
good
thing
with
respect
to
maximizing
customer
needs.
B
Our
business
needs
in
the
short
term.
So
the
idea
is
that
this.
The
fact
that
we
are
experiencing
friction
now
is
a
great
thing
because
we
were
already
experiencing
it.
We
just
didn't
talk
about
it
now,
you're
bringing
it
to
surface
ahead
of
the
quarter,
so
we
can
actually
have
a
meaningful
discussion
so
that
when
the
hive
aligns
on
the
chaos,
we
are
all
aligned
and
we
are
rooting
for
each
other
to
succeed
instead
of
pulling
it.
You
know
apart.
B
This
also
sometimes
happens
because
we
we
ask
each
functional
team
to
do
things
independent
of
the
other
functionality
right.
So
we
will
ask
ux.
I
need
you
to
improve
usability
and
I
want
to
set
an
ambitious
audacious
goal,
so
I'm
going
to
ask
you
to
go
from
67
to
72
in
one
quarter
of
cisco.
Now
that
means
you
pedal
to
the
metal.
If
you
express
everything
in
their
capability,
we
may
still
not
need
it,
but
we'll
try.
We
do
the
same
thing
on
the
engineering
side,
which
is
the
same
thing
on
the
product
side.
B
So
I
think
this
is
expected
and
I
think
what
we
should
be
doing,
therefore,
is
taking
a
look
at
the
broader
business
and
perspective
and
the
actual
debt
and
then
making
relentless
prioritization.
So,
for
example,
I,
if
the
hive
of
verify
says
hey
reliability
is
the
biggest
thing.
That's
hurting
us
right
now
and
tech
debt
is
the
biggest
thing.
That's
hurting
it
right
now.
So,
let's
all
as
a
team
align
that
those
are
that's
the
biggest
contribution
for
this
quarter,
and
that
doesn't
mean
we
can't
do
anything
else.
B
I
think
of
road
map
planning
as
rocks
pebbles
and
sand
analogy.
I
don't
know
if
you've
heard
about
this
right,
so
those
are
our
big
rocks.
Reliability
then
figure
out
what
are
the
ux
pebbles?
We
can
put
in
and
then
figure
out
what
the
features
and
we
can
put
in
so
that
and
then
communicate
it
very
broadly,
so
that,
as
a
as
a
high
now
we
are
all
aligned
and
we're
going
to
help
each
other
achieve
that
joint
goal.
And
then
we
can
also
give
the
same
communication
to
our
execs
in
our
field.
B
Because
then
the
hive
says
no,
we
have
looked
at
it
and
therefore
we
are
not
going
to
do
so.
Many
features
and
we
as
a
hive
have
looked
at
it,
and
here
is
why
we
did
it
and
if
the
e
team
disagrees,
then
at
least
we
have
all
the
information
and
data
to
back
up
our
decision
and
if
they
want
to
override
it,
that's
fine,
but
hopefully
over
time.
What
will
happen
is
it
will
give
more
and
more
autonomy
to
the
hive
and
less
and
less
sort
of
top-down
mandates.
If
you
will.
C
Yeah,
thank
you
for
explaining
that,
and
I
do
think
that
that's
where
there's
pretty
significant
difference
so
from
a
uxkr
perspective,
we're
looking
at
things
from
a
holistic
standpoint.
So
what
are
the
things
that
we
know
that
we
need
to
grow
in
or
that
we
need
to
focus
on
that?
Could
impact
the
entire
product.
C
So
this
gives
us
a
couple
of
things
one.
It
focuses
on
that
sus
kpi
that
we
have
and
then
it
also
gets
broader
awareness
for
our
product
for
our
product
designers,
so
our
designers
become
familiar
into
areas
that
they
are
currently
not,
which
then
should
broaden
their
scope
when
they're
thinking
about
you
know
how
they're
designing
things
within
their
own
particular
area
later.
That
should
help
address
the
adoption
of
additional
stages,
because
eventually
designers
will
have
so
much
knowledge
about
the
product,
not
just
specific
to
their
particular
area.
C
That
we'll
be
able
to
close
some
of
those
gaps
of
how
does
one,
how
does
a
user
transition
from
using
this
one
area
of
a
product
but
then
also
using
another,
and
so
when
we're
looking
at
it
holistically
and
then
we
are
presented
with
a
set
of
krs
that
are
specific
to
let's
say
verify.
C
That's
where
that's
where
I
think
there's
just
fundamentally
there's
a
difference
there
and
I
think
that's
what
we're
running
into
which
I
think
it's
okay
to
have
differences
there.
I
think
for
us,
it's
more.
How
do
we?
C
How
do
we
make
it
very
clear
for
designers,
for
example,
to
understand
what
it
is
that
they
are
to
be
working
on,
and
so,
when
we're
hearing
well
the
hive
kr's
our
priority
over
ux
krs,
that's
conflicting
to
what
message
I'm
giving
to
my
team.
What
I'm
saying?
That's
not
necessarily
the
case.
That's
just
an
open
for
discussion.
C
Let's
understand
what
it
is
that
the
hive
is
trying
to
do.
Let's
compare
that
to
what
we're
trying
to
do
as
a
ux
department
and
then
assess
priorities
from
there.
So
I'm
more
looking
for
an
open
dialogue
and
then
we
can
come
to
an
agreement
about
you
know
what
is
priority
for
that
quarter
for
that
particular
case,
but
my
hesitance
is
to
you
know
I
to
not
go
into
it,
saying
that
hive
kr's
are
more
important
or
that
ux
krs
are
more
important.
It's
just
more
of
let's
have
a
discussion
about
it.
B
So
it's
not
about
priority
that
one
supersedes
the
other
it's
about
jointly
aligning.
If
this
is
important,
then
this
should
be
a
hive
care,
because
then
the
the
entire
hive
signs
up
for
it,
because
the
reality
is
whether
we
say
it
or
not.
The
hive
is
signing
up
for
it,
because
that
designer's
bandwidth
is
being
taken
away
and
the
product
manager
is
expecting
that
bandwidth
to
deliver
the
commitments
that
the
product
manager
is
giving
on.
The
other
hand
to
customers
in
business
right.
So
when
we
say
oh
sorry,
we
will
just
take
that
bandwidth
away.
B
C
B
That
great
or
the
engineering
manager
might
say,
oh
wait,
those
things
that
you
want
us
to
prioritize,
because
design
is
not
available.
Well,
I
can't
do
them
either,
because
my
back
end
team
is
on
reliability
right
and
so
then
what
ends
up
happening
is
the
engineering
team
is
going
on
reliability.
The
ux
room
is
going
taking
designers
away.
B
There
is
nothing
to
deliver
that
quarter
for
customers
right
and,
if
that's
important,
then
let
the
hype
decide
that
and
explicitly
say
this
quarter,
there's
going
to
be
no
features,
because
we
are
working
on
these
long
reliability
and
ux
items
and
that's
okay,
because
then
now
what
the
pm
can
do
is
spend
their
time
on
market
analysis,
helping
marketing,
helping
competitive,
helping
sales.
They
can
spend
their
energy
on
doing
those
things
and
not
have
to
worry
about
the
monthly
cadence
of
delivering
iterative
features.
B
C
B
Yeah,
that's
a
great
question
and
I
think
this
is
where
the
uber
hive
comes
into
picture
right.
So
the
way
I
look
at
it
is
if
we
don't
want
that
to
happen.
Therefore,
so
christy
and
me
and
christopher
and
steve
and
jonathan
can
come
and
say
well,
this
is
important,
so
we
are
going
to
call
it
out
as
a
high
signal
kr
for
all
of
us,
and
so
that's
a
signal
to
all
the
hives
that
this
is
more
important
than
the.
B
Is
there
you
go
right
and
and
what
what
that
does
therefore?
But
but
it
still
allows
the
hive
to
come
back
and
say
we
heard
you
leadership,
but
we
want
to
be
able
to
get
an
exception
in
our
case,
because
we
have
another
fire
and
then
we
say:
okay,
eighty
percent
of
the
groups
are
gonna.
Do
this
twenty
percent
get
an
exception
versus
right
now.
B
What's
happening
is
because
we
don't
have
this
model
the
each
each
function
feels
like
as
that
either
give
us
a
top
down
or
don't
give
us
anything,
and
then,
when
you
give
it
top
down,
we'll
blindly
execute
on
it,
and
we
don't
really
worry
about
the
fact
that
we're
taking
bandwidth
away
and
violating
our
dri
models
right.
So
as
a
business.
What
we
are
doing
is
we
say
one
thing
in
the
handbook
and
then
with
all
these
top
down.
B
C
C
Yeah,
so
thank
you
for
explaining
that.
So
in
the
example
that
I
provide
here
about
the
heuristic
ux
scorecards.
B
C
B
C
Verify
is
a
critical
area
of
our
product.
It's
a
high
usage
area.
It's
in
our
top
three.
I
believe
when
you
think
about
create
and
verify-
and
I
think
the
third
one's
debatable,
but
if
we
were
to
say
verify,
is
not
participating
in
this,
then
that
is
other
designers,
not
getting
visibility
into
that
area,
and
then
yeah
I
mean
that's.
That
would
be
a
critical
one.
B
C
B
Right
and
and
that's
and
that's
exactly
the
conversation,
this
is
where
the
real
conversation
starts,
because
all
of
the
stuff
before
that
was
process
right,
and
so
the
question
is
okay:
it's
is
there
a
non-verified
designer
who's
learning
about
verify?
Well,
ikr
should
be
able
to
accommodate
that.
But
if
you're
also
saying
that
there
is
a
verified
designer,
that's
going
to
do
something
else,
then
you're
taking
the
verified,
designer's
bandwidth,
and
so
what's
the
impact
to
verify.
B
For
that,
that's
the
articulation
that
we
need,
and
then
we
say:
okay,
so,
let's
bubble,
then
I
think
bring
it
to
the
queen
bee
hive
and
say:
here
are
the
two
choices
we
have.
We
as
a
team
we're
still
unable
to
align
and
that's
okay.
Now
we
need
you
to
break
the
time
right
and
we'll
break
the
tie
for
you.
C
C
B
B
No
and
in
fact
but
but
I
think
what
you're
saying
the
I
empathize
with
that,
so
I
think
what
a
lot
of
times
what
functional
areas
think
is
they
have
to
advocate
and
pms
are
not
listening
and
that's.
Okay,
that's
our
job.
We
have
to
say
no
part
of
our
job
is
to
say
no
right,
but
the
feeling
that
you
have
is
the
same
feeling.
Engineering
figures,
the
same
feeling.
Infrastructure
feels
the
same
feeling.
Security
feels.
But
that's
not
it.
It's
the
same
feeling
our
customers
feel
it's
the
same.
B
Feeling
marketing
feels
it's
the
same
feeling.
Sales
feels
it's
the
same
feeling.
Customer
success
feels
scam
and
support.
Why?
Because
we
all
know
that
our
functions
are
not
operating
at
the
best
of
their
abilities,
and
if
we
had
more
bandwidth
and
more
team
and
more
capacity,
we
could
make
each
of
the
functions
first
class
right
and
the
the
job
that
has
been
given
by
our
ceo
and
two
pms
is
to
take
all
those
inputs
which
is
going
to
be
150
inputs.
B
I'm
just
going
to
make
this
up
and
then
pick
25
that
we
can
possibly
do
because
we
only
because
we
are
only
funded
for
25
right.
So
that's
like
a
broader
context
to
remember
so
it's
not
a
ux
only
problem.
It's
generally.
B
Then
the
second
piece
of
it
is
you're
saying
what
you're
suggesting
hey.
We
have
systematic
product-wide
improvements
to
make
in
ux
and
the
and,
if
each
individual
team
micro
optimizes
for
their
local
optimizations,
it's
hard
right,
yes,
and
I
think
for
that.
That
is
why
we
do
shared
okrs
at
my
level
and
christie's
level
right.
So
that's
why
we
picked
sus
as
a
shared
okr
to
give
signal
that
this
is
important.
Now,
if
there
are
more
things
beyond
that
that
ux
team
wants
to
do
well.
B
First
of
all,
we
have
to
recognize
that
we're
doing
a
lot
already
right,
so
there
will
be
some
trade-offs.
So,
yes,
ux
team
may
want
to
do
five
things
and
no
you're
not
going
to
be
able
to
get
to
do
five
things
you're
only
going
to
be
able
to
do
three
things
or
two
things,
and
and
that's
just
how
it
is
right
now,
if
you
say
no
sorry,
we
want
to
do
more
and
we're
going
to
take
that
bandwidth
away.
B
That's
when
the
that's
when
christy
and
I
have
to
connect
and
then
decide
for
for
you.
So
that's
why
I'm
saying
generally
this
giving
the
signal
should
work
for
like
80
of
the
cases
it
shouldn't,
be,
it
shouldn't
feel
like
you're
fighting
it
should
feel
like
you're
advocating,
but
part
of
advocating
is
also
educating
right.
If
every
designer
should
talk
to
their
hive
and
say,
hey,
look
we're
doing
this
broad
thing
you
you
all
need
to
understand
it.
B
This
is
the
context
in
which
we
are
operating,
which
is
great
for
the
engineering
manager
to
know
it's
great
for
the
product
manager
to
know
it's
great
for
the
test
team
to
know
it's
not
just
happening
in
a
silo,
and
so
that
conversation
and
dialogue
that
happens
in
each
hive,
where
each
team
advocates
for
what
they
want
to
do.
I
think
it's
precious,
you
don't
want
to
lose
it,
but
it
shouldn't
feel
like
it's
always
going
to
be.
No,
they
don't
understand
us
right.
Whoever
that
day
is
in
that
system.
C
B
B
I
think
we
should
note
that
down
as
a
concern,
but
we
haven't
even
tried
one.
So
my
and
I
think
the
hive
this.
This
is
the
only
team.
That's
trying
the
hive
cares.
So
my
request
is:
give
this
team
a
chance
to
sort
of
self
regulate
and
and
then
they
will
share
with
us
all
the
problems
that
they
had
and
they
can
start
stop
learn,
and
maybe
we
say
this
just
doesn't
work
for
gitlab
and
we
abandon
it
or
we
say
hey.
C
So
I
think,
I
think
we're
open
we're,
definitely
open
to
the
high
of
kr's
and
doing
this
experimentation,
but
it.
I
hope
that
it's
not
the
intention
that
hive
krs
are
if
this
truly
is
experiment,
let's
experiment
in
the
real
world,
and
that
is
not
to
say
that
hive
krs
are
by
default,
what
we're
going
to
do,
which
then
excludes
the
verified
designers
from
doing
ux
krs,
because
that's
I
don't.
B
A
So,
like
valley,
a
good
example
is,
we
are
already
aligned
with
the
mrux.
Widget
testing
has
selected
five
five
issues
where
we're
contributing
to
that
that
kr
already
and
we've
already
selected
another
uxkr
that
we're
contributing
to
on
it
on
pipeline
authoring,
but
the
other
issues
were
like
vitica
has
already
pinched
between
several
different
capacity
things,
and
I
have
a
bunch
of
features
that
she's
going
to
be
doing
so.
This
is
where,
like
when
continuous
integration
category
got
hit,
I
was
like
yeah.
C
To
so
that,
I
understand
it's
the
way
that
it
was
approached.
The
message
that
I
was
receiving
is
that
we
are
being
asked
to
pull
our
designers
off
of
uxkrs
by
default
in
order
to
support
the
hive
krs
and
that's
what
that's
where
my
concern
is.
I
don't
want
that
to
happen.
I
want
there
to
just
be
a
dialogue
about
prioritization
and
capacity,
and
you
know
what
is
the
hive
trying
to
do?
What
is
the
ux
department
trying
to
do?
What
are
the
trait
possible
trade-offs?
C
Because
that's
what
I
think
this
is
really
that's
what
it
comes
down
to.
We
just
need
an
open
dialogue
about
what
it
is.
The
capacity
is,
and
I
don't
want
to
overwhelm
anybody
and
if
you
are
saying
we
can't
add
vitica
to
any
more
things,
then
let's
talk
about
that
and
figure
out
what
to
do
to
move
forward.
A
So
it's
not
that
we're
saying
no
uxkrs
are
incorporated
in
the
hive
that
isn't
that
isn't
what's
happening.
It
was
like
we
reached
the
saturation
point
of
our
of
our
capacity
and
that
we
couldn't.
We
could
no
longer
commit
to
that
based
off
of
what
our
team
threshold
was.
So
we
had
to.
We
had
to
start
saying
no,
but
that
messaging
probably
got
lost
in
translation
clearly.
So
that
makes
a
lot
of
sense.
A
And
then
my
last,
the
last
point
I
have
on
here
in
the
agenda
is
around
adding
ux
kpis
to
the
hive
handbook
page,
because
today
we
just
have
usability
and
adoption
through
usability
as
a
theme,
but
we
don't
have
like
sus
or
ux
kpis
called
out.
Would
that
be
a
change
that
we
should
make.
B
I
would
think
so
because
I
think
when
the
moment
you
say
it's
hype,
then
each
functional
kpi
becomes
part
of
your
you,
as
a
hive
now
are
on
the
hook
to
deliver
it
or
not,
deliver
it
or
make
that
trade-off.
So
to
me,
gmaw
is
part
of
it,
but
sus
is
ux
tech
debt
is
reliability,
is
right
and
that's
why
that
that's
when
it
works
as
a
team?
Now
it
used
to
work
as
a
team
cohesively
when
there
were
not
a
lot
of
top
down
okay
and
we
were
moving
really
fast.
B
I
think
over
the
past
couple
of
quarters,
we've
had
a
lot
more
of
those,
and
so
it's
become
harder,
so
hopefully
high
and
may
will
remains
to
be
seen,
but
hopefully
high
will
help
bring
the
team
together
better
that
quad
or
that
hive
will
work
together
better.
They
will
understand
each
other's
needs
better.
B
They
will
understand
what
the
collective
goal
is
better
and
they
will
be
able
to
share
with
us
as
leaders,
so
your
designer
should
be
able
to
share
with
you
saying
this
is
what
I
plan
to
do
this
quarter
here
are
the
general
purpose
ux
improvements?
I'm
doing,
but
then
here
are
the
other
impactful
capabilities,
I'm
working
on
that
are
going
to
deliver
value
and
I
feel
confident
and
bought
into
it
right
and
hopefully
that's
where
we
want
to
go
where
everybody's
bought
into
it.
A
Okay,
you
know
that
we're
a
couple
minutes
over,
but
is
there
anything
else,
valerie
or
a
noob
that
we
should
cover
off
on.
B
No,
I
I
well
I'll
say:
yes,
there's
one!
This
is
hard
it's
hard,
because
you're
trying
to
align
functions
that
naturally
at
gitlab
haven't
had
to
do
this
advocacy
discussion.
It's
because
we
had
this
pms.dri
and
everybody
uses
the
prioritization
from
there
and
we
know
the
bad
side
effects
of
that
right.
So
we
want
to
avoid
that
and
that's
why
we're
elevating
every
function
into
the
hive
to
say
bring
your
like
advocate
for
it
and
then
that
way
the
designers
become
better
advocates
for
ux
craft
engineers.
B
C
Yeah,
I'm
interested
to
see
how
it
plays
out,
I
think,
jackie's,
a
great
leader
and
being
able
to
test
it
out.
So
I
think
this
is
a
good
one.
Yeah,
I'm
curious
how
this
scales
and
how
we'll
be
able
to
manage
that
for
sure,
but
definitely
I'm
a
big
advocate
of
trying
something
and
seeing
if
it
works
and
if
it
doesn't,
then
you
know
we.
B
B
C
So
this
has
a
this,
can
have
a
tendency
to
create
silos
additional
siloing
to
the
essential
product
or
a
certain
product
area,
and
we
are
challenged
with
creating
a
product
that
is
end-to-end
for
the
entire
dubsec
ops,
workflow
and
our
biggest
gaps
are
the
in
between
states
so
traversing
from
one
product
area
to
another,
and
I'm
really
curious
about
how
we
can
make
sure
that
we're
still
keeping
that
or
we
still
make
an
investment
and
addressing
that
when
we
have
hives
that
are
going
to
be
the
appearance
is
more
isolated
and
thinking
about
you
know
their
their
particular
group.