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

Minimum Viable Bureaucracy, June 2014 Edition

Minimum Viable Bureaucracy, June 2014 Edition

Chaordic, emergent process HOWTO

Laura Thomson

June 25, 2014
Tweet

More Decks by Laura Thomson

Other Decks in Technology

Transcript

  1. Minimum Viable
    Bureaucracy
    Laura Thomson
    [email protected]/[email protected]
    @lxt
    (CCSA) http://en.wikipedia.org/wiki/File:NARA_Backstage_Pass_%282011-08%29_-_14.jpg
    !1

    View Slide

  2. this talk is for:
    !
    people trying to lead a growing team
    people becoming leaders
    people wanting to change their team culture
    !2

    View Slide

  3. your approach scales
    until it doesn’t
    image credit: http://xkcd.com/55/
    !3

    View Slide

  4. in architectural terms:
    architectures scale linearly for a while
    then blow up
    re-architect and continue
    !
    team/company size is the same
    !4

    View Slide

  5. Dunbar’s number: a cognitive limit on the number of people with
    whom you can maintain relationships
    (theoretically: between 150-230)
    (It’s not great science, but the mental model has merit)
    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

    View Slide

  6. chaordic systems, trust and autonomy
    practicalities: process, artifacts, etc
    problem solving and decision making
    goals, scheduling, shipping
    managers, leaders
    !6

    View Slide

  7. Chaord, trust, autonomy
    L rempe, CCSA http://commons.wikimedia.org/wiki/File:Julia_Set_Of_Linearizer.png
    !7

    View Slide

  8. 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

    View Slide

  9. 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

    View Slide

  10. chaordic management:
    !
    self-organizing ducks
    CCSA http://commons.wikimedia.org/wiki/File:Five_different_rubber_ducks.jpg
    traditional management:
    !
    get your ducks in a row
    !10

    View Slide

  11. CCSA, Credit: Manu Cornet, http://www.bonkersworld.net/organizational-charts/
    !11

    View Slide

  12. 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

    View Slide

  13. how to build trust?
    !
    time: many small deposits in the trust bank
    start by trusting others
    be trustworthy
    build relationships outside of tense environments
    !13

    View Slide

  14. “Hire people you believe you can trust.
    Trust them.”
    -me
    !14

    View Slide

  15. trust enables autonomy
    autonomy enables engineer happiness
    autonomy enables leader scaling
    !15

    View Slide

  16. Practicalities
    Public domain, thanks to Evan-Amos http://commons.wikimedia.org/wiki/File:Duct-tape.jpg
    Practicalities
    !16

    View Slide

  17. awesome communication practices...require practice
    over-communicate
    effective remote teams are good at this
    write/record more things
    !
    asynchrony is key
    !17

    View Slide

  18. “We are all remoties”
    -- John O’ Duinn
    (formerly Release Engineering @Mozilla)
    http://oduinn.com/images/2013/WeAreAllRemoties-Haas-feb2013.pdf
    !18

    View Slide

  19. remote teams enable hiring the best people
    !
    good communication practices
    +
    high levels of trust
    = remote effectiveness
    !19

    View Slide

  20. chances are
    you will end up with more than one office
    !20

    View Slide

  21. shared communication spaces
    all work should have URLs
    IRC/campfire/whatever
    etherpads and wikis
    bug tracking
    email
    record meetings (video, audio, shared notes)
    record decisions
    !21

    View Slide

  22. 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

    View Slide

  23. %s/meeting/conversation/g
    collaborative problem solving
    maintenance windows
    triage
    communication between teams
    1:1s
    show and tell
    postmortems
    !23

    View Slide

  24. for actual meetings
    !
    agendas (skip if empty)
    limit # of participants
    limit length
    clustered: maker’s schedule
    record (asynchrony)
    take notes (asynchrony)
    !24

    View Slide

  25. minimum viable (project) documentation
    !
    how to install
    how to create and ship a change
    roadmap
    changelog
    glossary
    where to get help
    !25

    View Slide

  26. 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

    View Slide

  27. a.k.a.
    Applying an open source model
    !27

    View Slide

  28. tl;dr
    subject matter experts emerge
    make sure they have seconds
    rotate unwanted responsibilities
    !28

    View Slide

  29. open source model
    open source decision making processes vary, but patterns emerge:
    !
    subject matter expert = module owner = BDFL
    seconds = peers = committers
    !29

    View Slide

  30. remember:
    self-organizing does NOT equal democracy
    self-organizing does NOT equal anarchy
    !
    self-organizing systems emerge and converge but are not
    structureless
    !30

    View Slide

  31. 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

    View Slide

  32. “come with code”
    !
    many of the hardest problems and rewrites are 80% done by one
    person in a two day marathon (then of course the other 80%)
    proof of concept + momentum
    gets people motivated, makes the path clear
    !32

    View Slide

  33. a portion of each engineer’s time must be spent on what that
    engineer thinks is most important
    it may be 100%
    it may be 60%, 40%, 20%
    but it should never be zero.
    !33

    View Slide

  34. remember: push responsibility to the edges
    remember: open source models
    remember: freedom to innovate
    !34

    View Slide

  35. collaborative architecture design
    (for the non-bikesheds)
    brainstorm the interfaces, split up and go
    !
    interface design + decoupling far more critical than component design
    !35

    View Slide

  36. architectural goals:
    decoupled replaceable components
    clear interfaces/APIs
    tests for each component
    !36

    View Slide

  37. operational problem solving: same principles
    evidence > gut feelings
    problem immersion
    operational mindset is a key skill
    !37

    View Slide

  38. Goals, scheduling, shipping
    !38

    View Slide

  39. ...and (anti)estimation
    !39

    View Slide

  40. minimum viable product applies to everything
    everything
    everything :)
    !
    (viable is where you’ll bikeshed here)
    iterate toward greatness
    !40

    View Slide

  41. goal: create a prototype (MMVP?)
    goal: decide changes to ship
    goal: get it deployable
    goal: ship MVP
    goal: ship v2
    etc
    !41

    View Slide

  42. Why does estimation fail?
    !42

    View Slide

  43. detailed up front estimation of whole project
    vs
    agile: velocity/burndown/sprints
    !
    agile (etc) works better, but why?
    !43

    View Slide

  44. agile methodologies are a way of
    (secretly)
    admitting (large) estimation is always wrong
    !44

    View Slide

  45. Big$So'ware$Project$™$
    Thing$1$
    Thing$2$
    Thing$3$
    Thing$4$
    Thing$5$
    !45

    View Slide

  46. build project plan
    bask in smug self-confidence
    ...until project goes off the rails
    !46

    View Slide

  47. you forgot things 1.5, 4.5, 6, 7, 8, and 9
    (because you didn’t know enough yet)
    !47

    View Slide

  48. thing 5 turns out to be infernally difficult
    (optimal solution to NP-complete problem, requires FTL travel,
    requires no network partitions ever, etc, etc)
    !48

    View Slide

  49. thing 4 is blocked on someone else’s team
    ...who have more important things to do
    !49

    View Slide

  50. emergent/chaordic approaches - bottom up
    estimation - top down
    !
    inherently in conflict
    what can you do instead?
    !50

    View Slide

  51. anti-estimation:
    !
    prototype
    set timeboxes for prototypes
    set timeboxes for specs
    set timeboxes for shipping (limit scope to fit the box)
    build the hardest part first
    iterate toward greatness
    !51

    View Slide

  52. don’t commit to estimates for unknown tasks
    !
    just say no.
    !52

    View Slide

  53. never-done-ness
    !
    fight macro-perfectionism
    aim for micro-quality
    good code with tests in each iteration
    iterate to better quality
    !53

    View Slide

  54. ruthlessly murder scope creep
    your new favorite phrase:
    “not in this iteration”
    !54

    View Slide

  55. many small frequent iterations/short cycle times, because:
    !
    you get better at shipping by shipping a lot
    time to prod is reduced
    time to improve is reduced
    blockages are not blocked for so long
    next version soon fights perfectionism
    !55

    View Slide

  56. emergent process
    !56

    View Slide

  57. important to iterate on process
    ...as you would on product
    !57

    View Slide

  58. 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

    View Slide

  59. just like code:
    !
    don’t aim for perfection
    change one thing at a time
    iterate towards greatness
    !59

    View Slide

  60. Why have managers?
    Public domain, thanks to Pearson Scott Foresman. http://commons.wikimedia.org/wiki/File:Derby_%28PSF%29.png
    Why have managers at all?
    !60

    View Slide

  61. a rose by any other name:
    !
    founders
    team leads
    managers
    emergent leaders (think: open source)
    !61

    View Slide

  62. flat/structureless
    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

    View Slide

  63. leaders and community rules emerge constructively or destructively
    !
    (think of web forums)
    (think of mailing lists)
    (think of open source projects)
    !63

    View Slide

  64. manager/leader jobs:
    !
    recruitment
    support, transmit, guide culture
    mentorship
    prioritization
    big picture
    do the things no-one else wants to do
    !64

    View Slide

  65. 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

    View Slide

  66. Listening
    Empathy
    Healing
    Awareness
    Persuasion
    "The Understanding and Practice of Servant Leadership". Regent University. August 2005
    Conceptualization
    Foresight
    Stewardship
    Grow people
    Build community
    !66

    View Slide

  67. don’t stop coding?
    !
    enabling more important than coding
    but no code makes worse managers
    and harder to find your next job
    don’t do stuff on the critical path
    glue person / side projects
    https://blog.mozilla.org/dmandelin/2011/07/19/tales-of-a-project-leader-i-the-glue-person/
    !67

    View Slide

  68. 1:1
    three questions
    what are you working on?
    what’s blocking you?
    how can I help?
    !
    then, listen.
    !68

    View Slide

  69. 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

    View Slide

  70. 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

    View Slide

  71. managers are mentors:
    challenge people enough
    people are more capable than you think
    help them figure out where they want to go
    help them when they stumble
    !71

    View Slide

  72. ask questions instead of giving answers
    use Socratic/Confucian/Rabbinical method
    builds people, knowledge, confidence
    !72

    View Slide

  73. on stumbles:
    !
    first, no surprises
    shorten feedback cycle time: instant, explicit
    every reason and person is different
    boredom, burnout, depression, crises, cruisers
    help them fix it, or help them find somewhere they will be happier
    !73

    View Slide

  74. remember, if all else fails, these goals:
    !
    mastery
    autonomy
    purpose
    Reference: http://www.danpink.com/books/drive
    !74

    View Slide

  75. questions?
    Laura Thomson
    [email protected]/[email protected]
    @lxt
    https://speakerdeck.com/lauraxt/minimum-viable-bureaucracy
    !75

    View Slide