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

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

paypal vs netflix in 2011

dna @ paypal 2011

not invented here. long release/feedback

cycles. inward focus. risk averse.

In 2011, even a simple content copy change could take as much as 6 weeks

to get live to site

two pizza teams anyone?

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

change is hard

behavior is deep seated and reinforced

organizations contain anti-bodies that resist change

yet we were able to bring real change

one of many comments…

thank you for making it fun again to develop code at PayPal

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

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

the mindset we took to bring change

two attitudes

persistence

persistence 1

persistance is not just being stubborn

persistance is based on strongly held beliefs

core belief: what teams need to succeed

core belief: what teams need to succeed

it’s who you work with

who

core belief: what teams need to succeed

it’s who you work with

who

we changed who we hired

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

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

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

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

belief: working across teams

belief: working across teams

shared understanding

belief: working across teams

shared understanding

deep collaboration

belief: working across teams

shared understanding

deep collaboration

continuous customer feedback

the right mindset for change

we moved from “defending the solution” to “embracing the problem”

improv 2

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

improv is not just ‘winging it’

we engineered improv into the system

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

most organizations biggest challenge is moving

from a culture of delivery to a culture of learning

most organizations biggest challenge is moving

from a culture of delivery to a culture of learning

LEAN ENGINEERING

engineering for learning

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

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

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

@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

enable prototyping in the engineering stackthe whole history of our newest tech stacks has been to enable rapid engineering

engineer for the “living spec”

enable prototyping in the engineering stackthe 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

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

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”

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”

we democratized engineering

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

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

we gave agile a brain

illustration credit: Krystal Higgins http://bit.ly/18uP7N1

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

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

questions?

persistence