Process and Structure aren’t four-letter words

Why do people hear the word “process” and see themselves caught in a flood of molasses, moving slowly toward an ever-stickier goal? Why do people hear the word “structure” and think they’re going to be chained in place and performing jerky, robotic movements?

I try to school myself not to say these words. Not because I don’t believe in them. But because “them’s fightin’ words” for many people.

The moment I try to systematize something as simple as talking to a user, or plan for a second on how to engage users, if I use the “p” word or the “s” word, ears shut off and people hear 20-page status reports and if-then cases that run to 400 pages of instructions on how to brush their teeth or something.

No No No No NO!

I’ve spent many, many years as a musician, and one thing that I’ve learned is the value of jamming and the value of rhythm.  And that’s all Process and Structure are – the bones of the framework for the jam session.

Process is the rhythm around which the awesome project is built.  Rhythm can be heavy or light, but it needs to be there or things go nowhere.

Structure is the rules for what key to be in, the overall chord transitions, the tradeoff points between melody lines.   Structure can be heavily mathematically precise or loose and flexible, but, like gravity, it needs to be there or the jam session is just chaotic noise and wannabe soloists playing over each other as they jockey for position and attention or even just something interesting to break the boredom of noisy inertia.

My history is about not supplying too much structure or process.  It’s centered around light weight and trust in my teammates and shared goals that mean that none of us need overspecification and 400 pages of what to do if the cap is on the toothpaste or the lights are out when you get to the sink – you’ll figure out the best way.  Besides, the 400 pages of instructions don’t cover how to suppress new-vocabulary-word expletive education for the nearby minion when you’ve dropped the tot-lok magnet on your toe while trying to get the toothpaste out of the kid-proofed drawer. Oops, make that 401 pages of instructions. And counting.

Simple process: Remember to brush your teeth on the way to bed as part of the regular routine.  You know how.

One line and done.

When someone proposes a big, over-controlled structure to make a decision, the response shouldn’t be to pick it apart, and debate the merits of squeezing toothpaste from the middle versus bottom for hours on end, then move to rolling versus flattening as the tube empties.   Way too easy to get lost in the details and a permanent state of low grade hostility (“I am not even trusted to know how much toothpaste to use!”)  that substitutes for progress.

Instead, it’s back to what is the goal, and why is someone proposing that the toothpaste be kept in a drawer, neither in the front nor the back, but right in the middle, just left of center.  What’s the requirement here?  Off the counter?  Find in the dark so no brushing teeth with antifungal cream? These rules and over-detailed process specifications hide the bones of a very short, light statement that treats everyone as competent and allows for different brushing techniques.

How to extract that nugget from the overdescribed rules?  Here’s the simple, lightweight framework that I use:

First, are the goals clear?  Everyone know which end of the field we’re aiming for and what counts as a score?  In this case, WHY matters as much as WHAT, because you’ll never think of every.single what.  So the more every person knows what winning is, and how we know when we’re there, the more each one can test any decisions against “is this getting us closer to done and won?”

Second, what are the boundaries and what happens when we hit them?  If we all trust each other, where are the fences and issues where we need more visibility?  Is it when we do integration?  When we add new dependencies?  When the interfaces change? When performance testing shows significant difference from expectations?  What do those boundaries look like and what actions do we take when we get there?  Send an email?  Run some tests?  Ask for another set of eyes?  Put it under source control?

Third, what are some typical and hard situations where we need a structure or framework?  The typical, easy cases, well those are used to build the bones of the structure.   What do those workflows look like among all the individuals?  What’s the goals of each of their steps?  Those are the ribs of the structure.

The really hard cases are the ones that we test it with.  Within the framework do we come up with a way to handle the hard cases, all the way down to ugly details at ground level?  Does everyone agree that that way is acceptable, that even if there might be more than one possible way to cope, the framework drives to an acceptable means to address the issue?  We’re not looking for the best way here, just good enough and that the framework makes it easier to do the right thing and harder to do the wrong thing.  Honestly, when a real difficult situation comes up, it most likely won’t be exactly like the ones under discussion here, so the real goal is to make sure that the structure encourages the right process and acceptable solutions for things as they’re encountered

Fourth, what kind of communication and checkpoints do we need?  Even with connection points and fences and actions, it’s still worth checking in now and then to make sure that the framework doesn’t need some tuning.  These are the fine points of process.  I’ve found that demonstrations and discussions centered around actual use cases are much better than theoretical discussions.  Decide whether you need synchronization (meetings) or async discussions.  Use these lightly, and multi-purpose – tune process and build team – people are MORE important than the individual artifacts, because they’re going to be making many decisions outside the discussion, so these sessions are really about building understanding.  The goal is to have openness and trust that everyone’s working toward the same purpose, so these checkpoints are about making that happen more directly.  And “do we need this?” is always one of the first questions that we need to ask.  And adjust as needed.

This gives people the room to be themselves.  It means that no one is playing retroactive lawmaker, coming up with 50 steps to address yesterday’s minor issue that won’t ever happen again.  It means the team guides itself to efficient execution because there’s room to do it right and guidance on what “do it right” means.  And when that breaks down, there’s a way to deal with that which doesn’t involve acrimony.

Done right, process is as liberating and freeing and energizing as the best jam sessions.  People cover for each other and transition seamlessly and breathlessly, as a single living organism moving toward the same goal.

One thought on “Process and Structure aren’t four-letter words

  1. […] why the server failed.”  Not “just this once” and especially not before the (make it lightweight!) process has been tuned and owned by the team. Well, because there’s a reason that we ask […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s