►
From YouTube: Ops Backend Group Conversation (Public Livestream)
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
All
right,
everyone
I
think
it's
time
to
get
started.
So
if
you
want
to
head
over
to
the
dock,
you'll
see
a
link
to
the
slides,
I'm,
not
gonna,
run
through
them.
I'll
be
answering
questions,
but
I
do
have
a
audience.
Participation
slide.
So,
while
we're
talking
and
answering
questions,
please
take
a
look
at
slide.
4
I
really
need
your
help,
so
create
open.
Another
tab
go
to
LinkedIn
login,
look
at
slide.
4
pick
one
of
these
and
post
it
as
your
Linkedin
status.
A
A
Our
hope
is
to
continue
to
iterate,
but
the
goal
is
to
come
up
with
the
first
iteration
and
not
be
overly
ambitious
in
the
complexity
that
we
need
to
deliver.
So
it's
similar
to
I
feel
like
this
is
an
initiative
that
is
really
hard
to
deliver.
If
you
need,
if
the
goal
is,
you
know
a
humongous
spreadsheet,
with
lots
of
detail
every
level
and
so
on
and
so
forth,
so
we're
starting
small
the
gitlab
way
first
iteration
defining.
A
So
if
you
look
on
slide
9
defining
some
of
these
criterias
or
categories
is
one
of
the
harder
steps
to
start
and
I
feel
like
we
got
over
that
that
initial
hump.
So
with
those
in
mind,
the
next
goal
is
to
define
what
that
means
like
what
is
collaboration
in
an
engineering
role
and
then
start
to
work
on.
What
do
we
expect
from
a
junior
engineer
with
it?
Well,
not
in
our
case,
we
don't
have
junior.
B
A
Unrealistic,
not
not
a
lot
of
months.
How
about
that?
My
hope
is
to
deliver
it
by
so
this
initially
is
a
q1
goal
for
me.
So
if
I
want
to
be
ambitious,
it'll
be
by
the
end
of
the
month,
so
we'll
we'll
see
what
we
can
get
there,
but
it
is
a
really
great
initiative
and,
and
whatever
we
deliver
we're
gonna
continue
to
iterate
from
there.
A
A
A
Yeah
no
a
great
question,
so
the
key
distinction
is
the
pulse.
Survey
is
more
of
a
gut
check.
It's
three
questions
and
a
comment
box,
its
weekly.
So
in
a
sense,
it's
you
know
a
quick
check-in
every
week,
but
it
doesn't
have
to
be
driven
necessarily
by
a
specific
topic,
whereas
our
monthly
retrospective
I
want
the
teams
to
look
holistically.
Add
the
full
release,
you're
talking
about
team
dynamic
and
challenges,
there's
more
diving
into
the
topics
and
it's
is
very
actionable.
A
The
pulse
survey
is
something
that
I
used
to
keep
an
eye
sort
of
on
the
team
from
a
moral
standpoint
and
I
know,
that's
a
very
hard
thing
to
measure.
It
is
subjective,
but
that's
exactly
what
I'm
trying
to
measure
is
the
subjectivity
of
the
team
and
how
they're
feeling
so
I'm
focusing
on
three
areas.
How
do
they
feel
about
their
work
and
their
team?
How
do
they
feel
about
their
manager?
How
do
they
feel
about
the
company
and
the
aggregate
of
that
kind
of
gives
a
good
view
into
how
someone
is
feeling
about?
A
You
know
their
role
within
gitlab
and
if
they
leave
a
comment
which
I
really
love
to
see
and
appreciate,
that
helps
me
make
it
actionable
if
there's
something
that
we
can
change
or
iterate
through.
So
it's
been
like,
like
kudos
to
the
team
I'm
trying
this
MVC,
where
they
can
figure
back
in
and
the
monitor,
back-end
and
I
am
super
excited
every
week,
because
I
see
responses
and
that's
a
big
part
of
making
this
a
success.
If
no
one
responds
it's
really
hard
for
me
to
make
this
valuable.
So
that's
does
that
answer
your
question.
C
A
D
D
180
days
sounds
like
a
really
long
explain
before
a
first
commit,
so
so
I'd
love,
I,
love
to
you
know,
there's
some
interesting
story
behind
that
that
that'd
be
good
to
know,
but
then
the
other
aspect-
this
is
just
the
fact
of
you-
know,
I.
Think
I,
think
other
consumers
of
the
product
would
want
to
see
this,
like
you
know
how
fast,
how
fast
are
people
getting
involved,
particularly
for
fast-growing
organizations
that
would
be
using
get
alive,
yeah.
A
No
great
question
Christopher
I
I
have
not
but
I
will
I
will
take
an
action
item
to
talk
to
someone
about
this
in
product
and
I.
Do
agree
with
you
like.
The
reason
I
like
this
measure
is
that
it
does
give
us
a
sense
of
how
complex
is
our
product.
How
easy
it
is
to
set
up
your
local
environment,
how
easy
it
is
to
go
through
during
your
review
talking
to
a
maintainer
getting
something
merged,
even
if
this
is
the
simplest.
Mr,
are
actually
like
it's
actually
most
interesting.
E
A
No
great
question
Olivia:
this
is
distinctly
different.
The
first
mr
needs
to
be
a
contribution
to
the
product.
So
that's
what
we're
measuring
and
the
idea
is
taking
a
new
engineer
through
setting
up
everything
they
need
to
push
a
small
change
to
production
or,
in
our
case,
getting
it
merged
to
master.
C
F
I
would
like
to
jump
in
on
that,
because,
even
though
I'm
not
a
manager
anymore,
that
was
raised
a
lot
ring
and
boring
insecure.
What
we
did
was
a
bit
different.
We
only
counted
the
first
Direction
item
so
only
feature
if
you
date
the
end
book.
We
did
then
turned
out
as
the
first.
Mr
does.
It
make
sense.
Yeah.
A
Yeah,
no,
that's
that's
absolutely
right!
Philippe.
The
goal
is
to
do
something
within
the
product
and
it
doesn't
have
to
be
implementing
a
feature.
It
could
just
be
fixing
a
small
bug
or
getting
something
into
you
know.
C,
II
or
EE,
but
ya
know
we're
not
trying
to
track
the
the
handbook
merges.
That's
not
the
first,
mr
that
we're
targeting.
C
So
verbalize
this
and
then
write
it
down
you,
you
started
with
slides
talking
about
a
team
update
and
I,
see
a
lot
of
additions
and
growth
of
the
team.
Your
purview
is
quite
large,
covering
C,
ICD,
ops
and
secure
defend
at
the
moment,
but
which
ones
are
the
places
where
you're
most
concerned
about
where
we
are
in
hiring
ramp.
Yeah.
A
A
couple
of
teams:
we
we've
had
a
little
bit
of
a
challenge:
hiring
for
package.
That's
a
new
team,
and
typically
the
challenge
here
is
you
want
to
you
want
to
build
a
new
team
from
scratch?
It's
really.
You
have
to
be
very
methodical
in
your
first
hire.
You
need
someone
who's
capable
of
starting
things
on
their
own,
without
too
much
direction,
and
so
on
and
so
forth.
A
We
we
shifted
direction
because,
like
in
the
gate
lab
way,
this
wasn't
necessarily
working
very
successfully
so
kudos
to
Darby
he's
been
kind
of
lending
me
a
hand
and
doing
a
great
job.
So
he
split
our
efforts
so
that
I
can
focus
on
hiring
an
engineering
manager
and
he's
able
to
focus
on
hiring
engineers.
The
other
thing
we
did
is
that
we
took
on
the
responsibility
within
the
release
team.
A
So,
instead
of
just
saying
that
we
don't
anyone
for
package,
what
we're
doing
is
that
we
can
start
to
prioritize
some
of
that
work
within
release
engineering,
and
that
gives
us
a
way
to
be
able
to
deliver
things
for
package
without
necessarily
having
the
gate
of
hiring
a
team,
for
it
be
a
requirement
if
that
like,
if
that
makes
sense,
I
think
I
said
it
weirdly.
But
you
know
what
I
mean
and
then
the
next
one,
the
next
team
and
this
one
falls
into
my
ops
sub
department
is
serverless.
A
This
is
again
a
new
area
Jerris
doing
a
fantastic
job.
Dylan,
similarly,
is
playing
a
dual
manager
role.
Daniel
is
a
great
supporter
on
the
product
side,
but
we
are
building
a
team
from
scratch
and
we're
trying
to
find
folks
with
some
of
that
experience.
But
the
intersection
of
service
and
rails
is
very,
very
small.
So
again
we
are
broadening
our
efforts
and
trying
to
get
someone.
A
All
right,
while
I'm
waiting
for
a
question,
if
you
joined
later,
please
go
to
slide
4,
open
a
LinkedIn
tab
and
take
a
look
at
one
of
these
bullets
posted
as
your
status.
This
really
really
really
helps.
I
know
it
seems
like
a
minimal
thing,
but
gitlab
brand,
and
our
awareness
is
something
that
we
need
to
work
on.
It
amazes
me
when
I
go
to
meetups
or
talk
to
you
engineers
around
town.
A
They
like
we
have
such
a
compelling
story
to
tell,
but
a
lot
of
people
have
not
heard
it
so
I
really
encourage
each
of
you.
This
is
a
great
way.
We
are
a
diverse,
you
know
company,
and
we
have
plenty
of
networks
to
tap
into
so
I
would
really
appreciate
if
you
could
go
into
your
linkedin
and
post
one
of
these.