top of page
Search

Models, Tools, and Frameworks

  • Writer: Dave Abraham
    Dave Abraham
  • Apr 11
  • 8 min read

Updated: Apr 13

People that know me may be used to me referring to terminology from books, colleagues, presenters, and TV and other media. Sometimes they can seem overly simplistic. Sometimes they can appear overly complex.


In relation to business and teams, I have found it important to categorise some of the things I've learned into 3 categories - Models, Tools, and Frameworks. If you just come across certain terminology in casual conversation, they can also appear a bit random:


The way I define these terms is:

  • Models

    • are usually a concept to take some relatively complex scenarios in the real world, and turn it into a simple model to help a non-expert cope with the complexity, or start to learn a topic by breaking it down into manageable chunks.

    • Business courses often have a variety of models such as 2 x 2 grids, to turn a complex set of data representing anything from the marketplace, finances, people, or any other part of business, into some manageable components that students can process without getting dragged into the detail of specific examples.

    • They can be very useful. But it is also important to be wary of them, or understand their limits, because the real world is rarely as simple as the model.

    • As James Gleick described really well in his book Chaos back in the 1990s that I would paraphrase as "There's always more detail once you start to look closely"

    • Sometimes the models create ongoing research, either in a university, business school, or private business. The good ones (and not so good ones) often lead to a book or a series of books.

    • Many of the terminology and models I use are just used occasionally where they seem useful to help myself or someone else deal simply with a complex scenario.

    • There are a number I use, such as the Ansoff Matrix, Lencioni's pyramid, The Brand Arrow, various of the models in Good to Great such as "Right people on the bus, in the right seats". I also have my own model of an ICT architecture for SMEs, that I use as a virtual CIO to help SMEs adopt appropriate technology within a structured framework.

  • Tools

    • Some models get researched or adopted at scale by a significant enough number of people and organisations that they evolve and become proven to work (or not work).

    • If they are demonstrably proven to work in certain scenarios, then I would describe them as tools.

    • Just as with physical tools, it is still important to use the right tool for the job. This involved understanding what the current scenario is and what I want to achieve in order to select the right tool.

    • If I want to drill a hole in a piece of wood, I want a drill, rather than a saw. And if I want to drill lots of holes and only have a hand drill, that may be fine. But if I lots of holes to drill it may be worth going to the garage to get my electric drill. Or buying some appropriate drill bits.

    • Just as with physical tools, there are often a choice of tools.

    • As a manager, just like a tradesperson, I have a range of tools in my toolkit, for example:

      • For example for building a team with an appropriate mix of skills and personalities, I would usually use Belbin. However, I could have chosen to use DiSC, Insights, or Kolbe. Whilst each one is a different tool, and you need to know how and where to use each tool because they are different, they also have a lot of similarities. So if I work with a person or team that prefers another similar tool, I will assess how interchangeable they are.

      • As another example, Good to Great introduced the models "Right people on the bus, in the right seats" and "The Hedgehog Concept (simplicity within 3 circles)", amongst others. From these, and other models, I observe that the EOS tools "People Analyser" and "Delegate and Elevate" have emerged as proven tools, used across hundreds of thousands of organisations around the world.

      • Gallup 12 is a great tool for assessing and building staff engagement, proven across hundreds of thousands of organisations around the world.

  • Frameworks

    • Some tools work well on their own, especially for amateurs. Some tools work best when used with other tools that are designed to work together. Professionals tend to work in an environment where groups of people in a company, or indeed in an industry, use a common set of tools.

      • Accountants in any one country will tend to comply with a given set of standards, and have some standard tools that all work together to enable the accountant to work to their agreed professional standards in their country.

      • Lawyers work similarly - the government and courts of that country define the legal framework for how the country should run aligned to the culture of it's people.

      • Indeed the set of laws of a country are a framework for how the country should work.

      • IT Security professionals around the world use ISO27001 (evolved from BS7799) as a framework for managing security, and then picking the tools within that framework.

      • Business managers and owners in the UK that are not IT Security professionals can adopt the CyberEssentials framework. Over time, this is likely to become mandatory in some sectors or to win government contracts.

      • Software developers used to try to manage projects using a framework called Prince 2, or a model called Waterfall. However over the last 20+ years, a model or culture called Agile emerged. From my perception there is now a well proven framework called Scrum has emerged, proven across a large number of development teams, comprising a set of tools that have been adopted by many software development companies across the world, and that are free to adopt.

    • When running a business, therefore there are a number of frameworks that I naturally work within and comply with:

      • The legislation of the UK

      • The accounting and taxation requirements in the UK

      • Health and safety frameworks, as a minimum those mandated by UK law and best practices

    • Frameworks capture the best practices of other people, that have been tested at scale in different scenarios.

      • In the UK, although the amount of frameworks we have to comply with is increasingly and can feel frustrating for some people, I also believe that overall, because they have been developed over the last 1,000+ years, our frameworks still give us a large amount of freedom to live our lives how we wish to, with opportunity to set our own vision, including running private businesses.

      • The great thing about a private business, is that the leaders get to create their own rules, within the laws and culture of the country

    • Frameworks for running SME businesses

      • When I was running my first business, like many owner-managers, I and my co-founder felt that our business was unique.

      • And it was unique.

      • But until I went to Cranfield Univerity's Business Growth Programme, BGP, it was also inefficient because of how unique it was.

      • BGP introduced a framework, where we could adopt a set of tools, such as Belbin, within it's framework of "4 M's" - Market, Money, Management, and Me, across "Where are we now", "Where are we going", and how are we going to get there.

      • The 4 Ms was a distillation of the vision and models produced by the BGP team of Colin Barrow, Liz Clarke, Robert Brown and the team at Cranfield in the late 1980s, and as published in their book "The Business Growth Handbook"

      • For many years, I ran businesses and teams using that 4Ms framework.

      • More recently, I've observed a small number of similar frameworks emerge:

        • Scaling Up (which started from some models in the book Rockerfeller Habits, into an organisation called Gazelles, before becoming Scaling Up)

        • EOS (Entrepreneurial Operating System), developed by Gino Wickman who initially was a Gazelle's consultant, before working with Don Tinney to take the best practices of Gazelles, plus other learning and hands on experience, to create EOS. Initially this was visible to the world in the form of the book Traction in 2007.

        • There are probably some frameworks trained on MBA programmes, and some "models" hoping to establish themselves as frameworks.


I would summarise it as follows:


EOS as a Framework? Or is it a cult?

I originally treated Traction as "just another management book". It reminded me of all the things I'd learned from Cranfield BGP, Good to Great, and many other books. It reminded me about all the things I was doing well in the teams that I was working in, and also prompted me with some of the things I ought to be doing better in the businesses that I was involved in to get from good, to great!


However since being given the "the movie version of the book" introduction to EOS, by Jason Green, an EOS implementer in the UK in 2023:

  • I've really come to appreciate that over the last 20 years, EOS has become proven across hundreds of thousands or organisations across the US, the UK, and beyond.

  • what at first felt like just another set of models

  • then felt like a cult that you were either in or out

  • I now see it as a key framework for running pretty much any SME

  • EOS defines 5 foundational tools, that if you're not using all 5, you're not running on EOS. The 5 tools are - accountability chart, Vision & Traction Organiser (V/TO), Scorecard, Rocks (or Quarterly goals), and Weekly Meeting Pulse/Level 10 meeting to keep it all on track.

  • EOS defines a further 15 tools in the tool box, and I've learned that it's always worth reaching for those tools first, if they seem to be the right tool for a particular job.

  • One of those 15 tools is Kolbe. Personally, because I'm used to Belbin, I find it's relatively interchangeable. Like having Makita tools, but preferring the DeWalt sander, for example. It's not one of the core tools that defines whether you're running on EOS or not.

  • EOS is rather like "Scrum for business" -

    • it may appear a bit cult-like

    • EOS and Scrum both emerged over a similar timeframe, from a time when big things were achieved by big government and big business typically with top-down planning,

    • they both introduced in parallel a more agile "bottom up", democratic way of organising teams, to deliver big goals.

    • EOS is like business in black and white - it doesn't tell you how to do the things that make your business unique. That is for your marketing, sales, and operations teams, and management team as a whole to do.

    • Scrum doesn't tell you how to develop, that is for the members of the team to learn how to do.

  • However EOS and Scrum each defines the bare essential tools and structure to be successful, and gives me and the team freedom to add colour, motion, and sound where the framework doesn't have a tool.


So I now have the view:

  • I start with a framework - is there a mandatory one that I must comply with I use it. If there isn't a mandatory framework from "above", depending upon scale and shape of team I'm involved in, I will default to using:

    • EOS for running a business (but if I'm within a business, if there is a clear equivalent, I will be equally happy)

    • Scrum for running a development team or any team level project, if the environment is suitable for an agile approach to the project

  • I default to using Tools as provided/recommended by that framework, after assessing if they are appropriate for any particular task

  • And then I use other tools and models to add colour, motion, and engagement

  • Always aligned to my picture of success, and the team's picture of success.

  • Because the framework is of no value, if I'm not clear what we're trying to achieve.


Overall, the framework is supporting the tools, so I visualise it from the bottom up:

  • The business has frameworks

  • Each function within the business may have its own framework, but should also use the business framework

  • each function within a business will use the tools provided by the business framework, functional framework, industry frameworks, and any other tools appropriate

  • where a tool isn't available or suitable, then people will and should use appropriate models


Further reading:



 
 
 

Comments


bottom of page