Work that energizes

After a few newsletters about defining work with pattern languages, a friend of mine said:

"I don't get it. These pattern languages just look like outlines or specs. What's different?"

Well, okay ... at one level it is just a spec. And maybe focusing too much on the pattern language format is misleading, because a format alone doesn't solve all problems.

The deeper points are about concreteness and abstraction.

In a creative environment, where people join a team because they want to build something new and great, the way we define work can cause them to become energized or deflated.

When a problem is loose enough that there are multiple ways to solve it — and it's not obvious up front which way is better — this gives the designer the chance to experience a breakthrough. They know they'll be heads-down on paper for a day or two trying to untangle something or explore all the options, until suddenly "A-Ha!"  The direction becomes clear. That prospect is energizing.

On the other hand if the work is too loose, and nobody will be able to agree about which direction is the right one, there's little prospect of a breakthrough. The breakthrough experience depends on mutually agreed-upon boundary conditions.

Work can also be too concrete. Designers working at any level of the stack, including code, bristle at requirements that read as arbitrary. Requirements that are there "just because" are deflating. Taking those up a level by wrapping them in understandable boundary conditions moves them from the realm of "must be so because I said so" to "must be so because the world is so." Understanding the latter is energizing. The more we have a shared view of objective constraints, the more we can engage collaboratively in questions of goodness and fit.

Overly concrete requirements also send a social message: "I don't trust you." Which is of course deflating. Work that is spelled out with too much detail can make the receiver feel talked-down to: "Don't you think I'm capable of figuring that out?"

Intrinsic to the definition of a "pattern" is the notion that something can be done in more than one specific way. That's abstraction. Because a "language" is a composition of patterns, it contains interdependencies that aren't easy to satisfy — that's concreteness.

It's one thing to say "design a kitchen."

It's another thing to say "here are the blueprints of the kitchen, go build it."

And it's yet another thing to say: "A good kitchen has windows giving light from two sides. The counters are long and generous along the south side to get the light. Place a big table in the middle and light it from above to create an eating atmosphere." This information enables a designer to work within constraints while leaving the specifics and trade-offs open according to the realities of the project.

So the format is a good start. Whether the work energizes or deflates still depends on the contents. The factors described above can help strike the right balance. Enough latitude to enable breakthroughs. Firm boundaries to enable agreement. Specifics when hard-earned knowledge informs decisions. Trust when you know that capable people can work it out themselves.