This talk was given at YOW 2016 in Melbourne, Brisbane & Sydney Australia, December 2016. Change in an organization is really hard. This is especially true when a company that was once on the forefront of innovation finds itself having lost that luster through its own growth & success. The past few years there has been a transformation happening at PayPal that is touching every part of the organization to make it innovative again. At the heart of this change is engineering innovation coupled with a new, close partnership between product, design and engineering. Can your organization be changed? From Bill’s experience at Yahoo!, Netflix, PayPal and consulting with numerous companies he believes there are some core principles you can employ to drive transformation that are all centered around the customer. The question Bill will explore is “How can engineering and design be the catalyst for that change?” While this talk will be inspirational, it will take an honest (and humorous) look at what has worked and what hasn’t worked so well in trying to scale change.

1. bringing change
to life lessons learned at
netflix & paypal
Bill Scott
VP, Consumer & Venmo Engineering | Identity | Next Gen Commerce
YOW!
December 2016
Melbourne | Brisbane | Sydney
@billwscott
twitter | linkedin | paypal

2. outside-in culture
continuous customer feedback (get
out of the building - GOOB)
customer data central to decisions
think it. build it. ship it. tweak it
fail fast. learn fast.
experimentation... build/measure/
learn

3. paypal vs netflix in 2011

4. dna @ paypal 2011
not invented here. long
release/feedback
cycles. inward focus.
risk averse.

6. In 2011, even a simple
content copy change could
take as much as 6 weeks
to get live to site

7. two pizza teams anyone?

8. culture = (norms of behavior) +
(underlying shared values)

9. change is hard

10. behavior is deep seated
and reinforced

11. organizations contain anti-
bodies that resist change

12. yet we were able
to bring real change

16. one of many comments…
thank you for making it fun
again to develop code at
PayPal

17. from 2012 to now…
went from 1 app on nodejs to 120+
apps on node; went from a couple of
engineers working on nodejs to 100s
of engineers across PayPal, Xoom &
one of many comments…
thank you for making it fun
again to develop code at
PayPal

18. from 2012 to now…
went from 1 app on nodejs to 120+
apps on node; went from a couple of
engineers working on nodejs to 100s
of engineers across PayPal, Xoom &
from 2012 to now…
went from arguably the worst
frontend tech stack in Silicon Valley to
be being recognized as industry
leader in nodejs & javascript
one of many comments…
thank you for making it fun
again to develop code at
PayPal

28. the mindset we took to
bring change
two attitudes

29. persistence

30. persistence 1

31. persistance is
not just being
stubborn

32. persistance is based
on strongly held
beliefs

33. core belief: what teams need to succeed

34. core belief: what teams need to succeed
it’s who you
work with
who

35. core belief: what teams need to succeed
it’s who you
work with
who
we changed
who we hired

36. core belief: what teams need to succeed
it’s who you
work with
who
it’s what you
work on
what
we changed
who we hired

37. core belief: what teams need to succeed
it’s who you
work with
who
it’s what you
work on
what
we changed
who we hired
we wrote a
new story

38. core belief: what teams need to succeed
it’s who you
work with
who
it’s what you
work on
what
it’s how you
work
how
we changed
who we hired
we wrote a
new story

39. core belief: what teams need to succeed
it’s who you
work with
who
it’s what you
work on
what
it’s how you
work
how
we changed
who we hired
we wrote a
new story
we moved to
lean ux/
engineering

40. belief: working across teams

41. belief: working across teams
shared
understanding

42. belief: working across teams
shared
understanding
deep
collaboration

43. belief: working across teams
shared
understanding
deep
collaboration
continuous
customer feedback

44. the right mindset for change
we moved from
“defending the solution” to
“embracing the problem”

45. improv 2

46. improv is based on
humility to listen and
adapt to what you
hear

47. improv is
not just ‘winging it’

48. we engineered improv into the system

49. prototype the change
whiteboard
to code
code to usability
product/design/engineering in a tight loop with our customers
lean ux & lean engineering in action

50. most organizations biggest challenge is moving
from a culture of delivery to a culture of learning

51. most organizations biggest challenge is moving
from a culture of delivery to a culture of learning
LEANENGINEERING
engineering for learning

52. software must adapt
Our software is always tearing itself apart
(or should be)
Recognize that different layers change at
different velocities
All buildings are predictions.
All predictions are wrong.
There's no escape from this
grim syllogism, but it can be
softened.
- Stewart Brand

53. launching the ps3 (2010)
4 unique experiences launched the same day
several variations on each: 16 different test cells
2 different tech blogs simultaneously gave great review —
but were reviewing difference experiences
focus was on build/measure/learn

54. enable lots of little bets
the big bet. ramping model results in
one experience (with some tweaks
along the way) after a long ramp up
time
lots of little bets. experimentation
model results in many experiences
being tested all along the way
vs

55. @netflix: engineered for learning
netflix chose html5 for mobile (iOS, android) and
for game consoles, blu-ray players, hd-tvs, etc.
more recently moved to react native variant (JS)
to drive native experiences without the DOM
in both cases why?
path to build/measure/learn

56. enable prototyping in the engineering stack
the whole history of our newest
tech stacks has been to enable
rapid engineering
engineer for the “living spec”

57. enable prototyping in the engineering stack
the whole history of our newest
tech stacks has been to enable
rapid engineering
engineer for the “living spec”
make prototyping a first
class member of tech
stack

58. a tale of two trains - the product manager’s dilema

59. a tale of two trains - the product manager’s dilema
departs infrequently
“gotta get my features on this train
or I will have to wait a long time”

60. a tale of two trains - the product manager’s dilema
departs infrequently
“gotta get my features on this train
or I will have to wait a long time”
departs all the time
“if I miss this train another one comes
in a few minutes”

61. we democratized engineering

62. democratize the code base
starting to use git repo model for continuous deployment
marketing pages
product pages
content updates & triggers into i18n, l10n, adaptation
components
works well with cloud deployment (devops model)
enables the train to be leaving all the time

63. work in open source model
internal github revolutionizing
our internal development
rapidly replacing centralized
platform teams
innovation democratized
every developer encouraged
to experiment and generate repos
to share as well as to fork/pull request

65. we gave agile a brain
illustration credit:
Krystal Higgins
http://bit.ly/18uP7N1

66. agile is just a machine
it will crank ‘stuff’ out
it can be good or bad stuff
please don’t waste the machine
have a tight loop with our users
iterate to get experience “in the ballpark”
make it easy to iterate designs ahead of agile sprints

67. agile is just a machine
it will crank ‘stuff’ out
it can be good or bad stuff
please don’t waste the machine
have a tight loop with our users
iterate to get experience “in the ballpark”
make it easy to iterate designs ahead of agile sprints
the “brain” is our user

68. questions?
persistence