The clinic is for problems that have hung around for a week or so, escaping the solution by all these other methods and is holding up the project. Often, this type of problem turns out to be a systems problem that couldn’t be solved because the people working on it did not represent a wide enough scope. If the people who are part of the problem and not in the room, the chance of solving a problem goes way down.

Moral: Use every tool you have. This business is too hard to do otherwise.

Done well, I think the clinic method could help here – a good clinic team wouldn’t just look at the manifestation of the problem, they’d look at underlying causes and help guide the people reporting the problem (and others in the organization) to improve the underlying causes. Hard to do, though.

And, in a proper lean organization, they’re always reporting problems and working on ways to fix them in both the short term and the long term. (Where by “always” I mean “once a minute on average, a cord gets pulled somewhere in the factory that has the potential to stop a production line”.)

So I guess that’s a long-winded way of saying that I agree with your first sentence: pathologizing problems is the wrong way to go, it’s much better to have a deeply ingrained problem-solving (including problem-discussing) mentality.

Though something about the clinic idea still appeals to me – the basic analogy doesn’t strike me as inherently flawed. But that doesn’t mean that it’s a good idea in practice: probably our current state of affairs is such that what we need isn’t hospitals but widespread washing of hands….

I like the way we approach problems in architectural studio settings: you have your design team that works away at a problem, and on a regular basis a larger collection of designers get together to see your work and critique it.

A recent example is when my design lead presented a fairly simple set of solutions to the fenestration of a facade (the pattern of windows and solid wall, basically). We started off discussing that problem, but suddenly the conversation shifted and we were talking about how the tower rising above that wall looked really out of proportion. Nobody had considered that a problem, but once we started talking about it, the issue was not the awkwardness of the fenestration, but the fact that the tower itself was too wide.

Thinking back on my years of coding, regular crits like that would have made a huge difference in the quality of work we produced. Not only do you find a lot of problems in simply preparing your work for critique, but in the light of the critique you see problems you didn’t realize were there. It would have been a hard sell, though. People hate being put on the spot like that. Since I started architecture school I’ve been wondering how to take the format and repurpose it in a coding environment, and it would take some serious management commitment.