Trying to make sense of Rightshifting

I’ve been learning about Rightshifting of late and am finding the mental models used difficult to imagine. This led me to think about how I could redefine them so they made more sense to me.

However first up let me briefly surmise what Rightshifting is.

If you haven’t got time to look at these links now, skip forward, but they do a much better job than I will of explaining!

Rightshifting is a word coined by Bob Marshall, here’s his post explaining it.

In addition there is also the Marshall model, here is the explanation:

Basically Rightshifting is based on the premise that an effective knowledge work organisation is a function of the mindeset of the organisation.

There are 4 basic mindsets in terms of organisational effectiveness:

  1. Adhoc
  2. Mechanistic/Analytic (these terms seem to be used interchangeably in the Rightshifting community)
  3. Synergistic
  4. Chaordic (if you’re interested in where the word chaordic came from, see this book: )

It is then suggested that the closer to Chaordic you get the more effective the organisation is. However most organisations are stuck at the analytic stage. Hence the need to right shift organisations.

Here’s Bob Marshal’s diagram of the Marshall model, taken from the above blog post:

Marshall model
Marshall model

Note the red transition points, denoting how hard it is to break through into a new organisational mindset.

What I really struggled (am struggling!) to understand was what the different organisational mindsets really meant.

So  I wrote down some words that might be used to describe the different stages:

  • Adhoc: Cowboy, messy, chaos, creation
  • Mechanistic: Process, tools, rules, methods, control
  • Synergistic: Learning, flow, empowered, value
  • Chaordic: Opportunistic, come together, mushroom, sharing

As you can see by the words, the adhoc organisation sounds like an early start up. The mechanistic sounds like most businesses! Synergistic sounds like an Agile or Lean organisation and Chaordic sounds more like an open source community.

I then thought further and came up with these definitions, to help me map it to my understanding:

  • Adhoc: Finding value
  • Mechanistic: Building value
  • Synergistic: Flowing value
  • Chaordic: Enabling value

Take a look at Rightshifting, if you haven’t already, and let me know what you think about my definitions of the various organisational mindsets and if you think they are a useful  or helpful way of describing them.

More Rightshifting posts:

Go/No Go? Simple question powerful results?

I was thinking about the process of building a solution and it occurred to me that in many ways, each stage of developing a product or project is a simple Go/No Go question.

It doesn’t matter how complex or simple it is to reach the Go/No Go question, the fact still remains that all we want to know is if we should stop or continue. Let’s look at an example.

Imagine I have an idea for a fantastic new website that tells you how many weeks it’s been since your last run and prods you to go running. (I didn’t say it was a good example!)

At first it’s just an idea, but already I’m at my first Go/No Go gate. Is the idea worth spending some time on? At this stage I might just mull it over for a bit. But in the end I’ll either decide it’s worth looking into further or it’s a rubbish idea.

Assuming I said it was a Go. The next phase might be to do a quick hack to see if it’s interesting or so I can share it with some people. Once I’ve done this I’m again faced with the same question. Go/No Go.

Now we have an idea that’s made it though at least two gates perhaps I’d like to think about how it might become a proper product. So my next move might be to do a Lean Canvas, where I outline the business model. Again the purpose of this is to get to a Go/No Go gate.

Eventually I’ll start doing development on the product. I might even identify a MVP (minimum viable product), but again I just want to get it up online so I can get to another Go/No Go gate.

Finally, making one last leap of assumption, my product is successful and I want to build some new features. Again for each feature we can use the Go/No Go cycle.

This can go on indefinitely but the point is by using on the Go/No Go question I’m focusing on what I need to know to make that decision. Also, as it’s a choice that means I could throw away what I have done so far, it makes sense to work in smaller chunks. So there is less waste if I do hit a No Go.

What happens if we do hit a No Go? Well if it’s a product/project in development then it means just that. We’ve hit a point where there is no value in continuing. Do we want to launch something that has no or negative value? If the product/project launched and is delivering value then the No Go is only for the feature(s) about to be added. Again do we want to launch features without value?

What might happen if we can’t make such a binary decision? I’d suggest in that instance we need more data. Perhaps conduct an experiment or experiments to test the hypothesis. Whatever happens, in the end we’ll get to a Go/No Go choice.

The key to the Go/No Go approach is to ensure we eliminate the waste in getting to the Go/No Go gate. Take only the steps that allow us to make that decision, whether that be some thinking time, a napkin sketch or an iteration of development. Also that if we deliver value as early as possible in the process we minimise the risk of major waste.

Do you use a digital agency, it might be time to re-think your options?

Coming from a background in digital agencies I’ve often asked why a client wanted to hire an agency. However clients rarely understand why they need to hire an agency and in a lot of cases it’s not actually what they need at all, well not a traditional agency relationship anyway.

Traditional agencies work on the basis of project work. They are hired to do a project for the client (build a new website, re-design an existing website to make it better etc). There are only two reasons a client hires an agency in this context.

  1. They have the skills but not the time/resource to do the work themselves
  2. They lack the skills to do the work themselves

These two reasons, when coupled with project thinking (thinking where you give a brief, the work is done and then handed over to the customer at the end) lead most companies to look at an agency model to get the work done. You agree a fee with the agency, they do the work and the risk is all theirs. Sounds lovely in theory, but unfortunately the business of the web doesn’t fit neatly into the project model. It’s a good model for when you’re building a house or something tangible but falls apart with software.

The reason it falls apart is that a website or piece of software is not a finite project. There is no end state, just a constant state of improvement and development. You launch your site and customers want new features, or the market changes. You then need to go back and make changes to the “finished project”.

So now you have a choice, if you haven’t planned for this already, you either go back to the agency and do another project to add improvements or you do the improvements yourself (depends if your underlying reason was 1 or 2 above). So really you didn’t solve your underlying problem, lack of skills or resource, you just delayed when it became an issue. Add to this that the pace of change is getting quicker in the marketplace and you can see that old project based thinking is not the solution.

So what are the options you do have?

  1. If you have a lack of skills then get those skills on board.
  2. If you have a lack of resource then get those resources on board.
  3. Use a digital agency that thinks beyond projects.

Option 1 and 2 are really the only viable and sensible solution if your digital product is at the heart of your business. In fact think about the message you send out to your existing team(s) if you get in a digital agency. You could be sending out a message that you don’t want to invest in their skills and would rather pay someone else than help them get better.

Option 3 means looking more closely at your agency of choice and understanding that you will need to be with them for the long haul. This means thinking beyond projects. You’ll need an agency that values transparency with you and wants to work collaboratively with you and your team. The agency will need to gel with your organisation seamlessly and become like another ready built department. The agency will need to be brave enough to share knowledge and skills with your teams and sometimes work co-located with your company. You’ll need to look at a billing model that is collaborative and cost effective over time.

Does that sound like your existing agency or any agency you’ve worked with before? Chances are it doesn’t and that’s because most agencies are stuck in old ways of project centric thinking because clients expect/demand it. However it is incumbent on both the agency and the customer to reject this old mode of thinking to ensure that agencies and the solutions they provide are fit for the future.

Traditional vs collaborative agency model
Traditional vs collaborative agency model