The document discusses unconventional approaches to risk management in fast-growing companies. It advocates for limiting risk by testing ideas quickly with small groups of users rather than lengthy planning and debate. It also emphasizes the importance of working software over detailed project plans and status reports. Additionally, it suggests that companies should intentionally expose themselves to more problems and failures in order to learn faster through real-world experiences, rather than solely focusing on prevention. Quality is discussed as emerging from collaborative learning across teams rather than strict standardization or individual heroics like being paged at unusual hours.

1. Risk at warp speed
Unconventional risk control in high growth
environments

2. At warp speed: you can’t afford to worry about the wrong risks

3. Limit risk by failing fast
“Arguments about whether or not a feature idea is worth doing or not generally
get resolved by just spending a week implementing it and then testing it on a
sample of users, e.g., 1% of Nevada users.”
- Facebook

4. Original Wizard Express Wizard
Account > Trial
(Started Trial)
Trial > Wizard
(Completed Wizard)
Wizard > Paying
(Paying Customer)
ACCOUNT > PAYING CUSTOMER
(Overall Conversion)
77%
67%
31%
16%
90%
99%
18%
16%

5. Project plans vs working software
“Working software is the
primary measure of progress”
- Principles of Agile software development
“Responding to change over
following a plan”
- Manifesto for Agile software development

6. No status reports or project managers

7. We do traffic light some things

8. Convention wisdom = Prevention is better than recovery

9. But it should now be re-visited

10. Make bad things happen more often
“Do more painful things more
often!”
- Adrian Cockroft, Architect at Netflix

11. Karma as quality control at Facebook

12. Quality through being paged at 3am

13. How standardisation causes risk

14. The new standardisation is sharing learning
Group
1
Group
2
Group
3
PO / BA Discipline
Dev Discipline
FE Dev Discipline
QA Discipline
Dev
Practice
lead
FE
Practice
lead
QA
Practice
lead
We want people in the same discipline across different
Product Groups and different offices to share best practices
and tooling
Practice leads are peer recognised contributors and
coordinate the establishment and roll out of best practices,
training and guidelines to make disciplines more effective.
Similar to team leads, they will need some time carved out
from their Pod work to be good Practice leads
For example Practice leads form: coding conventions and
standards, training and induction for discipline members,
testing practices and approaches, release optimization and
practices
A Practice lead must be recognised by their peers as
influential or an expert before they are eligible to be Practice
lead
This provides a technically oriented career path

15. “Own what you're responsible for but don't limit yourself
to that - look for opportunities to add value wherever
you can and are able. Own improving any code you
touch to make it just a little bit better. #Ownership”
Questions?