►
From YouTube: Developing software engineers to catalyze the world’s tech ecosystems - GitHub Universe 2018
Description
Brice Nkengsa, Co-Founder & Director of Engineering (Andela), Charity Majors, Cofounder & CEO (Honeycomb), and Vivek Ravisankar, CEO (HackerRank) join a panel hosted Jenny Fielding,
Managing Director (Techstars).
The panel discusses developments around the globe & efforts to expand learning and development opportunites beyond the heretofore traditional centers of technology.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
A
Many
of
you
guys
know
our
accelerator
programs
we've
invested
in
over
2000
companies,
so
massive
portfolio
and,
as
you
can
imagine,
this
topic
is
near
and
dear
to
to
my
heart
and
to
everyone
at
all
of
our
portfolio.
Companies
would,
we
think
about
scaling
and
we
think
about
developing
talent
globally.
So
super
excited
to
have
this
incredible
group
of
companies
and
founders
here
to
talk
a
little
bit
about
their
experiences,
so
I'm
gonna.
Let
them
introduce
themselves
so
Bryce,
hi.
A
Well,
thank
you
guys
so
much.
This
is
awesome
to
have
you
so
I'd
like
to
start
talking
about
skills
and
we'll
start
with
you
Bryce
and
around
and
Ella,
and
so
that
we
know
that
increasingly,
innovation
is
everywhere
and
especially
on
the
African
continent.
So
Bryce,
can
you
tell
me
a
little
bit
more
about
the
ways
that
and
Ella
is
developing
kind
of
the
next
generation
of
software
engineers
in
Africa
right.
B
So
Aaron
dela
we
build
distributed
high-performing
engineering
teams
with
talented
developers
on
the
African
continent,
so
we
recruit
talented
people
with
high
problem-solving
skills
and
put
them
in
a
learning
environment
where
they
develop
their
technical
and
soft
skills.
We
put
a
big
emphasis
on
soft
skills
because
we
all
know
that
good
engineers
don't
work
in
a
vacuum.
You
altima
t
end
up
working
on
a
team
and
you
have
to
collaborate
with
people.
You
need
to
collaborate
with
marketing
teams,
product
teams
and
order
divisions
within
an
organization
in
order
to
build
great
products.
B
A
D
Sure
so
our
mission
is
to
match
every
developer
to
the
right
job,
with
the
driver
being
skill
over
pedigree,
so
it
shouldn't
matter
what
school
you
went
to
which
company
you
worked
at
before
what
matters
is,
do
you
have
the
skills
to
do
the
job
or
not?
So
we
do
a
lot
of
analysis
in
terms
of
what
kind
of
skills
do
companies
want.
Where
are
they
hiring
from,
and
we
actually
did
this
really
cool
analysis
of?
Where
are
the
high-performing
algorithm
problem-solving
folks
are
there
and
the
highest
weighted
we
got
was
from
Wyoming
from.
A
D
D
The
data
it
was
after
we
actually
did
the
data
we're
also
starting
to
see
customers
open
up
a
lot
of
offices
in
Amsterdam
like
in
the
Dutch.
You
know
when
you
go
to
booking
comm
uber
has
open
an
office
drop
box
open
an
office,
I
mean
there,
so
the
immigrant
program
is
so
strong
and
so
powerful
that
they
are
able
to
attract
talent
from
across
the
globe.
You
know
if
you
go
to
their
one
of
our
customers
and
if
you
enter
booking.com
office,
it's
like
watching
an
Olympic
ad.
D
Think
the
other
part
is
the
schools.
As
you
know,
the
whole
idea
of
I
think
people
what
people
call
as
non-traditional
developers-
I
don't
like
the
term,
but
you
know
that's
that's
the
best
way
to
represent,
which
is
people
who
didn't
have
like
a
great
college
degree,
but
for
graduating
from
boot
camps.
You
know
different
schools
that
you
probably
don't
don't
go
to.
So
that's
that's.
A
lot
of
those
are
like
really
strong
ecosystems
that
are
actually
increasing
the
supply
of
developers
in
the
world
right
now.
Okay,.
B
Campuses
in
Africa
we've
created
the
Angela
learning
community,
where
we
engage
over
10,000
learners
and
aspiring
software
developers,
and
we
push
out
content
to
them
all
the
time,
and
we
also
have
regular
meetups
at
our
locations
where
they
get
mentor
mentorship
from
Angela
developers
and,
as
effect
was
mentioning
also
in
Africa.
There's.
B
A
lot
of
up-and-coming
developer
groups
like
Google
dev
groups
and
Facebook
circles
are
very
prominent
in
Africa
in
Nigeria,
in
Kenya
and
Uganda,
and
there's
also
a
bunch
of
new
dev
groups
that
are
created
by
locals,
like
for
loop,
taking
pink
and
a
bunch
of
others
that
are
really
about
mentoring
and
getting
more
and
more
people
to
get
involved
in
technology.
How.
B
C
Unix
I
learned
Linux
by
reading
other
people's
badge
history
files,
like
computers,
aren't
hard
I
think
what
I'm
concerned
about
is
the
way
it
feels
like.
The
industry
is
increasingly
trying
to
professionalize,
which
is
good
in
a
lot
of
ways.
You
know
having
safety
standards,
you
know
being
more
like
real
engineers,
but
it
concerns
me
that
people-
you
know
like
me
who
are
liberal
arts
majors
and
who
just
like
messing
around
it's,
it's
creating
a
bar,
it's
creating
a
bar
with
you
know
like
so
they
say
about
hair
salons.
C
A
That's
a
great
lead-in
to
what
I
wanted
to
ask
you
about
which
is
really
cultivating
people
that
don't
necessarily
have
the
resume
the
pedigree,
the
education
that
checks
all
the
boxes.
How
are
you
at
home
tell
us
a
little
bit
more
about
honeycomb
and
how
are
you
kind
of
working
on
that
framework?
Well,.
C
C
Now
you
might
think
that
this
requires
you
know
best
in
the
world
engineers,
but
I.
Two
things
a
you
know:
the
computer
problems
are
never
the
hard
problems
its
product
market
fit,
and
all
these
other
problems
that
are
the
heart
pumps
and
be
I.
Think
that
is
important
to
remember.
The
great
teams
aren't
always
built
up
of
the
greatest
engineers.
C
It's
my
job
to
open
the
door
wider,
to
look
to
try
and
hire
people
based
on
their
skills,
their
strengths,
not
lack
of
weaknesses.
You
know
you've
been
in
an
interview
when
everybody
just
like
quizzing
you
to
see
where
you're
weak.
That's
not
what
you
want,
what
you're
looking
for.
So
we
always
ask
people.
What
can
we
ask
you?
What
can
we
do
in
the
interview
so
that
we
get
to
see
you
at
your
best?
C
C
Shot
yeah
and
I'm
just
like
this
should
be
super
standard,
but
like
you're,
not
you're,
not
hearing
people
for
lack
of
weaknesses,
cuz,
nobody
has
lack
of
weaknesses,
you're
hiring
a
team
to
complement
each
other
and
it's
more
important
for
managers
to
know
their
team's
and
know
what
elements
their
team
is
lacking.
What
strengths
they
need
to
add
to
make
the
team
stronger
unit
than
than
it
is
to
like
screen
for
people
who
are
this
good
at
data
structures
and
algorithms
like
that?
Just
does
make
any
sense.
I'd
love.
D
No
I
I
fully
agree.
I
think
you
know
one
of
the
things
that
you
know
we
have
been
even
trying
to
say
is:
how
do
you
get
the
best
version
of
the
candidate
in
an
interview?
An
interview
right
now
is
sort
of
designed
to
spook
you
or,
like
you
know,
here's
a
guard,
shot
question
that
you're
not
able
to
answer
and
they're,
like
a
bunch
of
reasons
for
that
right
from
the
questions
right
from
the
setup
like
how
many
people
developers
actually
write
code
on
a
whiteboard
on
a
day-to-day.
D
Right
exactly
and
but
the
interview
set
up
like
there
is
a
bunch
of
things
that
are
not
right
with
the
interview
process,
which,
which
inherently
makes
it
more
biased
in
the
process
and
then
also
defining.
What
are
the
actual
skills
that
you
need
in
a
job
is
also
not
straightforward,
like
a
deer's
experience
in
a
language
is
not,
as
is
that's
not
the
way
to
define.
D
D
Is
the
competency,
for
example,
whereas
it's
going
to
be
really
hard
for
you
to
do
it
for
sales,
like
you
need
a
charismatic
individual
like
Hut,
can
you
can
you
quantify
charisma,
it's
very
hard,
but
then
you
can
actually
quantify
I
need
this
person
to
have
this
level
of
competency
in
these
skills,
so
so
having
that
an
understanding
that
it's
about
building
a
team
that
can
work
together
well
and
the
sum
of
all
of
them
is
greater
than
the
individual
parts.
You
know,
that's,
probably
the
more
the
harder
part
in
the
engineering
hiring
process.
C
It's
important
to
try
and
like
for
my
money
like
what
out
of
an
interview
is
to
mimic
working
with
them
as
closely
as
I
can
right.
So
what
we
do
is
you
know
we
have
a
piece
of
code,
that's
crappy
code
and
we
send
it
to
the
candidate
the
night
before
and
we
let
them
ask
any
questions.
What
tell
them
what
questions
running
I
ask
them,
because
we're
not
trying
to
surprise
them.
You
know
if
they
want
to
prepare.
C
That's
fine,
I,
don't
think
it
takes
preparation,
so
don't
think
it's
gonna
improve,
but
if
they
want
to
know
that's
fine,
we
send
out
a
piece
of
code
the
night
before
and
we
ask
them
to
spend
no
more
than
an
hour
no
more
than
two
making
it
better
and
the
interview
isn't
actually
the
code.
The
interview
is
the
the
next
day.
Have
you
a
conversation
about
the
code?
Why
did
you
choose
this?
What
is
left
to
do?
What
didn't
you
have
time
to
do?
We
don't
want
them
to
spend
all
night
making
it
perfect.
C
We
want
them
to
take
the
time
that
they
have
like
you
do
in
real
life.
Take
the
time
that
you
have
the
code
that
you
have
to
add
to
or
extend
or
or
improve,
and
then
have
like
a
pull
request.
Type
discussion
like
talk
to
me
about
the
trade-offs
any
engineer
who
can
communicate
about
what
they're
doing
is
more
than
capable
of
figuring
out
how
to
do
the
work
and
the
reverse
is
not
necessarily
true.
There
were
plenty
of
who
can
do
the
work
and
they
they're
going
to
get
defensive.
B
I
think,
as
we're
talking,
one
thing
that
came
to
my
mind
was
around
a
lot
of
companies
hired
for
cultural
fit
and
there's
this
interesting
concept
that
I
read
a
few
days
ago
about
culture
ad
instead,
so
Aaron
della,
we
focus
a
lot
on
culture
and
what
he
can
add
to
the
culture
as
opposed
to
coming
in
and
having
to
fit
into
a
predefined
like
culture
and
I.
Think
it
meant
well
with
what
you
were
saying
around.
B
A
D
C
A
B
One
of
the
things
yeah
I
think
engineers
really
need
to
focus
on
problem
solving
skills
and
less
on
specific
language.
I
think,
once
you
learn
any
language,
you
can
learn
any
other
language,
so
I
would
focus
more
on
problem-solving
skills
and,
like
she
said,
communication
and
collaboration,
because,
ultimately
you
don't
work
in
a
vacuum.
You
have
to
collaborate
with
people.
You
have
to
communicate
your
ideas,
and
things
like
that,
so
I
think
problem-solving
to
me
is
one
of
the
critical
aspects
of
it
being
a
good
software
engineer.
C
There's
a
big
difference
here
between
giving
that
advice
between
answer
the
question
for
junior
engineers
and
senior
engineers
right
junior
engineers.
It's
like
get
to
be
a
senior
engineer
as
quickly
as
you
can,
and
that
means
learning
going
deep
in
a
framework
not
spreading
yourself.
You
know
learning
five
different,
you
know
frameworks,
that's
just
dipping
your
toes
in
each
one,
but
like
go
deep,
but
deep
in
something
and
get
as
much
exposure
as
you
can't
like
I,
never
recommend
to
any
junior
engineer
at
they
stay
at
one
company
for
the
entire
you
know.
C
Could
you
need
to
learn
how
different
people
do
things
but
then
went
through
a
senior
engineer
like
I
think
that
the
advice
is
much
more
often
about
leadership,
communication
and
persuasion
and
and
things
that
are
not
as
technical
unless
you're
the
archetype?
Who
really
wants
to
do
nothing
but
technical
work,
but
thing
you
still
need
to
look
for
different
ways
to
leverage
your
influence.
Yeah.
C
A
B
I
think
Erin
dela.
We
believe
that
the
future
of
work
is
distributed,
so
I
think
the
first
thing
is
to
look
beyond
your
local
markets.
You
know
during
the
keynote
yesterday
they
mentioned
that
80%
of
the
github
users
are
outside
of
the
US.
So
to
me
that
says
that
companies
should
be
looking
to
tap
into
that
global
work
force
to
look
for
the
best
talent
and
not
necessarily
just
focus
on
the
nearest
Talent
about.
A
B
D
Me
to
me
it's
all
about
impact.
The
engineers
need
to
feel
the
impact
all
the
time.
I
think
that's
what
is
oftentimes.
You
are
your
shipping
code
you're
constantly
doing
it,
but
what?
How
does
it
connect
to
the
business?
How
do
you
connect
to
the
business
impact?
It
comes
from
I,
don't
know
if
it's
the
engineering
manager
or
the
PMS
or
you
know
right
from
the
top.
That
is
what
is
a
huge
determinant
of
retention
in
an
organization
is,
am
I
making
an
impact
and
then
there's
a
personal
growth
aspect
to
it.
D
C
C
Is
the
trick
like
giving
people
the
autonomy
the
the
amount
of
impact
that
they
can
have
connecting,
like
you
said
to
the
business
value
and
I
actually
agree
that
the
future
of
work
is
distributed,
but
I
mean
we
can't
dismiss
the
fact
that
number
one
you
can't
have
distributed
distributed
people
you
have
to
have
distributed
teams,
because
if
you
have
just
a
few
people
who
are
remote,
you
have
remote
people,
you
know
it's,
the
entire
team
has
to
buy
into
it.
I
encourage
everyone.
On
my
team.
C
We
have
a
largely
SS
based
team
I,
encourage
everyone
to
work
from
home
or
remote
regularly
so
that
they
remember
what
it
feels
like
to
not
be
in
the
room
with
everyone,
because
it
changes
your
whole
way
of
working
and
it
does
slow
you
down
a
little
like
it
does,
there's
nothing
as
fast
as
you
all
are
in
the
room
together
going
to
lunch
together.
Just
spit
ball,
like
you
lose
a
little
bit
of
that
which
is
fine.
You
know,
as
you
as
you're
growing
I,
think
that
what
the
VCS
are
bombing
onto
is.
C
C
D
D
D
You
know
it's
fully
distributed
right
from
day
one
because
it's
I
think
why
I
think
there
are
a
lot
of
munication
challenges
that
you
would
have,
and
you
need
to
instill.
Writing
writing
notes
like
meeting
will
be
recorded
or,
like
will
be
posted,
and
all
of
those
things
needs
to
happen
from
day
one.
It's
gonna
be
very
hard
after
you
build
a
sizeable
team
to
completely
change
the
dynamics
of
how
your
existing
people
are
going
to
adapt
than
you
want.
D
I
think
the
advantage
is
that
you
get
access
to
a
wider
talent
pool
which
she
would
not
get,
but
he
was
I
would
still
recommend
people
to
come
on
site
for
the
initial
week
or
so
to
get
used
to
you
like,
even
during
the
interview
process
like
are
you
able
to
work
with
this
person
initially
and
then
have
have
the
ability
to
go
ahead
and
build
a
remoter
distributor?
Yeah.
Sorry.
A
B
Yeah,
so
exactly
the
same
way,
we
come
up
with
sort
of
practices
that
we
believe
for
good
distributed
teams,
but
one
point
Vivek
mentioned
is
also
that
we
do
have
our
developers
go
to
the
partner
site
and
to
build
rapport
during
the
the
early
phases
to
meet
with
the
people
they'll
be
working
on
before
going
back
to
being
distributed.
That
also
helps
a
lot.
We.
D
D
Not
been
able
to
pinpoint
it's
probably
more
like
a
human
human
thing,
but
like
once,
you
meet
this
person.
Oh
this
is
a
person.
I
have
been
slacking
and
emailing
all
all
along,
and
you
know
I
get
to
know
you
better
I
know
understand
why
you
were
coming
from.
What's
your
perspective,
why
did
you
ask
you
start
to
associate
tone
whenever
somebody
email,
you
see
you
always
associated
a
tone
to
that
email
and
now
that
that
becomes
more
of
a
I,
don't
know
friendlier
tone
of
or
assuming
the
right
intent.
Oh,
you
know.
D
A
B
Think
that
distributed
work,
setting
sort
of
levels
of
the
playing
field,
because
it
opens
up
different
ways
of
communicating
different
communication
channels.
So,
for
example,
in
my
personal
experience
when
I
was
a
junior
engineer,
it
was
very
daunting,
sometimes
to
be
sitting
in
a
room
with
a
bunch
of
senior
engineers
and
speaking
up
and
sharing
my
ideas,
around
architecture
decision
or
the
product
strategy
that
the
team
should
take.
But
in
the
distributed
work
setting
you
know,
I
can
use
slack
reaction
in
slack
messages
if
we're
all
on
the
zoom
call.
B
C
Well,
I
think:
how
do
you
build
them
into
a
we're
actually
building
this
into
our
products
in
a
lot
of
ways,
I
feel
like
most
of
the
tools
we
build
for
engineers,
don't
really
take
into
account
how
teams
work
and
we
build
nothing
for
individuals.
We
build
everything
for
teams,
because,
if
I'm
getting
paged
about
something
and
I've
never
seen
it
before
I,
remember
that
we
got
paged
about
this.
You
know
three
or
four
weeks
ago
and
I
think
Christine
was
on
call
I
just
want
to
go,
look
and
see.
How
did
she
do
it?
C
What
did
she
think
was
important
enough
to
post
it
to
slack
and
I
feel
like
this
is
having
that
sense
of
context
in
history
and
it's
the
it's
a
new
version
of
being
able
to
look
over
someone's,
shoulder
and
or
read
their
batch
history
file
right,
like
you,
learn
so
much
about
just
imitating
people
and
and
I
feel
like
in
a
distributed
context.
It's
easy
to
lose
that
and
our
tools
need
to
pick
up
the
slack.
D
C
D
D
Hire
yeah
yeah
I'm.
Just
thinking
that's
that's!
That's
pretty
interesting!
Yeah,
yeah,
yeah,
empathy,
yes,
I!
Think
there
is
a
default
assumption
that
engineers
are
introverts
and
they
don't
talk
and
they
don't.
You
know,
you
know
they
don't
want
to
participate
and
all
of
those
things.
I,
I
I,
know
I'm
an
engineer
myself.
I
used
to
work
at
Amazon
and
all
of
those
things,
I
I.
Think
there
is
a
you
know.
There
is
a
pipe
cast.
I
think.
C
A
D
Actually
do
a
very
similar
one.
Every
engineer
that
that
we
have
hired
so
far
has
to
present
a
business
plan
of
their
idea.
Assume
you
have
ten
million
dollars.
What
would
you
do?
How
would
you
do
and
it's
amazing
to
see
how
they
come
and
present
every
engineer?
I
know
it's
not
a
scalable
one,
because
my
time
is
limited
and
all
those
things-
and
you
know
my
recruiting
coordinators
are
always
like
complaining
about
this
stuff.
But
that
is
the
final
step.
D
C
That's
intense,
we
tried
to
ask
questions
to
tease
out
their
technical
judgment
basically
and
if
they
include
factors
like
you
know.
Well,
if
we
build
this
product,
what
isn't
getting
built
if
I
spend
my
time,
you
know
going
off
and
riding
a
storage
engine
for
fun.
What
is
the
you
know,
maintenance
cost,
and
is
it
worth
it?
It's
pretty
easy
to
see
who's
working
in
just
in
strict
technical
terms
and
who's
looking
around
at
other
teams,
and-
and
you
know,
the
actual
impact
of
what
they're
doing
mm-hmm.
A
C
B
I
think
always
looking
for
engineers
that
are
asking
the.
Why
essentially
always
curious
and
always
trying
to
get
to
the
root
of
things
and
not
just
you
know,
taking
stories
and
taking
product
requirements
and
kind
of
being
code
monkeys,
but
always
asking.
Why
is
improving
the
products?
Why
are
we
doing
this?
Why
are
we
going
this
direction
and
always
asking
to
get
a
better
sense
of
things?
The.
C
But
this
means
that
there's
going
to
be
higher
risk,
not
as
many
people
are
going
to
work
out
as
if
you
know
we
had
an
extremely
high
bar
and
we
were
like
you
know,
giving
people
a
month,
long
intensive
interview,
no
we're
choosing
to
take
a
risk
on
people,
and
so
you
kind
of
have
to
just
repeat
yourself
and
communicate
that
over
and
over
and
and
show
it
with
your
actions
in
every
way.
But
but
you
can't
have.
A
C
B
I
I
mean
I
think
it
starts
with
the
organization
kind
of
asking
the
developers.
What
kind
of
leader
do
you
want
to
be
right,
I
think
I,
don't
della.
We
sometimes
made
the
mistake
of
assuming
that
every
developer
wanted
to
be
a
tech
entrepreneur,
but
like
sometimes
some
developers
just
want
to
be
technical,
and
you
know
they
just
want
to
be
really
really
senior
and
push
the
boundary
of
technology
while
others
want
to
build
communities
or
others
want
to
build
open-source
some
developers.
B
C
I
think
it's
I
think
that
every
senior
engineer
should
do
management
at
some
point,
if
only
to
like
build
empathy
for
the
poor
souls
who
choose
that
as
a
long
term,
career
and
I
also
think
that,
like
going
back
and
forth,
is
really
valuable.
If
you
have
a
line
manager,
the
best
line
managers
are
no
more
than
three
or
four
years
removed
from
actually
shipping
code
and
which
means
that
if
they
want
to
do
that
job,
they
kind
of
have
to
go
back
and
periodically
refresh
their
skills.
C
I
am
a
huge
believer
in
that
management
is
not
a
promotion.
It's
a
it's.
A
career
change
like
they
should
be
paid
the
same
or
less
than
the
engineers,
and
it
should
not
be
shouldn't,
be
like
hey.
Congratulations.
You
really
have
to
pay
attention
to
your
language.
You
know
if
you
start
calling
it
a
promotion,
then
it's
a
demotion
if
they
want
to
go
back
to
engineering.
No,
no!
No!
No!
This
is
this
is
a
flat.
You
know
this.
It's
not
a
flat
organization,
but
you're
equals
so.
C
In
their
souls-
and
they
have
no
interest
in
it,
bless
them
more
people
are
curious.
You
know,
or
they're,
like
oh
I,
think
I
could
do
that
job
better
than
that
person.
You
know,
and
you
don't
know
until
you
try.
It
I
think
that
everyone
who's
interested
in
it
should
try
it,
but
nobody
should
force
be
forced
to
do
it
because
nobody
wants
to
report
someone
who's
forced
into
that
job.
C
D
Very
similar
I
think
there
are,
you
know,
I've
seen
in
our
company
engineers
wanting
to
continue
the
path
moving
to
engineering
management
moving
to
product
management
as
well,
but
I
think
one
of
my
biggest
learnings
is
to
make
it
very
explicit
to
the
engineer
on
what
the
role
change
will
entail.
That
engineering
manager
means
that
it's
about
empowering
people,
building
teams
a
lot
of
your
time
and
energy
and
everything
was
gonna,
be
focused
on
that.
Do
you
enjoy
writing
performance
reviews
right
of
people?
D
If
you
don't
hey,
you
know
you
should
actually
naturally
want
people
to
get
better.
Then
it's
probably
not
a
good
path.
Like
product
manager.
You
actually
enjoy
sitting
in
front
of
customers.
Cross-Functional
coordination!
Writing
PRD
is
like.
Do
you
really
enjoy
doing
that?
I?
Think
not
setting
that
expectation,
because
it's
a
it
just
feels
like
a
promotion
like
you
know,
Oh
engineer,
engineering
manager,
engineering,
product
management,
everybody
wants
to
continue
to
get
better,
but
if
you
don't
set
the
right
expectation,
it's
a
disaster.
I've
had
both
pros
and
cons
on
this,
like.
B
I
mean
there's
typically
the
individual
contributor
path
and
the
management
path
yeah,
and
then
on
the
division,
contributor
paths
you
become
more
and
more
senior
and
to
kind
of
push
the
boundary
of
technology
and
on
the
management
part,
is
about
building
teams
like
they
said
you
know,
helping
develop
others,
people
that
you
manage.
So
it's
really
a
lot
of
your
time
is
spent
around.
A
B
I
think
the
first
step
is
education
and
learn
about
it.
I
think
there's
a
lot
of
tech
ecosystems
coming
up
in
developing
countries
like
in
Africa
in
the
African
continent,
in
Nigeria,
Kenya,
Uganda,
Rwanda
and
Egypt,
and
all
the
parts
of
the
the
continents
so
I
do
think
that
the
first
part
the
first
step
is
education.
What.
A
C
I
think
that
the
first
thing
you
should
do
is
is
start
thinking
clearly
and
I'm
writing
clearly
about
what
your
philosophy
is.
What
your
hiring
process
is
what's
different
about
your
company,
why
people
should
want
to
work
there,
I
used
to
hate
company
values
and
I
would
roll
my
eyes
at
them
and
I
still
rolled
my
eyes
at
very
cliche
company
values
which
are
almost
all
of
them,
but
actually
it's
really
important
to
know
who
you
are
and
how
you're
different
from
other
places.
Why
should
anyone
want
to
work
with
you?
What
about
you.
A
D
I
think
I
think
if
you're
starting
a
company,
if
you're
just
10
engineers
or
five
engineers
or
whatever
I,
think
it
should
be
the
founders
DNA,
firstly
to
be
open
to
looking
outside
or
building
a
remote.
If
it's
if
the
founders
are
over
is
a
start.
Founding
team
does
not
fundamentally
believe
in
this.
Then
it's
not
going
to
work.
Then
it's
actually
much
better
to
just
pay
crazy
salaries
and
just
can
burn
more
money.
A
D
Yeah
I
think
I
think
I
think
one
just
being
open
to
the
fact
that
you
should
again,
like
you,
know,
skill
Trump's
pedigree.
You
know.
Firstly,
you
don't
really
understand
the
core
foundation.
I
think
that
that
should
be
straightforward,
whether
you're
building
it
in
San,
Francisco,
remote
and
but,
if
you're
thinking
about
like
building
a
remote
or
an
offshore
like
at
when
you're
like
eight
people
or
10
people,
then
you
have
to
really
build
your
communication
architecture.