Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Minimum Viable Bureaucracy

Minimum Viable Bureaucracy

Open source projects succeed with a minimum of process and management. How can you apply a chaordic open source approach to running your team?

Laura Thomson

July 25, 2013
Tweet

More Decks by Laura Thomson

Other Decks in Technology

Transcript

  1. this talk is for: people trying to lead a growing

    team people becoming leaders people wanting to change their team culture 2
  2. in architectural terms: architectures scale linearly for a while then

    blow up re-architect and continue team/company size is the same 4
  3. Dunbar’s number: a cognitive limit on the number of people

    with whom you can maintain relationships (theoretically: between 150-230) Dunbar, R.I.M. (June 1992). "Neocortex size as a constraint on group size in primates". Journal of Human Evolution 22 (6): 469–493. 5
  4. chaordic systems, trust and autonomy practicalities: process, artifacts, etc problem

    solving and decision making goals, scheduling, shipping managers, leaders overview 6
  5. chaord “any self-organizing, adaptive, nonlinear complex system, whether physical, biological,

    or social, the behavior of which exhibits characteristics of both order and chaos” -- Dee W. Hock http://www.myrgan.com/Inc/Literature_files/The%20Chaordic%20Organization.pdf 8
  6. John Lilly described Mozilla as chaordic: “high degree of chaos

    higher level order robust, failure-tolerant, creative” many open source projects like this and some companies http://www.slideshare.net/johnolilly/stanford-presentation-on-mozilla-presentation 9
  7. management: “get your ducks in a row” chaordic management: self-organizing

    ducks CCSA http://commons.wikimedia.org/wiki/File:Five_different_rubber_ducks.jpg 10
  8. the basis of any self-organizing system: trust “Nobody comes to

    work to do a bad job” Sidney Dekker, The Field Guide to Understanding Human Error 12
  9. how to build trust? time: many small deposits in the

    trust bank start by trusting others be trustworthy 13
  10. “We are all remoties” -- John O’ Duinn (Release Engineering

    @Mozilla) http://oduinn.com/images/2013/WeAreAllRemoties-Haas-feb2013.pdf 18
  11. remote teams enable hiring the best people good communication practices

    + high levels of trust = remote effectiveness 19
  12. shared communication spaces all work should have a URL IRC/campfire/whatever

    etherpads and wikis bug tracking email record meetings (video, audio, shared notes) record decisions 21
  13. team meetings alone can actually reduce communication waiting for a

    weekly team meeting (or even daily standup) is like waiting for an annual perf review 22
  14. for actual meetings agendas limit # of participants limit length

    clustered: maker’s schedule record (asynchrony) take notes (asynchrony) 24
  15. minimum viable (project) documentation how to install how to create

    and ship a change roadmap changelog glossary where to get help 25
  16. Problem solving and decision making Pierre-Yves Beaudouin / Wikimedia Commons

    / CC-BY-SA-3.0 http://commons.wikimedia.org/wiki/File:Mus%C3%A9e_des_sapeurs_pompiers_de_l%27Orne_-_37_-_r%C3%A8gle_%C3%A0_calcul.jpg 26
  17. open source decision making process: subject matter expert = module

    owner = BDFL seconds = peers = committers 29
  18. remember: self-organizing does NOT equal democracy self-organizing does NOT equal

    anarchy self-organizing systems emerge and converge but are not structureless 30
  19. allow primary owner or motivated champion time to make a

    prototype ...while not working on other stuff ...don’t let it go too long in isolation many architectural problems are bikesheds (c) John Myers, CCSA http://commons.wikimedia.org/wiki/File:Bike_shed,_Frances_Bardsley_High_School_for_Girls,_Romford_-_geograph.org.uk_-_561356.jpg 31
  20. “come with code” many of the hardest problems and rewrites

    are 80% done by one person in a two day marathon proof of concept + momentum gets people motivated, makes the path clear 32
  21. a portion of engineer’s time must be spent on what

    engineer thinks is most important it may be 100% it may be 60%, 40%, 20% but it should never be zero. 33
  22. collaborative architecture design (for the non-bikesheds) brainstorm the interfaces, split

    up and code interface design far more critical than component design 35
  23. goal: create a prototype (MMVP?) goal: decide changes to ship

    goal: get it deployable goal: ship MVP goal: ship v2 etc 41
  24. you forgot things 1.5, 4.5, 6, 7, 8, and 9

    (because you didn’t know enough yet) 47
  25. anti-estimation: prototype set timeboxes for prototypes set timeboxes for specs

    set timeboxes for shipping build the hardest part first iterate toward greatness 51
  26. many small frequent iterations, because: you get better at shipping

    time to prod is reduced time to improve is reduced blockages are not blocked for so long next version soon fights perfectionism 55
  27. if something’s not working for people, fix it don’t say

    “some day” do it now “start with what can be fixed today, before going home. use dividends from small improvements to put down payments on larger improvements” 58
  28. just like code: don’t aim for perfection change one thing

    at a time iterate towards greatness 59
  29. Why have managers? Public domain, thanks to Pearson Scott Foresman.

    http://commons.wikimedia.org/wiki/File:Derby_%28PSF%29.png 60
  30. a rose by any other name: founders team leads managers

    emergent leaders (think: open source) 61
  31. there is no such thing as a structureless organization structure

    may be emergent, but it’s there leaders guide emergent culture and structure in a constructive direction References http://flag.blackened.net/revolt/hist_texts/structurelessness.html http://eaves.ca/2009/07/06/structurelessness-feminism-and-open/ 62
  32. leaders and community rules emerge constructively or destructively: (think of

    web forums) (think of mailing lists) (think of open source projects) 63
  33. servant leadership model: be humble you are an enabler enabling

    is more important than doing (but don’t stop coding) introverts make great servant leaders Reference: Robert Greenleaf,“The Servant as Leader”, 1970 65
  34. Listening Empathy Healing Awareness Persuasion Conceptualization Foresight Stewardship Grow people

    Build community "The Understanding and Practice of Servant Leadership". Regent University. August 2005 66
  35. don’t stop coding? enabling more important than coding no code

    makes worse managers and harder to find your next job don’t do stuff on the critical path glue person / side projects 67 https://blog.mozilla.org/dmandelin/2011/07/19/tales-of-a-project-leader-i-the-glue-person/
  36. managers are an umbrella large company, bureaucratic company keep bureaucracy

    from raining on your team Credit Christoph Michels, CCSA, http://commons.wikimedia.org/wiki/File:Yellow_umbrella.JPG 69
  37. marketing/raise visibility: “this is a good team to join” “this

    is a good team to work on my stuff” “this team makes things I want to use” raises morale, strengthens ID and culture 70
  38. managers are mentors: challenge people enough delegate people are more

    capable than you think help them figure out where they want to go help them when they stumble 71
  39. on stumbles: first, no surprises every reason and person is

    different boredom, burnout, depression, crises, cruisers help them fix it, or help them find somewhere they will be happier 72
  40. remember, if all else fails, these goals: mastery autonomy purpose

    Reference: http://www.danpink.com/books/drive 73