Why I Don’t Like “Frameworks”
Last week, I mentioned that a framework can be useful – or it can simply be a prop (something that looks good but perhaps doesn’t have much substance).
I’ve seen too many books and articles written with the Three Steps for This or the Circle of That. Each of those formulaic solutions is often just the same common-sense information, repackaged in different ways. They are touted as simple solutions that anyone can do – and they often fail because real solutions require introspection, buy-in at every level, and sustained effort at every level.
When employees are faced with a barrage of these failed initiatives, they become disheartened that anything will ever change – and they give up even trying. Without your employees’ buy-in, your efforts at change will fail.
So, that’s the “prop” side of frameworks – marketing fluff, superficial structure, a novel way of looking at the same thing from a different perspective. It’s not that they can’t work, it’s just that they in themselves are not a means to the end you seek. They are no magic wand that you can just wave at the problem to make it go away.
Where a framework becomes useful is in helping you (or the consultant) remember to complete all the steps of a process. And the processes are really very much the same when you’re looking to solve a problem – listen, research, ask questions, get buy-in, diagnose the underlying issue(s), create a solution, implement it, and then evaluate it and make changes as needed.
My concern is that cute frameworks with catchy names gloss over the real work that needs to be done. They make it look like solving problems is easy and that one solution with work for every company. That simply isn’t the world I’ve experienced.
What “frameworks” do you use internally or with customers/guests? Who benefits from the structure of that framework? How effective is the framework in doing what you want it to do?
Who else should you be bringing into conversations on that topic? How can you better to listen to what is being said (and to what is not)?
What tools do you use to determine whether you are addressing symptoms or the actual (sometimes hidden) underlying problem?
What supports do you have in place to keep your good solution from slipping backwards into “how things have always been done”?
How do you measure your progress and assess what is working and what is not? What process do you have in place to ensure your solution is updated and adapted as you learn more and try new things?