Minimum Viable Bureaucracy, June 2014 Edition

Slide 1

Slide 1 text

Minimum Viable Bureaucracy Laura Thomson laura@laurathomson.com/laura@mozilla.com @lxt (CCSA) http://en.wikipedia.org/wiki/File:NARA_Backstage_Pass_%282011-08%29_-_14.jpg !1

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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_ﬁles/The%20Chaordic%20Organization.pdf !8

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

chances are you will end up with more than one ofﬁce !20

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

“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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Goals, scheduling, shipping !38

Slide 39

Slide 39 text

...and (anti)estimation !39

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Why does estimation fail? !42

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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 ﬁghts perfectionism !55

Slide 56

Slide 56 text

emergent process !56

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

if something’s not working for people, ﬁx it don’t say “some day” do it now ! “start with what can be ﬁxed today, before going home. use dividends from small improvements to put down payments on larger improvements” ! !58

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

ﬂat/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://ﬂag.blackened.net/revolt/hist_texts/structurelessness.html http://eaves.ca/2009/07/06/structurelessness-feminism-and-open/ !62

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

don’t stop coding? ! enabling more important than coding but no code makes worse managers and harder to ﬁnd 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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

ask questions instead of giving answers use Socratic/Confucian/Rabbinical method builds people, knowledge, conﬁdence !72

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

questions? Laura Thomson laura@laurathomson.com/laura@mozilla.com @lxt https://speakerdeck.com/lauraxt/minimum-viable-bureaucracy !75