Learning to Fail

Talk about team culture, learning to fail and making it an asset to your team's goals.

Transcript

1. Learning to Fail Friday, January 27, 2012
2. Open source software to improve the lives of people living in poverty. Friday, January 27, 2012
3. — Friday, January 27, 2012
4. Africa 1 billion people 500 million phones Friday, January 27, 2012
5. 25 Botswana 26 Zwaziland 18 South Africa 24 Lesotho Africa People hardest hit by HIV/AIDS are also those least likely to have access to relevant information. Friday, January 27, 2012
6. Friday, January 27, 2012
7. FAIL Friday, January 27, 2012
8. Hindsight is a luxury. Friday, January 27, 2012
9. 5 years of growing pains. Friday, January 27, 2012
10. 0 6 12 18 24 30 36 Patients Not Returning Before After Friday, January 27, 2012
11. How hard can it be? Friday, January 27, 2012
12. Deceptively simple. Lack of ownership. Being too clever. Friday, January 27, 2012
13. What is it we’re building? Friday, January 27, 2012
14. Friday, January 27, 2012
15. One hammer to rule them all. Friday, January 27, 2012
16. Hit scaling issues hard & fast. Friday, January 27, 2012
17. Commitment issues. Friday, January 27, 2012
18. 800,000+ Uniques Friday, January 27, 2012
19. 0 25000 50000 75000 100000 June 2010 October 2010 May July Sept Nov Friday, January 27, 2012
20. Architecture prevented efficient caching. Friday, January 27, 2012
21. Metrics killed the site. Friday, January 27, 2012
22. Mild tunnel vision. Slight frameworkitis. Friday, January 27, 2012
23. Everything breaks at scale. Friday, January 27, 2012
24. Team Culture Implications Friday, January 27, 2012
25. You reproduce what you are. Friday, January 27, 2012
26. “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations” – Melvin Conway Friday, January 27, 2012
27. A software system will reflect the social structure of the organization that produced it. Friday, January 27, 2012
28. Failures are to be expected. Friday, January 27, 2012
29. Focus on small teams, few organizational layers. Friday, January 27, 2012
30. Introduce small changes. Minimize risk. Friday, January 27, 2012
31. Ship all the time. Friday, January 27, 2012
32. Avoid organizational silos, reduce bus factors. Friday, January 27, 2012
33. Trust, Cooperation & Transparency. Friday, January 27, 2012
34. Emphasize learning, code reviews & shared responsibility Friday, January 27, 2012
35. Team communication tools are vital. Friday, January 27, 2012
36. Kill your darlings. Embrace change. Friday, January 27, 2012
37. Broken gets fixed but shitty lasts forever. Friday, January 27, 2012
38. Technical Implications Friday, January 27, 2012
39. Queue everything and delight everyone. Friday, January 27, 2012
40. Automate everything. Friday, January 27, 2012
41. Continuous Integration Friday, January 27, 2012
42. Code reviews. Friday, January 27, 2012
43. Make deploys easy. Friday, January 27, 2012
44. Metrics should be cheap. Friday, January 27, 2012
45. Failing adds value. Friday, January 27, 2012
46. Thanks. Friday, January 27, 2012
47. Thanks. Friday, January 27, 2012
48. @smn http://github.com/praekelt Friday, January 27, 2012