►
From YouTube: Discussion on Working Groups - L&D Sessions
Description
Sid (GitLab CEO and co-founder), Stella (GitLab Chief of Staff) and Josh (GitLab Learning & Development) discuss Working Groups.
Learn more about Working Groups: https://about.gitlab.com/company/team/structure/working-groups/
A
Hi
everyone.
Today
we
are
going
to
be
talking
about
working
groups
in
the
ceo
learning
session.
My
name
is
josh
from
get
lab,
learning
and
development.
I'm
joined
here
with
sid,
get
lab
ceo
and
co-founder
and
stella
the
chief
of
staff,
so
we're
gonna
be
talking
about
working
groups
when
to
create
one,
how
to
do
it
and
what
are
the
benefits
and
I'm
going
to
ask
stella
the
first
question
so
stella?
What
is
a
working
group
at
gitlab.
B
Thanks
josh,
so
this
is
directly
from
the
handbook,
but
it's
an
arrangement
of
people
with
different
functions.
It
has
defined
rules
and
responsibilities
and
is
tasked
with
achieving
a
high
impact
business
goal.
It
depends
what
disbands,
when
the
goal
is
achieved
defined
by
exit
criteria,
so
git
lab,
doesn't
accurate
bureaucracy.
C
When
working
asynchronous
is
too
slow,
so
a
working
group
is
expensive,
like
you're
you're,
going
to
have
meetings
with
busy
people,
so
you
only
want
to
do
it
for
important
things,
but
some
important
things
can
be
done
asynchronous,
but
asynchronous
tends
to
take
more
time
than
synchronous.
So
if
you
have
an
important
problem
that
needs
to
be
sold
fast,
you'd
start
a
working
group
for
it
and
at
some
point
you
should
go
out
of
the
working
group.
C
C
Yeah
every
working
group
is
cross-functional,
so
will
be
different
functions
and
then
at
some
point
you
might
have
a
problem
where
kind
of
it
needs
to
go
up
the
chain
to
the
other
function
that
those
functional
chains
meet
in
the
e-group.
So
it's
important
to
have
an
e-group
member
on
board
in
in
case
there's
ever
a
need
for
something
like
that.
B
When
you
launch
these,
the
intent
to
disband
is
always
there
in
working
group
definitions,
but
for
some
companies
that
could
be
three
years
and
for
us.
I
think
we
look
at
this
as
something
that's
not
always
the
most
efficient
way
of
operating
isn't
something
we
want
to
have
for
extended
period
of
time.
So
it
would
be
a
rarity
to
see
something
go
past,
that
kind
of
quarter
or
two-quarter,
mark
and
and
other
pieces.
We
always
think
about
efficiency,
so
we
may
be
in
this
way
of
operating.
B
We
may
find
we're
halfway
through
the
quarter
and
find
better
ways
to
do
things
and
we're
kind
of
happy
to
iterate
or
revisit
that
model,
and
part
of
that
is
that
bias
for
async,
that's
mentioned
where
if
we
see
opportunities
to
cut
down
the
number
of
meetings,
we
will
do
it
if
we
find
ways
to
collaborate
better
through
an
issue
or
google
doc
will
iterate.
So
there's
not
a
quick,
always
use
process
and
there's
not
someone
kind
of
managing
the
same
wage
time.
A
That
makes
sense,
and
you
know
I
think
one
thing
when
I
first
started
working
at
gitlab-
was
that
we
don't
employ
project
managers
and
sid.
You
know,
why
is
that
the
case
and
and
what
are
the
benefits
of
not
having
project
managers.
C
Yeah,
I
wanna
one
caveat:
we
do
employ
project
managers
when
we
need
to
interface
with
other
organizations
that
is
super
complex
and
then
project
managers
are
real
benefit
there
and
that
can
be
customers
or
partners
or
anything
else.
Internally.
We
don't
have
project
managers
and
that's
because
we
want
to
have
a
lot
of
agency
and
responsibility
for
our
team
members,
a
project
manager
who
kind
of
asks
you
the
status
of
work
and
then
puts
it
in
a
tool
and
shows
it
to
other
people
and
makes
those
updates.
C
C
We
want
people
who
are
self-managing
or
a
manager
of
one
and
not
having
internal
project
managers,
allows
us
to
kind
of
keep
people
accountable
for
that,
because
when
you
get
project
managers,
the
first
people
who
will
leave
are
the
ones
who
are
really
good
managers
of
one
because
they
don't
need
a
project
manager.
A
That
makes
a
lot
of
sense,
yeah,
I've,
never
I've
never
heard
it
explained
that
way,
and
I
think
that
the
concept
of
the
dri
and
managers
of
one
you
don't
need
a
project
manager
because
we're
all
managers
of
one
and
dris
for
our
respective.
You
know
actions
and
activities.
A
B
Absolutely
so
there's
a
number
of
key
players,
I
think
two
to
highlight
are
the
facilitators.
This
is
the
person
organizing
the
meetings
making
sure
it
runs
on
time,
making
sure
things
that
are
followed
in
action.
It's
it's
playing
part
of
that
project
management
role.
The
other
piece
is
the
dri.
That's
it
highlighted
says
the
person
who
makes
sure
things
moving
and
is
responsible
for
the
ultimate
outcome
needs
to
make
sure
the
right
people
are
there.
B
Nothing
falls
through
the
cracks,
and
I
think
that
since
we
don't
have
that
kind
of
muscle,
because
we
don't
do
it
all
the
time,
the
dri
will
also
be
the
person
who,
if
we
find
out
that
there's
no
function
that
traditionally
handles
a
piece
of
work
that
person's
responsible
for
finding
out
who
will
be
responsible
and
that's
a
key
part
of
the
responsibility.
B
The
other
piece
is
the
working
group
members
and
making
sure
that
they're
aware
of
the
ask
for
them,
and
they
know
how
to
pull
other
people
in
as
needed
and
that's
going
to
vary
by
project
executive
stakeholder,
I
think
said
already
spoke
to
that.
That
kind
of
escalation
point
that
sponsor
that
person
who
can
represent
something
to
e-group
if
needed
and
be
a
tiebreaker
and
something
here
as
well.
Just
how
do
you
manage
itself?
B
A
C
Yeah
there's
some
great
features
in
gitlab.
Most
people
are
familiar
with
the
issue
tracker,
but
also
we
have
epic's
functionality
to
aggregate
that
on
a
higher
level.
There's
a
roadmaps
function
where
you
can
see
a
timeline
of
your
project
and
also
the
static
site.
Editor
might
be
handy
to
maintain
the
working
group
pages
and
other
handbook
pages
that
you
might
be
changing.
A
B
And
I
haven't
done
a
poll,
so
I
can't
speak
to
everyone
at
the
working
group
happening
at
the
moment,
but
some
things
I've
noticed
just
being
really
clear
on
time,
commitments
and
expectations
for
members.
People
go
into
it
and
some
come
with
expectations,
we'll
be
there
for
the
meeting
and
that's
their
participation.
Others
come
ready
to
roll
up
their
sleeves.
B
I
think
really
articulating
up
front
like
what
is
needs
to
be
achieved
and
what
is
each
person's
role
in
that
and
we
iterate
so
we'll
discover
and
change
over
time,
but
trying
to
help
people
understand
the
need
for
their
role
up
front
is
really
important
and
then
project
scope
is
part
of
that
as
well,
so
like
what
is
the
entirety
of
the
project
and
a
good
example
that
I
came
up
with
recently
in
the
working
group
that
I
was
part
of,
is
we
had
this
big
piece
where
marketing
was
really
key
and
there
was
someone
from
external
communications
in
the
room,
so
he
said
great,
like
you're,
in
charge
of
marketing
and
after
a
few
meetings
that
person
said.
B
Oh,
I
don't
think
I'm
really.
You
know
that
person
and
she
was
absolutely
right-
there's
probably
five
other
people
we
had
to
plug
in
to
make
that
work
and
15
by
the
end
of
the
project.
So
that's
a
proliferation.
You
don't
want
to
people
in
most
cases,
but
I
think
it's
really
important
to
kind
of
get
like
what
is
the
overall
scope
of
this?
Who
are
the
people
who
are
needed?
Let's
make
sure
we
engage
them
at
the
right
times
in
the
right
ways
and
help
them
understand
our
expectations
for
them.
B
B
So
you
do
this
when
you
need
them,
then
you
come
back
to
async
and
preference
for
like
lighter
communication
as
needed,
but
I
think
it's
adapting
that
process
for
different
groups
and
based
on
urgency
and
needs
dog
fooding
again
like
try
to
dog
food
when
you
can
there's
needs
for
sometimes
like
a
google
doc.
For
reasons
like
confidentiality
so
know
the
whole
arsenal,
I
shouldn't
say,
arsenal
but
know
all
your
options
for
tools
know
what
you
can
work
with
and
look
at
past
examples
of
what's
happened
with
projects.
B
B
There's
a
lot
of
people
interested
in
a
lot
of
projects,
there's
sometimes
limitations
on
how
you
can
share
it
could
be
passive
or
it
could
be
even
something
like
for
a
project
as
part
of
every
week
on
that
e-group
agenda
would
be
there
as
passive
languages
if
you're
really
interested
click
through
here
and
find
it.
But
you
never
wanna
under
communicate
with
folks
who
might
need
to
know
or
might
need
to
weigh
in.
A
Yeah,
those
are
all
great
points.
I
I
really
liked
how
you
you
know
talked
about.
You
know,
referencing,
what's
been
done
in
the
past
as
well
like
on.
I
know
on
the
working
groups,
handbook
page,
there's
a
lot
of
links
to
previous
examples
of
working
groups
to
reference.
So
that's
that's,
really
helpful
and
you
know
say
just
lastly,
here
you
know
we
we
try
to
be
transparent,
but
some
working
groups
handle
limited
access
information.
C
Yeah
as
transparent,
as
is,
as
is
reasonable
and
practical,
every
working
group
for
sure,
should
be
on
our
list
of
working
groups.
If
you
can't
give
any
more
information
about
the
work,
what
the
working
group
does
you
can
link
to
our
private
handbook,
where
you
can
elaborate
on
that?
If
it's
more
limited
than
that,
if
it's
a
limited
access,
then
you
can,
for
example,
work
in
a
google
doc.
C
We
have
a
system
of
code
names
in
gitlab,
so
if
you're
doing
something,
that's
not
public,
don't
name
the
working
group
exactly
what
you're
doing.
If
that's
confidential
you
can,
you
can
use
a
code
name
instead,
I
think,
for
the
success
of
the
working
group.
It's
really
important.
Anybody
else
can
quickly
see
what
the
working
group
is
about
you're
going
to
have
requests
to
non-working
group
members
over
time.
So
it's
important
than
that.
A
Great-
and
you
know
I
I
think
I
just
wanted
to
thank
you
all
for
your
time
and
really
deep,
diving
working
groups.
If
there's
anything
else
left
to
share
or
talk
about,
feel
free
to
throw.