►
A
B
Like
I
said
my
name's
austin,
I'm
also
a
product
designer
here
at
git
lab.
We
both
work
under
the
same
stage
and
manage
just
with
different
groups,
and
I
just
want
to
share
a
little
bit
of
my
perspective
to
come
from
a
different
type
of
working
environment
coming
into
get
lab.
While
I
was
still
semi-fresh
in
my
mind,
then
about
a
half
year
in
now,
cool.
A
B
B
That
was
something
I
was
not
used
to,
I
would
say
in
the
past
it
was
usually
one
designer
to
one
product
just
for
the
enterprise
apps
that
I
was
designing
for
and
in
some
sense
there
was
like
a
greater
accountability
for
the
product
now
because
there
are
so
many
more
eyes
on
it
and
so
many
more
opinions,
whereas
before
I
was
just
like
my
opinion
and
then
the
front
end
development
team-
and
that
was
about
it
so
things
like.
Maybe
how
do
we
structure
the
navigation?
B
We
have
to
get
a
lot
more
people
to
agree
on
the
direction
for
that,
as
opposed
to
what
I
was
used
to
before.
I'm
like
no,
let's
just
like
change
it,
because
I
have
an
opinion,
and
I
just
want
to
change
things
so
getting
used
to
not
still
getting
like
handshakes
from
everybody
that
for
approval,
but
rather
looking
to
show
the
direction
and
then
helping
advocate
for
why
that
direction
makes
sense
was
definitely
a
different
experience
for
sure.
Have
you
experienced
anything
similar
in
that
regard?.
A
Yeah
yeah.
I
think
that
that
that
makes
a
lot
of
sense.
The
fact
that
we
are
working
on
things
which
potentially
touch
lots
of
different
teams
and
stage
groups
means
that
the
amount
of
transparency
that
we
have
around
what
features
we
build.
What
tweaks
we
make
all
that
sort
of
stuff
is
really
vital
and
by
being
transparent,
it
means
that
people
become
aware
of
the
changes
that
we
want
to
make
because
everyone
can
contribute.
A
I
think
you,
you
brought
a
really
interesting
point
up
in
that,
while
we
don't
need
to
find
consensus,
it's
definitely
within
our
interest
to
be
advocating
and
selling
the
the
point
of
view
or
perspective
that
you
have
to
other
people
and
communicating
that
as
transparently
as
as
as
possible,
also
in
a
way
which
is
asynchronous
as
well,
so
whether
it
comes
to
sort
of
talking
about
your
direction.
Recording
videos
writing
comments,
posting
in
slack.
B
Gotten
comments
like
hey.
What
are
you
doing
here?
I'm
doing
something
similar
in
settings
and
I'm
trying
to
figure
out
this
pattern
or
I've
seen
like
our
director
come
in
and
provide
some
thought
on
like
the
flow
of
a
user's
journey,
and
that's
not
something
that
I
was
used
to
in
the
past
and
it's
kind
of
like.
Oh,
I
wasn't
ready
to
share
my
idea
yet,
but
ultimately
it's
like
trying
to
surrender
some
of
that
pride
to
know
that
everybody
means
well
and
we're
trying
to
reach
the
best
product
together.
B
A
The
the
term
I've
heard
for
that
experience
that
you
mentioned
within
our
handbook
is
called
like
having
a
low
level
of
shame,
so
basically
getting
things
out
there
with
a
moderately
low
level
of
fidelity
so
because
some
feedback
is
better
than
no
feedback
and
you're
not
getting
any
feedback
whatsoever.
If
it's
stored
away
somewhere
on
your
your
local
computer.
B
Otherwise,
you're
just
keep
like
creating
this
like
ocean
of
feedback
that
can
become
like
insurmountable.
You
might
just
get
too
many
thoughts
on
this
flow.
The
visual
hierarchy,
the
information
architecture,
the
tech
writing
when
really
you're
like
hey.
I
just
wanted
to
know
like,
should
this
be
on
this
page
at
all,.
B
B
A
So
that's
like
really
I'd,
say
like
being
a
good
host.
When
it
comes
to
sharing
your
content,
you
can
think
about
providing
an
environment
where
people
our
are
responding
to
the
things
you
want
them
to
respond
to
using
the
same
sort
of
language
and
focus
on
the
sort
of
areas
that
are
important
to
you
at
that
time.
They
can
respond
outside
of
it,
but
providing
that
mapping
of
where
you're
looking
for
feedback
is
generally
great
and
then
they
can
add
additional
things
on
top
of
it.
If
needs
be.
B
Yeah
100
something
else
that
was
definitely
a
welcome.
Change
was
the
amount
of
like
learning
that
is
demonstrated
by
the
team
and
then
the
response
being
that
it's
celebrated
openly.
That's
been
very
encouraging,
so
we
have
monthly
showcases
of
like
what
different
stages
and
groups
are
working
on,
which
is
like
something
I'd
love
to
see.
B
You
were
supposed
to
be
the
one
like
giving
me
opinions
and
to
see
people
like
humble
themselves
and
share
like
I
am
also
learning
and
looking
for
feedback
too,
even
though
I'm
a
staff
or
a
senior
or
whatever.
It
might
be,
that
just
kind
of
helps
reinforce
that,
like
we're
continuously
learning
here
and
we
celebrate
all
the
learnings
along
the
way.
B
A
B
Yeah
it
was
like
where
I
came
from
everything
was
celebrated
in
the
point
of
like.
Did
you
hit
your
kpis?
What
metrics
did
you
hit?
Did
you
get?
Did
you
reduce
time
on
task?
There
wasn't
a
whole
lot
of
room
to
say
this
feature
really
sucked,
and
we
see
that
in
our
user
base,
and
this
is
how
we're
going
to
make
it
better,
and
this
is
why
we
like
that
change,
or
even
just
like
I'm
saying,
like
senior
leaders
showing
that
they
too
are
seeking
feedback.
You
never
heard
those
people
looking
for
feedback.
A
Okay,
so
if
we
take
a
look
at
like
your
your
previous
organization
and
the
model,
there
was
more
junior
designers,
they
they
they
listen
to
the
feedback
of
of
the
senior
designers.
The
senior
designers
can
provide
like
direction
and
all
this
sort
of
stuff
in
a
in
a
new
sort
of
more
transparent
environment.
What's
the
relationship
between
designers
at
different
levels,
then.
B
I
don't
know
if
I
can
give
an
exact
like
tier
of
how
the
relationships
look,
but
I
can
pull
an
example
that
I
thought
was
a
really
great
way
to
be
transparent
through
collaboration
pedro
one
of
our
staff
designers.
He
pulled
together,
one
of
our
most
popular
features
in
gitlab,
the
merge
request
page
and
he
articulated
all
the
different
states
visually
and
then
created
this
asynchronous
issue
to
collect
feedback
from
all
designers,
not
just
from
the
other
staff
designers,
not
the
other
senior
product
designers,
not
just
the
vpn
directors.
B
B
So
I
learned
a
number
of
things
I
learned
like
the
architecture
of
the
page,
I
learned
different
edge
cases
and
then
I
also
learned
what
other
designers
were
critiquing
on
the
page,
because
it
was
just
an
open
form
of
like
hey.
We
need
to
make
this
better.
There
hold
nothing
back.
Let's
all
talk
about
it.
It
was
super
interesting
to
see
the
different
perspectives
of
people
that
have
been
here
a
long
time,
the
ones
that
were
newer
and
just
getting
to
see
that
collaboration
was
really
really
helpful.
A
Yeah
yeah,
that's
that's,
definitely
a
great
point
to
bring
up.
I
think
pedro
did
a
great
job
and
experimenting
with
the
format
as
well
as
presenting
and
being
such
a
good
host
for
collecting
that
feedback
as
well.
And
what
I
noticed
with
that
with
that
exercise
is
how
different
everyone
else
thought
about.
B
I
think
that's
just
one
of
the
great
demonstrations
of
how
transparency
really
helps
make
gitlab
a
better
product.
I
would
imagine
like
my
previous
teams
that
would
not
have
been
as
celebrated
or
even
probably
represented
in
terms
of
a
mechanism
for
collecting
feedback
one
because
it
might
be
too
challenging.
B
We
worked
on
such
different
products
that
it's
sometimes
hard
to
really
understand
the
context,
since
we
all
work
in
gitlab,
it
kind
of
helps
that
we
have
some
awareness
of
the
rest
of
the
product
verge
request
being
one
of
the
more
popular
ones,
but
still
like
you
know,
going
out
and
just
listening
that
feedback
and
then
also
taking
action
on
it
and
showing
how
it's
making
progress.
I
mean
it's
it's
the
exact
example
of
being
transparent
in
the
workplace
and
helping
others
grow
at
the
same
time
as
we're
progressing
the
product.
A
Definitely
definitely-
and
I
think
this
also
sort
of
alludes
to
another
type
of
transparency
which
I
I
was
very
new
to
when
joining
git
lab.
So
I
had
user
research
sessions
user
testing
sessions
in
previous
jobs.
However,
I've
never
really
designed
transparently
in
issues
just
which
can
be
viewed
by
users
at
any
time,
viewed
or
commented
on
on
at
any
time
as
well.
So
it's
like
almost
like
you're
designing
with
an
audience
which
has
its
challenges,
but
also
has
this
tremendous
number
of
opportunities
was
as
well.
I
was
wondering
whether
you've
noticed
anything
around
that.
B
Yeah
I
had
a
funny
instance
happened
last
week
we
have
noticed
that
in
some
of
my
group,
some
of
our
customers
are
responsible
for
taking
screenshots
of
their
settings
and
time
stamping
them.
I
was
thinking,
yes,
you
know
a
feature
that
I
experience
in
my
day-to-day
life
that
is
similar
to
this
is
using
time
machine
on
my
laptop,
where
I
can
like
go
back
to
specific
snapshots
of
my
laptop
and
it's
just
like
jumping
back
in
time.
Yeah
man
that'd
be
really
cool
if
we
had
that
in
gitlab.
B
B
That's
great,
I
mean
just.
I
never
thought
I
would
ever
see
that
issue
ever
I
mean
I
was
like
working
on
it,
so
I
was
just
like
trying
to
document
my
thoughts
as
I
was
going,
but
as
I
got
a
good
laugh
out
of
just
a
community
person
just
throwing
a
comment
on
there
and
I'm
sure
they're
getting
notifications
now
every
time
that
I
add
designs
to
it,
change
the
title.
B
I
took
off
time
machine
off
the
title
I
didn't
want
to
be
there,
that's
hilarious,
but
yeah
I
mean
I
think
it's
been
cool
to
be
able
to
see
community
contributions
for
sure
and
get
to
champion
those
ideas.
I
think
that's
been
very
fun
to
not
only
be
a
part
of
the
gitlab
team,
but
also
celebrate
the
people
and
the
greater
gitlab
community
that
want
to
make
the
product
good
as
well
and.
A
I
suppose
that's
where,
like
our
value
of
transparency,
came
from
originally
was
our
open
source
history
and
the
requirement
for
transparency
in
order
to
make
open
source
happen.
So
I
think
yeah
having
the
community
around
is
just
is
so
valuable
and-
and
you
can
see
with
even
with
situations
like
yours,
where
people
are
sort
of
just
joking,
a
little
bit,
there's
a
huge
opportunity
for
like
serendipity
of
people,
just
stumbling
across
things,
adding
their
thing
and
and
just
seeing
what
what
emerges
at
the
back
of
it.
B
Yeah
yeah,
I
think
an
unintended
aspect
of
transparency
is
even
in
our
hiring
process.
When
I
was
going
through
it,
I
was
able
to
go
into
the
backlog
of
the
team
that
I
was
interviewing
for
and
see
the
problems
that
they
were
working
on
and
talk
about
those
problems.
In
my
interview,
so
often
when
I
interviewed
other
companies,
you
don't
give
a
very
vague
understanding.
B
You
kind
of
like
get
pitched
the
problem
space
of
the
product,
maybe
a
little
bit
of
like
the
specific
features
or
areas
you
work
on,
but
it's
really
hard
to
understand
what
that
means.
When
you
can't
like
see
it,
you
can't
like
test
the
product,
and
so
it
was
really
insightful
for
me
to
be
like
okay,
these
are
the
problems.
I've
worked
on
day
to
day.
I
can
even
like
try
and
make
myself
work
in
this
way,
so
I
try
to
find
an
idea
come
up
with
a
design
for
it.
B
A
Yeah
yeah,
that's
true,
because
the
way
that
information
is
structured
within
gitlab,
the
way
that
we
work
and
so
on
transparent
for
everyone
to
see,
but
the
content
that
you
talked
about
and
having
a
like
a
detailed
understanding
of
what
is
the
problem
space.
I
think
that's
that's
a
really
good
point.
They
bring
up
so
top
tip
for
for
anyone.
Who's
looking
to
join
git
lab.
Take
a
look
at
your
your
group
and
what
they're
working
on
and
see
whether
you
can
you
can
get
anything
interesting
from
there
understand.
A
B
Just
show
everything
that
you
can
like
if
you're
ever
in
a
file,
make
sure
it's
open.
The
worst
is
when
someone
says
like
I
can't
see
this
link
so
always
make
sure
your
figma
files,
your
google
docs,
your
mural
boards,
your
whimsical
pages,
your
gitlab
issues,
unless
it
should
be
confidential.
There
are
those
unique
circumstances
where
maybe
we
talk
about
customer
information,
we
don't
want
to
expose
that,
but
always
have
things
default
to
open
and
then
think
about
how
you
can
expose
more
of
your
workflow
into
a
transparent
way.
A
That's
yeah,
that's
a
great
piece
of
advice,
challenge
your
assumptions
within
your
workflow
and
see
how
you
can
make
them
more
transparent.
Sometimes
they
may
not
work,
but
it's
at
least
worthwhile
trying
to
experiment
at
least
cool.
Exactly
austin
really
appreciate
your
time.
Thank
you
very
much
have
a
good
day.