Endpointing vs Next-Stepping

i mentioned endpointing yesterday. i’m always using geepaw-isms & expecting people to know what i mean. endpointing is over-focus on eventual destination. in s/w, it’s seeing development as a long trip to a known destination on a known map.

john winthrop, a few centuries back, used “the city on the hill” to describe an endpoint, in his case for the puritan colony. the metaphor, of a trip to a place, is as natural as any human expression. but it contains within it some very misleading ideas. it’s easy to slip from “going from here to an imaginary place” into “going from NY to LA”. (cheap shot about imaginary LA elided.)

the nature of complexity is such that predictability (Y-axis) mapped to time (X-axis) isn’t remotely linear. it has a very sharp knee. predictability gently curves slightly downward as we move out in time, then suddenly drops precipitously.

where’s that drop-point in s/w? well, we could argue, of course. it’s clearly before we get to 90 days. i’d argue it’s much further left. IME within a few weeks, predictability virtually vanishes. YMMV, but whatever u take the value to be, watch it and remember it and attend.

now, the city on the hill of our software efforts is nearly *always* further away than a few weeks, usually further away than a quarter. no worries, we say: we’ll break the duration into periods shorter than knee and we’ll add them all together. we’ll *decompose*.

again, this is a natural choice. unfortunately, it’s not a rational choice in the face of genuine complexity.

you’re thinking of each decomposed segment like a line segment, and you will line them all up to get from NY to LA. but you’ve forgotten some critical things.

1) the segments may be of fixed length in time, but they aren’t of fixed length in productivity. we account for this w/over-estimates. or rather, we try to. but the unfixed production length isn’t the only problem.

2) the segments are of variable length AND their of variable orientation. they all *start* where the last ended. but even mild unpredictability means they head off at angles different from the earlier direction. the consequence is that we’re continuously being thrown “out of line” by various amounts.

3) the city on the hill is not actually LA on a roadmap. it is an idea, a schema, a theory, a vision. and just as we’re moving, so is it. it isn’t just the market that changes, it’s really *everything* related to our vision, including us.

“endpointing” hurts us more than it helps us. the ideas built into it carry over into our process & planning in nefarious ways.

it encourages us to make commitments we can’t possibly keep. that in turn encourages lots of very counter-productive behavior. death marches. contract-style litigation. factional war. blame-shifting. the list goes on and on.

it encourages us to mislead. we mislead ourselves, each other, our customers, our shareholders. i work hard to avoid words like “evil”, but this is a kind of structural madness. because it sets up zero-sum, all wins for one are losses for others. the pie never grows, it’s only distributed differently.

how do we change this?

well. a start. we need to, i’m reminded of the great New York magazine competitions, “block that metaphor!”

software development at even moderate scale is never “NY to LA in 60 days”. never. i’m sore tempted to propose “exploration”, but even that doesn’t cut it. pick an arbitrary average scumbag explorer, say lewis & clarke. they had a city on the hill, but it was really just “west to the pacific”. they did not know the way. they often didn’t know where they were

that’s the *good* part of that metaphor. they optimized for stepping, for sustenance, for collaboration, for motivation. they embraced change rather closely.

the bad part of the exploration metaphor: land is land. it changes very slowly. it almost never drops out from under you. reasonably well-scouted routes don’t suddenly become impassable. and most tellingly, lewis & clarke got to move the same stuff every day.

in software, the stuff we move gets *bigger* and *different* every day. it’s as if we built at every camp site a new, larger, different, more populous, house, then set out the next day to move it further along.

so i can’t fully embrace the exploration metaphor, because radical unpredictability & ever-increasing burden aren’t there.

still. it’s a start. how does this add up to advice?

well, i’ve said it. optimize for small doable/undoable steps. optimize for motivation, the engine that keeps us going. optimize for collaboration, the source of most of the ideas we’ll need. optimize for sustenance, harvesting value as we go. some keys:

  1. don’t waste an inordinate amount of time arguing about what color to paint the walls in the city on the hill.
  2. choose steps based on “not definitely backwards” rather than “leads in a straight line to target”.
  3. believe that the land will in fact drop right out from under you, so always remember undoability.
  4. give 75% of your attention to this week, 20% to this month, and 5% to this year.
  5. harvest every inch of value you find every step of the way by handing it to customers.

the opposite of “endpointing” is “next-stepping”. train people in these ideas, AT EVERY LEVEL. they’re relevant in code, process, planning.

and the “NY to LA”? block that metaphor.

“Avoid Changing Code” Should Be Avoided

Of all the bad advice the geek trades inherit from over-simplified manufacturing & engineering, perhaps the worst: “avoid changing code”.

Take a minute, and think of all the things the trade does to avoid changing code. Virtually every element of “big design up front” policy is based in this view. Long stretches for analysis, longer ones for design. Planning cycles that extend years into the future. Years. I am not exaggerating for effect. Years. Contract-like specifications, database designs that start with hundreds of tables. So-called security systems that make exposing an endpoint a six-month four-committee process. All of the variety of viewpoints we call endpointing — trying to create a complex system by drawing a straight line from here to there. Think of this huge investment. And it’s all because we are trying to avoid changing code.

Why? What’s so bad about changing code? There’s a long list of potential answers to that question. But they seem to fit conveniently into two rationales.

Rationale 1: Changing code is bad because it means doing the same work twice. (An inheritance from manufacturing faux-efficiency.)

Rationale 2: Changing code is bad because it introduces potentially wild uncertainty. (An inheritance from engineering faux-science.)

The argument from efficiency is rooted firmly in construction. If you don’t dig the basement now, it’s far harder to dig it later. One hears that exact metaphor with some frequency. And it has some application to software, but not much. There are a small number of things it’s best to implement first. These take the form of things we think geekfully of as “aspects” in aop.

Localization is a good example. The later we put off localization, the harder it gets to do. But most of software isn’t like digging a basement. Most of software isn’t aspect-y like this, touching everything everywhere. Most of the things we worry about when we endpoint our systems are things the geeks could change any time we wanted at very low price. Now, let’s be careful here. Not all geeks. 🙂 People trained heavily in change-avoidance need to be re-trained before they can do this. Code bases mired in change-avoidance need to be re-worked before this can be done to them. The point is, if we’re not avoiding code change, code change from an efficiency point of view is basically net-neutral. (More later).

What about the argument from uncertainty? The gist: “Don’t touch that, you don’t know what it’s connected to.” Whenever I hear this, I think to myself, ummm, gee. Why don’t I know what it’s connected to? The idea’s that computer software is a dark mysterious place, full of indeterminacy and randomness. Changing code means radical uncertainty. This is, to put it as mildly as I can bear to, “not true”. Computers work because they do the same thing in the same situation every single time. That’s the exact opposite of uncertainty.

To be sure, them doing the same thing in the same situation every time can confuse humans. This happens because we think the situation is the same but the computer does not. Computers are very picky, people are loosey-goosey. But changing code doesn’t introduce uncertainty, it reveals and heightens uncertainty that was already present. Another way to say this: If you know exactly what the “before” does, you can easily guarantee that the “after” honors the parts you keep. Same provisos as before. Geeks need to learn how to do this, and codebases need to be built/altered to support it.

My bottom line here: “Avoiding code change” is fabulously expensive and entirely unneeded. It promotes neither efficiency nor certainty. I mentioned before that the efficiency difference between changing and not-changing code is nil. If we left it there, why choose code change? Because code change enables continuous harvesting of value, and avoiding code change disables it. Efficiency and certainty are certainly related to value harvesting, I wouldn’t argue with that. But they are not the only factors. In my forthcoming series on optimizing for complexity, I offer a sub-problem: Optimizing for sustenance.

The key idea here is that orgs can sustain themselves while they develop software by frequently harvesting every bit of value they create. This comes down to continuously revealing increasing capability to users and using their feedback interactively to drive and feed our efforts. Avoiding code change can not do this. It suppresses exactly the attitudes, techniques, and experience we need to harvest value interactively.

Umpty-nine years ago, when all these old agile guys were young and less sullen, a guy named Beck wrote a book that was foundational. The name of the book is “Extreme Programming Explained”, and it has a particularly revealing subtitle: “Embrace Change”.

Embrace change. In code, in people, in process, in market, in model. Embrace change.

Shouts out to friend @kentbeck. For all the changes since, all the wrangles and aggravations and owwies, you hit that nail square on its head.

Using Strategy & Function-Specific To Attack Large Classes

In IT work — “it puts the database on its browser skin” — we often face sooner or later the problem of the gigantic object.

Some systems, especially “global monolith reboots”, just start there. Others just grow and grow and insensibly slide into it over time. The problem is that there are one or a few objects that are just plain central to the domain. To forestall ron and his marick quote, I’ll use the classic ‘order’ as my example here. Imagine a system that is meant to interact with orders all the way from manufacturing to stocking.

Planners give detailing to orders, then assign them to production facilities. Those folks use an app to update state right up to logistics. Logistics moves the orders from vendor to vendor, sometimes as simple as parcel delivery, sometimes shipping containers, and so on. Vendors use those orders to track their inventory, monitor their part of the pipeline, add/alter as their marketing changes shapes.

In beginner’s OO, we do a thing that olbs sometimes call “noun circling”. Go through the specs and circle all the nouns and call them objects. Noun-circling isn’t bad, per se. But it can be dangerous for the inexperienced, and as Bob Martin pointed out, inexperience is the norm. All of this is why I recommend that my intermediate oo friends invest heavily in understanding two closely related patterns.

These are the strategy pattern (from gof) and the function-specific pattern (from I made it up from so many owwies I have lived through). Strategy was originally designed for supporting variant algorithms for operations on an object. If there are two ways to calculate the gross weight of an order, the strategy calls for me to have two classes, one for each algorithm. These classes are inside the skin of order. Depending on domain, the order (or a client) chooses one, and assigns it as a member then when another client asks for the gross weight, the order uses its own strategy field to calculate the correct response.

This has nothing to do with solving the problem I laid out, but in fact, the exact same mechanism can be used in a number of ways. Forget two ways to gross weight. Consider two dramatically different algos, like compute gross weight and select best production line. We use the same basic mechanism, placing a class as a member of order, but we use those classes for completely different purposes. Our very large order object becomes smaller each time we do this — if we decompose reasonably well.

The first few times one implements strategy, one meets some delicate questions. How do I get the data to the algo object is a big one. How/when do I set or change strategy is another one. I have no set rules for this, I’m a stepwise experimenter by nature. You just have to try it different ways until it starts to feel tight. Do that often enough, and you’ll get quite good at it. I often find myself holding just one data field in the monster object: the key I need to find anything I want about an order. Individual strategies do the rest of the work. This works well, but can eventually cost you performance. Wait til it does, is my advice.

Now what about the function-specific object? This is what I call a kind of external strategy.
Here, the order doesn’t keep its own strategy’s internally. Any strategy can be applied to any order by a client. (this is nothing more than a complex functor, an object that represents an actual *function* rather than a noun. Nothing new under the sun.)

Now push one more time. What if I make a class that a) is an order, but b) is customized for, say, plant-choosing. Its methods are tightly focused around all the things one needs to do to choose the right plant for building its order. It exposes few or even none of the underlying order data or its generic operations. Instead, it just does plant-selection. I have taken the key+functor idea of strategy and I have bundled several related strategies into an object “on top of” an order.

This is not rocket science. Most geekery is not rocket science. But it’s not the kind of thing a noob can see without prompting. And it’s not the kind of thing an intermediate can do without practice and experimentation. So the next time you see a very large object — lots of data, lots of operations — maybe you can get some new ideas for how to wrangle it.

A key insight: working this way means I no longer have to design either my order or my order’s underlying db in one massive step. I can always add new function-specific orders. I can keep running my tests against my old ones to prevent interaction effects and I can refactor my db right underneath all this without having to change any of the client code. The fundamental challenge of massive it is to find ways to do it one step at a time. Strategy + function-specific are a start.

Idols of the Schema: Ignoring Data While Overvaluing Ideas

the ‘idols of the schema’ is a geepaw-ism, and deserves some background & explanation.

when we value the simplicity & clarity of an idea over the complexity & muddiness of its referent, we’re caught in an idol of the schema.

sir francis bacon was an english noble, a famous lawyer, and author of the Novum Organum, one of the seminal texts of empirical method. he wrote among many other things, of the ‘idola mentis’: idols of the mind, and offered four of them.

the use of the word ‘idol’ was quite significant. the emerging proto-sciences framed themselves very carefully w.r.t theology. their investigations of the world were said to be efforts to reveal an aspect of the deity by examining its creation in detail. they argued that studying god’s creation was literally studying the purpose & desires of its creator, a holy act — not, notably, blasphemy. characterizing shoddy thinking as idols of the mind, he invoked biblical idols: false gods his audience was more familiar with than us.

he described four in particular: idols of the tribe, idols of the cave, idols of the stage, and idols of the market.

these four don’t map to anything obvious from their titles, so let’s attend to them for a second.

idols of the tribe are false beliefs that arise from the shared nature of all believers, in other words, from human limitation. idols of the tribe include perceptual failures & the majority of what we now call cognitive biases, like anchoring, confirmation bias, etc.

idols of the stage are false beliefs that come from ‘received wisdom’, in other words, from the institutions that transmit blinding dogma. tho there’s no way us to learn what’s needed only by experience, the dressing up & overvaluing of prior ideas sometimes cuts thinking short.

the idols of the cave are false beliefs that come from the peculiarities of our own individual experience. most of us find it much harder to think past our own rich anecdotes to the possibility that they really form only a rare & misleading case.

idols of the marketplace are false beliefs based on the complex limits of shared human language. these are basically communication failures. if one word means two things to two different purposes in two different people, it’s easy to see how misleading all language can be to us.

so. now we come to ‘idols of the schema’.

some disclaimers: i don’t compare myself to sir francis. i don’t think he missed it. i don’t think they’re not there in his four. rather, i wanted to highlight a particular kind of shoddy thinking, give it a label, and let us mull on it anew.

fred brooks said, what, has it really been 40 years now, that the geek trades work with “mind stuff” to an extent rivaled by few others. and this déformation professionnelle places extra impact on a particular class of shoddy thinking, what i call the idols of the schema.

we spend massive amounts of time w/ideas, both free-roaming — still in our heads — and bound — crystallized in some form in reality. both are needed. w/o free-roaming ideas, we make no progress. w/o binding them into reality, we make no progress. 🙂

the two have very different flavors or textures. free-roaming ideas float in the ether, and floating there gives them nature: in comparison w/bound ideas, they are clear, with crisp boundaries, they elide corner cases, they are easy to reason with, easy to render.

in comparsion w/free-roaming ideas, bound ideas are muddy complex beasts. hard to draw. hard to consider. hard to flex & fit. free-roaming ideas can drive our behavior, and so can bound ones, and we use both to do so all the time.

the idols of the schema come when we have one idea IN BOTH FORMS, free & bound. in our heads and in the code. in an org chart and in an org. idols of the schema is overvaluing the free form when the bound form is in front of us throwing off data about whether it works or not.

some cases will help. i’ll take them from different domains, because the truth is, i see them everywhere i go these days.

let’s do code. did you go patterns-happy? many of us have. the GOF book was so beautiful. it’s difficult to express the excitement we felt. a particularly common form of this: “everything is subject-observer”. i wrote an app this way once. i’m happy to say it only took once.

subject-observer is simply beautiful. but it serves a very special purpose, dependency inversion. to use S-O when u don’t need it is owwie. expressing every relationship as S-O turned my simple app into an absolute nightmare of comical proportion. simple changes took hours, complex ones took weeks. genuinely hard ones took, well, forever.

reader, i took it in the backyard & shot it. you see, i valued the simplicity & clarity of “one pattern to rule them all”, free, over the actual results bound in my code base.

or, let’s do orgs. didja ever separate out all your DBA’s and put them in one team? on paper, org chart, *free*, this is a great idea. by putting the experts together, i maximize their expertise. driving them via ticket, i create orderly flow and eliminate “bad DB change”.

wonderful idea in free form. horrible idea once bound into the reality of software development. and we bound it, boy did we ever. and it’s gone on for 30 years and is still going on in some backwaters. all because we love the free-roaming idea more than terrible result.

what about certifications? once more, a great idea in free form. once again, the benefits are overwhelming in powerpoint. and once again, i’ve yet to see a binding of the certification idea that was worth a shit in reality.

the free idea crumples nearly instantly once bound. wrong questions are asked, right answers are irrelevant, gaming & cramming abound. and we keep telling ourselves that we just need to tune the binding. there *will* be a certification that is nearly as good bound as free.

but i don’t believe that. i just don’t. the data is too overwhelming. i’m sorry, i realize this will greatly trouble some of my friends.

here are some hallmarks of idols of the schema.

  • great pictures. org charts, design patterns, certification programs, grand architectural visions, they all come with great images. branching strategies, flow-charts for TDD, the oft-misrepresented waterfall, on and on it goes.
  • another hallmark: branding. strong names, little [tm]’s, certification boards. clever acronyms, furious flavor wars, exciting religious debates backed entirely by rhetorical skill. all ought to make a thinker nervous.
  • a third: lack of steps & experiments to take you from here to there, what we call “endpointing”. “it will be great when we get there.” “it only works if all the pieces are put together at once.” these are stock lines for free ideas.

so this muse has gone on for hours, and i’m as tired as you.

when i say “idols of the schema” i mean “shoddy thinking based in mind-stuff when there’s ample real-stuff to base our thinking on.”

at the bottom of the first slide of every talk i give it says: “suspect all systems”. that’s my idols of the schema showing. 🙂

Purpose As Motivator: The P in RAMPS

Purpose is the P in RAMPS. purpose as motivator is about the sense an individual has that she’s contributing to a greater mission shared by many.

both attributes matter: mission must be of a higher order than any individual’s whim, & it must be felt to be shared by the whole team. 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.

like such a stem, it serves the role of distributing nutrients throughout the team.

we mentioned “belonging” when we talked safety, and it raises its head again here. purpose is the second pillar of the sense “i belong”. purpose helps explain our world: ourselves, the problem, its solutions, not just to others but to ourselves, too. purpose is the frame through which we see our own portrait. if its ugly, we’re ugly. if it’s fuzzy, we’re fuzzy. if poorly lit, we’re dark.

as a manager, purpose has the most ready control. it’s as if the knobs for purpose were larger, centered in my dashboard. sadly, the bright dials and sure-grip knobs are something of an illusion. managing purpose is as much an art as with the other RAMPS ideas.

let’s talk about a few common flaws in the structures of purpose in an organization.

the first is an ordinary (if astonishing) human faculty going awry: the faculty of decomposition. my organization is large. my aspiration, my highest purpose, is both large and quite abstract. it can be said in a single sentence, usually. my team, and its individuals, are tiny by comparison. to bridge that abstraction gap, we must decompose purpose. and it can go quite wrong.

remember we mentioned that stem-looking cross-section? i mentioned specifically its sloppiness. there’s a larger enclosing boundary, within it are smaller ones, some nearly aligned, some nearly entirely separate, some 50/50 overlapped.

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. even here, tho, idols of the schema can raise their ugly well-projected “it’s-just-logical” head. the stem metaphor falls apart a little: in real life, those tubes and tubes of tubes don’t form firm boundaries, nor should they.

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. no area of your brain is really entirely disconnected from the others. not only do they interact at the borders, but they also reach across huge distances, connecting entirely “separate” functional areas in bizarre & delightful ways. it is quite literally the anti-org-chart. so, with the purposes that provide flow across your orgs.

so. enough theory. what kind of advice can we give to managers — teams lacking urgency — around the motivator of purpose?

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.

achieving these certainly starts with direct education and consistent language. explain it, for crying out loud. often. the same way. then, make sure the boundaries between purposes that are most frequently in contact are highly permeable.

how can you do that? roll team members across those borders, formally and informally. and encourage them when they do it themselves. the classical up-the-chain-over-and-down-the-chain approach of hierarchical control is a real purpose-breaker. you want to avoid it.

consider building real structures to move people from purpose to purpose — especially people you think will become your leaders. a formal exercise, “chartering”, can be a useful start. google “team charter” and read most of the first page of links for ideas.

another piece of advice: be careful not to conflate purpose with either metric or instrument.

purpose doesn’t tell us how we’ll know when we’re achieving. that’s what metrics do. and purpose doesn’t know tell us how we will achieve it, either. that’s what instruments do. we may *have* to have both metric and instrument — we probably will. but we don’t have to move to them insensibly.

such movement is called ‘slippage’. we slip from a difficult to assess thing to an easier one. we slip from a problem to a solution. a key: DECLARE SLIPPAGE. that is, when we move from, say, “what we want,” to “how we will do it,” hand-wave the move, every time. we’re entering a new mode of thought when we do this. by handwaving it, we signal the transition, and open ourselves to idea generation.

similarly with metric. “what we want” might be “happier customers”. “how we’ll tell” might be any number of variant techniques. when we move from purpose to metric or purpose to instrument, make a big deal out of it.

finally? you’ll hate this. give up this deadline business altogether.

a deadline isn’t a purpose. it usually isn’t even an instrument. it’s just a metric most of the time. there *are* people who are motivated by deadlines. and others who are not, or who are even de-motivated by them. if your team lacks a sense of urgency, i bet they don’t lack a sense of deadline. they just think it’s unreachable or undesirable.

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.

parting shot: to get to a purpose that will motivate your team, get your team to help discover & refine it.

Purpose is the ideas & language through which your team sees themselves, as individuals & teams, the brushstroke of their self-portrait.

a team that sees itself working to a worthy mission is a team that’s suffused with a sense of urgency.

Rhythm & Urgency: The R in RAMPS

Rhythm is the R in RAMPS. let’s take a look.

rhythm is about tension & release. it is the sense one has of readying, girding, coiling, then taking that stored energy & sending it out.

we’ll get to music in a second, tho maybe in a way that will surprise you. but let’s start with some non-musical kinds of tension & release. a spring is stretched, creating tension, then let go of, creating release. your movement is your muscle cells in rhythm: they get fat and short, storing potential energy, then thin & long as they let go of it. a bow and arrow works identically: you pull the string to store energy, let go of the string and the store goes out to the world.

some nearby words: expansion & compression, coil and strike, build & peak, the list is long.

now we come to music. a first reaction to the word ‘rhythm’ in music is to associate it primarily with what musicians call ‘meter’. meter is just the thump thump thump of the beat, whether explicit or implicit in the performed song.

but to think that’s the only example of what we’re talking about is to grossly limit your understanding of rhythm as motivator & music both. music is arguably music because of the sheer variety & multiplicity of the tension-release cycles that go on inside it.

when you hear a verse and a chorus and a verse and a chorus, notice that the verse is usually different & the chorus is same-ish. the verse builds tension — anticipation that the chorus is coming — and the chorus resolves that tension. rhythm.

if you listen closely to great performers work your well-known songs, you’ll notice how often they *leave* the melody. they rise above or below, they trill around, they add fillips: they are creating the tension in you that they’re coming back. rhythm.

and of course, there’s actual rhythm. sophisticated drum lines walk away from or elaborate on meter, reaching climactic moments on return. i could easily go on all day about musical forms of this. i will spare you, in one of my occasional bouts of beneficence.

what rhythms, cycles of tension & release, do the individuals on your teams feel, and how do they relate to urgency?

there are myriad rhythms in geekery. as in music, there’s usually major & minor beats, phrases and measures. these come quickest to mind:

the daily standups, if you’re doing that. the weekly retros and, if you’re doing it, planning sessions. all of these form a beat.

but there are many more. refactoring, green to green code-changes, provides wonderful tension+relief in tiny little doses. all of the steps of TDD are like this. we briefly perturb the system, sending it into imbalance, then we hit the closing keystroke: TA-DAH! the cycles i use to push code, easy in my case, harder in many VBCA shops, are themselves little rhythms.

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.

on the one hand, the longer you build tension before release, the more powerful the force. cool. but incomplete. because on the other hand, the longer you hold it, the harder it gets, and the slower your recovery — the greater your need for respite. (in the nervous system, this is called the refractory period. the time required between one tensioning before the next can happen.)

we started w/the concern about a lack of a sense of urgency. do you see that a sense of urgency is exactly what the tension-building makes? it’s our anticipation of the resolution, the release, that provides us with the primary motivation for coiling in the first place.

i almost always want to ask an urgency-lacking manager: how long since the last tonic? how long have we spent in refractory? recall that most of the time the manager’s asking me this are already in deep shit. it’s not the sort of question one asks, otherwise.

the odds are good that a) it’s been forever since the tonic, and b) the refractory time is at zero because of it.

the first thing you need to do when you see your team lacks urgency is to look very hard at what you are now and have been asking of them.

to get to urgency, you have to have a normalcy from which to depart. a team lacking the one nearly always lacks the other. so the biggest thing you can do to create urgency is to refuse to demand it until the team has recovered its normalcy.

that’s a big one, and i know it’s hard. it consists of telling people — usually above you — that the answer is no. no. you can’t have it 10/1. no. you can’t add that in, too. no. you can’t ask for a stretch goal from a team that isn’t meeting normal ones. yikes. but if you want a team that can pull off a dramatic rise to the occasion now and again, you have to do this.

what about at a lower level? are there things we can do there? yes, of course.

a substantial building of tension can be thought of as many smaller cycles. the smaller cycle raises tension, then releases *some* of it. i might encourage the team for this very reason to adopt the many so-called “continuous” aspects of the agile technical set.

microtests take minutes to write and pass. when they go green, they release a little tension, but not all of it: the story isn’t done yet. refactoring green to green is a kind of globally neutral process. it builds & releases. it’s very soothing for most people, and though it produces no new feature in the instant, it actually makes the production of new features easier. a good normalcy to have!

every actual release to the field is certainly a release of tension also. could we release to the field far more often? every commit to head — your geeks know what this means even if you don’t — is similar in effect.

you can think of it this way: experiencing tension & release & maximizing their effect is a skill. skills need practice. *all* of the step-wise work your team does gives them that practice. some of it, because it’s only partial, also builds towards the climax.

one more piece of advice before i pause for release.

looking away from the problem is a form of release AND a form of tensioning at the very same time. when i hit a local climax: back to green let’s say, and i take a walk around the block, or add a move to the team game, or whatever, i am releasing local tension. but only *local*. my mind is usually still chugging away on the next larger tension i’m in.

it’s important not to confuse urgency with busy-ness. the amount of time i spend staring at a screen is decidedly not a valid measure. neither is the number of hours i’m in the building. neither is the frequency with which i scowl and look very serious. (in my admittedly special case, just the opposite, actually.)

help your team develop its own rhythms. help them create refractory periods: stretches of normalcy. help them ramp tension by stepping, and intermix partial-release stepping like pushing code with neutral stepping like refactoring. if you’re asking me about urgency, you’re dug into a deep hole. it will take you time — and rhythm — to dig out of it.

just as you need to give your team normalcy, refraction, ramping, you need to do the same for yourself. investigate rhythm by looking around you and noticing all the cycles in the daily life of your individuals. watch how they respond as individuals to each kind of cycle. strengthen the reactions you like. share them with other teammates.

rhythm is to some extent the most *technical* of the forces we’ve talked about in rhythm. this will require some thought and delicacy. urgency is fundamentally about tension and release, and any investment you make in rhythm will pay off mightily in team energy. have at it!

S Is For Safety

let’s do Safety, the S in the recent RAMPS as motivational force series.

safety is hard to get at in one summary sentence, but i’ll try. 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.

at its simplest, this sense manifests as the belief i’m allowed, even encouraged. allowed to be different. allowed to be mistaken. allowed. you can see how hard that is to summarize! it connects to some of our deepest feelings.

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.
  • second, it lets us bring people together who are not all alike, and those differences are the wellspring of creativity.
  • 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.

safety is too often used as rhetoric, especially in these polarized times. on a personal note, such usage always deepens despair in me.

how do i, as a manager, do anything at all about the feelings of safety the individuals in my team have? perhaps the first thing i need to do is accept that there is no possible safety by fiat. i simply can not make a safety rule. and for much the same reason, i — as manager — can’t *teach* safety. imagine being taught fearlessness by someone you’re afraid of. so. i guess i’ll have to watch it, occasionally reach backstage for tiny adjustments, nurture it, and above all else: model it.

as a manager, here are some things you can try to increase the sense of safety your individuals feel.

wait. before i quite go there. i need to say something about acceptance. the cornerstone of safety is a broad sense of acceptance. acceptance of mistakes, of difference, of the actual over the desired. and acceptance of others begins — you guessed it — with acceptance of your self.

for me, that acceptance began by realizing that all my great strengths could be equally well characterized as great weaknesses. i mentioned earlier that i see everything as sliders these days. that includes the features of my character. where once i saw some one of these as terribly weak, i now see it as the flip side of something tremendously strong, and vice versa. and i still work on adjusting my sliders to be more to my own liking, the “better” i mentioned before. i don’t see any one setting as ideal.

a f’rinstance: when healthy, i’m terrific in someone else’s crisis. warm, calm, steady, useful. a great strength, yes? i do that through systematic suppression of my own raw feeling. and the cost of that suppression is literally life-threatening to me. is it a strength? a weakness? it’s neither, it’s both. it’s who i am. that’s what my self-acceptance looks like.

(i don’t purport to be expert at this. color me “work in progress”, please. but that’s my current stance.)

so. *now* back to some things you as a manager can do to nurture safety in your team.

constantly rotate leadership roles amongst the entire team. example, rotate who runs standup every day, retrospective every week. updating the stupid electronic psuedo-board. and so on. rotate a lot.

model making mistakes, seeing them, chuckling, and moving on. this is fundamental, and many managers get it wrong. 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. i really can’t express adequately the astonishing value of laughter at ourselves in building safety. humor is the great softener. self-deprecating humor even moreso. engage in it, and share it. laugh often.

be wary of totalitarianism in culture. safety is not caused by rules, so be slow to add rules. rules often seem like safety-promoting handrails, but they’re much more often used as difference-bashing bludgeons.

don’t tolerate cut-off’s or shut-ups in meetings or bull sessions. if X cuts off Y, step in, ask Y to continue, assure X we’ll get to her. do tolerate anger. anger isn’t evil or bad or wrong. some expressions of anger can be, but the occasional angry outburst isn’t a mortal sin. remember, the goal isn’t beige. we’re not finding the one color everyone on the team is least offended by. we’re building a mosaic.

safety is hard. there are few things that are definitely out, many things that might be in, and lots and lots of border. 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.

Autonomy: How Freedom Correlates To Urgency

Let’s talk about the A from RAMPS today: Autonomy.

Autonomy is “simple not easy,” just like the rest of the motivating forces. Autonomy is the sense of an individual that she is free to work the best way she knows how to achieve the tasks in front of her. We call self-driving cars “autonomous”. We do that to contrast them with cars that are controlled by humans: machines. 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.

In my experience, autonomy is always set lowest on the slider in the IT departments of large organizations (VBCAs). The classic definition of non-autonomy is that of totalitarianism: Everything not expressly required is expressly forbidden. Notice that this is a game of boundaries. Organizations always have boundaries, rules drawing lines, beyond which we don’t go. As we’ll see when we get to interaction effects later, boundaries are best situated carefully with respect to purpose. Almost every restriction on my working freedom removes motivation from me. BUT, if it balances with other sliders, it’s worth it, net +.

The most disastrous boundaries I see are usually the ones justified by “efficiency” (the scare quotes are intentional.) And the second class of disastrous boundaries are those justified by what we call asteroid worries. “What if an asteroid strikes the company’s campus?” is an asteroid worry. It simply doesn’t bear any weight of concern at all. Because if an asteroid strikes, the comment blocks you require before every method JUST WON’T HELP.

How can managers affect autonomy? In ways big and small, actually.

We increase autonomy by reducing the set of boundaries to the smallest set we can live with. By rigorously connecting them to purpose. In already-demotivated teams, by strongly encouraging step-wise experimentation around pushing and probing and meeting those remaining rules. 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. Many companies have run many such experiments, from killing time clocks, to offering X days a week of “work from home”, and even completely eliminating every requirement that a worker be present.

Here’s a fascinating thing: Almost none of these companies have abandoned their experiments, and many have made them firmest policy. I’m gonna ask a bitter question: Do you think these orgs do this because they love their employees more than their stockholders? No. I’m sorry. They don’t. They do this because their employees get more work done without the rule than with it.

The range of moves towards autonomy are hardly limited to hours and location, tho. There are myriad opportunities large and small. Almost anything that makes me more of a human and 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. Got a coding standard? Make it fit on one page. Got a database normalization standard? Make it fit on one page. And so on and so forth. 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. How laborious are your rules for checking in code? I’ve a client whose teams take half-an-hour FOR EVERY PUSH. Lose that fast.

As orgs grow, there’s a huge pressure to standardize. Resist that pressure with great ferocity. The rationale is that we must have every team work the same way to work together. It’s simply bogus. I’m sorry, but it is. What we must have is every sub-team interacting with every sub-team in their view in a way that works for both sub-teams. 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.

I’ll drop one more note. 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.  A team rolls code that is excellent and needed but not part of the standard process? Bless it. After-the-fact blessing of individuals pushing boundaries, small and large, that’s how you bring them back to a sense of autonomy.

When I meet a new team, they’re almost all wondering what kind of random crappy new system I’m going to force them to use. “What fresh restrictive hell is this?” I find the easiest-to-fix owwie that they feel, and I say, this is stupid, let’s fix this. Rinse, lather, repeat. After a few of these, they start to get it: My early big mission is to free them to take control over their work life. I don’t care about method or system. I don’t care about rules. I care about whether they are gaining control over their work-life.

Sometimes, I go to the grandboss and say, “They want to try this, and they’re scared of you. Don’t notice it for two weeks, then bless it.” (I’m corrupt.) A few weeks later, the grandboss comes by and says, “I see that you’re not doing X, you’re doing Y. How is it?”… she says, “Great! You folks are rocking.” and walks out the door.

This is the granting and encouraging of autonomy. It’s resisting standards for the sake of standards. It’s resisting asteroid rules. It’s telling trusted people that we trust them to help us solve problems, without telling them how. Teams that feel in control of their work out-perform teams that don’t by orders of magnitude.

People want to succeed. People don’t want to be machines. Hold those two ideas close, and autonomy can drive your urgency-blues away.

Mastery As Motivator: The M of RAMPS

let’s talk a little about mastery today, in the sense of the RAMPS conversation from yesterday. what is mastery-as-motivator, and what can we do about increasing its motivational force?

as i said before, the motivational force called mastery is about how humans value their own growth. all of us carry around an idea, implicit or explicit, of how as individuals we could be “better”. mastery as motivator is the sense we have that we’re stepping *towards* that “better” as we work.

now let’s be clear, we’re far outside the range of the readily webster’ed definition here. no two “better”s are the same. no given “better” is actually guaranteed to provide real results. my “better” isn’t even the same “better” from day to day!

nevertheless, there are trends. i value being an effective programmer. i value being kind. i value being seen as net-positive influence. i value shipping, too. 🙂 and tho the local targets of these vague abstractions vary widely, they still fit in my idea of “better”.

so what, as a manager, can you do to harness this motivational force of mastery?

here’s a hint: it’s going to look like a cost, it’s going to be measured by sensitivity, and it’s going to require u not to reduce humans.

first, looking like a cost. adam smith wrote much of the benefits of specialization. his ideas morphed into a pretty bizarre cult. the 20th century version of this cult pretends that every trade is like a faux-1960’s-production-line.

i say faux advisedly. real production lines only barely resemble dumbassed oversimplified machine-like things. that was always a myth. further, the most successful production lines on earth were soundly defeated in ’80s and ’90s by interlopers like toyota. how were they defeated? by introducing more purpose, autonomy, and mastery into any production method requiring human motivation as engine.

(long digression over. sorry. sometimes i get overwrought.)

onto the question of measurement. just, don’t. no excel. no powerpoint. no reporting. you’re going to have to watch & listen & live with. not reducing humans. to get to that, i’m actually going to jump forward. 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. pick a human. vary the types of tasks you offer them. watch for the cases where they jump right in, eyes alight. *bingo*. i say “offer” for a reason. don’t assign. it violates autonomy and it’s likely to demotivate more than motivate.

notice, too, very important: i said “individuals” in my question, not “team”. there are a few team “better”s one encounters, and i always look for them. but don’t hold out for that.

size and shape of challenge are really important. by shape we’re talking about tasks that are just within someone’s reach. “rewrite our entire database” isn’t within anyone’s reach. “take this file and make it awesome” is closer. how about, “riff on adopting ELM for a half hour”. “run the retrospective tomorrow?” “unify how we fetch orders?” these are all options.

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.

you don’t have to go blind into this. you don’t have to change policy — yet. try some experiments and see what happens. do you allocate time for your individuals to do any damned thing they think might help? think it over. start small. make it happen.

get your db gal rolling js. get your js guy trying a backend experiment. get all of them sharing results with each other.

celebrate lessons. celebrate learning. there are plenty of non-economic reasons to do this, but the economic ones are sufficient.

we work with geeks. geeks, *by* *definition*, love learning this shit. it is what we are, that love.

that’s it for now. i know it was long, more disorganized than yesterday. that’s to be expected. everything i’m saying is “simple not easy”. work with individuals to learn their “better” & aim them cheerfully right at it. you’ll get more urgency than you ever dreamt possible.

A Sense Of Urgency: RAMPS As A Motivation Model

A very common question: managers turn to me and say, “My team lacks a sense of urgency, how can I give them one?”

After I get over the snarky replies — I come from a long line of “the managed” — I do have what I think is an answer: “Study the idea of RAMPS, find the missing or depleted elements, move to restore them. And friend, don’t expect you can do it using words.”

RAMPS is my acronym for the five drives I believe must be balanced for strong motivation: Rhythm, Autonomy, Mastery, Purpose, & Safety.

Rhythm is periods of tension leading to periods of release. It’s the coming and going of energy & intensity. Autonomy is the sense of being able to control one’s own situation, a kind of freedom of action within some broad boundaries. Mastery is about growth, the idea that every person has in mind a better self they want to approach. Mastery is the sense of approach. Purpose is the sense of belonging to a movement or activity that is more than just one person in the dark, it is the shared goal. And Safety is the belief that we are allowed to be different, even wrong, whether it be temporally local or temperamentally global.

I think of these as sliders — I think of everything as a slider these days — positioned on their little scales of 1-10. The managers asking me this are normally sitting at 9-10 in purpose, and with the others set very low, perhaps at 0. That’s the situation usually, by the time a manager is tearing her hair out coming to me with that question.

There is no one one best way to set those sliders. People are different, and teams made from people are different.But i’ve rarely seen a high-performing aggregate whose only motivation was their shared purpose. If you want your team to want to be at work, to want to be fired up, to want to be nailing it, you must husband & attend to all five.

Teams lacking safety lack ideas, cuz having a new idea is scary. Ideas are the fundamental unit of software progress. Teams lacking purpose got no where to go. they don’t belong to something larger, so they don’t go the extra mile to stay in it. Teams lacking the drive for mastery are drones, having locked in their achievements, never to progress again inside the team. Teams lacking autonomy lack the freedom to make things worse, but they also lack the freedom to make them better. Teams lacking rhythm are either exhausted from non-stop effort or bored from non-stop conservation of effort. Neither way works for long.

My guess is that a team “lacking a sense of urgency” has deficits in everything but purpose. And purpose is buttressed by each of the others, which are after all highly intertwined, supporting & building off each other. Stressing purpose to the exclusion of the others is a very common mistake, and often a nearly fatal one.

I’ve more to say on all of this, maybe one by one over time, but that’s enough for now.
RAMPS — Rhythm, Autonomy, Mastery, Purpose, and Safety.

Someone else said it better than me: make great software by making great teams.