►
Description
Featuring: Bill Higgins, IBM and Jason Warner, GitHub
People often say that in order to achieve sustainable excellence in software, you need to get the culture right. This is true, but at this level, not very actionable. Over our years of building and deploying tools to development teams, we have found that providing the right tools can act as a catalyst for positive culture change. When you provide the right tools to your development teams at scale, you show that you’re serious about changing the way they work. When you help teams learn and master the modern practices that the tools enable, your teams get better at their craft. Your investment in tools and practices help create an environment that attracts and retains top talent. This is all easier said than done, and in this 40 minute panel discussion Bill Higgins, IBM Distinguished Engineer, along with Jason Warner, SVP of Technology of GitHub, discuss concrete strategies for rolling out great tools at scale, including: choosing the right tools, finding and empowering user champions, enabling effective continuous learning (in the context of doing work), gaining the support of senior leadership. Bill and Jason have many years of experience building and deploying tools, and now work closely together on the evolution of GitHub for Business and using GitHub at IBM.
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
B
B
A
Awesome
so
we
started
working
with
IBM
back
in
2015
March
2015
funny
to
get
a
call
from
IBM.
There's
a
big
account.
We
thought
okay,
what's
going
on
here,
it's
gonna
be
interesting.
They
wanted
to
start
a
push
into
cloud
and
cognitive
and
they
thought
we
should
look
at
github
as
a
way
to
get
us
ready
to
do
that
kind
of
coding,
and
it
was
good
journey.
We've
been
working,
super
close
with
IBM
they're,
our
largest
customer
they're,
one
of
our
largest
partners.
A
B
A
Months
ago,
maybe
four
months
ago,
so
that
article
is
a
basis
for
this
talk,
we'll
try
to
get
the
link
out
to
you
before
the
end
of
the
show,
but
it's
based
upon
that
so
just
to
kick
things
off:
I'm
gonna,
moderate
and
I'm
gonna.
Let
these
guys
do
the
talking
they're,
the
engineers
here
and
they're
gonna
be
best
at
explaining
how
culture
change
comes
about,
and
the
effect
tools
has
on
that.
So
first
question:
just
to
set
the
stage
is
culture
is
bandied
about
as
a
word,
that's
used
in
lots
of
different
contexts.
B
Go
first
yeah,
so
a
culture
like
Paul
said
is
one
of
those
words
that
people
say
but
I,
don't
think
a
lot
of
people
really
understand
what
it
means
and
a
lot
of
people
don't
understand
how
to
actually
change
it
so
to
get
really
concrete,
because
you
know
we're
engineers.
So
we
like
to
talk
things
that
are
real.
B
I
had
visited
a
friend
of
mine
who,
at
the
time,
was
CTO
at
Etsy,
and
we
were
talking
about
starting
a
consortium
around
resilience
and
digital
infrastructure
and
I
went
to
Etsy
and
I
saw
that
the
way
that
they
developed
was
radically
different
from
IBM
continuous
delivery
chat
ups,
but
but
also
the
the
collaboration
between
developers.
Anybody
and
that's
he
could
see
the
code
of
anybody
else
and
so
I
thought
just
as
a
thought
experiment
what?
B
If
what
if
IBM
worked
a
little
bit
more
like
Etsy
and
what
would
it
be
like
for
developing
Watson
and
cloud
and
all
that
stuff?
And
what
we
realized
was
that
it
was
going
to
require
a
fundamental
culture
change,
which
meant
our
policies
are
the
way
we
approach
failure
and
so
to
me,
the
the
culture
is
really
about
the
kind
of
the
tasks
and
assumptions
about
how
you
work.
What
is
rewarded,
what
is
expected,
what
is
sanctioned
and
yeah?
That's
what
it
means
to
me
so.
C
Pretty
similar,
to
be
honest,
so
I
think
that
it
comes
down
to
a
lot
of
those
expectations,
sanctions
and
things
that
you
just
say
this
is
part
of
who
we
are
and
that's
how
we're
gonna
do
it,
but
also
this
is
allowed.
This
is
not
allowed.
This
is
enforced.
This
is
not
enforces,
look
the
other
way,
I!
Think
of
it.
C
As
you
know,
you
can
see
healthy
and
unhealthy
of
all
types
of
delivery
models,
but
when
it
comes
to
the
culture
of
the
place,
your
the
way
you
work
sometimes
infuses
how
you
react
as
well,
so
I
think
of
it.
This
way
to
like
see
ICD
as
a
culture
model,
is
interesting,
because
what
that
forces
you
to
do
is
feedback
loops
have
to
be
tight
in
the
way
that
that
works
is
you're,
if
you're
getting
information
very
quickly.
C
A
B
The
the
first
set
of
tools
that
we
rolled
out
were
github
slack
and
then,
as
a
second
set,
we
did
Travis
CI.
Oh
sorry,
mural
was
part
of
the
first
set,
and
we
had
we
had
kind
of
looked
at
some
of
the
cultural
pathologies
at
IBM
and
one
of
the
big
ones
that
we
saw
were
these
gaps
between
the
different
disciplines.
B
Engineering
didn't
really
get
along
with
design
didn't
really
get
along
with
offering
management,
and
one
thing
that
we
noticed
was
that
they
tended
to
work
in
different
tools
like
we
found
this
one
case
where
a
product
management
team
didn't
even
have
access
to
the
backlog.
The
engineering
teams
backlog,
and
so
the
first
set
of
tools
that
we
picked
were
tools
that
really
facilitated
interdisciplinary
collaboration
like
github,
like
mural,
like
slack
and
overtime.
C
What
you
said
there
about
trying
to
get
them
to
talk,
because
that's
one
of
those
things
if
you
understand
that
you're
optimizing
for
this
dysfunction,
that
is,
that
their
organizations
don't
even
interact
with
each
other.
You
can
at
least
understand
what
you're
trying
to
solve
and
it's
the
fundamental
what
probably
trying
to
solve
and
then
what
you're
trying
to
get
out
of
this.
If
you
have
organizations
that
talk
all
together
but
they're
slow,
looks
very
different
and
well,
you
might
have
a
different
choice.
C
A
B
Do
you
do
right,
yeah,
so
there's
you
know,
there's
always
inertia
and
complacency,
because
lots
of
people
are
comfortable
with
what
they're
doing,
even
if
their
business
results
aren't
great.
So
what
we
did
was
since
IBM
is
a
massive
company.
Obviously
we
could
find
the
people
who
wanted
to
embrace
this.
So
a
lot
of
the
the
new
hires
had
already
used
github
in
college
or
they'd
used
it
for
open
source
projects.
Some
of
the
industry,
hires
were
the
same.
B
Some
of
the
longtime
IBM
errs
had
been
frustrated
with
business
outcomes,
and
so
they
wanted
to
try.
So
what
we
did
was
we
tried
to
find
those
folks,
the
champions
to
start
adopting
the
tools
and
when
they
demonstrated
success
through
this
better
way
of
working,
then
we
would
very
intentionally
do
internal
marketing
to
shine
a
light
on
them
and
say:
look
what
this
team
did
from
a
business
perspective
and
then
work
backwards
to
their
different
way
of
working
and
so
the
as
a
posed
to
us
being
change
agent.
Saying
hey,
you
should
work
differently.
B
People
would
look
at
their
peer
teams
who
are
having
better
results,
and
you
know
kind
of
natural,
human
in
curiosity
and
jealousy
they'd
say
well.
Maybe
I
should
try
that
and
then
we
started
to
see
that
diffusion
curve
of
the
early
adopters
infecting
the
early
majority
and
then
finally
dry
dragging
along
some
of
the
late
majority,
which
is
where
we're
at
right
now.
A
B
A
D
A
B
A
B
B
So,
along
with
the
tool
investments,
they
also
made
a
bunch
of
real
estate
investments
to
create
open
spaces
just
more
light,
but
there's
actually
an
interesting
analogy,
because
I
sort
of
think
of
the
physical
open
spaces
as
the
physical
analog
to
the
digital
open
spaces,
whereas
before
teams
might
have
been
compartmentalized
where,
if
Jase
and
I
are
a
different
team,
he
can't
see
my
code.
I
can't
see
his
code
now
we're
in
an
open
space
github
where
we
can
see
each
other's
code
and
more
easily
share
back
and
forth.
B
C
So,
but
this
is
the
first
one
and
the
I
remember.
The
physical
location
was
the
first
thing
that
you're
like
okay.
This
could
be
different.
This
could
actually
be
fun,
there's
colors
and
all
that
sort
of
stuff.
But
then,
when
you
saw
how
often
they
were
releasing
software
there
and
how
they
were
doing
it
is
that
was
the
moment.
I
was
like
okay,
so
there
is
something
a
little
bit
different.
I
remember
going
back
after
that
interview,
saying,
oh
dear
god,
no
bill.
A
How
hard
was
it
to
change
management
like
you
had
an
idea,
you
wanted
to
go
and
do
this
and
get
these
tools
in
there
and
have
culture
change
and
you
had
to
start
somewhere.
Gonna
start
on
some
project.
So
did
you
like
intentionally
pick
this
particular
project
and
then
how
did
you
get
management
buy-in
to
let
you
experiment
with
this
inside
IBM
which
really
think
about
it?
It's
you
know,
you've
got
to
change
a
big
ship.
So
how
did
you
get
management
buy-in
on
that
yeah.
B
Good
she's,
a
good
one,
so
we
started
with
just
the
practitioners.
We
we
intentionally
started
in
stealth
mode.
We
didn't
want
to
come
out
and
say:
hey
everybody,
we're
gonna
change
the
culture,
because
then
you
know
everybody
rightfully
turned
you
off.
So
we
started
by
doing
very
real
things
like
making
github
available
to
people
saying
that
it's
okay
to
have
public
repositories
within
the
within
the
rip
within
the
overall
system,
and
so
we
started
to
get
the
practitioner
adoption
and
then
we
actually
did
get
some
pushback
from
some
parts
of
management.
B
Some
managers,
because
of
bias
or
not
wanting
the
turn
of
changing
tools,
try
to
push
push
back
against
it.
But
there
was
enough
momentum
and
enough
adoption
that
at
some
point
the
executive
team
came
around
at
some
point.
The
head
of
Watson
actually
said
this
is
really
great
stuff
and
then
we
started
to
get
those
executive
champions
and
then
we
could
shine
a
light
on
them
as
executive
champions.
B
Just
like
we
used
to
shine
a
light
on
the
team
as
local
people
having
success,
so
we
were
fortunate
and
that
we
had
some
really
progressive
leaders
like
David
Kenney
of
Watson
and
Rob
Thomas
of
analytics,
who
became
executive
champions
because
they
knew
that
to
be
more
competitive.
Their
teams
had
to
you
know,
there's
a
saying
like
to
be
better.
You
have
to
be
different,
like
by
definition,
and
so
they
wanted
their
teams
to
get
much
better,
and
so
they
became
great
champions,
for
the
tools
did.
A
You
see
real,
did
they
see
real
I
mean
a
lot
of
management?
It's
like!
Ok,
that's
all
great
everybody's
happy,
that's
cool
can
recruit
better,
but
I
want
to
see
output
I
want
to
see
something
that
gets
out
to
the
street.
That
makes
money
or
cuts
costs,
or
did
they
see
real
output
out
of
this
product?
Is
that
what
you.
B
Know
for
sure
I
mean
one
thing
to
remember
about
companies
like
IBM
and
other
older
software
companies
is
that
we
didn't
start
on
the
cloud
we
didn't
start
with
SAS.
We
started
from
on-premises
delivery
and
we
needed
to
shift
to
cloud
and
SAS,
and
so
to
do
that
we
needed
a
fundamentally
different
way
of
working.
So
these
general
managers
and
senior
VPS,
whose
jobs
and
bonuses
depend
on
having
better
results.
It
was
in
their
selfish
interest
and
their
team's
work
better.
So
they
were
highly
motivated.
They
weren't
trying
to
be
nice.
B
Know
I
think
we
saw
a
good
organic
growth
over
the
first
just
kind
of
viral
practitioners
talking
to
practitioners
teams
talking
to
teams
over
the
first
year,
so
I'm
probably
gonna
have
some
revisionist
history
I'm
looking
at
David
here
cuz,
he
remembers
better
than
I
do
but
I
remember
there
was
this
one
meeting.
We
have
this
this
meeting
where
Arvind
Krishna
our
head
of
research
in
hybrid
cloud,
has
all
the
development
VP's
from
around
the
company
and
they
make
decisions,
and
there
was
this
one
meeting
where
we
were
talking
about.
B
Should
we
all
go
into
github
and
there
was
yes
yeah
Paul
Paul
agrees
is
the
head
of
github
sales
and
there
were
a
few
VPS
who
spoke
up
and
said
yeah.
We
should
do
github,
but
we
should
also
do
a
common,
continuous
deployment
tool
and
we
want
the
the
project
was
called
whitewater.
We
want
the
whitewater
team
to
do
it
and
it
was
at
that
point.
I
was
like
wow,
this
is
gonna,
be
sustainable.
I
was
really
worried
about
this
stainability
because
I
don't
know
how
many
people
work
in
big
companies.
B
It's
very
easy
for
a
change
initiative
to
get
killed.
Oftentimes,
they
don't
get
enough
momentum
and
then
they
just
get
killed.
So
that
was
always
the
worry
with
our
project,
but
it
was
in
that
one
meeting
about
a
year
in
when
we
had
a
couple,
pretty
powerful
executives,
speak
up
and
say
we
need
to
do
more
of
this.
That
I
thought
this
is
going
to
become
I
mean
we.
We
still
have
to
work
hard,
there's
lots
of
work
to
do,
but
this
is
gonna
be
self-sustaining
as
long
as
they
don't
make
any
big
mistakes.
D
B
B
B
So
in
github
you
can
certainly
commit
right
to
master,
but,
in
my
opinion,
you're
much
better
off
if
you're,
creating
pull
requests
having
those
code
reviewed
iterating
on
those
as
part
of
a
continuous
delivery
process.
So
in
both
cases,
you're
getting
the
code
into
master
but
in
very
different
ways,
and
so
about
a
year
in.
We
realized
that
to
get
the
next
30,000
users,
we
would
have
to
really
invest
in
helping
people
understand
the
better
practices
that
the
tools
enable
but
did
not
force
upon.
You.
A
C
Don't
think
that
I
think
context
matters
which
optimization
you're,
making
things
like
that
I
think
that
the
fool
the
tool
scenario
is
we
see
that
all
the
time
I
think
in
tech
in
general
is
that
bad
buying
decisions
for
the
wrong
reasons
lead
to
bad
outcomes?
Adoption
of
technologies
is
also
one
of
those
things
that
can
fall
by
the
wayside
if
someone's
using
the
the
the
whatever
it
be
inappropriately,
I,
remember
way
back
when
I
think
was
2006
we're
doing
some
experiments
at
the
company.
C
I
was
AB
with
in
cloud
computing,
just
starting
Amazon's,
just
releasing
some
stuff,
someone
decided
to
write
a
POC
of
a
thing
and
there
and
it
was
terrible
because
they
were
trying
to
use
an
old-world
style
of
work
with
this
new
service
and
they
try
to
shove
all
this
data
through
it
in
the
way
it
was
working.
It's
like
oh
look
at
this.
C
C
You
can
ultimately
have
a
better
outcome,
but
you
can
also
understand
more
about
what's
going
on
and
why
that
this
whole
thing
might
actually
be
meaningful
and
I
think
that
was
a
you
know.
My
biggest
learning
and
all
years
in
tech
is
that
people
adopt
things
for
the
wrong
reasons
without
understanding.
Why
and
then
they
say
this
doesn't
work
because
it
doesn't
look
just
like
this
other
thing
that
I
know
how
to
use
exactly.
Databases
are
a
common
example
of
that
to
me.
Yeah.
B
Users
are
in
and
they're
there
in
github
all
day
and
so
I
kind
of
laugh
because
we
spend
so
much
time
teaching
machine
these
days
with
machine
learning
and
building
models,
and
things
like
that
and
I
think
there's
actually
a
huge
opportunity
for
companies
like
github
and
slack
to
actually
teach
humans
by
having
you
eyes
that
kind
of
hint
at
these
better
practices
or
maybe
media's
data
insights
team
can
say,
hey
I,
see
you're
working
like
this.
Have
you
considered
working
like
that
in
the
and
here's?
C
Sure
and
it's
it's
part
of
the
whole
learn
side
of
the
github
story
that
we
have
talked
about
internally
quite
a
bit,
but
it's
definitely
something
that
Chris
is
super
passionate
about
as
well,
and
we
think
about
the
next
wave
of
developers.
We
think
about
the
next
generation
of
folks
who
are
going
to
be
meaningfully
making
change
in
the
world
and
Meade
you
and
I
actually
go
back
and
forth
them.
That's
quite
a
bit,
and
we
think
about
this
I'm,
an
old
infrastructure
person.
C
B
Right
yeah,
it's
sometimes
it's
harder
for
us,
because
you
know:
we've
had
some
degree
of
success,
and
so
the
human
nature
is
to
just
keep
doing
what
you're
doing,
because
it's
work
for
you,
it's
kind
of
got
you
to
where
you're
getting
to.
But
as
the
world
changes
you
have
to
be
ready
to
adapt.
You
have
to
be
ready
to
learn
better
practices.
B
The
previous
CIO
at
IBM,
Jeff
Smith,
had
this
great
saying,
which
was
there
are
six
billion
people
in
the
world.
Somebody
is
doing
what
you
do
better
than
you
are
find
them
and
bring
it
back
here
and
I
think
it
really
takes
a
you
know,
a
curiosity
and
a
humility
to
constantly
have
that
mindset
and
bring
those
ideas
back
into
the
companies
and
then
try
to
spread
them.
So.
A
What
do
you
think
about
a
total
choice?
We're
gonna
do
one
more
question
here
then
I'm
gonna
turn
over
to
the
audience
we're
about
halfway
through
and
we'll
turn
out.
Do
your
questions
and
then
one
final
question
for
the
two
guys
up
here,
but
thinking
about
tool
choices
in
general.
How
do
you,
how
do
you
look
I
mean
if
it's,
if
the,
if
the
tool
and
the
culture
somehow
intertwine
you
know
you've
spoke
about
that
your
article?
A
But
what
do
you
look
at
a
horizon
on
a
tool
versus
you
pick
a
tool,
and
how
do
you
expect
it
like
three
years
five
years?
Is
it
something
to
live
with
you?
You
expect
the
company
to
iterate
on
it
and
soon
I
mean
it's
like
you're
betting,
your
culture
on
this
you
have
a
tool.
How
does
that
all
go
hand
in
hand
with
long
term
thought
and
how
you
how
you
pick
what
you
pick
right.
B
So
our
rule
of
thumb
was
if
we
can't
plausibly
imagine
this
tool
still
being
used
at
high
scale.
Five
years
from
now,
don't
even
bother
with
it,
because
the
the
cost
of
replacement
in
the
crop
cost
of
retraining
is
just
so
incredibly
high.
And
that
was
one
of
the
reasons
that
tools
like
github
and
slack
were
so
attractive
because
they're
kind
of
like
de
facto
standards.
B
B
We've
had
different
uptake
of
tools.
The
biggest
uptake
has
been
on
github
and
slack
other
ones,
don't
get
quite
the
uptake
for
various
reasons,
and
so
I
think.
The
best
case
is
when
both
the
doers,
like
the
developers
or
the
designers
and
the
leaders,
the
executive
leaders
hundred-person
see
the
value,
and
they
kind
of
selfishly
want
to
adopt
those
tools
because
they
think
they'll
either
write
better
code
or
have
better
business
results.
That.
A
C
C
That's
so
fundamental,
you
know,
and-
and
those
are
rare
those
are
those
are
not
that
common
and
then
there's
ones
that
just
like
a
high
friction
cost
to
replace
and
I,
usually
think
about
those
as
two
and
a
half
to
three
years
and
right
now,
like
the
the
the
the
one
of
the
most
common
examples
are
from
a
programming
perspective.
Is
the
front-end
frameworks.
C
Stuff
that's
going
on
is
that
every
couple
of
months
it
seems
like
something
is
it's
kind
of
waning
and
another
one's
coming
up
and
the
cost
of
switching
is
incredibly
high
and
if
you're
on
an
old
version
of
a
thing.
So
it's
incredibly
frustrating
when
you're
thinking
about
it
from
a
CIO
CTO
perspective
of
you
know
what
you're
making
your
bets
on.
So
it
does
even
have
that
time
horizon,
but
I
definitely
want
to
make
at
least
three
years
because
of
the
friction
of
switching
and
the
cost
of
switching
is
so
high.
Do.
E
D
D
B
D
F
Got
paid
slack
at
my
company
just
like
in
the
last
few
weeks,
the
developers
had
seen
the
benefit
in
it
for
years
developers.
Think
of
all
this
stuff
is
like
awesome.
We
had
a
tough
time
convincing
the
business
leaders
and
the
executives,
and
just
like
the
business
people
that
weren't
necessary
leaders
like
I've
the
value
of
that
stuff.
How
do
you,
how
do
you
guys
get
people
to
use
new
technologies
that
maybe
the
developers
see
is
just
like
normal
always,
and
how
do
you
convince
people
of
the
value
of
those
kind
of
things
so.
C
C
Think
that
that
the
trade-offs
you
make
and
I
think
the
decisions
that
you
do,
we
as
an
industry
don't
do
that
if
you,
if
you
go
through
and
actually
inventory
people
who
are
our
CEOs
these
days,
they
come
out
of
marketing
and
come
on
a
product
and
they
come
on
a
sales.
No
offense
Paul
but
I
mean
there's,
there's
a
there's,
a
reason.
C
This
you
are
my
favorite
sales
guy,
my
current
favorite
sales
guy,
but
there's
there's
a
reason
why
I
historically
that's
the
case
but
I
just
think
as
an
industry
if
we
have
more
technical
CEOs
over
time,
stuff
like
that,
is
actually
an
easier
conversation.
But
in
the
meantime,
the
best
way
to
commit
I
found
to
convince
executives
of
the
value
of
things
is
you
you
have
to
make
the
compelling
pro/con
other
case,
which
is
we
what's
the
cost
of
not
doing
this
and
you
put
it
in
costs.
A
dollar
per
conversation.
B
B
And
then
once
we
had
a
few
of
those
executive
on
boards,
the
the
ones
who
didn't
really
get
it,
we
could
just
say:
well,
you
should
talk
to
David
and
then
they
could
have
a
senior
level
conversation
about
why
David
was
motivated
as
a
senior
VP
to
adopt
a
certain
technology
in
his
organization.
So
I
don't
know
if
you
had
that
luxury,
but
that's
how
we
did
it
ya.
F
Know
I
mean
people
are
very
open
to
everything,
I
guess
for
me,
it's
just
it's.
A
lot
of
the
stuff
seems
really
natural
to
developers
and
a
lot
of
folks
that
aren't
developers
are
technical
people
like
you
said
like
they
just
it.
It
doesn't
like
click
to
them,
quite
as
fast
like
why
this
would
would
make
such
a
big
difference,
because,
like
slack
honestly,
I,
don't
know
how
I
would
live
without
slack
on
a
development
team.
F
C
I,
don't
know
if
you
can
from
an
emotional
side,
except
that
I
every
once
in
a
while
I
will
have
to
play
that
card
if
I'm
in
a
different
I'm
a
very
privileged
position,
all
of
a
sudden
I
get
hub
and
I'm
furious
that
Heroku,
but
if,
on
the
flipside
early
in
my
career,
you
build
relationships,
one
so
that
you
can
pull
out
this
next
card,
which
is
the
trust
me
card.
Let
me
let
me
show
you
the
value
of
this
thing.
Trust
me
give
me,
give
me
a
little
bit
of
runway
to
do
this.
C
F
B
Person
firms
so
at
IBM.
What
I
found
is
it's
big
enough
that
there's
always
somebody
in
HR
or
in
finance
or
wherever,
who
gets
it
and
can
be
your
champion?
And
then
the
pattern
I
use
is
just
work
with
that
person
help
make
them
successful,
even
if
we
have
to
spend
serious
effort
to
make
them
successful
right
integrations
for
them
whatever
and
then
shine
a
light
on
them
so
that
they
it
spreads
as
they're
from
their
success.
All.
G
H
H
The
answer
is
yes,
there
has
been
tremendous
adoption
right,
so
I'm,
the
federal
right,
bum
divide,
the
the
federal
government,
is
always
slow
to
adopt
things,
probably
the
same
for
any
government,
but
at
the
end
of
the
day,
we're
at
the
point
now
with
github
and
these
types
of
technologies
that
it's
table
stakes,
it's
its
power
and
cooling.
It
just
has
to
get
done.
So
the
answer
is
yes:
there's
there's
massive
adoption,
mainly
on
the
enterprise
side,
still
scared
of
of
calm
for
perceived
security,
that's
kind
of
a
religious
discussion
almost
so
we
don't.
C
This
is
won't
answer
for
github
in
this
sense
here
our
I
live
in
Victoria,
British,
Columbia
and
I
I'm
in
the
local
tech
community
up
there
working
with
government
and
things
like
this
there's
a
local
scene
called
Tech
Tori
up
there,
it's
kind
of
fun.
However,
when
every
time
every
time
you
have
to
have
a
conversation
with
the
government
sector,
it's
I
mean
I
thought
IBM
decision
making
was
slow.
This.
E
C
That's
a
Canadian
government
too,
so
it's
60%
watered-down,
but
it
is
incredibly
frustrating
because
it's
no
one
ever
you
don't
never
feel
that
anyone
has
power
to
make
a
decision.
Nor
has
the
budget
or
if
someone
has
that
ability
to
make
a
decision,
they
don't
have
the
budget
and
then
you
have
to
make
to
government
agencies
talk
to
each
other
just
to
do
any
simple
thing
and
that's
an
incredibly
frustrating
experience
and
if
you're
doing
it
nights
and
weekends,
it's
almost
not
worth
your
time.
So
God's
work
trying
to
sell
the
government
so
well.
A
We
actually
were
meeting
with
someone
earlier
who
said
in
the
day
as
few
years
ago.
It's
very
difficult
to
talk
about
open
source
and
sort
of
mid-level
management
and
down
were
no
we're,
not
gonna
do
open
source,
but
the
luxury
for
inspired
leaders,
I
guess,
was
well.
The
President
Obama
had
put
out
his
you're
gonna
use
open
source
as
much
as
you
can.
They
had
air
cover,
so
they
could
say.
Look
you
can't
challenge
this.
A
It's
coming
from
the
top
that
we
should
be
doing
this
so
that
kind
of
air
cover
in
government
as
well
as
air
cover
and
some
of
the
more
enlightened
businesses
we
work
with.
It's
really
beneficial
top-down
to
say.
We're
gonna
start
looking
at
things
like
this
and
I.
Think
you
got
that
same
statement
from
IBM
when
they
had
the
right
VPS,
who
are
pushing
this
yeah.
B
One
nice
thing
is
that
there's
been
some
amazing
people
from
the
tech
industry
go
into
government
with
the
explicit
goal
of
changing
the
culture
and
demonstrating
better
ways
of
working
like
I,
don't
know
if
you
know
Jays
humble
he
wrote
some
books
on
continuous
delivery.
He
went
to
work
for
the
I
forget,
which
website
it
was
with
the
explicit
goal
of
showing
that
continuous
delivery
can
work
in
a
federal
agency,
and
he
succeeded
so
I
think
there's
some
of
that.
That
will
help.
I
Hi
I
was
wondering
if
well,
this
conference
and
throughout
other
conferences,
I've
been
to
have
heard
a
lot
about
team
dynamics
and
how
traditional
companies
usually
look
at
teams
as
top-down
order
takers,
maybe
in
some
cases,
but
the
shift
is
kind
of
towards
more
decentralized
teams
and
without
the
hierarchy
and
those
teams
have
been
found
to
be
more
productive.
In
some
cases,
I'm
wondering
if
you
guys
have
seen
that
to
be
true
throughout
some
of
the
transformations
you've
seen
or
maybe
not
true.
B
I
mean
what
I've
seen
is
that
you
know
you've
got
these
buzzwords
like
DevOps
and
agile
and
there's
actually
real
thinking
behind
them
and
real
experience
behind
them,
and
that
the
risk
is
that
a
company
will
say,
let's
become
agile
and
not
really
understand
what
it
means.
But
the
good
case
is
where
an
executive
really
understands
a
principle
like
I'm,
going
to
define
an
outcome,
an
aggressive,
ambitious
outcome
and
then
assemble
an
interdisciplinary,
talented
team
to
achieve
that
outcome
and
then
we'll
have
regular.
B
We
call
them
playbacks
where
we
see
the
progress
towards
that
and
the
ability
to
course-correct
is
necessary,
but
I
guess.
For
me
it
really
depends
on
the
leader
to
Jason's
point
understanding
the.
Why
behind
the
new
way
of
working
and
then
then
actually
making
that
the
culture
and
in
my
experience
it's
hit
or
miss,
sometimes
the
leaders
get
it.
Sometimes
they
don't
I.
Guess
you
probably
see
this
every
company
you
talk
to
you
we're
already
agile.
We
already
do
DevOps,
it's
like!
Well,
why
aren't
you
kicking
ass
yeah.
C
This
to
me
is
one
of
those
things
where
people
actually
look
for
a
tool
to
solve
a
human
problem,
and
but
fundamentally
a
human
problem
and
to
me,
at
the
end
of
the
day,
comes
down
to
organizational
dynamics
and
leadership.
Frankly,
leadership
and
the
different
styles
that
will
and
won't
work
and
that
won't
will
resonate
and
won't
resonate
and,
at
the
end
of
the
day,
I
think
that
comes
down
to
that.
C
We
as
an
industry,
probably
need
to
do
better
on
that,
but
we
are
seeing
most
of
the
trend
go
to
that
decentralized
context
at
the
top
push
decision-making
as
far
down
the
stack
as
possible,
allow
people
to
be
autonomous
by
Taconic
but
accountable
and
a
transparent
way,
and
then
they
can
run
as
long
as
the
outcomes
are
there.
The
model
is
hard
and
it's
kind
of
scary,
if
you've
never
seen
it
before,
but
it's
also
the
one
that
is
more.
J
Hey
so
I
work
in
the
financial
services
industry,
which
is
similar
to
government
and
that
there's
a
lot
of
slow
decision-making
and
restrictions
on
what
we
can
jump
to
things
like
github
and
slack
and
I.
Think
a
lot
of
people
now
take
for
granted.
It's
like
that's
the
tool
also
have
enterprise
level
things
that
make
it
easier
for
regulated
industries
to
take
part
in.
J
Are
there
tools
that
you
guys
are
seeing
come
down
the
pipeline
that
you
think
in
the
future
are
gonna,
be
like
these
tools
that
everyone's
looking
around
being
like
you're,
not
on
slack
you're,
not
in
github,
like
what
are
you
doing,
but
that
also
might
have
the
foundational
like
support
for
people
like
in
government
and
financial
industries
to
actually
adapt
and
push
for
like
things
that
are
a
little
less
scrappy
and
more
like.
We
can
actually
push
this
for
empowerment
of
developers
in
those
industries.
I'll.
C
It's
in
of
each
country
adopts
a
certain
flow
on
that
cloud.
Computing
is
never
gonna,
you're,
never
gonna,
see
this
kind
of
uptake.
This
to
me
is
the
most
obvious
one
to
have
this
conversation
around,
because
it's
it's
so
critical
to
get
this
kind
of
sorted
quickly.
That's
not
a
tool!
It's
more
of
this
big
ol
perspective,
but
slack
runs
in
the
cloud
we
the
cloud.
K
B
Out
I
mean
not
so
much
that
they
got
outright
rejected,
but
there
were
certainly
ones
that
didn't
get
the
kind
of
uptake
that
we'd
wanted.
Where
we
started
with
github
and
slack
and
mural,
and
they
pretty
much
overnight
had
greater
than
ten
thousand
users.
We
naively
thought
that
every
additional
tool
would
have
a
same
dynamic,
but
for
instance,
we
try
to
put
a
CI
tool
out
there
and
it
got
a
couple
thousand
users,
but
it
couldn't
displace
Jenkins
and
it
couldn't
displace
some
of
the
other
tools
just
because
people
were
really
tied
to
it.
B
So
I
don't
really
know
what
the
formula
is.
That
causes
one
tool
to
get
that
sort
of
viral
adoption
and
another
tool
not
to
you,
but
but
I
guess
in
a
in
a
company
of
our
size.
You
can
always
you
know,
put
out
something
good
and
get
a
couple
thousand
users,
but
the
question
is:
will
it
hit
that
tipping
point
and
get
the
entire
internal
market.
B
C
C
I
think
Obama
kind
of
pushing
that
from
the
top
and
the
open
source
is
an
example
of
someone
who
saw,
try
and
need
to
get
in
front
of
it
and
wanted
to
push
a
progressive
stance
and
I
think
that
the
only
way
that
the
current
government,
or
even
probably
future
governments
of
the
not
as
progressive,
think
about
changing
their
stance
on
things,
is
basically
industry's
pressure
and
and
I.
Don't
like
that,
because
I
don't
like
companies
influencing
government
so
that
degree,
but
I
think
that
there
has
to
be
some
understanding
of
what
the
out.
B
Right,
I
guess
one
had
a
concrete
story
on
that
was
probably
before
your
time.
Probably
a
lot
of
things
are
before
your
time,
but
about
during
the
Obama
administration,
the
they
passed,
the
health
care
bill
and
they
put
up
this
website
healthcare.gov,
and
it
was
just
the
total
dumpster
fire.
The
site
didn't
really
work
for
people.
B
It
was
always
going
down,
so
I
created
a
crisis
and
there's
this
saying
I
think
I
forget
who
it
came
from,
but
it's
don't
let
a
good
crisis
go
to
waste
so
because
of
that
crisis,
Obama
surveyed
various
thought
leaders
in
the
industry
about
how
can
we
get
better?
And
it
was
through
that
that
he
started
to
hear
about
continuous
delivery
and
many
deployments
a
day
and
they
made
those
foundational
to
rebuilding
healthcare.gov
and
and
then
it
became
healthy
over
time.
B
E
Pressure,
hi
I,
just
I,
joined
github
a
few
months
ago,
actually
same
time
as
Jason,
so
I
thought
coming
in.
It
was
just
all
about
code.
Scm
then
quickly
learned
that
here
we
use
it
for
everything
even
planning
this
event
right.
So
I'm
curious.
You
know
in
an
implementation
as
large
as
IBM's.
That
is
that
happening.
Do
you
see
that?
How
much
is
code
versus
you
know
other
creative
uses?
If
you
will
that
aren't
just
you
know,
tied
to
developers,
yeah.
B
Well,
it
certainly
started
with
what
we
think
of
sort
of
the
hard
core
developers,
the
ones
who
use
every
feature,
but
then
over
time
it
kind
of
branched
out
into
people
who
were
just
using
issues
or
just
using
ecosystem
tools
like
Zen
hub
to
work
on
backlogs
and
things
like
that,
or
even
one
funny
thing
we
saw
was
one
day.
We
saw
an
influx
of
3,000
new
users.