►
From YouTube: Areas of Focus Workgroup - 2021-02-11
Description
Areas of Focus Workgroup - 2021-02-11
A
A
A
We
said
it
was
baffled
statistics
a
little
bit
that
100
of
people
said
we're
wrong,
so
we
must
be
wrong
or
all
21
of
the
people
who
did
our
surveys
are
wrong,
so
we
have
to
determine
which
do
we
want
to
do
it's
interesting
because
it
looks
like
a
lot
of
people
here,
I'm
going
to
share
my
screen
that
way,
we
can
look
at
it
all
together.
That
way.
A
This
looks
like
the
right
page
cool.
The
interesting
part
is
so
here's
the
managing
group
project,
which
we
all
said
it
would
be
part
of
the
one
that
most
people
said.
It
was,
though,
is
a
gitlab
feature
which
I
find
interesting
since
service
desk
is
a
thing
that
exists.
You
know
outside
of
gitlab,
I
mean
zendesk
itself
uses.
B
B
B
Okay,
so
issue
tracking
is
under
project
management
under
plan,
and
then
service
desk
is
under
certify
under
plan,
but
they're
both
on
their
plan
and
almost
everything
under
plan,
I
would
say,
is
a
kind
of
core
get
loud
feature,
so
it's
not
actually
too
far
off.
If
we
think
about
it
that
way,
and
if
we
think
of
service
desk
as
managing
issues,
so
I
actually
think
we
were
wrong.
A
Is
so
my
honest
view,
there
is
we're
wrong
if
100
of
the
responses
say
we're
wrong.
We've
got
to
be
wrong,
so
I
would
actually
agree
with
putting
it
under
get
out
features
which
would
then
make
that
a
non-issue
area
if
we
align
on
that
one
okay.
So
we
agree
cool
well
on
the
plus
side,
I'll
go
back
to
sharing
my
screen.
A
That
means
that
one's
not
an
issue
anymore
and
I'll
modify
this
so
done
cool
the
other
one
interesting
one
was
the
merge
trains
which
was
question
five
and
there's
no
confusion
of
was
this
emerge
train
issue.
The
title
of
the
ticket
was
merge.
Trains
was
that
so
what's
interesting
is
52
said
that
it
was
a
gitlab
feature,
makes
sense.
That's
what
we
all
kind
of
said.
It
was
the
one
that
interested
me
was.
33
percent
of
the
people
said
it
was
a
get
lab
runner,
cicd
package
issue.
A
Which
is
a
pretty
decent
amount
of
people
who
said
it
was
something
different
now
my
confusion,
there
is,
I'm
not
sure
the
correlation
there,
other
than
cicd
can
create
a
merge
train,
but
anything
like
any
merge
really
can
create
a
merge
train
like
it's
not
limited
to
ci
cd.
It's
not
even
really
associated
with
it.
Other
than
ci
cd
can
make
a
merge
train,
but
arguably
a
lot
of
things
can
make
a
merge
train.
B
I
I
have
no
real
insight
into
why
someone
would
say
cicd
aside
from
the
fact
that
I
actually
you
know
what
I
really
don't
know
like
merge
trains
are
like,
in
my
mind,
are
purely
to
do
with
merge
requests,
and
that
is
a
get
loud
feature
which
is,
you
know,
and
I
think
part
of
source
code
or
plan
one
of
the
two.
I
don't
even
remember
it's
like,
but
it's
one
of
those
stages
that
are
pretty
core
to
get
that
feature.
I
it's
definitely
not
like
verify
or
whatever.
B
A
My
only
thinking
here-
and
this
is
where
kind
of
like
my
only
thought
process
on
this
is
self-managed-
is
much
less
likely
to
deal
with
merge
trains
than
com,
and
my
thinking
is
it's
that
limited
exposure
that
would
make
them
think
that
merge
trains
are
somehow
associated
with
get
lab
ci
cd,
especially
since
the
place
they
would
see
the
most
is
getlab.com
for
a
handbook
change
and
a
big
part
of
a
handbook
change.
Is
that
huge
job
list
that
runs,
but
that's
me
kind
of
making
an
assumption
on
this.
One.
B
D
A
Forget
it
yeah
yeah,
it
was,
it
was
something
we
had
talked
about
and
it
was
like
if
they're
anonymous,
we'll
probably
get
what
we
thought
would
be
true
responses,
so
like
cool,
it's
anonymous
like
this
is
also
one
that,
like
we
had
one
comment
there
where
it's
like
get
lab
feature
seems
broad,
but
they
picked
git
lab
features,
so
it
was
like.
Oh
so
you
picked
the
right
one,
but
no
one
seemed
to
want
like
there
was
very
few
secondary
choices
on
that
one.
It
was
like
almost
everyone
either
said.
A
Most
people
said
it
was
a
feature,
but
then,
like
you
know,
seven
people
were
like
no.
This
is
a
runner
thing.
You
know,
so
I
think
that
might
be.
We
should
edit
the
get
lab
features
where
it
says,
such
as
issues,
boards
source
code,
wiki
and
add
the
word
merge
trade,
since
that
seems
to
be
a
confusion
that
we
can't
really
explain.
E
I
might
have
been
one
of
the
people
who
said
pipelines
and
I'll
tell
you
why,
because
some
of
these,
I
went
not
a
support,
engineer,
not
quite
sure
how
you
classify
these.
What
did
the
customers
say
at
the
start?
Let's
do
a
quick
search
of
docs.
Now
when
I
search
for
merge
train
in
the
docs,
it
comes
up
under
the
subject
of
pipelines,
so
I
possibly
did.
I
was
possibly
one
of
those
people
who
said
that
it
was
pipelines
for
that
reason
because
of
where
it
sits
under
docks.
A
So
this
might
be
a
naming
issue
of
the
docs
make
it
sound
like
this
involves
a
pipeline,
and
I
would
also
agree
that
if
I
see
the
word
pipeline
I'm
going
to
go.
Oh
that's
gitlab,
ci
cd,
because
that's
what
we
call
them
but
yeah!
That's
that's
interesting
like
it
says
it
constantly
and
then
you
get
to
actually
reading
about
it
and
it
just
stops
using
that
terminology.
A
B
That's
what
this
page
would
be
about
like
how
things
how
how
the
pipeline
is
run,
how
the
pipeline
is
triggered,
which
which
shaw
it
pulls
from
and
stuff
like
that,
depending
on
where
it
is
in
the
merge
train
and
then
there's
the
actual,
merge
train
feature.
So
there
are
two
parts
to
it.
So
I
can
kind
of
see
why,
like
you,
would
need
to
really
look
at
the
tick.
I
actually
haven't
looked
at
the
tickets
in
detail,
so
I
would
have
to
look
at
them.
Look
at
it
again,
but
it.
B
I
would
say
that
if
I'm
just
looking
at
the
title,
I
would
probably
say
if
it's
a
merch
train,
it's
probably
related
to
emerge
request.
But
if
it's
to
do
with
okay,
how
does
a?
Why
is
this
pipeline?
Working
this
way
when
it's
in
a
merged
train
that
is
actually
more
of
a
pipeline,
ci
cd
question.
So
actually
does
the
kind
of
depend
a
little
bit
and
I
totally
understand
jane's
point
with
like.
B
B
We
do
have
a
number
of
tickets,
that
kind
of
when
you
first
get
them.
You
don't
even
know
necessarily
what
they're
about,
and
you
end
up
having
to
reclassify
them
later.
So
I
I
don't
think
it's
a
bad
thing.
We
still
got
over
40
50
of
the
first
choice
and
total
over
60.
If
you
add
first
and
second
choice,
so
I
think
it's
okay.
It
is
a
slightly
ambiguous
thing.
B
A
A
Looking
at
the
comments,
the
one
that
really
shine
to
me
is
the
geo
ticket.
Almost
you,
almost
everyone
who
put
other
on
that.
One
was
like
this
is
geo.
It's
like
okay,
yes,
it
is
geo
and
that
seemed
to
be
what
they
think
is
geo's
a
category
two
itself
and
I
would
agree
like
maybe
a
sub
category,
but
then
we
have
some
categories
for
kubernetes,
docker
omnibus,
like
it
I
that
one
I
was
like
okay.
A
A
I
did
find
that
one
interesting
cool,
but
what
I'm
seeing
from
this
survey
and
our
results
is,
it
looks
like
we've
got
our
categories
pretty
well
hammered
down.
Everyone
seems
to
be
able
to
pretty
easily
put
stuff
in
place,
with
the
exception
of
service
desk
and
merge
trains,
and
those
seem
like
two
kind
of
weird
areas,
but
we've
agreed
service
desk.
A
A
So
let
me
share
my
screen
once
more
cool,
so
here
we've
got
our
sandbox
and
you'll
notice.
The
views
are
radically
different,
there's
several
ones
missing,
and
this
is
because
dot
com
with
sla
sm
with
sla.
We
combined
those
into
one
support
with
sla
the
support
the
the
self-managed
needs
or
needs
assignee,
and
the
com
needs
assignee
once
again,
combined
into
one
so
three
technically
because
there's
one
per
region.
A
A
Lnr
became
its
own
group.
Cicd
became
its
own
group
free
customer
com.
Problems
became
its
own
group
and
if
you
look
at
my
profile,
where
I'm
assigned
to
just
way
too
many
groups
in
the
sandbox
you'll
notice,
we've
got
these
four
new
ones
of
areas
of
focus.
Ci
cd
naming
is
something
we'll
figure
out
for
these.
I'm
just
putting
areas
of
focus
me
and
cynthia
were
like
that
makes
it
easy
to
know
what
we're
doing
right
now,
but
as
an
example.
A
A
A
The
form
is
not
any
of
these
stuff.
That
has
nothing
to
do
with
it.
What
really
comes
into
play
for
this
one
is
using
the
sauce
problem
type
and
the
self-managed
problem
type
from
the
forms
and
saying
it's
support
for
runners
or
it's
ci,
cd
and
those
criteria.
What's
helping
us
say,
that's
what
tickets
go
in
this
view,
nothing
else.
A
The
concept
me
and
cynthia
are
thinking
is
along
those
lines
of
using
what
we've
already
got
to
kind
of
help
us
filter
these
areas
of
focus
and
then,
as
we
specialize
further
out,
we
can
make
the
views
and
criteria
like
that.
A
little
more,
you
know
specific
to
whatever
category
we're
working
with,
but
that's
kind
of
what
me
and
cynthia
have
been
working
on.
But
what
are
y'all's
thoughts.
Do
you
think
that's
kind
of
what
we're
looking
at
what
we
want
zendesk
to
look
like?
C
You
know
globally,
but
also
by
region,
so
that
we
have
the
right
number
of
people
to
the
right
number
of
things,
and
it's
still,
you
know
you're,
not
looking
at
all
the
areas
of
focus
and
saying
well,
I'm
gonna
go
pick
one
from
here,
one
from
here
from
here
that
we're
trying
to
do
it
to
a
point
where
people
are
working
on
their
areas
of
expertise.
You
know
over
time
and
over
time,
switching
and
that
sort
of
thing,
so
you
know
it'll,
take
some
balance
and
management
based
on
where
we're
seeing
ticket
going.
A
Yeah,
I
definitely
think
that's
something
that
like
before
we
go
live
with
this,
we
should
definitely
say:
okay.
Well,
these
are
our
criteria.
This
is
how
we're
determining
these
groups,
and
we
should
definitely
try
to
pull
historic
like
these
are
the
kind
of
numbers
we've
seen
month
over
month
for
these,
so
that
on
day,
one
when
this
goes
live
and
we're
ready
for
everything-
and
you
know
sean
goes
to
jane
he's
like
hey,
you
were
the
ek
you
were
the
the
apac
person.
How
do
I
pick?
Who
goes
where
jane
can
go?
A
C
Exactly
and
I
think
in
addition
to
the
volume
distribution,
we
need
to
consider
the
time
some
time
element
right
on
and
whatever
that
time
needs
to
be.
If
it's
total
resolution
time
or
just
request
or
wait
time
or
whatever
it
happens,
to
be
that
that
plus
the
volume
or
that
multiplied
by
the
volume
to
be
able
to
get
that
distribution,
yeah.
C
E
A
A
We
don't
want
to
have
like
the
l,
r
situation
of
great
everybody's
allocated,
no
one's
in
l,
r,
no
one's
doing
those
tickets
we're
in
trouble,
or
we
have
like
two
people
and
no
one's
doing
them
beyond
that.
So
I
definitely
think
this
is
something
we
want
to
do.
I
think
it'll
also
kind
of
help
us
like
in
the
in
the
scheme
of
like
hiring
and
figuring
out
like
if
we're
noticing
hey
look
we're
getting
a
ton
of
volume
in
this
specific
area.
A
B
B
Types
like
I
say,
they're,
not
exactly
the
same,
but
a
lot
of
them
are
close
or
exactly
the
same,
and
so
we
can
then
break
that
down
by
region,
and
then
we
can
start
slotting
people
in
as
in
preparation
for
the
move,
so
that
we
can
say
like
okay
right
now,
we
have
these
people,
who
will
be
an
expert
in
these
areas?
Is
that
enough?
B
You
know
we
don't
have
like
a
ton
of
experts
and
we're
actually
sure,
like
we're
kind
of
short
on
having
any,
I
think
in
a
mia.
So
then
you
know
potentially
reaching
out
to
the
media
managers
to
say
hey.
We
need
at
least
one
person
or
two
people.
However
many
it
is
to
at
least
be
training
in
this
area
so
that
they
are
getting
up
to
speed
on
it,
and
I,
I
think
that
I
think
that's
fine.
B
E
It
in
terms
of
ongoing
visibility,
which
is
sort
of
related
of
who's,
in
what
focus
area,
what
area
of
focus?
Sorry,
I'm
guessing
that
we'll
be
able
to
do
something
automated
from
zendesk
to
our
support
team
website,
so
that
we
can
actually
go
in
and
write
order
either
by
this
person
has
got
these
three
areas
of
focus
in
zendesk
I
yeah
cool.
Thank
you.
A
Yeah,
luckily,
the
support
team
yaml
already
has
your
zendesk
groups
and
that's
because
it
helps
my
team
when
it
comes
to
audits.
Luckily,
because
it's
there,
it
means
we
can
do
all
kinds
of
automated
things
to
the
team
page
or
set
up
things
to
be.
Like
hey.
We've
noticed
that
this
eight,
you
know,
we've
got
10
people
who
said
they're,
l
r
focused,
but
their
percent
focus
on
that
is
30,
which
tells
us
that
it's
not
it
equates
to
like.
Luckily,
software
is
really
good
at
doing
math.
E
B
E
B
A
Yeah
and
the
the
team
page
that
you're
referring
to
yeah
that
it
runs
on
schedule
every
day
to
make
sure
that's
as
up
to
date
as
possible.
I
think
it
midnight
utc,
because
that's
just
the
time
I
always
seem
to
pick
for
some
reason,
but
luckily,
because
that's
kept
up
to
date
in
general,
if
you
know
jane,
you
go
to
look
at
it
at
most,
it's
hours
off,
and
that's
it
not
days
weeks
months.
A
A
B
So
one
of
the
questions
I've
actually
been
getting
from
people
like
other
ics
in
particular,
is
that
they've
obviously
started
hearing
about
some
of
this
work.
We've
been
talking
about
coalescing
for
over
a
year
now,
and
so
one
of
the
things
I'd
been
thinking
about,
and
I
actually
talked
with
ronnie
a
little
bit
on
monday,
because
a
lot
of
the
new
hires,
at
least
under
ronnie,
we
always
pictured
as
kind
of
what
we
have
been
calling
a
hybrid
role
right,
which
is
that
they
might
start
their
focus
in
sas.
B
Where
are
we
with
kind
of
pushing
that
you
know,
even
if
it's
only
10
mike
lockhart
is
a
good
example.
He's
he's
like
on
the
area
focus
page
you'll,
see
that
he's
specifically
listed
as
10,
so
it's
not
a
lot,
but
just
starting
to
really
kind
of
push
the
team
to
learn
more
about
the
other
product
and
go
through
the
training.
Now
I
know
the
training
is
not
quite
there
yet
so
ronnie,
and
I
did
briefly
discuss
that
as
well.
B
E
Just
a
couple
of
comments
on
that,
I'm
just
about
to
try
and
find
out,
but
one
I've
got
three
people
like
mike
mike
alvin
and
kenneth,
who
are
all
on
boarding
as
hybrids
alvin's.
You
know
40
60
kenneth
is
just
about
to
migrate
into
doing
self-managed,
but
the
more
important
point
to
that
is
weiming
actually
has
a
okr.
This
quarter
specifically
around
cross-training
people,
and
I
think
the
intention
is
probably
to
have
out
of
the
back
of
that
some.
You
know
broader
learning
that
can
go
more
global
to
help
with
this.
E
A
I
do
think
it's
helpful
to
like
align
with
weiming
and
just
be
like
hey
we're
working
on
this
thing.
We
think
what
you're
doing
is
also
going
to
be
very
tied
in
with
this,
not
necessarily
like,
if
we're
doing
the
same
work,
but
like
we're
going
to
put
some
reliance
on
what
you're
working
on
to
help
make
this
thing
really
work,
because
I
I
do
foresee,
if
we
don't
make
sure
the
team's
prepared
and
we
have
people
who
are
still,
I
can
only
work
sauce.
I
can
only
work
self-managed.
A
What
we're
going
to
see
when
we
coalesce
everything
is,
I
don't
know
how
to
work
tickets
anymore,
because
you
know
I
keep
getting
sauce
tickets
that
I
can't
work
or
I
get
self-managed
tickets
that
I
can't
work.
So
I
think,
like
the
work
wayming's
doing,
is
very
important
with
this,
especially
to
us,
but
I
do
think
you're
right
if
we
should
make
sure
we're
aligned
if
we
means
like
oh,
I
plan
to
have
a
rough
draft
by
end
of
quarter
and
next
quarter,
we'll
start
training
people.
A
I
think
it's
important
that
we
do
make
sure
we're
aligned
on
that
just
to
kind
of
make
sure
we're
not
trying
to
go
live
before
the
team
is
ready
to
actually
coalesce
fully,
at
least
technically
speaking,
ready.
I
think
we'll
we'll
definitely
find
out.
There's
going
to
be
people
who
are
just
they
do
not
want
to
coalesce,
because
it's
always
been
this
way.
A
Like
the
areas
of
focus
concept
yeah,
so
the
group-based
views
are
doable
right.
Now
we
have
two
group
based
views
that
essies
can
access
for
areas
of
focus.
I
put
placeholder
names
in
them
and
I
have
been
fighting
off
other
managers
who
are
like.
Oh,
we
could
do
this,
I'm
like
nope.
I've
already
claimed
those
views.
I
did
a
lot
of
work
to
get
those
views
they're
not
going
anywhere,
so
we
could
in
theory,
set
up
at
least
two
of
them
to
start
kind
of
working.
C
No
yeah,
I
would
suggest
we
we
hold
off
and
because
it's
hard
to
say,
okay,
well,
new
people
are
going
to
do
this.
I
think
we
have
to
we're
we're
having
to
manage
the
distribution
and
who
works
on
what
already
right,
and
today
it's
it's
to
some
extent
predefined
by
people,
but
by
the
same
token,
again
outside
of
l,
r
and
even
to
this
exit.
But
people
can
work
on
anything
right.
C
So
I
think
from
an
onboarding
perspective,
managers
could
try
to
figure
out
how
to
get
people
into
the
areas
of
focus
that
will
be
defined,
but
I
think,
as
soon
as
we
start
to
make
view
level
changes
than
the
rest
of
the
rest
of
the
support
organization.
What's
this
about
how
come?
I
can't
do
that
right.
So
we
start
to
be
segmenting
by
segments
of
people
so
yeah.
B
So
in
shifting
the
problem
types,
you're,
you're
gonna
be
changing
exactly
what
might
fall
under
an
area
of
focus
and
how
those
tickets
kind
of
come
in
and
like
having
to
completely
change.
Those
views
again
later
might
be
a
bit
of
an
issue.
Now
there
are,
you
know,
as
jason
said,
because
there
are
certain
ones
that
are
very
defined
or
you
know
are
not
going
to
change.
B
Then
we
could
do
that,
but
I
I
don't
know
how
much
of
how
much
of
an
advantage
it
is
to
implement
this
at
the
instance
level
versus
say,
having
someone
and
encouraging
someone
to
create
their
own
custom
view
to
focus
on
tickets.
So,
just
as
a
very
quick
example,
I
actually
have
two
of
my
own
custom
views.
One
is
specifically
on
saml
and
one
is
actually
specifically
on
omni,
auth
and
oauth,
because
I'm
doing
training
modules
or
well
one
I
already
completed,
but
the
other
one.
I'm
now
doing
right
and
the
other
one.
B
I
just
the
view
that
I
previously
created.
While
I
was
training
in
that
area.
I
just
kind
of
left
there,
but
I
think
there's
no
reason
why
we
can't
encourage
people
to
create
their
own
views
kind
of
as
a
temporary
means
right
to
kind
of
focus
on
those
tickets,
especially
if
they're
trading
in
that
area
and
if
and
I've
done.
B
Like
I've
thrown
it
into
support,
where
you
can
review
before
I
mean
there's
a
million
one,
zendesk
tutorials
out
there
on
how
to
do
it,
and
if
anyone
needs
you
know
extra
tips
or
whatever
I'm
sure
we
can
arrange.
You
know
doing
a
quick
demo
record.
It
upload
it
onto
unfiltered
or
something
you
know
like
whatever
people
need,
and
so
I
I
do
think
that
with
new
people,
we
can
definitely
encourage
working
like
starting
in
certain
areas
and
starting
to
do
that,
but
yeah
I
I
I'm
just
I'm.
E
Yeah,
that
was
the
connection
I
missed.
I
because
I'm
just
thinking
about
getting
early
feedback.
You
know
iterating
getting
early
feedback.
I've
got
kenneth
who's
just
about
to
start
into
self-managed,
and
if
I
could
kind
of
go
right,
you
know
let's
focus
on
this
area
of
focus,
but
but
you're
right.
I
haven't
made
that
connection
with
the
problem
types.
Yet
so
I'll
work
with
them
on,
as
you
say,
individual
views
to
do
that.
B
Yeah,
and
and
again,
if
I
mean
support
ops,
is
here
to
help,
as
jason
said
in
the
chat
any
of
us
who've,
you
know
done
it
before
it
is
fairly
simple
once
you
know
what
to
do
so,
you
know
any
of
us
would
be
more
than
happy
if
you
want
to
start
having
ics
think
about
it
and
work
that
way.
I
I
really
don't
think
that's
a
problem
right
as
long
as
you
know,
they're
aware
that
you
know
they're
uncrew,
they
should
still
be
looking
at
the
ones
with
sla.
B
You
know
that
that
sort
of
thing,
as
long
as
we're
not
breaking
from
kind
of
using
the
views
that
we
already
have
for
the
purposes
that
we
have
it,
I
see
no
problem
doing
that.
I
do
this
actually
all
the
time
in
my
own
work
because
of
again
trying
to
bring
myself
up
in
the
areas
I'm
training
in
and
to
kind
of
keep
an
eye
on
areas
that
I'm
an
expert
in.
B
I
actually
do
have
views
for
that
already
and
again,
that's
absolutely
no
problem,
I
would
say
in
terms
of
thinking
having
people
think
about
it
that
way
and
working
that
way
is
just
whether
we
do
it
in
zendesk
right
now.
I
I
I
would
say
we
should
probably
hold
off
and
and
have
individuals
make
their
own.
A
So,
to
answer
your
question
of
what
the
timeline
is,
I
actually
want
us
to
have
an
implementation
plan
ready
by
the
end
of
the
quarter
and
the
idea
there
is
we've
done
all
the
testing
that
we
can
do
and
we're
saying
all
right.
We
want
to
go
live
with
this
next
quarter.
Here's
how
we
plan
on
doing
that
and
that
that
doesn't
necessarily
mean
we're
going
live
the
following
quarter.
A
C
If
that's
part
of
the
implementation
point,
why
could
we
consider
think
thinking
of
starting
implementation
by
the
by
next
quarter
versus
having
a
plan
and
then
having
because
the
way?
The
way
I
view
having
a
plan
by
end
of
quarter
is
we'll
have
a
plan
and
then
we'll
start
to
communicate
it
and
then
we'll
go
through
and
iterate
on
the
plan?
What
I'd
like
to
have
is
is
here's
the
plan.
A
D
B
I
would
probably
separate
that
by
I
I
like
tom's
way
of
thinking
about
it,
where
we're
implementing
the
plan
in
next
quarter,
and
then
I
would
say
that
I
would
call
it
the
go
live
date,
so
our
go
live
date
might
be
not
next
quarter
might
be
the
quarter
after,
but
that
we
are
implementing
the
plan
that
we
come
up
with
next
quarter.
So
I
yeah
I
like
the
way
that
tom
describes
it.
A
A
It
is
not
just
it's
in
zendesk,
it's
us
getting
everything
ready
for
it,
making
sure
people
are
trained.
Looking
at
what
the
distribution
needs
to
be
monitoring
it
over
the
course
of
a
quarter
and
going
our
distribution
may
have
looked
bad
last
year,
but
it
actually
looks
like
this
now,
so
I
do
yeah.
I
agree
with
you
that
we
will.
A
Maybe
we
get
lucky
and
weiming
does
like
something
amazing
that
makes
people
able
to
get
trained
in
a
month
and
then
it's
like
great
that
reduces
our
time
to
go,
live
on
in
zendesk,
but
I
do
think
part
of
that
is
going
to
be
here's
our
criteria
to
put
this
into
zendesk
and
go
live.
That's
our
implementation
plan
of
we
have
to
work
to
get
that
criteria
hit.
If
that's
training
or
you
know.
A
If
it's
oh
well,
we
we
need
to
focus
on
hiring
people
in
this
area,
because
it's
a
huge
problem
and
then
we
talk
to
tom
and
eric
and
figure
out
what
we
need
to
do
there.
We
need
to
figure
that
part
out.
We
need
to
figure
out
okay,
so
go
live.
Is
here
we're
right
here
where
we're
like?
Okay,
we
think
we've
got
the
final
categories
that
we
want.
We
think
we've
got
a
basic
idea
in
zendesk.
E
This,
I
do
wonder
if
I'm
very
conscious
of
the
absence
of
a
currently
self-managed
focused
engineer
in
the
work
group,
someone
who's
used
to
that
way
of
life
and
the
mindsets
that
come
with
it,
and
I
just
I
do
wonder
as
we've
looked
towards
implementation,
whether
we
should
actively
encourage
someone
to
join
this
group.
Oh
yeah,
oh
yeah,
if
he
called
jason,
I
hadn't
thought
about
it.
That
way.
A
Yeah,
I
was
one,
but
it
admittedly
was
like
almost
two
years
ago.
So
it's
it's
been
a
hot
minute
yeah.
I
do
think,
as
we
start
planning
what
we
need
to
do
for
next
steps.
It'd
be
good
to
get
a
self-managed
engineer
in
here
as
well,
so
we
have
cynthia
who's
got
the
you
know
the
soft
side
of
things
locked
down.
She
knows
that
stuff
better
than
anybody.
I
know
it'd
be
good
to
get
somebody
on
the
self-managed
side
and
it's
like
great
y'all.
Two
can
really
work
together.
Help
us
figure
out.
A
E
B
Whether
that's
you
know,
people
who
have
been
here
a
long
time,
whether
it's
new
people,
and
I
think
it
would
be
a
you
know,
good
to
get
a
mix,
and
that
should
definitely
be
part
of
the
plan
that
you
know,
because
I
think
we
can
do
a
few
things
in
parallel
right.
We
we
get
stats,
we
say:
okay,
here's
the
volume
for
each
of
the
the
problem
types.
This
is
this
is
what
kind
of
resourcing
we
need,
but
in
the
meantime
we
can
also
see.
A
Engineers
yeah,
I
fully
agree,
and
I
think,
like
I
think,
once
we
start
making
this
implementation
plan.
I
think
the
idea
of
like
beta
testing
it
via
personal
views
is
a
very
useful
method
to
make
sure
that
okay
yeah,
we
know
that
I
can
set
up
zendesk
to
do
this.
We
know
that
we
can
categorize
tickets
because
we
we
sat
here
and
did
it
right.
But
how
does
this
actually
work
when
it's
being
used?
A
C
A
Looks
great
with
zero
tickets
in
it,
but
how
will
that
look
like
even
the
idea
of
like
coalescing
the
views
right?
So
if
there's
50
in
self-managed,
50
and
sauce,
that's
100
tickets
in
one
view,
is
that
how
we
actually
want
to
do
this
or
is
it
okay?
We
looked
at
it,
that's
terrible!
We
don't
want
to
do
it.
We
should
keep
those
separated
and
not
coalesce
the
views,
because
it
will
do
this
or
we
go
yes.
A
That
view
will
be
ugly,
but
the
whole
point
of
that
view
is
to
have
every
ticket
in
it
anyway,
because
I've
argued
before
if
somebody's
been
like
the
pending
view
is
terrible.
I'm
like
I
agree.
You
should
never
look
at
that
view,
that's
an
ugly
view,
but
the
whole
point
of
it
is
to
have
every
pending
ticket.
It's
not
meant
to
be
pretty
just
like
the
oh,
the
on
hold
or
the
open
view
or
the
new
view.
A
I'm
like
yeah,
they're
ugly,
it's
every
single
ticket
ever
they're,
not
meant
to
be
pretty
they're
meant
to
be
there,
for
we
need
to
look
at
something
on
a
greater
grander
scale
than
just
the
separation.
We
currently
have
like
the
new
view,
is
not
there
to
be
helpful
for
anyone
other
than
when
tom's
like.
Are
we
getting?
Is
there
a
ton
of
new
tickets?
I
can
go
straight
to
that
view
and
go
yes.
There's
this
many
super
useful
for
that
specific
purpose.
A
I
think
I
can
map
old
values
and
new
values
together
to
kind
of
give
us
a
baseline
of
what
it
looks
like
month
over
month,
worst
case
I'll
pair
with
ilia
to
help
me
out
there.
If
I
need
it
jane,
could
I
get
you
to
talk
with
wayming
a
little
more
in
depth
about
what
he's
doing
with
his
okr
see
how
we
can
kind
of
work
with
him
or
rely
on
him
a
bit
for
that.
E
I
can
his
his
okay
is
really
detailed
and
it
is
actually
quite
specific
around
you
know,
then
he's
he's
doing
it
within
our
region
with
a
couple
of
people
and
some
very
specific
cross-training,
but
I
can
certainly
have
a
chat
with
him
about
how
that
could
have
yeah
awesome
work
with
us.
Sorry,
I
haven't
had
enough
coffee.
C
A
A
A
C
A
A
A
But
I
just
spent
20
minutes
doing
it,
so
I've
got
that
disabled
right
now.
It
has
just
a
message
that
says
this:
for
this,
this
form
has
been
closed,
but
I'll
loop
in
I'll
make
sure
I'll
put
some
notes
in
that
issue.
I
made
that
has
the
results
and
then
I'll
share
that
amongst
the
team
and
say:
okay,
yeah,
here's
what
we
discussed,
here's,
what
we've
decided,
here's,
how
we're
going
to
continue
moving
forward.
Thank
you.
Everybody
who
participated.
It
was
really
appreciated.