What we carry into a new job

A while ago, I came across a post on Instagram from a psychologist. Sadly, I didn’t make a note of who wrote it.

The post was about dating after the end of a relationship. One idea in particular stayed with me: when you begin a new relationship, you don’t arrive as a blank slate. You bring aspects of the previous relationship with you.

He said, “Your nervous system is still calibrated to your last relationship.”

Not necessarily because you want it to be, but because experience shapes expectations. Things that happened before can affect what you notice, what you worry about and what feels safe.

And recently I’ve been thinking: the same is true when we start a new job.

Continue reading What we carry into a new job

High-trust teams need less process

Process is useful. It creates structure, makes work visible and helps people coordinate.

But as teams mature and trust grows, some processes become unnecessary. What once provided helpful support can become friction.

Process often compensates for low trust

When trust is low, organisations tend to introduce more controls:

  • additional approvals
  • detailed status reports
  • frequent progress checks
  • rigid handovers
  • rules designed around exceptional failures

These may provide reassurance, but they also slow decisions and reduce autonomy. Over time, people may focus more on satisfying the process than achieving the outcome.

Continue reading High-trust teams need less process

What teams taught me by failing safely

Failure is not usually something organisations want to talk about.

We prefer words like delivery, progress, efficiency and success. Those are good things. But in Agile work, some of the most important learning comes from small failures that happen early enough to do something about them.

The key is not to avoid failure completely.

The key is to make failure safe enough, small enough and visible enough that the team can learn from it.

Continue reading What teams taught me by failing safely

Scrum Masters and Cynefin – when the team needs stability first

This is the fourth and final post in a short series exploring the Scrum Master role through the four main Cynefin domains:

  • clear
  • complicated
  • complex
  • chaotic

The first post looked at the clear domain, where simple rules and repeatable practice can help.

The second post looked at the complicated domain, where teams need expertise, analysis and informed judgement.

The third post looked at the complex domain, where teams need feedback, experiments and learning.

This post looks at the chaotic domain.

What is the chaotic domain?

In the chaotic domain, the situation is unstable.

Cause and effect are unclear.

There may be pressure, urgency, confusion or even panic.

The team does not have enough stability to analyse the problem properly. It may not even be clear what the problem is yet.

Continue reading Scrum Masters and Cynefin – when the team needs stability first

The Scrum Master’s hardest skill is knowing when not to act

Scrum Masters are often expected to help.

They notice tension.
They see confusion.
They spot inefficient conversations.
They recognise patterns before the team does.

So the temptation is obvious: step in, explain, fix, smooth, coach or redirect.

Sometimes that is exactly what is needed.

But sometimes the most helpful thing a Scrum Master can do is pause.

Continue reading The Scrum Master’s hardest skill is knowing when not to act