(2017-09-09) Hill Software RAMPS

GeePaw Hill has TweetStorms about a RAMPS (Rhythm, Autonomy, Mastery, Purpose, and Safety) (Autonomy, Mastery, and Purpose) model of Software Development team Motivation: make great software by making great teams.

(He saves storify versions for his blog. I link to both sets below.)

Rhythm and Urgency: post tweet. obviously, every software release is a release in this sense, too. OR SHOULD BE. hmmm. there's a clue... one kind of tension & release is taking a deep breath, holding it, and then exhaling. let me ask you a question: how long can you hold your breath?and when you hold your breath a long time, does that first gasping out instantly restore you to normalcy? another clue.

Autonomy: How Freedom & Urgency Correlate: post tweet. if i say an individual doesn't feel he has autonomy, i'm saying he feels like he's just a machine at work, controlled entirely by others... the biggest known bang for the autonomy buck, the one that gets the most press, is quite largescale, and it has to do with time.... companies reduce or eliminate fixed hours and fixed locations for their workers... here's a fascinating thing: almost none of these companies have abandoned their experiments, and many have made them firmest policy. almost anything that makes me more of a human & less of a machine increases my sense of autonomy. let's look at some small ones... almost all "standard process" efforts reduce autonomy. try making every such standard fit on one page... i should be able to hand my new geek ALL of what she's required to do as a geek on three or four pages... the idea that that means they all work the same way is a boundary too far, and a classic instance of Idols of the Schema... remember my starting question was about how do i get my team to feel a sense of urgency? by the time we ask that, we're in trouble. and much of it comes from over-bounding, from loss of autonomy. we're in recovery mode... there's a special technique here. "catch them doing something wrong, then bless it." a team eschews the standard manual check-in and rolls a script where they ask the user two questions and automate all the rest. bless it.

• more on the "idols" - see Francis Bacon

Mastery as Motivator: post tweet: so what, as a manager, can you do to harness this motivational force of mastery?... onto the question of measurement. just, don't. no excel. no powerpoint. no reporting. you're going to have to watch & listen & live with... i want to morph the q "how do i instill sense of urgency?"... the new (sub) question: how do i present my individuals with the right size & shape of challenge to mesh with their "better"?... you're gonna have to learn their "better" a little, first. you can ask, and that will help. you can also watch, and that will help... you simply must work with people to find tasks that are not at the center of their current competency.... you simply must see tasks rotated among people who aren't task-specialists.... and you have to accept that the cost of this -- on-paper inefficiencies -- is more than repaid by the benefit -- a driven team... we work with geeks. geeks, by definition, love learning this shit. it is what we are, that love.

Purpose as Motivator: post tweet: purpose as motivator is about the sense an individual has that she's contributing to a greater Mission shared by many... purpose is really always purposes. seen "from above", it resembles a sloppily drawn cross-section of a stem...a larger (sloppy) boundary, decomposed into smaller (sloppy) circles, some nearly concentric, some nearly side-by-side, and so on...the first common mistake of the would-be purpose architect: to think one great big circle is enough... purpose here, is the grand one-sentence abstraction that sounds like overly verbose ad copy. it's a great big tube, w/ empty cross-section....it's simply not close enough to the ground. orgs like this are usually hopelessly random in their actions. and possessed of low morale... another failure of purpose, is to populate the interior of our cross-section with a million perfectly designed same-size sub-purposes...... think of this as like giving every tiny sub-team of 3 people a completely separate purpose from every other sub-team.... it makes your org not an org, just a large collection of small groupings. same effect: random action and low morale... somewhere between those two extremes is a sweet spot. larger purposes loosely shape and contain smaller ones, and so on... we edge away from the woody stem towards the brain stem... there are broad groupings or functional areas in your brain. but they're loose as hell... first. your individuals must be conversant with all the nested purposes in which they live up to that great mission statement above... second, they need to be conversant with how they fit with their most-immediate purpose-neighbors as well... then, make sure the boundaries between purposes that are most frequently in contact are highly permeable... another piece of advice: be careful not to conflate purpose with either metric or instrument... finally? you'll hate this. give up this Deadline business altogether... there are myriad ways to organize your work and predict your future and win that don't involve deadlines at all... as a manager, a big part of your job is actually finding and using these. as an executive, it's most of your job.

Safety: post tweet: safety is the sense we have that we belong: that we're trusted, valued-in-spite-of, inside a team that welcomes our strange unruly selves... psychological safety is important for several reasons... first, it enables what we call courageous curiosity. the will to ask a question and get a real answer, however hard, and work with it... third, it lets us see our shared purpose from the widest possible view, which gives us myriad more ways to contribute to it... fourth, it lets us apply all of our character to the sustenance of the team, not just the "ordinary" and "expected" bits... if you can't make mistakes and adjust, how do you expect them too? if they can't make mistakes and adjust, how do you expect progress? encourage every one and every thing and every meme your individuals think is funny & not mean... the most effective thing you can do is model, over and over. make mistakes. laugh. forgive. accept. re-direct. a safe team is a rocking team. they'll produce a fountain of ideas for you, and ideas are the fundamental unit of software progress. how do i instill urgency? a safe team is driven to use itself -- all of itself -- to secure its purpose at top sustainable energy. try it.

Ron Jeffries discusses: asking people to live with a sense of urgency is both cruel and ineffective, especially in software development. Cruel because why should people work 8 or so hours every day in a panic? Ineffective because software development is mental work and when you are feeling a sense of urgency, your mind flails around, you thrash, you make mistakes, you cut corners.