Hey Folks! It’s a new site. If you see bad links or odd behavior, please contact me right away. Thanks! – GeePaw
 Home  Home  hom  Meet with GeePaw  Meet with GeePaw  mee  Work with GeePaw  Work with GeePaw  wor  Who's GeePaw  Who's GeePaw  who  Blog  Blog  blo  Contact  Contact  con

Standardize-By-Problem, Live Vertically

 15. July 2017

i’ve been thinking lately of how much “enterprise standards” ruin our lives.

when i coach in VBCA environments, i confront this problem more or less constantly. the standards can be enterprise tools, enterprise negotiations, enterprise processes. i see two factors in this. 1) solution-locking definitions, and 2) inadequate coaching reach & action.

improper solution-locking definitions is my best (bad) phrase for this: we specify standards by solution, not by problem.

let’s take an easy one: these horrible enterprise source vaults one sees so much of. there are real justifications for having an enterprise standard around the source vault.

  1. we want to know everything is backed up somewhere else all the time.
  2. we want to know there is a “gold” version of every artifact at the source level AND the final level.
  3. we want to know what the changes were. (and sometimes who did them, tho that’s worth very little in real life.)
but those justifications are not the standard. the standard is to use some slow awkward owwie ‘80s interface app that cost bazillions. do you see the disconnect? if the standard were expressed as the problem, anyone could use anything AS LONG AS IT SOLVES THE PROBLEM SET.

by specifying solution instead of problem, tho, we lock in the solution. thus my bad name: solution-locking definitions.

my advice then: specify standards by specifying in detail what problems a compliant solution must solve. period. then let the birdies fly.

the second factor is about the coaching we give people up the chain of command, and it’s also a doozy of a problem. the majority of coaches, especially in VBCA’s, either don’t or can’t reach adequately up the chain of the command. there are lots of reasons for this, presenting typically in combination, which makes it even harder.

reason: c-level buy-in is hard to sell. reason: c-levels are busy. reason: c-levels breathe very abstract air.

reason: c-levels even if bought in don’t drive m-levels well. reason: organization survival is not tightly correlated to success.

reason: coaches don’t know how to talk to c-level OR m-level. reason: we have always lived this way. reason: fear fear fear must drive us.

and i could rattle off a dozen more.

but look here, coaches. all those things are problems we deal with routinely with the people we actually live amongst as coaches. so what do we do when we coach? we live with people, doing what they do, doing it with them, doing it near them, all the time.

i don’t tell a geek “write tests” and walk away. i mean, i wish i could, but i don’t do it cuz it doesn’t work.

to get them to understand what i mean, i have to live with them, day by day and step by step, working with them as they work with it. but we quite commonly do exactly that, tell-then-walk-away, with all the people between our team & the top.

addressing this factor is about figuring out how we can live with a team vertically. live with each member of it all the way to the top. it is, for me, a somewhat unsolved problem, the getting in to that place. i’ve done it some, but not enough. but that’s what i have to do.

so, wrapping it up. if we want to change the world so that “enterprise” isn’t a derogatory word, we have to make two changes.

we have to start specifying standards by specifying problems. we have to start living vertically.

go forth and change!