Thread by @swardley

Be careful with the idea of org changes as forcing functions for a company to adopt effective principles.

I hear people saying - "if we just re-org the structure then everything will work" - as often as I see it failing.

instead of trying to move the deckchairs on the Titanic, focus on fixing the great big hole.

Put effort into improving principles within the organisation ... from this ...

... to this.

You'll probably find (well, this has always been my experience) that the organisation you require will emerge from the act of sorting out basic principles.

Unfortunately, it's not so "dramatic" for executives or as financially rewarding for consultants as a major re-org is ... but then, if the focus is on building an organisation capable of adapting to future changes then I'd take the path of sorting out principles first.

X : You're very boring.
Me : Hmmm ... ok. Let's do some agile everywhere, buy some robots, add a bit of AI with blockchain, make sure it's enterprise digital and bimodal the shit out of this place whilst we DevOp all the things and undertake a massive re-org ... biggest one yet.

... alternatively, we can start with getting good at BORING old phase I ... focus on users, focus on user needs, challenge assumptions, understand what is being considered, use appropriate methods etc etc etc

Oh, and to be absolutely clear, every example that I know of a company trying to adopt the "pioneer - settler - town planner" structure without first getting their principles in a decent state has ... failed.

Principles first.
Org structure later.
Culture, later still.

X : What do you mean by principles?
Me : Universally useful patterns that apply regardless of context.

My list of them (Wardley's doctrine) is provided in the table. These are derived from mapping with the exception of "seek the best" which was used to populate the table.

X : How did you organise that table?
Me : Mostly through mapping. Some principles are built on others etc. It's also
1) Not an exhaustive list
2) Constantly expanding as principles co-evolve with technology change.

X : Are these the same as values?
Me : No. Values are things you believe in rather that universally useful principles of action. When it comes to values some are mutually exclusive and some non-exclusive. You can map values as well. They evolve to become "accepted".

X : Non exclusive?
Me : OK, "project method" [meaning] has three different competencies (agile, lean, six sigma) with each evolving to be best suited to one material instance of an evolving thing. That thing also has a common meaning (i.e. teleportation)

Me : This leads to the universally useful principle of use appropriate methods. Hence when creating a large project you will tend to use multiple methods unless you want to fail regularly.
X : I was talking values.

Me : Sure. Well within that landscape you have one principle (use appropriate methods) and two opposite but not exclusive values (i.e. you need both) - a belief in people over process PLUS a belief in process over people.

... so, you've got principles (universally useful patterns) which I provide in my doctrine table plus you also have evolving values (i.e. beliefs) some of which are exclusive and some are non-exclusive.

i.e. with non exclusive values you can validly hold opposing beliefs at the same time because they are context specific.

In the same way you can agree to multiple methods precisely because they are context specific competencies.

In short, you can agree with both the beliefs of "process over people" and "people over process" at the same time by pointing to the contextual nature of that belief.

Exclusive beliefs are things like "belief in God" - you can't both believe and not believe at the same time.

However, for the time being don't worry.

Focus on doctrine, i.e. that list of principles and simply remember that values (i.e. beliefs) are not the same as principles (i.e. patterns of universally useful action).

That's all you need to do. Fix the doctrine.