Category: Leadership

A while ago, a media customer asked me to assess their search team. They’d been told to adopt Continuous Delivery practices, while still shipping features. The team struggled to make changes, deadlines were missed, and morale was low. I sympathised, and could see most of the pain was self-inflicted. Other teams had successfully adopted Continuous Delivery, but the search team had started from scratch. Their manager asked me “are we in chaos”, and were surprised when I said “it’s repeated complexity not chaos, and the repetition is the frustration”.

The Cynefin framework is helpful here. In chaos, cause and effect are unclear, and the environment is unstable. An analysis won’t work. You have to act to create order, sense what’s changing, and then respond accordingly. If you’re in a jungle and it’s on fire, you get out.

In complexity, cause and effect is only understood in hindsight, and the environment is dynamic. A step by step plan won’t work. You have to probe the terrain, sense what works, and respond by adapting. If you’re in a jungle, you gradually hack through the undergrowth. If enough people take the same route, a trail starts to form. That’s how learning happens.

Over time, I’ve realised this is my leadership style. To help teams navigate complexity by finding a way through, capturing what we’ve learned, and sharing it so others can go further and faster. That’s principles to guide us, practices to ground us, patterns to repeat what works, and pitfalls to avoid what doesn’t. When I was a full-time engineer, I built CI/CD pipelines for teams. Then I created paved roads in platform engineering. Now I write advisory guidelines in inner-sourced handbooks, that anyone inside Equal Experts can use and improve.  

Back to the media customer. Their search team was frustrated, and frustrating, because they were ignoring the Continuous Delivery guidelines from other teams. They’d started from scratch, hit the same problems others had solved, and failed to solve them. It didn’t happen out of ignorance or arrogance. It happened because starting from scratch feels faster. It comes from:

• an illusion of progress
• a bias towards our own ideas 
• a fear that learning takes too long
• a desire to prove something (to yourself, or to others)

If the trail is good enough, starting from scratch means more mistakes, duplicated effort, and slower results. You won’t create your own trail through the jungle any faster. You’ll probably end up in a swamp, despite signposts pointing away from it. 

And you can always make that trail easier to find, understand, and trust. Capture learnings in easy to consume formats. Share them in existing open spaces that are frequently visited, and searchable. Listen to feedback from teams, collaborate with them on updates, and give them credit for their work.

Don’t start from scratch. Improve what exists, share it back, and leave it better.

(available on LinkedIn)

When I advise senior technology leaders, I like to understand how they work, so I can adapt my style to help them succeed. So when they’re thinking about making changes, I’ll ask:

How do you want to manage feedback for this initiative, from concept to execution?

That tells me whether they see feedback as:

• Data points to set a direction, or validate a decision
• Conversations to be designed, or cascaded sequentially
• Opportunities to learn, or boxes to tick

There’s lots of feedback models. I call one of them the feedback waterfall, and I advise against it. It’s when a well-intentioned person asks for feedback to validate a decision, and seeks learning opportunities by cascading conversations sequentially through their organisation. 

For example, a fictional CTO is frustrated with her organisation’s Scala tech stack, due to skills scarcity and salary costs. She decides on a transition to Kotlin. She runs a workshop with her engineering managers, to gather feedback and draft an execution plan. She then shares the plan, one group at a time, with her staff engineers, architects, and tech leads, to collect more feedback. Finally, she announces the plan to the organisation, and expects teams to begin the transition. This feedback model looks like a waterfall, because it’s a waterfall.

I understand the appeal of a feedback waterfall. By shaping the Kotlin decision with her engineering managers, the CTO is shielding a fragile, early stage idea from the tyranny of the herd – the noise of unstructured discussions, dominant voices, and scattered opinions. And in theory, the execution plan is strengthened by the downward flow of feedback, with each group gradually brought into alignment.

But a feedback waterfall results in:

• Scepticism. Staff engineers, architects, and tech leads aren’t sure if the CTO genuinely wants their ideas, because the Kotlin transition is pencilled in and it anchors conversations. Commitment is weakened, because people dislike blurring feedback with communication.
• Resentment. Engineering managers don’t contribute after phase 1, so they feel sidelined. Staff engineers, architects, and tech leads don’t contribute until phases 2, 3, and 4, so they feel disempowered. Testers aren’t invited at all, so they feel excluded. Energy shifts away from collaboration, because people resent the process.
• Delays. It takes weeks for the CTO to complete phases 2, 3, and 4. An engineering manager is on holiday. Staff engineers are at an offsite. An architect is sick. Tech leads are busy with business deadlines. Critical insights arrive slowly, because people aren’t immediately available. 
• Friction. The CTO has to revisit her decision in phases 2, 3, and 4. Staff engineers say they mentor junior engineers in advanced Scala. Architects warn the messaging system depends on Scala types. Tech leads reveal there are internal libraries lacking Kotlin bindings. Valuable insights risk rejection, because people lack time and energy to revisit past conversations

Senior leaders don’t usually feel the pain, because they’re the first person in phase 1, and the only person in every phase. And they can make mistakes, just like me or anyone else. They might accidentally exclude someone, or mix teams in different phases. They might believe alignment requires agreement from everyone, and seek consensus in every phase. They might start treating feedback as a tick-box exercise if a phase is too slow. Those situations only add to the scepticism, resentment, delays, and friction.

I’ve seen and contributed to too many feedback waterfalls, and they’ve always led to under-informed decisions and suboptimal execution. And it’s hard to persuade senior leaders to change how they manage feedback, because they’re people, and there’s always reasons behind reasons. Feedback waterfalls aren’t really about senior leaders protecting their ideas from the tyranny of the herd – they’re protecting themselves. They fear messy workshops, design by committee, or a loss of control. They lack the appetite or skills to navigate the ambiguity, creative tension, and unresolved views of open conversations. 

There are better ways of managing feedback for an initiative, from concept to execution. The Scala CTO might have asked for feedback on her frustrations before making a decision, been clearer about what was open for discussion, and run parallel feedback phases afterwards. But before that, we need to talk more openly about why feedback waterfalls are so appealing, and so damaging.

(available on LinkedIn)

I describe myself an engineering advisor. An engineering leader, a former engineer, who now likes to advise other engineering leaders. And as an advisor, I often reflect on what makes someone effective, and ineffective, in such a role. What makes a good advisor?

One way to define good advice is by understanding what bad advice looks like, and avoiding those pitfalls. And when it comes to advisors, there’s a lot of bad advice out there. Advice can be uninformed, ill-timed, non-actionable, or disrespectful, but my personal favourite is unwelcome advice.

Unwelcome advice may seem harmless, but it’s deeply damaging. It can feel patronising, intrusive, and undermine your confidence to handle your own challenges. And it’s often well-intentioned, which makes it difficult to say “I didn’t ask for help” or “I’m good thanks” without causing offence.

I’d say good advice is respectful of autonomy:

• If someone doesn’t ask me for help and I have something to offer, I try to create a space in which they know it’s OK to ask
• If someone does ask me for help, I try to offer insights that encourages self-reflection, empowers better decisions, and allows for a different course to my own

I say “try” because humility is so important. Being a good advisor isn’t easy, I’ve made mistakes, and I’m always learning from peers in the technology industry like Rachel Uhrig David Espley and Sam McGregor . And of course, my family, who hear “I didn’t ask for help” or “I’m good thanks” with patience and good humour, at least once a day.

(available on LinkedIn)

I’ve been reflecting on servant leadership a lot recently. It started in August, when I saw Lauren Woods‘s inspiring talk at ETLS Las Vegas about her leadership at Southwest Airlines.

(Gene Kim and I swap notes on IT Revolution and Agile On The Beach speaker management, and we agree an event has to open with a great keynote. Lauren did just that)

Southwest is big on servant leadership. Its founder Herb Kelleher once said “I’d rather have a company bound by love than a company bound by fear”. And as president, Colleen Barratt shaped customer strategy and employee culture in terms of corporate values and service. It’s a big part of their enduring success.

That commitment to servant leadership resonates with me at Equal Experts, where our network and business are grounded in treating everyone equally regardless of their role. My role as Global SVP Technology at Scale is to enable our customers and engagement teams to succeed. I can’t succeed on my own.

It’s hard to explain servant leadership. I used to describe it just by saying I’m opposed to saviour leadership. That’s where a well-intentioned hero tries to solve team/organisation problems themselves. Over time, they’re over-involved and burn out, while the team/organization is over-reliant and growth opportunities are missed for others. It’s short-term gain and long-term pain.

On a recent flight to the USA, I re-read The Secrets of Consulting by Jerry Weinberg. It’s a great read, and I’d forgotten that Jerry outlined a servant leadership model of MOIJ – motivation, organization, information, and jiggling. I realised that’s a close approximation of how I approach servant leadership:

• Motivation. Encouraging people, acknowledging them, giving them feedback, and having empathy for their situation
• Organization. Creating or modifying structures and resources so it’s easier for people to do their work
• Information. Sharing facts, ideas, theories, so people have more knowledge and different perspectives to act upon
• Jiggling. Offering new ideas to people, to shake them out of a rut when they’re stuck

Although as the son of a trade unionist and a pharmacist, maybe servant leadership wasn’t really a choice for me 🙂