►
From YouTube: Plan Engineering FY23Q4 OKR Summary
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
This
is
a
quick
run
through
of
plans
fy23
Q4
okrs,
as
you
can
see,
I'm
not
quite
sure
which
of
these
is
correct,
but
we
either
accomplished
84
or
0.9
or
90
of
our
okrs,
for
this
quarter
either
way.
These
are
pretty
good
outcomes.
You
can
see
this
nice
trend
line
here
of
check-ins
throughout
the
quarter,
which
shows
a
consistent
kind
of
contribution
towards
the
goal.
It's
always
a
little
bit
below
the
ideal
trend
line,
but
that's
kind
of
to
be
expected
of
okrs.
A
You
want
them
to
be
ambitious
enough
that
you
accomplish.
You
know
between
70
to
100
if
you're
easily
accomplishing
100.
It's
considered,
you
know
not
ambitious
enough
a
goal,
but
we
had
a
pretty
ambitious
goal
as
our
main
okr
for
this
quarter,
you
can
see
it
ladders
directly
up
into
the
CEO
goal
to
do
okrs
within
gitlab
by
q1
of
fy24.
A
That's
the
quarter
we're
currently
in
so
you
can
see
here
that
we
accomplished
this
to
92
percent
and
I'll
expand
this
here
and
we
can
have
a
look
through
some
of
the
key
results
that
we
attempted
for
the
quarter.
So
this
okr
was
really
let
down
just
by
one
QR.
This
key
result
here
to
onboard
successfully
three
contractors.
A
We
infected
two
contractors
took
a
little
longer
to
get
through
the
process
of
finding
an
onboarding
contractors,
and
we
were
quite
a
way
into
the
quarter
before
we
had
accomplished
that
for
even
I
think
the
first
contractor
at
that
point.
Nevertheless,
these
three
KRS
here
are
really
inputs
and
not
icons.
A
This
one
here,
this
final
one
is
like
kind
of
the
most
important
one,
so
that
was
to
make
the
first
iteration
of
okrs
work
items
available
for
use
within
gitlab
by
q1
of
fy24,
and
what
this
means
in
reality
is
that
we
would
have
all
the
code
in
production
behind
a
feature
flag
and
have
it
stable
enough
to
flip
the
feature
flag
on
for
an
internal
group
so
that
everyone
within
the
organization
could
complete
their
okrs
and
we
achieved
that
goal.
So
that
was
really
a
phenomenal
effort
from
everybody.
A
I
want
to
take
a
chance
to
say
thank
you
to
everybody
in
plan
who
made
that
happen.
Even
if
you
didn't
work
directly
on
this
goal,
you
worked
on
something
that
Allied
other
people
to
focus
on
this
goal.
So
it
was
a
huge
accomplish
and
really
really
well
done.
A
The
second
okr
was
to
implement
significant
performance
enhancements,
and
this
was
completed
to
61
percent.
But
if
I
expand
this
site,
you
can
see
why
most
of
the
contributions
that
weren't
completed
to
100
were
actually
closed
at
zero
percent
or
a
low
percentage,
because
we
decided
we
didn't
want
to
do
them.
This
okr
was
quite
ambitious
as
well,
because
it
was
the
first
implementation
of
a
kind
of
new
strategy
for
improving
performance
within
the
UI
that
focuses
on
optimistic,
rendering
front-end
caching,
things
like
that.
A
It's
probably
easier
just
to
demonstrate
it
rather
than
to
go
through
the
KRS.
So
here
is
a
group
issues
list.
It's
important
to
note
that
it's
a
group
issues
list
it's
gitlab
org
and
it's
quite
a
large
group
in
that
it
has
a
lot
of
subgroups.
A
lot
of
projects.
Team
members
have
access
to
various
things
within
those
groups.
A
So
if
I
wanted
to
filter
this
by
labels,
the
labels
list,
the
calculation
required
to
show
me
the
labels
I
had
access
to
was
actually
incredibly
slow.
You
can
see
here
if
I
go
and
load
the
labels
list.
Now
it's
instant,
so
the
first
page
of
labels
is
instant
and
also
you
can
see
recently
used
labels,
but
if
I
put
in
you
know
common
things
that
I
would
filter
for
these
are
also
very
very
fast
because
it
starts
to
Cache
on
my
browser,
common
searches
that
I
make
and
to
put
this
in
context.
A
These
would
previously
take
six
to
ten
seconds.
For
this
group.
It
was
a
really
painful
experience
and
in
actual
fact,
what's
going
on.
Is
that
rendering
the
labels
from
the
front-end
cache
and
then
refreshing
the
list
using
the
same
long
running
query,
but
in
the
background
so
I
get
the
labels
first,
and
you
know
this
is
a
list
that
doesn't
change
very
often,
but
if
it
has
changed,
I
will
see
the
new
labels,
but
I
won't
be
held
up
by
the
request
cycle.
A
The
second
thing
about
this
is
that
the
list
of
issues
itself
is
actually
cached
here.
So
if
I
refresh
the
page
you'll
see
very
for
a
short
period,
this
empty
State
and
then
you'll
see
a
list
of
issues
here
and
again,
the
same
thing
happens.
So
you
see
that
this
is.
You
know
this
is
again
A
large
group
with
a
lot
of
activity,
so
you
saw
one
list
initially
and
then
you
saw
more
issues
pop
in
on
top.
A
That's
because
it
renders
firstly,
the
issues
from
the
cache
and
it's
running
the
the
request
in
the
background
to
refresh
and
get
the
new
issues
and
put
them
on
the
top.
So
you
just
have
this
snappier
experience
where
you're
kind
of
navigating
around
and
it's
very
quick
and
you
nine
times
out
of
ten-
are
going
to
get
access
to
the
thing
that
you
want
much
much
more
quickly
than
you
would
have
previously.
A
A
A
Another
part
of
this
was
to
actually
prepare
for
future
performance
improvements.
So
if
I
go
to
this
issue
list,
so
what's
different
about
assigned
issues
and
regular
issue
lists
is
that
this
was
always
in
view
or
was
in
view
when
we
started
this
quarter.
This
issue
list
assigned
issues
is
actually
in
Hamel
or
was
in
Hamel.
A
This
has
now
been
ported
into
view
by
Kong,
and
this
frees
us
up
in
the
future
to
actually
cache
this
as
well.
So
this
almost
definitely
form
part
of
a
an
okr.
In
q1
as
well,
and
what
that
means
is
instead
of
again
having
this
request
cycle,
your
assigned
issues
will
load
almost
instantly
from
the
cache
optimistically
and
then
the
cache
will
update
in
the
background
from
request,
just
like
it
does
with
other
issues
list.
A
The
ultimate
goal
is
to
make
it
extremely
inexpensive
to
navigate
to
things
that
are
assigned
to
you
using
this
menu
up
here
on
the
top
and
starting
with
issues.
So
so
yeah.
That's
a
demo
of
this
okr,
the
second
okr
for
performance
improvements.
We
will
have
another
one
for
this
quarter.
There
are
a
couple
of
working
groups:
betting
up
around
front-end
performance,
which
will
also
look
at
not
just
doing
this
within
plan,
but
spreading
It,
Out
Among,
the
engineering
engineering
organization.
A
Let's
see,
if
I
covered
everything
here
so
yeah,
we
can
expand
this
one
here
to
see
a
little
more
about
what
was
done
and
we
can
see
the
one
that
was
closed
out
here
was
related
to
indexeddb.
Most
of
the
other
KRS
were
accomplished
in
full.
A
A
A
Yarka
also
had
an
okr
here
to
improve
plan
stage
processes
themselves,
including
documenting
a
retrospective
process
for
plan,
which
we
didn't
have
before
this
a
properly
documented
timeline
and
also
creating
weekly
updates
for
plan
stage
team
members
to
move
them
out
of
one-to-ones
and
into
higher
leverage
environments
like
an
issue
or
multimodal
communication,
and
so
on.
So
a
couple
of
important
things
to
note
about
this
okr,
we
didn't
count
okrs
themselves
as
a
new
process,
because
that
would
be
double
counting
we're
all.
A
We
already
have
an
okr
for
producing
okrs
as
work
items,
so
that
wasn't
counted
and,
second
of
all,
in
the
first
KR
to
trial
three
process
improvements.
We
didn't
include
health
status
automation
because
that
was
already
trialled
with
other
groups
before
the
quarter
started,
so
we
had
to
find
three
new
ones.
The
idea
was
to
find
three
new
process
improvements
that
would
give
us
four
in
total
to
trial
with
other
teams
and
then
Implement
three
of
those
at
the
organizational
level.
A
We
actually
only
did
two
new
processes
with
other
groups,
but
we
did
Implement
three
process
improvements
at
the
organization
level.
One
was
value
stream
analytics
within
retrospectives,
so
you
can
now
access
value
stream
analytics
for
the
Milestone
that
the
retrospective
is
for
directly
from
the
retrospective
itself.
The
second
one
was
internal
notes
on
retrospectives,
so
that
safe
information
can
be
properly
protected
within
the
retrospective
process,
which
ultimately
makes
retrospective
issues
public.
A
This
improves
transparency
because
you
can
make
the
whole
issue
public,
even
if
there's
information
in
there
that
you
want
to
keep
private
within
the
organization
that
can
be
done
using
an
internal
note
and
the
third
process
Improvement
at
the
organizational
level,
was
to
introduce
health
status
automation
across
the
board
for
the
whole
gitlab
project.
Now
any
issue
with
the
deliverable
label
within
the
current
Milestone
will
have
its
health
status
updated
automatically
if
it's
not
updated
by
the
assignee.
A
A
The
idea
behind
it
was
to
build
a
habit
for
pushing
our
features
throughout
the
organization
for
making
sure
that
we're
communicating
even
the
small
features
to
the
rest
of
the
organization
and
helping
to
improve
the
efficiency
of
gitlab
generally
by
informing
people
of
the
features
that
we're
building
understanding
as
a
team,
how
to
collect
feedback
on
those
features
and
how
to
best
communicate
them
to
the
rest
of
the
org.
This
was
completed.
A
A
We
basically
one
per
month
new
process
for
Improvement
for
the
whole
of
the
organization,
which
is
a
really
nice
outcome
and
also
helps
us
gather
more
feedback
on
the
features
that
we're
producing.
A
Finally,
the
last
okr
was
Around
Talent
assessment,
not
really
something
you
can
do
at
anything
less
than
100,
but
it
was
useful
to
track
throughout
the
organization
as
ultimately
with
any
timeline,
especially
one.
That's
on
the
scale
of
month
month
and
a
half
you're
going
to
get
a
lot
of
PTO.
We
want
to
make
sure
that
the
talent
assessment
process
is
broadly
on
track,
regardless
of
PTO,
and
it
was
so.
You
can
see
if
you're
interested
very
quickly
here
which
groups
were
able
to
complete.
A
Obviously,
if
a
subgroup
of
mine
can't
complete
Talent
assessment
on
time,
then
I
also
can't
mark
this
as
100
percent.
All
Talent
assessments
have
been
done.
This
is
just
a
measure
of
what
was
done
within
the
quarter.
I
think
90
is
pretty
much
what
I
would
expect
about
10
of
PTO
to
interfere
with
the
process.
A
Everything
else
is
more
or
less
what
I
would
expect.
So
those
are
the
okrs
for
Q4,
we'll
have
okrs
for
q1,
but
those
will
be,
of
course,
within
gitlab
itself
and
will
be
visible
to
everyone.
I
will
do
an
update
on
those
within
the
team
meeting,
probably
next
week,
so
that's
about
three
weeks
into
the
quarter.
A
Obviously
we
want
to
bring
that
timeline
forward,
but
I
think
just
given
that
we're
using
a
new
system,
even
though
it's
one
that
we
built
the
whole
organization
has
to
learn
to
use
it
so
we're
a
little
bit
later
this
month
with
getting
okrs
finalized,
but
you
should
be
able
to
figure
out
like
roughly
from
these,
what
we'll
be
targeting
in
q1.