Minimum Viable Bureaucracy

Slide 1

Slide 1 text

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

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) 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 overview 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

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

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 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 (more on this in a bit) 15

Slide 16

Slide 16 text

Practicalities Public domain, thanks to Evan-Amos http://commons.wikimedia.org/wiki/File:Duct-tape.jpg 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 (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 a URL 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 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 decision making process: 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 proof of concept + momentum gets people motivated, makes the path clear 32

Slide 33

Slide 33 text

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

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 code interface design 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 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 :) 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, 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 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, 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 ﬁ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 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

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 Conceptualization Foresight Stewardship Grow people Build community "The Understanding and Practice of Servant Leadership". Regent University. August 2005 66

Slide 67

Slide 67 text

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

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 delegate 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

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

questions? Laura Thomson [email protected]/[email protected] @lxt 74