Hello, Koné Consulting

TRIZ is a half-hour scavenger hunt for things a system is doing that are actively keeping it from serving its purpose or intent. It’s one of the greatest liberating structures. In TRIZ, a group will:

  1. come up with processes or methods to consistently ensure an unwanted outcome (e.g. sales prospects are lost, all patients are infected, each software release has errors);
  2. think about things they are already doing that resemble the methods devised in the previous step; and
  3. figure out how to stop doing those things.

TRIZ is always funny, sometimes terrifying, and often directly useful. I rely on it for software products. Rather than making “usability improvements” or adding speculative features based on inadequate research, TRIZ helps me find aspects of a product that actively frustrate and defeat customers so I can yank those suckers out.

Controlled burn

I closed Different Chairs in order to make room for something else. Too many aspects of being a sole proprietor kept me from creating the experiences I wanted my clients to have.

In order to do better work, I had to find great people to work with, and, somehow, I fell in with the best. I’ve joined my friends, co-conspirators (and, now, colleagues) at Koné Consulting.

Forget chairs, let’s look at the whole damn table:


It’s a tiny, distributed group; we work remotely. But when we gather in person now and again, this is the inevitable configuration.

What does this mean?

For existing clients, this is all old news: I’ve been working to ensure continuity for those that want it.

For everybody else — well, it’s simple. It means that when you ask for help, or work with a product I make, or we sit down to figure out something tricky, you don’t just get me, even if it’s only the two of us at the table. You get Alicia’s commitment to quality and humanity, Sharon’s ability to create space for decision-making, Christina’s talent for taking care of any problem, Alicia H.’s focused execution, Devin’s rolled-up sleeves, André’s unlimited energy and relaxed discernment, and whatever scattershot nonsense it is I scrabble together. If that’s not Voltron, it’s at least the Sea Team.

And for me? Means I’m feeling lucky. These people make my work better in all the most difficult ways: by opening space for action and contemplation; by challenging me to keep that spring in my step; and (the hardest one) by actually helping me become a better person.

Please enjoy this photograph of a beautiful location at sunset.


Goodbye, Different Chairs

It’s been an interesting eight years.

I started Different Chairs after finishing grad school in the Potemkin village of Ann Arbor, Michigan. I didn’t know what I was doing; I made mistakes continuously. Wherever it was possible to do something wrong, I did, and maybe half of the time I managed to learn from it and improve my work.

Here’s one thing about running a small business: it’s never easy, although it’s sometimes good. Here’s the other thing: even a sole proprietor can only be as successful as the people whose support, collaboration, and friendship make it all possible. You know who you are. Yes, you. I don’t say it often enough, but I’ll say it now: thank you.

In the end, I solved problems. I made clients happy. I treasure every moment of it, even those I won’t miss. Today’s the last day of Different Chairs, and tomorrow is the first day of what’s next.







The glass

Now here’s a little parable, or joke:

The optimist says that the glass is half-full.
The pessimist says that the glass is half-empty.
The lean consultant recommends finding a smaller glass.

This parable, or joke, is a pocket-sized exemplar of what’s good — and what’s insufficient — about lean thinking.

What’s good

There’s an acknowledgement of contingency. People have their own beliefs, perspectives, and intuitions. These can be respected without reference to validity or necessity.

It’s a response to the situation as encountered. No part of this story is about finding individual culpability or placing blame. Neither is there any discussion about how things “should” be, or even how much water is “enough”. (Although how much water people want is a different matter entirely.)

It’s about making a discrete, intentional change. You know, given an existing situation that isn’t to everybody’s satisfaction, even an arbitrary change might wind up making things better.

What’s insufficient

The proposed resolution isn’t necessarily a useful improvement all by itself. It could be meaningless tidying up, and could in fact be valuable;
either way it’s disconnected from the larger environment and intents shared by both the optimist and pessimist. The basic principles that were bundled up into lean (a) have to do with correlating the work everybody is doing with the actual purpose of the organization they work in and (b) very rarely come up in “lean work” or “lean projects”.

There’s a tremendous amount of fatigue out there related to lean thinking and lean transformations. We’ve all seen this kind of thing before: feel-good rearranging of deck chairs; a dollop of anal retentiveness over box lunches and cheerful whiteboards.

Unfortunately, that’s skepticism that lean has earned over the decades, and you have to respect people who feel that way.

Lean and related jargon are terms that have reached peak fluff. (Example: last week a trainer for a proprietary, nightmarishly over-complicated content management system told me that the product in question was lean because “you can administer it from a web browser and not a desktop application and it has great ROI.” That is a direct quote.) All this damage is the reason I try to talk around the term “lean”, and prefer instead to focus on the underlying practices and motivations — which, ironically, are usually as novel and exciting to people as lean itself is overtired and stale.

No capital L

What is lean, anyways? Is it a system, a tool, or a cult? As always, depends on who’s buying, and who’s selling. Here’s my advice:

If you want to learn about lean, read only books from before 01980, with one exception: W. Edwards Deming’s Out of the Crisis. This was published in 01982 but is in fact a retrospective of his decades of work. If you do read the book, count how many times he uses the word “lean”, and then use it about as often as he does.

Also, you might want to get yourself a smaller glass.

Problems and solutions

A long time ago, my mother-in-law Sue told me that some problems just don’t have solutions. I knew she was wrong. I knew that every problem has a solution — that having solutions are what problems are for. Of course, I was wrong, and she was right.

Some problems have solutions that you can see, but can’t get to. Some solutions are even worse than the problems they’d solve. And some problems are just plain tricky: the swords of mighty kings forged into gordian knots. Other problems are solved merely by waiting for a person to die or for an empire to crumble. And whenever you solve the worst problem you’re facing, the second-worst problem immediately steps up to take its place.

Storytime with Jerry Weinberg

A friend recently tweeted this quote from Jerry Weinberg’s “Secrets of Consulting” (a phenomenal book with a lousy title):

That quote reminded me of my own summary of “Secrets of Consulting”, which, true to his homilist technique, I call the “don’t be a jackass” rule:

The “don’t be a jackass” rule

Problems are everywhere. Acknowledge that you, under your own strength, are not going to solve every problem you see, or every problem you know how to solve — and if you try to, you’re just being a jackass.

(What’s this all about? Well, go read Weinberg’s book, or soak in Todd Clarke’s visual book notes for the same. I recommend both.)

Finding 15% solutions

What I’ll often do, instead, is turn to one of my favorite liberating structures, a little bauble called 15% solutions.

For me, the search for 15% solutions begins with the recognition that the biggest, thorniest problems we face are just another part of our environment. Our problems are located in the same big soup as our colleagues and peers; as people we like and people we don’t; as our organizations, affiliations, and communities; as our responsibilities, creditors, paradoxes, and best-laid plans. Furthermore, most things in this jumble are as hard to change as the built environment, even if they aren’t physical stuff that’s too big to move or profoundly meaningless boxes and arrows on a flowchart or orgchart.

But there’s always a little wiggle room. Small things you can change without getting permission, or by begging forgiveness. Things left uninstrumented or directly within your grasp. That’s the 15%.

A 15% solution is what you arrive at when you stop worrying about the intractable systems of the world as they whirl without cease under encroaching darkness, and instead identify the tiny, immediate, and maybe effective things you can do right now.

If you do this by yourself, that’s great.

If you do it with a few other people who are stuck in the same problem, that’s even better. (In fact, the amplifying effect this can yield is the point of the liberating structure.)

In other words

  1. Don’t leap at problems, or you’ll just find more problems.
  2. Don’t leap at solutions, or you’ll be a jackass.
  3. Remember to try the easiest things first.
  4. It can be pretty hard to find the easiest things.

“Problems and solutions” was originally published in the Different Chairs journal.

Why your CMS is awful, II: what do to about it

In the previous post in this series, I described the circumstances that make most content management systems for the web unwieldy and unpleasant.

It’s possible — maybe even the common case — to put a lot of work and resources into a CMS project, only to wind up with something so hostile that nobody uses it, or it becomes arcana that’s relegated to technical staff.

So let’s assume you’re starting a project incorporating a web CMS, and that you’ve chosen technology based on the capabilities of the system: it’ll do all of the things you and your constituents want it to do. Awesome! Now we’ll try to make a meaningful experience for the people you dearly hope will get into the CMS and create and share stuff that will affect the world in some way.

It’s a two-step process:

  1. have the right stuff, and
  2. work on the CMS throughout the project.

Having the right stuff

Here’s the checklist I use at Different Chairs. These items almost always come up during requirements analysis, and if they don’t, users will ask for them (typically after the money is spent). Nothing here has to do with the basic capabilities of the CMS. We’re assuming you’ve got something capable — and want to improve the odds that anyone will actually bother with it. I’ve also given implementation notes for the Django CMS, since that’s what I work with most often.

Requirement Why it matters Django CMS notes
Support for phones and tablets.

Working in a CMS seems like a “desktop task”, since the administrative user experiences are complicated and sprawling. But people will use the tools in front of them, and that’s increasingly not a laptop or computer screen. Therefore, consider a responsive design for the CMS’s admin experience. Start with making the experience possible, since it almost certainly won’t be with the default admin presentation.

No magic bullet here. Until recently, django-admin-bootstrapped supported the Django CMS and provided a decent responsive design for the admin (it doesn’t support Django 1.5 or Django CMS 2.4). A better solution is to use django-bootstrapped, which takes a similar approach but yields better markup and responsive layouts that scale more appropriately to small screens. You’ll have to override some of the CMS’s templates to get this to work, but it’s well worth the effort.

Easy ways to work on and share draft content.

Any capable CMS will have ways to view, compare, and revert to versioned content, as well as deliver an editorial workflow that satisfies bureaucracy. It’s fine for this to remain a fail-safe that not everybody cares about. But there should be a simple means for someone to create a new draft, look at it, and share it internally. It’s important to be able to work in private, at one’s own speed, and be confident in how the end product will appear and function.

  1. Create a top-level page for draft content, configured such that it’s never published.
  2. Add an item to the CMS toolbar allowing someone to create a new, draft page that’s a child of the page from the first step.
  3. Show this to everyone who will use the CMS.
Live editing.

How easy is it to fix a typo? If you have to go into the CMS, drill down to the content you were just looking at, and enter some editor, you’ve lost. Ensure that logged-in CMS contributors can make quick edits in place and you’ll be surprised by how often they do.

The CMS toolbar is a nearly perfect solution. Set up actions that satisfy common needs, even if they’re just deep links into the CMS admin. Test dynamic or interactive templates, making sure that all states are available to the CMS toolbar.

Structured content everywhere…

For lots of things (lists, addresses, event information), it’s easier to work with a well-designed, considerate form than a text area. Add as many kinds of structured data to the CMS as you can. Their data models and forms-based presentation need good validation and descriptive help and error messages.

Find or create many plugins. In addition to useful third-party plugins like djangocms-table, keep an ear out during development for opportunities to create CMS plugins to capture little bits of data, or to make it easier to syndicate or republish things from other applications.

…but always in the right context.

What kind of page are you creating or changing? What part of the page? The answers to these questions should control what kinds of content are available to work with. Make this easy to change, but come up with sensible defaults that simplify the author’s work. Available options may differ based on where someone is and what they’re doing — but they’ll always make sense.

You wouldn’t believe how often I see Django CMS projects in deployment without a CMS_PLACEHOLDER_CONF setting, which maps available plugins to placeholders and therefore to templates. Producing templates with these relationships in mind is a powerful way to help people feel comfortable and confident when using the CMS.

An appropriate rich text editor.

Two concerns: (a) Nobody likes these stupid things. (b) The most common content management tasks involve fiddling with some copy in a rich text editor. Therefore, configure the rich text editor to generate markup that you won’t regret down the road, and use one that helps authors create and style copy that integrates into the rest of your site’s presentation. A good starting point would be WYMeditor.

Use the CMS’s default of WYMEditor and configure the daylights out of it so that the available classes and elements match the site’s layout, both in the editor and in the content previews it generates. Make the exact same editor configuration available to other web applications used by the same people.

Opt-in notifications for people who want them.

People want to know what’s happening to content they’re responsible for, sometimes without inserting themselves into an editorial workflow. Provide ways to generate feed, get automated e-mails, or other notifications for changes to sections of a site they’re interested in. If it’s a migration to new CMS from some other system, wire page-not-found errors and other errors to the same notifications.

One simple approach is to write some Django signal receivers to listen in on page changes and dispatch e-mails or user-level notifications. You might also choose to create create reporting views in the CMS admin — or just show people how to satisfy their curiosity by looking at the reversion “recent changes” listings.

Don’t let tools wait until the end

When designing a content-driven site, keep the CMS in mind from the beginning of the project. As you do:

  • Research will drive basic decisions about access to, workflow for, and the purpose of content. (The people that will use the CMS are users too — so don’t forget to do user research with them.)
  • Content strategy can inform the structured content you set up in the CMS.
  • Information architecture will hint at the hierarchy and inheritance of templates.
  • During development, the people who will ultimately use the system might like the chance to see and experiment with it.
  • Analytics and instrumentation can be hooked into the CMS, so when you encounter errors you can easily move from a problem to its resolution.

If you work on the management tools while working through the purpose, intent, and content of the product itself, you’ll get more useful, coherent tools.

When you’re asking people across your team or organization to write, communicate, and inspire, you’re asking them to do something that’s never easy. Don’t let the content management system keep these folks from doing that hard work, and doing it well.

“Why your CMS is awful, II: what do to about it” was originally published in the Different Chairs journal.

Why your CMS is awful, I: capability & experience

What’s more valuable: having the capability to do something you’re interested in, or the experience of doing it without an undue amount of frustration and delay?

Seems like an abstract question, but it’s important to ask when you’re creating or selecting a content management system (CMS) for the web.

Remember the last time you used a CMS. Now, let me describe what you saw: A list of slightly different kinds of things, almost identical in appearance. An awkward mechanism for attaching images or other media to your work, involving a weird modal screen with a half-dozen fields you always ignore. An unused scheme for accessing older revisions of content. A way to work with draft content, or publish to a staging service, that’s still a little confusing after all this time. A sidebar or footer telling you that things you don’t care about are out-of-date. Oh, and somewhere, a few taps in, a wee text area, festooned with a rich text editor (itself having a stripe of about 15 icons, of which you use two or three).


The CMS nightmare I’ve described is typical of a system trying to offer the most capabilities. These systems make several claims:

  • that you can do all kinds of useful, amazing stuff;
  • that you should come to the system having already decided exactly what to write, or publish (and you’d love to type it all out into that tiny text area); and
  • that if you don’t know or remember how to use the system, it’s your own fault.

But they fail to acknowledge some important things:

  • that you, like everyone else, are stressed out by writing;
  • you’re worried about getting things to look and behave right, or that you’ll do something that undermines your message;
  • that you might have preferred to do this work from your phone or tablet; and
  • that you’d like the system to be smart enough give you reasonable defaults and let you choose only from options that make sense.

No wonder everybody hates their CMS. No wonder there are so many elaborate CMSes that go unused.


When someone, we’ll call him Joe, is motivated to go create or maintain something that requires him to go into the CMS, he’s already set about a very difficult task. Communicating with others is hard. Delivering a message is hard. Writing is hard. Encouraging readers to take some action is hard. Dealing with deviant and spammy commenters is hard. Writing a support entry about how to fix or replace a faulty hose that keeps falling out of the device is hard.

Therefore, setting about his task, Joe logs into the CMS. What does he see? A list of similar but slightly different things. A confusing sidebar. A wee text area.

Nothing here is providing a welcoming environment for Joe to do his work. There’s too much stuff, some of it never needed, most of it not needed right now. And if he completes the task that brought him into the CMS, he’ll feel that he’s succeeded despite the system, not because of it.

Which brings us back to the original question. What do people value more in a CMS: the capabilities they offer, or the experience they provide? For me, the answer’s simple. People value experience, and take capabilities for granted.

Having it all

Most open source CMSes offer a terrible experience, though they may be quite capable. They’re engineered from a one-fits-many perspective, with user interfaces that inflate or deflate based on which feature sets you’ve enabled. Introduce the dreaded plugin architecture, where little bundles of third-party functionality can be added (each dragging along their own user interfaces) and — well, you know where we end up.

Tremendous capability, hidden inside a poor experience.

For example, my favorite system for new content management projects is the Django CMS. It has a nice set of capabilities, a moderate amount of third-party applications that can extend those capabilities in the usual ways, and is otherwise easy to customize and improve. But, guess what? It’s just awful to use. The good news is that rounding off rough edges and improving a user’s experience is orders of magnitude easier than developing a modern CMS’s capabilities from scratch.

See the next post in this series for specific things a CMS should do to make it a decent environment to work in, as well as tactics for implementing those recommendations for projects that happen to incorporate the Django CMS.

“Why your CMS is awful, I: capability & experience” was originally published in the Different Chairs journal.

I’ll have a definition of “done” when I’m dead

One of the great bugbears of scrum and scrumbut systems is the Definition of Done (DoD, not to be confused with the Pentagon). Managing a product by post-hoc reporting works best when everybody on the “team” can point to a wiki page somewhere and proclaim, “My feature is done!”

Now on that wiki page, behind the cobwebs and broken links, is a bulleted list. It lists things such as: the code is written; the tests pass; the things are prepared; other things have been accepted; — or whatever else the management had everybody decide at last year’s Why The Product Is Late summit, in that classic consensus-building exercise where the manager speaks and everybody else waits, silent yet eager, for the moment of quiet assent to pass.

After a developer has checked in her work and proclaimed “my feature is done!” she is absolved. In a state of grace she drifts towards the weekend.

That’s our first definition of done. We’ll call it DoD (1).

Sometimes one might ask: what does it mean to be done with this product?

The answers come from way over there, outside of the technical group. The product is being sunsetted, repositioned, moved upmarket or downmarket. Retired, put to pasture, abandoned. Maybe frozen: the changeless, icy core around which the salesforce orbits.

If a feature can be done when it’s “done!” on Friday morning, a product can be done in the same way a puppy is done. Either it grows into something else or it just doesn’t make it. That’s DoD (2).

But what about you? Yes, you. What does it mean for you to be done? Are you done when the product is? When you have enough money to retire, or are forced into management? When you give notice? When your contract is up, and you from your labors rest? Let’s call this hairball DoD (3).

The Ann Arbor Chronicle is the newspaper in a town I once lived in. After writing for long enough to gestate an actual living human being, Dave Askins, the Chronicle’s editor, published a fascinating editorial grappling with the job. His readers compared the gig to running a marathon. But, Dave wrote:

“It’s not really clear what counts as the finish line — when I die, perhaps? The idea of attending Ann Arbor city council meetings until the day I die is a fairly sobering prospect. I’m not sure that’s what I signed up for.”

That was four years ago, but I remember it as the most acute condition of DoD (3) I’ve ever seen.

Now, I’ve used the word “done” in each of these senses, and more. It’s as slippery and unhygienic as a river otter. But here at Different Chairs, I call something “done” when it’s ready to start.

Before your product is ready to radiate out into the ether and help real people change the world in real, measurable (if tiny!) ways, it’s in development. It’s in process. But when it’s useful enough to keep somebody’s attention long enough to help them do something — guess what? — it’s done. Instead of wondering what’s the most important thing to do, or worrying about your development schedule and the tenuous ligaments holding it to reality, or the fact that time speeds up as you fall behind schedule, relax: you’re done! It’s time to watch how people use the experience you’ve created for them, and learn from their mistakes and yours, and improve the experience in worthwhile and surprising ways.

That is to say: once you’re done, you can really get started.

“I’ll have a definition of ‘done’ when I’m dead” was originally published in the Different Chairs journal.