An Introduction to Frameworks: finding the sweet spot between structure & adaptability

Some people love frameworks, some hate them — especially when they are imposed as a control mechanism. I’m broadly framework positive: I use them as tools for working, collaborating, teaching, and learning. I have had a lot of fun and learned a lot over the last few decades since delving deeply into the wonderful world of frameworks.

So here’s my opinionated introduction on why frameworks can be good, what they are good for, and how to make frameworks work for you.

Like a framework, scaffolding provides structure to support your endeavours

Short version

1. Why frameworks? Frameworks provide helpful structure, with rigidity in some areas, and flexibility elsewhere, for all sorts of complex challenges, especially when working in teams and groups.
2. Small is beautiful. I prefer small, memorable, easy-to-learn frameworks that can be extended and combined to tackle bigger challenges. If you can sketch the main idea(s) on the back of an envelope or drink coaster it will be easier to remember … and explain.
3. No panaceas. Frameworks should come with a description of their sweet and sour spots, rather than claim to be panaceas. If they don’t, figure this out yourself. Be wary of claims of “the perfect framework”.
4. Large frameworks may have useful parts. Sometimes they can be usefully deconstructed and mined for smaller pieces.
5. Learning is usually required. To learn a new framework, “empty your cup” and try it out a few times. Seek mentors if confused. Cross-compare and combine with other frameworks to further test it out.
6. Stay humble. Once you’ve internalised a framework remember that others don’t necessary have your skill or experience. It’s time to teach!
7. No perfect framework. Even a flawed framework has value, and every framework has flaws. A common trade-off is between ease-of-learning and flexibility.
8. The map is not the territory. Use a framework too much and you’ll start to see the world exclusively through it. [If you only have a hammer everything looks like a nail.] So have alternatives at hand.
9. Grow, then refine your toolkit. After a few years of collecting and trying frameworks do an audit. It’s far better to have five frameworks that together cover 90% of situations than 50 that cover 99%. They make a lighter toolkit to carry!
10. Don’t shoot the messenger. I can’t believe how much framework-bashing goes on nowadays. These are just tools, people. It’s okay to do something else. There’s probably some good that can be salvaged. OTOH if they have been turned into the basis of a multi-level marketing cult your antipathy may be understandable!

Why frameworks?

Say you want to get something done: bake a cake, deliver a project, or learn a new skill. At one extreme you could precisely follow a step-by-step recipe or process. At the other extreme you could improvise, making it all up as you go along or rely on habits and skills from past experience. These two extremes mark out the poles of a continuum between conformity to a pre-defined approach and autonomy to maximally exercise your own judgement.

Frameworks attempt to find a happy medium between the extremes of maximum safety and maximum autonomy. Ideally there is enough structure and guidance so that you won’t get into too much trouble, while allowing for a degree of individual expression and adaptation. The former gives a sense of predictability. The latter allows people to apply their existing talents and skills more freely, and to adapt to the current context.

But people and contexts vary, posing a challenge to the creators of frameworks. While the framework attempts to encode the experience and dare-I-say-it wisdom of its creators, they cannot know your exact context, and they don’t know about you, your skills, and your limitations.

Therefore framework authors may well choose to explain in additional detail what they mean, and add extra rules. Adding more detail may increase the sense of safety, but reduces adaptability and modularity — the ability to combine with other frameworks or work in novel circumstances, unless there is a mechanism for updating or contextualising the framework.

For example, the 10 commandments of Moses sets out a brief religious and ethical framework, but the Torah (Hebrew bible) contains in total 613 commandments, giving considerably more structure for those who follow their guidance.

The 10 Commandments of Moses (translated)

What is a framework, anyway?

Here’s Mike Cohn, describing the notion of a framework in an Agile context, but it works as a more general definition too:

Scrum is a framework. Scrum provides a structure to work within and desired outcomes to achieve, but leaves teams [or whoever — Dan] room to decide how best to achieve those outcomes in their specific context.

Think of a framework as the frame of your house. You can build a lot around the frame, with considerable flexibility, but the frame itself is necessarily somewhat rigid. (You can always bend the frame, but that’s a more advanced move, and comes with trade-offs.)

Here’s a sketch of the Scrum framework … it’s not all there is to Scrum, but the basic structures and roles are apparent.

What I look for in frameworks

I like frameworks that have a low barrier to entry — making them easy to learn — and have lots of space to grow. There may be more advanced parts, but ideally you don’t need to learn that stuff to get started. To paraphrase the great educator and technologist Seymour Papert: “We want low floors, high ceilings, and (while we’re at it) wide walls.”

By these criteria basic Scrum is perhaps a little heavy-weight, although Agile luminary Alistair Cockburn managed to distil the essence of Scrum “onto a post-it note”.

One of my favourite frameworks is Bernice McCarthy’s 4MAT model, from which we can extract the simpler: Why / What / How / If framework for presentations and writing.

1. WHY?
2. WHAT?
3. HOW?
4. [what] IF?

In a nutshell, if you’re preparing or critiquing a presentation or written piece:

1. Make sure that you cover the Why? What? How? andn what If? questions. These will appeal to different (diverse) kinds of people in your audience / readership.
2. Do it in the above order. It tends to flow better.

I love this because the framework helps correct for personal bias towards a preferred question and spot omissions. In the case of this article it reminded me to go back and “Start with Why”, where in an early draft I had jumped to the What.

Want to help someone become a better editor? Encourage them to read over a presentation with this framework at their elbow.

Want to go further? There are deeper parts of the model, teased in this diagram …

A deeper dive into the 4MAT model

Perhaps sadly I’ve got so much value out of the simpler form — Why? What? How? what If? — that I’ve never really gotten into the additional detail. And I can easily remember those four or five words!

How I learn a new framework

Another framework, this time for learning, is summarised as “Shu, Ha, Ri”. These Japanese words capture an approach to learning-by-doing common in the martial arts.

At the Shu level one empties one’s cup and strives to learn the basics without being critical. This may take some time. Think of the Karate kid practicing “wax on, wax off” without understanding why.

At the Ha level one can break the rules in order to adapt to context.

At the (rare) Ri level one has so internalised the learnings that one can act intuitively while formulating a new understanding, perhaps leading to a whole new style or sub-style.

So, ideally, I:

1. apply the Shu philosophy and spend a bit of time learning a new framework on its own terms. [Note: this gets harder the more experienced and grizzled you are, but it can help you stay young-at-heart and humble.] Try it out on simpler challenges, by the book.
2. progress to Ha. Step back and assess what the framework has to offer, cross-reference with other approaches, and apply it (probably in combination) to some larger challenges.
3. decide whether to add it, wholly or in part, to my existing toolkit. If I keep using it long enough I’ll start to internalise it, and perhaps it will start to come out unconsciously (Ri).

On the other hand, I recommend against forcing others to start at the Shu level. The choice to “empty one’s cup” is a personal choice, so better to invite rather than impose. For this reason I sometimes refer to my teaching style as Ha-Shu-Ha. Start more flexibly, wait for people to volunteer for the more rigorous training, and plant seeds for further development — back to Ha, and eventually, Ri.

What Else?

Frameworks can be a bit too rigid

I think framework designers often fall into a couple of traps:

1. Failing to specify the pre-requisites and range of applicability of their creation. This can make it seem like they intend their framework to be a panacea (i.e the magic wand or silver bullet that will fix everything).
2. Making too large a framework, hindering learning, flexibility and up-take.

My advice to would be framework designers:

1. Be humble. Explain where your framework is intended to be used, and where it is not applicable.
2. Small is beautiful. Design a small diagram that captures the essence. If there’s more depth, design a learning path where learners can optionally learn additional increments, or mix-and-match with other approaches.

For framework users:

• Remember that (most ;-) frameworks are not religious texts!
• This bit takes judgement: know when to follow the rules (Shu), and when to start breaking them (Ha).

The Patterns Connection

Some readers may suspect that I am a fan of design patterns and pattern languages, they would be correct!

The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

— Christopher Alexander, A Pattern Language

For those who are familiar with this kind of approach, essentially I am advocating treating large frameworks as if they were pattern languages — even if it means reinterpreting more rigidly phrased language — and treating smaller coherent pieces as if they were patterns.

Once again the Scrum is a good source of examples:

• The better known Scrum Guide is a short, Shu style document. It has the virtue of brevity, but comes across as somewhat dogmatic.
• A Scrum Book: The spirit of the game is a far richer pattern-based exploration of Scrum.

Conclusion: build your toolkit

There are lots of great tools out there, including frameworks. Go forth and learn from them. Take them seriously, but not too seriously!

Key points:

• You can use the Shu, Ha, Ri approach to learn new frameworks and other tools.
• As you become more sophisticated, be prepared to simplify and fill in gaps, and mix and match (Ha style)
• Teach others. The 4MAT framework can be helpful here.
• You may find, like me that after a while you have too many tools! This is when it makes sense to do an audit, and critically review which are your go to frameworks.
• Finally (as always): have fun!