Blog

Posted on

Smoothing things out

One of earliest childhood memories of travel is riding in the back of the car driving along a motorway in mountains in the north of Italy. To traverse a terrain of deep valleys and high ridges the engineers had taken a midline. The road leaps across the ravines on high viaducts, plunging straight into a tunnel only to fly out again across the next bridge. With the sea glistening deep below it was an exhilarating journey. (Did this sow the seed of going into civil engineering?)

Faced with a series of peaks and troughs the engineers flattened the journey. They saved journey time and energy on every single car journey on that route, every day for over half a century.

Smoothing things out is something that engineers seem to be generally good at. For example we’ve been straightening rivers to make them more navigable for centuries. 

But building faster, straighter roads also increases traffic. Straightening rivers increases flood risk. 

When we start to consider the unintended consequences smoothing things out we might find that working with the ups and downs and twists and turns is better. The friction slows down the flow. People or water, in these examples, spend longer in each place. There is greater interaction and opportunity exchange and creation of wealth in its many forms.

Next time I cross the Italian Alps hopefully I can do it on a bicycle, following the contours of the river valleys.

This post originally appeared on eiffelover.com in 2024.

Posted on

Go (notes on complexity)

My favourite board game is Go. A 19 by 19 board. White stones versus black. You win by surrounding your opponent’s stones before they surround yours. The game has just three rules, but from this simple concept a game of incredible complexity emerges. 

My early years of playing Go were frustrating: it didn’t matter what I did, I couldn’t find a way to win. And now that I am more experienced, I find it hard to teach others. I take solace therefore that while the first computer to beat a reigning chess world champion (Deep Blue versus Gary Kasparov) did it in 1997 it took another 20 years for a computer, Deep Mind to beat reining world Go champion Ke Jie. 

The reason Go is so much harder for a computer to play than Chess is the number of branching possibilities that emerge from each move. It is just not possible to play solely on the basis of the player assessing the opposite player’s best move. And therefore a much more complex dynamic emerges in the game that involves the players ability to spot patterns as much as the patterns themselves. 

I find this fascinating. In this complex situation, the players are part of the solution. Or put it another way, the solution is function of both the physical reality (the stones on the board), the players’ perception of the stones, and the players’ perception of each other’s perception of the stones. In maths terms, the solution y = f(physical world, internal world).

It highlights for me that with complex situations in which engineers (and other humans) are agents, how we show up and how everyone else is showing up has a big impact on the outcome. We are a long way from optimum answers that can be deduced from calculation.

This post originally appeared on eiffelover.com in September 2024

Posted on

Machine work

Inputs

Outputs

KPIs

Tools

Models

Performance

Quantitative analysis

Scaling up

Accelerator

Dashboard

Timesheet

Human resources 

Bottom line 

When we think of our work as the work of a machine, then is it any surprise that the incredible machines that we have built will one day starting doing it for us.

But we do ourselves a disservice if we only think of ourselves in machine terms. If we leave out empathy, care, collective knowledge, grounded understanding of place, knowing that is not describable in words, trust, passion, play… then we are not bringing our whole selves to the work we need to do. 

There are so many more ways of knowing than the knowledge we can enter into a computer. Let the computers do the computational part – they will be very good at it – and let us step into our wider intelligence as engineers (and other humans).

This blog post was inspired by Reinventing Organizations, by Frederic Laloux. 

This post originally appeared on eiffelover.com in September 2024.

Posted on

Metaphorical measure expressions

In a recent workshop, I heard someone say, I wouldn’t touch that with a barge pole. 

While I kept my game face on, my pedantic, literal inner voice started wondering, how long is a barge pole? 

I discover that a barge pole is between 2.4 and 5.5 metres long. 

(Incidentally, I also discover that they are traditionally made of ash, which is hardwearing and floats well)

And then I realise, 2.4m to 5.5m is quite a big range, and the expression has different meanings depending on which end of that scale we are on. 

2.4 metres after all is not that far away. It is closer together than the opposing front benches of the UK’s House of Commons, which are two sword-lengths apart, another non-standard unit, but which we can actually measure on the floor at 3.96m. 

So the expression probably implies the lengthier end of the barge pole scale. Which leads to my next thought — never mind wouldn’t, what about couldn’t? I’m not sure I could easily pick up a 5.5 metre long pole at one end and poke someone with it, no matter how much disdain I had for them. 

I am of course ignoring the point of ‘metaphorical measure expressions’ as I discover they are called, in that they ‘lack the quantising function that literal uses of measure expressions have’. 

Silly me. It’s just an expression. A yardstick. A rough ball park. And now I’m wondering how big a ball park is…

References

https://en.wikipedia.org/wiki/Setting_pole
Two Swords and One Inch Apart?
https://repositori-api.upf.edu/api/core/bitstreams/713f367a-e9a9-43b9-912e-5c35f387813e/content
Posted on

A full basket of regenerative design learning opportunities

There’s a lot of ideas in this week’s blog posts, which if you are reading this in the weekly digest you can scroll down, but before you do, lets quickly look at what’s in the autumn’s basket of training to sign up to.

At this equinoxy time of year things seem to gather pace. Day length changes fastest, and ideas that have been ripening all summer suddenly fall into place. Like an autumn harvest, they come not as a trickle but in a glut.  

And so here, dear blog readers, are opportunities to harvest regenerative ideas for the autumn, winter and year ahead.

Seeing the System

Our online introduction to regenerative design is filling nicely with practitioners from across the built environment. Over four weekly sessions we’ll introduce key models such as the Systems Bookcase and the Living Systems Blueprint, building confidence and clarity in applying regenerative thinking.

Begins 12th November | Register by Friday 31st October

(It will come round faster than you think!)

>>Register here<<

Regenerative Design Lab — cohort 6

Our first open cohort in 18 months, welcoming applications from leaders and future leaders across design, construction, education, policy, and strategy.

Applications open 3rd November. Interviews in January 2026. Course runs March 2026 to November 2027. 

>>Details and register your interest<<

Regenerative Design Lab – cohort 7

A Lab for alumni to deepen their regenerative practice, taking the work they began in earlier cohorts and supporting each other to create bolder change.

Applications open 3rd November. Interviews in January 2026. Course runs March 2026 to November 2027. 

>>Register your interest here<<

Posted on

Visions that abstract us/ visions that ground us

Many vision statements float in the abstract. To be a global leader… To minimise store-to-door time… They sound clear, but they ignore the ecology and community that make the work possible. At best, such visions are inert to these realities. At worst, they succeed only at the cost of them.

A regenerative vision is rooted in place — in ecosystem and community. It sees the thriving of that place as central to success. So that our activity enhances this and the other places it touches. Perhaps, even, that this place would miss us if we were gone.

So rather than a mission statement that puts you anywhere and serves nowhere, see what happens when you serve somewhere.

Related tools > Continuous Place-Based Design

Posted on

Get on the ground and start moving around

In the early days of the internet, you had to know a website’s URL in order to visit it. 

Companies like Yahoo! set themselves up as way-finders. Visit their site and you could find links to popular places on the web. All organised under headings like a giant directory. 

And then a little company called Google came along and started building its own map of the web, based on exploration. Its bots would crawl the web, visit each website one at a time, figure out what it was about, and then follow the links from there. Which connections are strong? Which are weak?  Which way does the traffic flow?

This is a very different approach to knowledge gathering. Not based on a top-down hierarchy but on-the-ground mapping based on simple questions. 

What is here, what is happening, which ways are things going? 

With Google’s tool, all you had to do was search — they had the map, and it was a much better representation than Yahoo’s top-down approach.

Of course, who owns the map, and what they use it to do, are important questions too. 

But the underlying premise remains, if we want to really understand a situation, then get on the ground and start moving around. 

Related tools
>Continuous Place-Based Design
>Systems Survey

Posted on

Teaching theory versus the inconveniences of reality

Theory is abstraction. It is an understanding that is distilled of the inconveniences of reality to allow us to make predictions about that reality. 

Most engineering degrees start with the theory. Vast columns of theories stacked one on top of each other in piles called things like

Mechanics 1

Mechanics 2

Mechanics 3

And then at some point in that journey we ask students to apply that theory in a real world context. 

What if we flipped that model?

Start with observation — the opposite of abstraction. Discover the inconveniences of reality to allow us to find out how the world actually works. 

Observation 1

Observation 2

Observation 3

Of course that leads to an equally lopsided model, uninformed by the telesecoped sum of thinking available to theoretician.

Of course, the answer lies some where in the middle, sprinkled with a fair dose of application. 

Observe

Theorise

Apply

Observe 

Theorise

Apply

Etc 

It is surprising how radical this suggestion is.

Posted on

Overcoming the status quo

A system rests at equilibrium because that is its most likely position. Any spare energy is used up by processes — feedback loops — that keep returning the part of the system to this state.

This applies in organisations as much as in chemical systems.

We may make what feels like a significant change. A new initiative. A new process. A new product. But if the original feedback loops aren’t altered, then over time, friction will rub away what is distinct and we return to the status quo.

If we want to create a new equilibrium — a new status quo — then we need to:

  1. rewire the feeeback loops to reinforce this change rather than continuously undermine it
  2. Imbue the new initiative with enough energy to resist the friction it causes while the system around it rearranges itself.

If the change is good enough, it will generate enough energy of its own to keep going. That’s how most solutions succeed, be they organisational, or chemical.

Related tool > Ambition Loops

Posted on

Ripe learning opportunities from moments of transition 

Transitions are ripe moments for reflection on action.

When we’re in the flow of delivery, we rarely have the chance to pause and ask what we’re really doing or why. But transitions — a change of job, a shift in funding, or simply the end of a project — give us the opportunity.

Creating change means pushing, pulling or nudging outcomes away from their default path toward an intentional one. But while we’re in the thick of delivery, it’s easy for intentions to get blurred, or dropped altogether.

So when we pop out the other side of a period of work, it’s worth asking: what was I really trying to do, and what actually happened?

  • Here are some questions I use to harvest learning at the end of a project:
  • What did I set out to do? Even if you can’t fully recall, try to write it down.
  • What did I actually do? Not just the deliverables — think about the journey: the conversations, obstacles, and detours.
  • What were the consequences — intended and unintended? In complex systems, surprises are inevitable.
  • What advice would I give someone else setting out on the same journey? You can’t repeat the past, but someone else can build on it.

These lessons are easily lost. Once we move on, the window for reflection closes quickly. So take the time to harvest the fruits of transition while they’re still ripe.