►
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
B
Yeah
I'm
Ben
I
founded
our
company
a
few
years
ago
and
I
felt
like
reaching
out
because
we
have
a
lot
of
similarities
and
we
sort
of
look
up
to
get
lab4
in
a
lot
of
ways.
We're
trying
to
do
everything
distributed
commercial,
open
source
and
I
think
we're.
So
we
try
to
model
ourselves
after
you
all.
So
it's
great
to
have
a
conversation
yeah,
and
the
first
question
is
that
you
have
a
lot
of
radically
open
ways
of
operating.
Can
you
name
a
few
of
them
most
sort
of
impactful
transparency,
policies
or
ways?
A
Thanks,
oh
thanks
for
the
compliment
and
I
think
you're
doing
great
are
building
a
community
that
isn't
easy
and
f2
is
one
of
the
most
biggest
one.
We
see
out
there
so
well
done,
and
thanks
for
doing
this
Cole
with
me
most
impactful
one
definitely
has
been
our
handbook.
It's
allowed
us
to
skills,
allow
people
to
join
the
company
not
having
to
ask
a
lot
of
company
questions
to
others.
Yeah.
Our
people
universally
report
is
like
if
I
ask
questions
that
people
are
so
helpful
and
then
I
should
start
asking
like
okay.
A
How
many
questions
did
you
ask
compared
to
your
last
job,
because
it's
probably
a
lot
less
people
are
not
as
tired
of
questions
here,
because
a
lot
of
it
was
written
down
and
the
other
big
impact
has
been
hiring
like
the
handbook
allows
people
to
see
how
we
operate
and
if
they
like
it,
they
can
opt
into
that.
So
that's
been
a
enormous
benefit.
A
A
B
A
Of
it
is
a
different
style
guide,
although
in
the
handbook
style
guide,
we
prefer
to
the
doc
style
guide,
it's
a
completely
different
team
for
documentation,
it's
written
by
developers
and
then
there's
a
documentation
team
that
kind
of
reef
actors
it
and
there's
all
the
other
things
for
the
handbook.
It's
written
by
leadership
and
basically
everyone
in
the
company
and
then
there's
only
a
single
person,
brain
sex
and
who's
who's,
doing
work
on
like
a
refactoring
it
and
fixing
broken
things.
Although
we
might
intensify
that
a
bit
but
different
people
different
purposes,
different
repos.
B
A
Lots
of
lessons
I
think
a
few
things
that
want
to
highlight
and
like
it's
very
counterintuitive,
to
work
handbook.
First,
so
we
discovered
you
have
to
be
handbook
first,
like
documenting
stuff.
After
the
fact,
it's
not
gonna
happen,
people
have
busy
lives.
So
if
you
make
a
change,
it
should
be
changed
in
the
handbook.
That
is
the
way
you
communicate
a
change.
If
not
changing
the
handbook,
it's
not
changed.
You
cannot
ask
anybody
to
do
something.
That's
not
in
that
book.
A
That's
hard
and
forcing
that
is
a
big
part
of
my
life,
so
yeah
trying
to
find
different
ways
to
enforce
that.
But
it's
certainly
not
something
that
happens
organically
and
that
that's
what
you
see
it
every
other
company
that
the
handbook
becomes
still
because
people
start
doing
other
things
to
communicate
changes
I
think.
As
far
as
for
working
asynchronously,
our
top
three
values
help
there
there's
our
results.
A
A
Transparency
helps
because
you
don't
have
to
like
ask
for
access
to
stuff.
Most
of
the
stuff
is
open
either
to
the
public
or
within
the
company,
and
iteration
means
scoping
things
down
and
to
the
smallest
possible
thing.
Then
shipping
that
really
quickly
and
that
helps
because
if
you
take
small
steps,
you
don't
need
to
coordinate
with
as
many
people,
because
it's
a
small
step,
if
you're
off
in
the
wrong
direction,
you
can
correct
on
the
next
step.
Well,
if
you're
gonna
do
a
nine-month
plan,
then
you
better
coordinate
with
everyone.
B
A
We
we
do,
but
we
use
our
regular
tools
to
do
the
no
more
communication,
so
I
think
it's
really
important.
If
your
promote
that
you're
intentional
about
informal
communication,
we
have
different
ways
in
which
we
simulate
that
yeah
do
a
group
conversation
every
day
or
it's
still
about
work.
It's
a
certain
department
that
has
a
presentation,
but
instead
of
presenting
it,
it's
just
Q&A
for
25
minutes.
We
do
breakout
calls
where
you
sit
with
a
group
of
people.
You
get
a
you
get
a
question
to
talk
about
today.
A
We
also
encourage
people
to
do
coffee
chance,
so
I
had
one
yesterday,
new
team
member,
just
you
can
plan
a
coffee
chat
without
anybody.
A
coffee
call,
including
with
me,
and
we
make
people
do
10
of
those
so
that
they
get
used
to
the
fact
that
you
don't
need
an
agenda.
You
can
just
send
anybody
a
calendar
invite
to
plan
25
minutes
to
just
hang
out
together.
Maybe
talk
about
work,
maybe
not
talk
about
work.
It's
all
fine!
A
It's
the
kind
of
a
water-cooler
conversation,
and
the
last
thing
I
want
to
highlight
is
the
team
social,
where
you
hang
out
with
your
direct
team
for
like
50
minutes
every
week
on
a
fixed
point
in
time,
and
it's
just
because
in
remote,
you're
so
efficient
that
there's
not
a
lot
of
like
time
waiting
for
the
meeting
to
start
and
things
like
that,
so
you
have
to
create
that
space.
We
save
a
lot
of
time
by
not
commuting.
B
Cool
yeah:
this
is
all
helpful.
This
is
all
you
know,
we're
we're
patting
down.
You
know
we're
up
to
12
people
now,
but
it's
a
great
planning,
for
you
know
growth,
and
it's
it's
useful
to
hear
about
all
this.
The
so
you're
built
on
on
Rails
you're,
an
important
open
source
company
and
built
on
like
an
important,
open
source
project.
How
is
how
is
your
relationship
with
the
framework
itself
and,
like
the
other,
open
source
components
of
your
company
evolved
over
time
like?
A
So
I
think
we're
mainly
of
consumer
else.
We've
not
contributed
back
along,
but
we
have
contributed
back
here
and
they're,
mostly
like
bug,
fixes
and
things
like
that.
We
love
Ruby
on
Rails,
because
it
allows
us
to
go
really
really
fast.
A
lot
of
complex
business
logic.
Ruby
is
a
great
language
to
implement
and
test
that
in
the
by
no
means
it's
frills
only
where,
for
example,
hiring
for
go
engineers
and
if
you
look
at
get
lab
architecture,
there's
lots
of
different
components
to
it.
A
There's
a
lot
of
other
open
source
graph
Anna
from
media's,
but
there's
also
stuff.
We
spun
out
ourselves
like
Italy
it
layer
but
trying
to
use
open
source
and
trying
to
use
the
right
language
like
everything.
That's
there's
a
lot
of
performance
and
multi-threading.
We
tend
to
write
and
go
like
get
lab
workhorse
and
things
like
that,
but
a
rails
app
is
has
most
of
like
a
complex
functionality.
It's
not
super
performance
sensitive!
It's
just
a
matter
of
managing
all
that
complexity,
and
it's
been
amazing
and
we've.
B
Yeah
that
kind
of
looks,
like
you
know,
possibly
a
view
into
our
future
as
we
as
our
complexity,
naturally
evolves
and-
and
we
just
have
to
do
new
things
and
so
yeah.
It's
always
kind
of
cool
to
check
out
what
URL
to
because
it
kind
of
Maps
well
to
our
articles
and
and
what
we
want
to
do.
How
the?
How
is
the.
B
So
you
know,
for
example,
like
a
community
got
gitlab
calm
to
the
sort
of
self-contained
self
and
developer
community
and
stuff
yeah,
just
like
open-ended
like
any,
where
we're
sort
of
like
just
beginning
to
embark
in
that
net
phase.
Any
high-level
advice,
as
we
start
to
think
about
this
in
terms
of
how
it
plays
with
our
our
business
or
open
source
strategy,
anything
cetera,
yeah.
A
A
A
Think
building
communities
in
companies
is
hard
and
companies
are
reluctant
to
pay
for
that.
Yeah
I
do
think
that
there
is
a
huge
skill
gap,
most
companies,
where
it's
not
clear
what
skills
people
have
and
snoc
and
there's
not
it's
hard
to
uplevel
them,
and
that's
that's
where
you
do
an
amazing
job
on
the
internet
way,
but
all
the
great
content
you
produce.
A
A
B
Yeah
yeah
that'll,
make
sense,
I
think
the
we're
trying
to
let
the
market
pull
us
in
the
right
direction
and
we're
still
like
you
know
a
little
bit
out
from
lock
being
locked
into
too
much.
So
it's
it's
really
nice
to
hear
that
or
I
don't
know
any
signal.
We
can
get
I
think
at
this
point.
It
is
helpful
in
a
map
and
that,
as
as
we
as
we
as
we
navigate
it
so.