I’m just beginning to design two new “Skillbuilders” (workshops) for the Maine Association of nonprofits. Workshop design comes easy to me, and I’ve a track record of considerable success. Still, I’m expecting to learn significant lessons as we first experience these workshops being presented to live audiences. How can I maximize my learning from these pilot runs?  And how can I organize my initial work so that these questions are clear?

My first rule is to always list the goals, and design the evaluation process, before completing the workshop design itself. Just the titles, in this case “Asking Great Questions” and “Crafting Your Elevator Speech”, are not enough.

For example, digging deeper into my “Asking Great Questions” agenda, I began to see such questions as:

• Who should be learning what about the process of creating, editing, and asking questions? (Who is our target audience?)

• What key ideas or understanding do we believe participants in the skillbuilder should take away? (What are we aiming to teach?)

• What experiences (not what lessons) will have make this happen?

• Are there important things that participants may need to un-learn? (What habits, or what blindness, are we trying to overcome?)

Working with such questions early in the workshop conception stage, I began to see that the kinds of questions that might fit into an employment interview are very different from those that we might want to ask of other stakeholders in our organization, of lawmakers or regulatory officials, of teachers or of researchers and guides whom we trust.

With each clarification of the goals comes new clarity about how to observe and measure whether we have achieved those goals. And, so, the evaluation process is built as the workshop is designed. Even more important, the questioning process informs the whole conception of the workshop.

In fact, I needed to create another set of questions, to evaluate my initial description of the Skillbuilder, before even developing the main workshop agenda:

• Who will the description attract, and are these the people I want in this skillbuilder?

• What expectations will the description create, and is this an expectation that I can and want to fulfill?

• The skillbuilder will be require very active participation, and will include little content that can be received passively.  Will that be clear and a positive aspect of participant’s experience (or will there be comments about the lack of Powerpoint slides with detailed text guides)?

Thinking about this process led me to look back at the first outline I wrote for an earlier Skillbuilder I had developed with Deb Nelson. Along with my first rough draft outline, I had sent her a memo with a heading “Questions for Us”, and the following content:

• Our goals for the workshop

• What we have to tell or teach vs. participants learning from each other

• How we will know we have succeeded — Key evaluation question

• Possible pitfalls — What should not happen?

• Personal goals — Why we are doing this

Ask yourself these and similar questions as you prepare your presentations, your lectures, your workshops.  Even when the answers seem to be obvious and so clear, write them down. Revise that draft copy. And let your questions be your guide.


I’ve identified six critical skills, that serve me well in my coaching and consulting.  In fact, I think these may be all the skills that I need.

But check me on this.  Comment on this blog with what you think might be missing or wrong.

1. Listening (and looking, and listening)

Listening is an active process.  It’s not summarily waiting until the other speaker is done, so that you can respond!  At best, it includes offering some feedback, that allows you to test whether you’ve understood.  And the other modes — looking and listening — are just as active.  As a photographer, I have to constantly ask myself, “What’s visually interesting her”, and, “What am I seeking?”

2. Asking great questions

Lots of questions come from a wrong place — trying to show off, or make the speaker wrong, or some such.  Great questions illuminate, open up a deeper dialog, expose important issues.  They may also show some bias or committment, but they are not argumentative debating points.

3. Giving and receiving feedback

The most helpful feedback is offered with understanding and compassion.  It may be as simple as, “I see you doing this, and wonder why you feel you need to?”.  Feedback to you is best received as helpful advice — not as criticism.  It’s coaching, editing, insight that can refine, sharpen, augment.

4. Design thinking

A good design is an economical, functional, beautiful solution to a well-understood problem.  It may be an elegant bridge that supports many cars, or a simple tool to cleanly cut pieces of pie.  A design may be a process, an interaction, or may be embodied in an object.  Design thinking is focused on creating such full solutions, rather than makeshift steps that appear to solve an immediate problem.

5. Feeling and showing empathy and respect

Conflict can be constructive, if we see those who differ from us as helpful messengers of new points of view.  Even if those points of view seem to us completely wrong, perhaps even counter to our core values, an empathetic and respectful relationship leads us to seek understanding, welcome deep sharing.

6. Integrity, including being able to say “I don’t know”

Truth telling is becoming increasingly rare these days, but it still matters.  And one of the most important truths — especially in business situations, is that we don’t know the answer.  Why not just say so?

In consdiering the design challenges I face, I’d distinguish process from paradigm.

Many of the processes I use may be time worn, orthodox, etc. Contextual inquiry (or listening to users) is not new, paper prototyping was not invented last week. I use them not because they are “accepted orthodoxy” but because I find them functional steps towards creative solutions.  The fact that they may be “orthodox” does not make them wrong or outmoded.

But I’m stuck with too many old paradigms about how to understand the world. I imagine a vehicle having some controls, and would have trouble coming up with a Segway where you just lean to steer it. I imagine sound players will have knobs, and would not have expected the iPod model. I still expect cameras to look like those old film devices, even though the physical constraints that led to such designs are gone. I don’t choose these paradigms — I’m stuck with them, until I find a way to escape.

How will my processes, methods, whatever, help me to see the world outside the paradgms that limit my vision? That’s the burning question for me — each day, and with each new project.

We had an affectionate connection to our Quaker meeting house in Portland, but it didn’t work very well.  The circulation was poor, so that after meeting for worship, visitors had a hard time finding refreshments, and we had a hard time finding each other.  There was no handicapped accessible bathroom.  And we knew that with our growing population of young families, we’d need more space for children’s programs.  We could imagine adding more space, but not any natural way to cure our building’s problems.

Than misfortune hit us with grace.  Part of the plaster ceiling in the meeting room had detached from its framing, and so we hired a contractor to remove and replace that ceiling.  They had just started the demolition face when the whole ceiling fell — exposing framing that was dangerously weak.  Luckily nobody was hurt. At one point in our history, there had a been a removable partition dividing the meeting room into separate area for men and women, and when that had been taken out some important structural members had been compromised as well.  Luckily the pending failing of these beams was announced by the falling ceiling, and we were able to put up temporary bracing to make the space safe.

But now there was no putting off major work on our building.  We engaged as one of our meeting members, Chris Wriggins, as  architect for this project.  His recommendation to us was startling and disturbing.  Chris noted that our meeting room was a long rectangle, and that by simply removing one end of that room and turning that space into a wide hallway, we’d have excellent circulation right through the core of our building.  There would be enough space to create a new wide stairway to the lower level, with a power lift riding alongside that stair.  That would make the already large bathroom accessible to all.  Finally, we could put a modest addition on the rear of the building, creating new classroom space.

What was disturbing about this plan was that it entailed cutting off part of our meeting room — and that room was our reason for existing.  It seemed unthinkable that we’d diminish that space — at least until we thought carefully about it.  But we realized that the meeting  room, even without that end, was large enough for almost all our gatherings.  And for those events where we couldn’t fit, the space in question wouldn’t make any difference.  (Very large funerals were typically held at another church in town.)  Finally, we tended to arrange chairs in a circular formation, so making the room more square might even feel like an improvement.

We decided to go forward with this plan, and have found that the renovation turned out to be an improvement in every way.  The meeting space feels more comfortable, circulation is better, the addition does provide important new space, and the overall project was not as costly as many of us feared.

I tell this story to illustrate some key points in this design thinking:

  • Chris Wriggins, the architect, was able to put aside emotional reactions and look clearly at the space and circulation issues presented.
  • His solution represented a new paradigm for how to deal with the building.  (Rather than just add the spaces we said we needed, he changed the whole building’s circulation.)
  • While the solution seemed obvious once it was put forth and argued, it was “out of bounds” to most of us before that.
  • The solution was remarkably simple.

What enabled Chris Wriggins to see this simple solution, while the rest of us couldn’t even imagine it?  He’d never seen exactly this problem before, or even one that was very close.  He had no special tools, and no advanced technology.  As a member of our community, he shared our emotional connections to the space and how it was used.

Clearly, something in his training led to a kind of design thinking that led him to a crucial idea that was the key to this solution.  I wish I could explain — actually wish I could fully understand — that design thinking.  But suffice to say that it is distinctive, that it’s of special value, and that it’s relevant in most aspects of our institutional and individual lives.  Design thinking is central.

“Designers don’t follow trends — we make them”.

Quote from Brook DeLorme, clothing designer, as she spoke before a business networking group, and was asked how much she follows and responds to fashion trends.  Her web site is www.Brookthere.com, and her store / workspace is located at 37b Wharf Street in Portland, Maine.

My tolerance for complexity — in all things — seems to be decreasing with age. And I don’t believe it’s the onset of dementia. Quite the contrary, I attribute it to wisdom gained with considerable experience

Brian Kernighan, one of the authors of the ‘Unix’ computer language, wrote:

Debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

Computer programs always have some degree and complexity, and usually are not exactly correct.  They are born with “bugs”, and the task of debugging is about finding those flaws of logic that lead to wrong behavior in certain — perhaps unusual — cases.  If the program is written in a clear straightforward manner, with visible structure, and an appropriate number of explanatory comments, the debugging process will be much easier.  But if the program is written with clever tricks — perhaps taking advantage of some esoteric facts about the number system — debugging will be difficult or, as Kernighan suggests, impossible.

I used to travel widely, delivering to computer programmer audiences a talk entitled “On being lazy, absent minded, and a great system developer”.  I explained that being lazy meant that once I’d developed some code that worked, I’d take time to document it carefully, and package it so that it could be re-used in other larger programs in a natural way.  Thus I would do something well, once.  Being absent minded meant that I’d often lose track of where I was in the coding or development process.  To compensate, I’d have to write a plan first, and document any changes to that plan as I proceeded.

With these definitions, all the developers and analysts in my audiences could affirm that my qualities of laziness and absent-mindedness — as I compensated for them — were excellent qualities!  In fact, what I’d spelled out are two best practices for writing code.  A program consisting largely of well written and already debugged small sub-programs will almost always be more reliable than one written as a new mass of virgin code, and intelligent comments are an important compliment to the code itself.

I asked my audiences for a show of hands, how many spent much or most of their time debugging or updating other people’s code.  Most raised their hands.  Then I  asked how many found that code to be unclear, unstructured, hard to read, and difficult to  modify in a safe reliable fashion.  Again, most hands went up.  Finally, I asked how many were rewarded in their performance review for writing such high quality code — instead of just for writing lots of lines of code that seemed to work.  This time the hands stayed down.

Evidently, although we recognize that complexity is almost unmanageable, we’re too often unwilling to invest in simplicity.  And simplicity is the product of good design.  I believe that the underlying issue is our reluctance to understand the importance of design.

I’ll have more to say about this in future posts on this blog.