Building it isn’t the problem – guess what is?

Any readers in Madrid?

I try my best to hide it but a few people know, in an alternative life I could have been a very happy train spotter. Perhaps its just an engineer’s hardware fetish, but it isn’t the actual trains themselves, its more the systems around railways which fascinate me – perhaps thats why I said yes to the poison chalice that was Railtrack all those years ago.

Anyway, this means I follow a few transport bloggers. One of them through up the really interesting piece on How Madrid built its Metro Cheaply.

One reason this piece really resonates with me is I know clients who are obsessed with not spending money, or rather: there is unlimited time and money for governance, assurance, stage-gates and all the paperwork, but money for actual work is restricted by all those costly processes.

Once again see the Dustin Hoffman, Laurence Oliver story in playing out.

But back to Madrid. If you read the piece you find that Madrid built the metro cheaply not but using some new fangled technology to dig the tunnels, not by forcing suppliers down to minimal price or replacing humans with AI robots.

No, most of the cost savings were on the way the work was set up, what you might call “management side”. So, time to delivery was prioritised over cost and, so work could happen rapidly planing and environmental processes were changed, and communities included in discussion. The solution was not to get rid of management; the solution was to change management approach and priorities with management as part of the solution – this is reminisent of Fred Brooks.

Rather than seeing each metro line as a project on its own – with its own set-up, shutdown, management and engineering teams – there were seen as a continuous series. This allowed teams, and learning, to flow from one to another.

In other words, rather than project-project-project, it is continuous engineering. Another example is rail electrification programme. The UK sets up each electrification efforts as a unique project while Germany runs a rolling programme. Germany electrifies nearly 10 times as much track a year as the UK.

Even when Madrid did make changes to the engineering work they were management driven to reduce costs and accelerate delivery, e.g. the use of standardised designs and existing technology.

Although we are talking about a very physical metro project here many of these ideas flow across to technology, software, systems.

The challenge we face today is rarely “Can we build it?”

Today the experience and technology exists, whether building metros and software system. You might as well assume you can build it, the technology is there.

The challenges we face are: can we build it in time? in a cost-effective manor?

Rising costs and time might be seen as the second version of Parkinson’s Law: “the number of workers within public administration, bureaucracy or officialdom tends to grow, regardless of the amount of work to be done.”

More than the technology it is the administration which is the constraint.

Yet, looking at the engineering to reduce time and money may be the wrong place to look – especially when quality is cut. Instead, there is a need to engineer the environment – the management processes and approaches, the rules, regulations and funding – around the work to allow it to proceed rapidly and cheaply.

However, cutting management time – all that administration, governance, reviews, “are you building the right thing?” – entails some risk. Spending money to remove the risk slows it down and increases the price. Proof again of an economic definition “profit is the return on risk.” Eliminate all the risk and you eliminate all the profit, or in these cases, benefit.

(Madrid metro image taken from Wikichttps://commons.wikimedia.org/wiki/File:Madrid_Metro_Map.svgommons by Javitomad under CCL license.)

Building it isn’t the problem – guess what is? Read More »

Race against risk

There are those who think “projects can save money by going slow.” I’ve never quite understood this because the same things still need doing but even serious people say it (HS2 anyone?). Actually, they are trading reduced expenditure now for longer expenditure in the future. Maybe that means that less money needs to be borrowed now so interest payments are less over all, perhaps.

This kind of thinking also leads companies to split resources between multiple work streams: rather than having a team of 4 people work on 1 thing and get it done quickly the same 4 people work on 4 different things and all 4 get done slowly.

I’ve long argued that “shorter fatter” is better because that means the return on investment starts flowing sooner. It also means there is no “bulge” at the end when 4 projects complete and everyone is racing for the same scarce resources to complete.

This longer-slower thinking is common in the project mindset but is is absolute rubbish.

I see two reasons why people may choose to believe this.

One, people don’t like making decisions, and especially don’t like saying No. So rather than cancel a project it can be reduced in size so nobody is upset.

Two, people care far more about cost than benefits. Add to that, most people don’t understand cost of delay.

So what should teams do?

Recognise that when you start work on something you open a risk window. If you aren’t doing anything then there is no risk of doing – there may be risk of not doing but that is another story. Once you open the window you are at risk, at the very least you are at risk of needing to write-off expenditure in future.

The more you spend the more the more there is at risk. And the big risk is often that there is nothing to show for the expenditure.

What most people miss is: the longer the window is open the more chance you have of a risk happening. If your project last three months the chances of loosing a key member of staff in that time is low, if it lasts one year the risk is higher and if it lasts five years it will certainly happen.

Similarly, the chances of adverse weather hitting your construction site, a competitor launching a rival product, new technology rendering your work obsolete, a pandemic hitting or one of a million other things are all increased when your project take longer.

Once you start work you are in a race against risk.

Perhaps my industry knew this once upon a time and that is why IT projects used to have long drawn out requirements phases: low cost, low risk. Only when the coding starts and the costs go up does the risk get serious.

But we now recognise that the more requirements you gather the greater the risk that they change. The requirements risk window opens the day you start writing them. Only when you show customers working product do you know if you got them write.

Then, once work starts and big money is being spent go at it hell-for-leather. Concentrate your resources, aim to close the risk window but also deliver: early delivery further reduces risk but also increases the return-on-investment because there is no return, its not all spending.

Race against risk Read More »

New year: out with the old

Button marked "Reset the world"

My first blog of 2025, and following my annual procedure I have created a new archive for this year’s posts. Then I reviewed all posts that didn’t get published last year. Among all the posts you will have enjoyed last year there are half as many again which didn’t get published. Half a dozen have been carried over but most, about 4 times as many have been discarded.

A few of these are completely written posts awaiting a final edit but which I decided weren’t worth publishing.
A few more are posts I started to write but decided to they were too off-topic or too personal.
A few more never got beyond the first sketch.
And the remainder never got beyond the title and a note or two.

Broadly I’m following the same pattern I have been advocating with OKRs and Backlogs: decide your goals, drive work from goals and discard the backlog every few months. Let ideas go makes space for new ones, and if any are so great that I really should have them, then I’m sure I’ll think of them again.

It occurred to me the other day that this is the same logic I use with newspapers. I still buy and read a physical newspaper several times a week. There are several reasons I like the physical versions but one of them is the timeliness of it.

I buy the newspaper in the morning. The news has been curated for me: I don’t go hunting across websites to find news I might like. Then, at the end of the day the paper goes in the recycling. If I didn’t read a piece then too late. I had 14 hours to read it, tomorrow is new day with new news.

In all these cases it is only by letting go of the past – of ideas and partially done work which I’ve invested in – that I have space for the new. I wager that new ideas will be worth more than those of the past which didn’t make the grade. I accept that I might loose a few valuable ideas but I also know that if they are really good I’ll probably think of them again.

Now a question: are our technologies keeping the past alive too long?

Since my blogging is all electronic it would cost nothing to keep those old blog ideas hanging around. Similarly our backlogs only became bottomless pits when we stopped writing them on index cards.

Digital newspaper allow you to read today’s news, some of tomorrow’s and any day in the past – this means navigating them can be hard. I’m regularly struck by the way many blogs and online journals hide the publication date.

Facebook makes it hard to loose friends and LinkedIn makes it hard to forget past work colleagues. We are captive to past posts, pictures and comments.

Forgetting has a role to play in letting in the new and allowing us to advance.

Just because we can keep the past current should we? I don’t think so. Even if it costs nothing in terms of storage and archives the past makes it harder to see what is before us because we are trying to see so much more.

(Image from Jose Antonio Gallego Vázquez on Unsplash)

New year: out with the old Read More »

Core message – succeeding with OKRs

“What is your core message?”

Perhaps surprisingly “this”what is your core message?” is one of the tougher question I’ve been asked lately. My problem is, while know the value of focus and regularly preach it focus I can be weak myself. So, this question has me thinking of several possible answers.

Those answers are connected but I’d have to spend time enumerating my philosophy. And actually, the best explanation of that philosophy is the books I’ve written over the years starting with Changing Software Development.

Fortunately, my inquisitor was asking specifically about Succeeding with OKRs in Agile so the full question was really “What is your core message of your OKR book?” which makes it a bit easier.

(By the way, the Italian translation of Succeeding with OKRs in Agile has just been released.)

Succeeding started life as a brain dump to myself of what worked, and what didn’t work, when using OKRs in agile teams. It wasn’t intended to have a core message, it was more “here is bunch of things to help with OKRs.”

Still, there is reoccurring, core, message: OKRs are mechanism for agreeing shared goals, communicating goals and driving action, to work everyone on the team should be included and everyone is responsible.

Let me expand on that…

When something (opportunity, challenge, problem, whatever) is big enough to need more than one person then it is a very good idea indeed if those people can agree on a shared goal (objective, target, aim, desired outcome). Unfortunately, giving people goals is a really poor way of goal setting for a variety of reasons.

The days when one person could give orders down the hierarchy are gone. That may have worked in 1914 but society is less accepting of that approach today. Not only that but modern companies and systems are too complex for a big brain approach to work.

Perhaps the biggest reason is that a big brain approach fails is because simply giving people work to do fails to harness their motivation, talents and abilities of the people doing the work.

Commitment – and therefore motivation – will be highest when those doing the work have had a voice in forming the goal. Co-creating goals shares and enrols people. This brings all to the table and harnesses their brainpower. In doing so there is a place for diversity and dissenting opinion. Different views and different approaches creates more opportunities.

Driving working from goals is superior to working from plans because goals are more stable, plans are frequently derailed. You can, and should, keep coming back to goals. Plans are just a means an end, plans are created as needed to advance on the goal.

In this context OKRs are a mechanism for agreeing share goals, communicating goals and driving action to deliver goals.

Now that is the core message, but alongside it is some caution. Unlike some OKR proponents I recognise problems. Not fatal problems, but things to be careful with.

Goals can mislead. By their very nature they simplify and abstract so you need compensating mechanisms. So revisit goals regularly – the OKR framework defaults to every 3 months. This provides opportunities to refine goals and renew enrolment.

Simpler short term goals are great for motivation and focusing work but they miss the broader view. Broad long-term goals can be too abstract for people to associate with or to drive work. So these need to be used in tandem.

Smaller and short term goals need to be nested inside broader, longer term, goals and ultimately our personal and organisational purpose. However, goals is not a sure fire win.

Problems arise when goals conflict: The sooner this is identified the more options there will be for reconciling those conflicts.

While single minded goals are great at focusing teams for action they risk destabilising the wider system, e.g. near term cost reduction can undermine resilience, succession planning and innovation. So you need to regularly take a step back and think more broadly.

Back to core message: In the days of the big brain mastermind they (CxO, consultant, central planner) was expected to do the broad thinking while lesser minds would consider action. Rather than separate by role I suggest they are separated in time: everybody shares responsibility, while they spend most of their time delivering they surface every few months and think broadly. Its more egalitarian.

This doesn’t take any longer because the big brain doesn’t need to spend time explaining their great ideas to everyone else and then policing compliance. And since everyone is involved with setting understanding and motivation are higher so the chances of meeting the goal are higher.

Core message – succeeding with OKRs Read More »

Patterns for Highly Autonomous Teams & Team Energy Theory

A treat for those who like a longer read, two new papers. Both of these come from this summer’s EuroPLoP 2024 conference. As with all my other patterns papers these are on my website.

Patterns for Highly Autonous Teams

The first, Patterns for Highly Autonomous Team is a joint work with Tsvetelina Plummer and gives three patterns for, well, highly autonomous teams:

  • Autonomy over Money
  • Everyone a Manager
  • Simple Financial Reports

In addition to the patterns the paper contains a long pre-amble on the nature, naming and history of autonomous team – which also explains why the terms “self-organizing team” and “self-managing team” may not be the best.

Perhaps controversially the pre-amble also described why management and leadership are in not different things but, in fact, inseparable.

The patterns themselves seek to recast existing ideas in the pattern form supplemented by our own observations and additional examples. The origins of the paper was a desire to writer and research Autonomy over Money. When we went looking for new case studies we got two surprises. First, there were fewer examples to find than we expected – although they certainly do exist. Second, most of the examples we found were outside of technology and software development in particular.

So, read the paper and let me know what you think.

Team Energy Thoery

Second up is a write up of a focus group discussion of little theory which I’ve had for some time. To explain, let me quote from the paper:

“Team Energy Theory proposes using the metaphor of energy to describe team work. Specifically, TET explores how the rules of energy can be used to describe team work.

This paper describes a workshop which explored the theory. The workshop decided the theory was useful and provides some insight. It was agreed the model could be usefully applied with other groups to discuss what made for an effective team and how less effective teams came to be.

Several parallels were explored, e.g. natural tendency to minimise energy expenditure, and several more were identified for further exploration, e.g. the different forms of energy and conversation of energy between these forms.”

Again get in touch if you have any questions or would like to continue the discussion.

Both these papers best thought of as late drafts. They will officially be published as part of the ACM Digital Library proceeding of EuroPLoP 2024 in the coming weeks. However, I prefer these versions because the font and layout make them much more readable. (It is beyond me how anyone can read the ACM format.)

Patterns for Highly Autonomous Teams & Team Energy Theory Read More »

Writing OKRs masterclass online in January

My online Writing OKRs Masterclass is back in January. Held in partnership with Avanscoperta this hands-on class has you writing OKRs, understanding what makes good OKRs and what to avoid!

If you are struggling to write OKRs, or if your job requires you to write OKRs regular then this is the class for you: Product owners and Product Managers, Scrum Masters and Agile Coaches, Managers of all descriptions and aspiring leaders who expect to be using OKRs in the future.

Starting with the nature of objectives and key results we will look at what makes a good objective, what they are not, and why objectives are subjective, and objectives in the organizational context and goals-within-goals.

We will then look at how to measure key results, how to put numbers against intangible results and quantify changes. We will discuss the importance of refining OKRs with feedback and present rules of thumb for writing OKRs. Finally we will discuss the difference between leading and lagging indicators, the advantages and disadvantages of each.

Sign-up now, use the code Allan_Blog_10 for a 10% discount – places limited.

Writing OKRs masterclass online in January Read More »

How do I combine OKRs with KPIs?

“How do I combine OKRs with KPIs?”

I’m going to let you in on a secret: this is both the question I get most often about OKRs and a question I dread.

I groan internally when someone asks. Unfortunately, its one of the most common questions I get. So while it has been on my list of “Things to blog about” for a year I’ve been putting it off.

Dragon Jojic ask me this last year and I spent weeks digging up articles and reading. I kind of got an answer, but its not a great answer, it was about 10 pages long.

So why do I hate this question?

The thing is, KPIs – key performance indicators for those who have been lucky enough to avoid them – are something of a moveable feast. That is to say, they mean different things to different people in different places. To make this worse, it turns out that KPIs lack a foundational text.

When I began my research last year I assumed that I could find the original book or journal article were KPI were described. But, it doesn’t exist.

The expression seems to have just arisen in management talk and stuck. So there is no commonly agreed definition. So let me give you three ways the I see it being used, and thus, three answer to the original question.

First “Informal KPIs”. Teams and companies talk about KPIs and many numbers are called Key Performance Indicators but there is no agreement on what the important, key, KPIs are. Nor is there any definition what a so-called KPI actually measures or how it is measured.

Worse the increasing use of dashboards is making means KPIs are proliferating. Increasingly the term is just applied to any old metric that somebody wants to aggrandise.

If you are using informal KPIs like this then go right ahead and use OKRs. Hopefully OKRs will, in time, help bring order to your KPIs.

The second type of KPI are Formal and Targeted. There are a recognised limited number of well defined KPIs. Not only does the company set targets for KPI measurement but they may well draw up action plans to achieve those targets. I found David Parmenter’s “Key Performance Indicators” book a pretty wise here.

Used like this KPIs aren’t actually massively different from OKRs. If this style of KPI is working well for you then why add OKRs? You need to understand why you would use both because they overlap. Adding OKRs may simply increase costs and bureaucracy, at worst OKRs might set up conflicting goals.

However, while many companies are undoubtedly using many informal KPIs there are very few who are using this style of formal KPIs.

Finally, the third type of KPIs are my preferred sort. This style of KPIs is closer to Balanced Scorecard approach style. Here KPIs are well defined but they are not targeted directly. Rather, KPIs are used to monitor the organisation and check it is moving in the right direction and not getting out of balance.

This model is akin to hospital monitoring instruments. The instruments tell you patient heart rate and blood pressure but have no control over those measurements.

OKRs are the mechanism to change those measurements. OKRs on change and action, they also help individuals and teams plan and align. You don’t say “Lets target lower blood pressure” you say “Lets target a healthier diet” or “Reduced stress.” That in turn reduced the KPI.

So there you have it, in order to answer the question “How do OKRs fit with our KPIs?” I need to ask you first “How are you using KPIs?”

Want to discuss your situation more specifically? Get in touch, e-mail me or book a call.

How do I combine OKRs with KPIs? Read More »

The first agile transformation failure

Shall I tell you a story of a failed corporate transformation project?

A story of executives who enthusiastically embarked on a journey to greater employee involvement utilising new technology – embracing self-organisation in teams, or to use an older term sociotechnical systems.

A story of well intentioned, experienced, consultants who bit of more than they could chew. Consultants who would have followed organic, piecemeal growth, elsewhere but driven by executive desire to get the project done fast misled themselves. Consultants who adopted a cookie-cutter approach, expanded their team with less experienced consultants, while neglecting the very client employees they sought to enlighten.

Perhaps you are already bored, you’ve heard this story before. But what if I tell you it was PacBell in 1986? – 15 years before the agile manifesto.

This story, together with many others is in a book called Age of Heretics. By the end of the book I felt I had seen a glimpse of the future, and it wasn’t a happy future.

While I knew bits of the story – or stories – the booked filled in some pretty big gaps. It turns the “agile revolution” is a remake on a bigger scale, there is no happy ending but maybe there is reason to hope.

For most of the last 20 years me an others have been talking about a collection of ideas known as agile. It is well known that most of these ideas go back far further…

Eric Trist described “sociotechnical systems” which were the fore runner of self-organizing teams.

Edwards W. Deming and Philip Crosby began a quality movement which was the pre-cursor of technical excellence and things like pair programming, refactoring, automated testing, etc.

Toyota’s Lean system teaches the importance not just of quality but managing workflow, involving the workers, stockless production and just-in-time working.

But it turns out there are many more stories which are less well known. I knew a little of the Topeka Work System but was oblivious to similar experiments at Procter and Gamble.

Nor did I appreciate just how many of these ideas were interconnected already. That in the post war period the academics and practitioners who invented and experimented intermingled, shared ideas and built on one another.

It turns out that what were a few experiments in the 1950s grew in the 1960s. By the 1970s General Foods and P&G were building new factories on these principles and Shell was abandoning its Unified Planning Machinery.

While growth continued into the 1980s there were failures like PacBell. Despite great success General Foods was never able to capitalise on the Topeka success. In fact, in an eery future echo others in the company found it difficult to work with the self-organizing teams at the factory.

And thats why Age of Heretics also reads like back-to-the-future for agile practitioners. While many of the experiments were a great success many of them eventually succumbed to normality.

In some cases the guardian angel boss moved on and their successors failure to appreciate or protect the experiment.

Ideas failed to travel and experimental plants were seen as odd or difficult. When ideas did travel the transplanted seeds failed to grow. It turns out copying processes is only part of the change needed.

Just about all the case studies given in this book will resonate with those in the agile community. The PacBell case in particular could have been written about many large companies, particularly banks, on an agile transformation in the 2010s.

(There are some other pre-cursors of our current world in here too. Like the 1972 Limits to Growth report which pre-shadowed many of today’s environmental discussions.)

Its very easy to be depressed about agile transformation after reading these stories but I shouldn’t be. After all, now I understand things better maybe I can avoid them?

Perhaps more positively, despite all these failures these ideas keep coming back. Haighmoor coal mine may have been the first self-organizing team in 1950 but by 1960 there were more. Not all survived but more followed them.

Topeka may have been the largest example when it opened in the early 1970s. Despite facing challenges – the loss of key staff, neglect by the parent company, changes of ownership, expansion and down-sizing – it was still self-organizing until 2002.

Repackaged as agile these ideas have reached more teams than ever before. While there have been lots of failures and sacrifices in this time the ideas live on. Slowly, the superior performance of this way of working, the applicability to work in the digital age and the expectations of younger generations probably guarantees that this is the future.

However, that doesn’t guarantee success for any one company or team. There will continue to be failures. So, as we pause for breath I suggest you read the fascinating Age of Heretics – it may not contain the word agile but it is a both an agile history and prophecy.

The first agile transformation failure Read More »

Little book of workflow management

I have a confession to make. I recently published a series of articles not on this blog, and not even in my newsletter. I wanted to try something a bit different. I wanted to try writing short descriptions of the working techniques agile teams use but without using the word agile, referring to software development, or even IT. It is increasingly clear that the agile way of working benefits many beyond technology so I wanted to see if I could help.

All the articles are free on LinkedIn and now I’ve combined them together is a short book – or is it booklet? – which I’m calling Little Book of Workflow Management. I’m writing this on LeanPub and you can get the book now – the code Blog2024 should get you the book half price.

There are a few more short pieces I plan on adding, most of them will find their way to LinkedIn too but some will not. After that, I’m not sure what happens, I’ve got a few ideas of where this project might go.

As always I’d love to hear your feedback on this embryonic book so please let me know what you think. And if you’d like to talk about how to apply these lessons in your team book some time with me.

Little book of workflow management Read More »

How can you scale without authority?

A few weeks ago I was at the Royal Albert Hall for one of the BBC proms concerts. I’m there to listen to an orchestra perform a concert but what always amazes me is how the players work together. How do they do that? How do they all know exactly, to the split second, to push their bows up? And exactly when to pull them down?

Sure there is a score, and a conductor giving them clues but there is more to it than that. How can they all play the same tune at exactly the same time? Soloist I understand, easy, one person, but in an orchestra? Synchronised every second? Now that is what I call a scaling problem.

Do you scale?

Let me ask: Do you scale? and how do you do it?

Do you lie awake at night trying to work out how your team can work together with three other teams all building parts of one solution? – like the violins working with the wind section, and occasionally a big drum coming in.

Scaling seems to be a perennial conversation, and inevitably it actually means scaling up: how should we scale our company? how should we scale our team? should we use SAFe? or LeSS or some other scaling framework?

Organising in the large frequently boils down to giving some people authority to tell others what to do. Sometimes that is by issuing direct instructions today “Today you do this, you do the other and you do that thing.”

Less often it is by setting rules, rules are standing orders: “all expenses must be approves by a senior member of staff”. And sometimes by mandating what is to be the output “Don’t stop until all products are 10cm in length and weigh 100g.”

In the modern work environment where individuals and teams expect autonomy – perhaps they are Gen-Z or perhaps because they take an agile approach – this creates a lot of tension. While a framework might reconcile some tensions it still boils down to giving someone authority at some time. It becomes an exercise in passing the authority baton: the Product Owner mandates what is to be done and passes the baton to the Scrum Master. When the work is done the baton is passed to the Release Engine, next is the Business Owner who decides success or failure.

Leadership doesn’t so much emerge as gets programmed. There are fewer opportunities for shared leadership and what there is happens as a time share. Many teams are still following somebody elses plan rather than co-creating.

Less common scaling methods

Yet there are other co-ordination mechanisms out there which are all too frequently overlooked. In fact, in his latest book my favourite management thinker Henry Mintzberg sets out six:

1. Mutual Adjustment: Communicating directly

2. Direct Supervision: Issuing Instructions

3. Standardizing the work: Establishing rules

4. Standardizing the outputs: Controlling performance

5. Standardizing the Skills and Knowledge: Prior Training

6. Standardizing the Norms: Sharing Beliefs

Numbers 2, 3 and 4 utilise authority, someone issues the instructions, someone sets the rules and someone controls performance. These are the ones which formal scaling approaches rely on. The brand name frameworks say little about 1, 5 and 6 – missed opportunities.

Number 1 and 6 tend to be what happens informally in small companies and families. Those scaling teams and projects may treat them with suspicion.

Number 5 is key to orchestras, other arts and the military. Actors and musicians often spend more time rehearsing than performing. Armies will train soldiers again and again. Military training is expensive too: they will be sent to foreign climes for exercises and train with allied nations to make sure their troops can work together. (Such exercises can also send a message to potential opponents too.)

How does the BBC orchestra do it? Don’t ask me! I see the conductor doing 2, the music score controls the output 4, and I know they have trained as individuals for years then rehearsed together, 5. I’d hazard a guess that 1, 3 and 6 also play a part.

Technology companies try to recruit skilled “plug compatible” staff. New employees arrive ready trained and are expected to substitute for one another. One Java programmer leaves so they hire a ready trained one to replace them. They might get a half-day induction but they then they are thrown into the team without any training.

The emphasis on existing skills almost precludes shared training or finding common beliefs. Companies rely on #2, #3 and #4 to instruct them what to do. Some companies embrace #1 while other insist on several thousand kilometres separation. (In the online world casual, ad hoc, conversations are rare, you need to schedule video calls 2 weeks in advance.)

A better way to scale

So, instead of scaling with authority – instructions, rules and controls – what if scaling was done through training and rehearsal? Instead of standardising by mandate what if scaling was done through collaboration and exploration? And what if shared leadership was acknowledges and embraced?

Instead of scaling with the written word, what if people are brought together to find common beliefs, common values and to create a shared understanding of what work goals were? And then practice working together?

I think this is one of the challenges for the next decade. Most of our companies, their structure, organization and management thinking is predicated on the assumption of authority and that people can be told what to do. It is an assumption which increasingly doesn’t hold and even if it does there are commercial, competitive, advantages, for those who can find different, superior, ways of working. That is the new challenge.

Like to conitinue the conversation? E-mail me or book a call.

Opening image of a proms concert from courtest EddieColdrick CCL licesne via Wikicommons

How can you scale without authority? Read More »