Steve Smith

When I’m asked by senior leaders about technology transformation, I recommend creating a learning organisation through an accountability culture. If an organisation doesn’t have accountability, it won’t learn from itself, and it won’t improve itself. The Accelerate book by Dr. Nicole Forsgren et al proved that the key predictor of better business outcomes is a learning organisation – fast, visible feedback loops based on people actively sharing information, and treating events as learning opportunities.

Learning depends on accountability. I’d say that accountability is answering questions, being accountable means theoretically having to answer questions, and being held to account means actually having to answer questions. An accountability culture is where questions are freely asked and answered, so people can learn and improve together.

I’ve worked in multiple high performing organisations, and each time there was an accountability culture. As a technical lead at LMAX under Dave Farley, anyone could question my design choices, and I could answer them. In addition, I could question Dave’s choices for the whole trading exchange, and he always took the time to explain his thinking. That’s what accountability looks like.

What unaccountability looks like

I often see an unaccountability culture in organisations. People don’t ask questions, don’t answer questions satisfactorily, and/or don’t follow up on answers. Here are some examples:

• Mandatory AI adoption. A CTO announced mandatory Cursor adoption for engineers. After three months of mixed AI experiences, tech leads asked about value for money. The CTO’s only answer was productivity had to increase.
• Product away day. A CPO ran an away day for their senior leaders. A few attendees skipped the pre-reading, and their catch up time cost everyone half a day. The CPO didn’t ask why those attendees had come unprepared.
• Website outage. A COO endured a multi-hour website outage. They asked their head of operations why the outage happened. The head of operations only gave cursory answers, which the COO had heard before.
• Under-performance. A CDO had a head of data engineering, head of data science, and head of analytics as their direct reports. The head of analytics was known to be under-performing, but the CDO didn’t ask them about it.

Unaccountability happens for lots of reasons. Sometimes people can’t speak up because of power dynamics and systemic inequalities. Sometimes they’re constrained by insufficient capacity, knowledge silos, vague responsibilities, and skill gaps. But the overwhelming reason I see is people prioritising niceness over kindness. We’re socially conditioned to avoid discomfort, and preserve relationships and status. We over-estimate the danger of speaking, and under-estimate the cost of saying nothing.

What unaccountability feels like

I think about the negative impact of unaccountability at three levels:

1. Personal. People are left frustrated, disillusioned, and upset, because when efforts to collaborate, learn, and improve go nowhere it shows that opinions and time don’t matter. In the CPO away day example, the prepared attendees were resentful of the unprepared attendees for the extra effort they’d put in, and it damaged relationships.
2. Cultural. Inaction is understood to be safer than curiosity, because when saying something doesn’t make a difference, silence becomes the norm. Seeing the CPO not ask questions signalled to attendees that unpreparedness had no consequences, and curiosity was unnecessary.
3. Organisational. Learning doesn’t happen, because when feedback loops are missing or broken, decisions aren’t examined and experiences become waste. When the CPO didn’t ask why some away day attendees were unprepared, they missed a chance to learn their product leaders regularly worked out of hours on unsustainable client demands

Unaccountability compounds over time, because people copy power. When they see unasked questions, unsatisfactory answers, and unactioned follow-ups from their senior leaders, they adapt downwards and standards decline. High performers lose their gumption, and low performers are emboldened. The same problems repeat, and the same flawed solutions are started from scratch. If an organisation doesn’t have accountability, it won’t learn from itself, and it won’t improve itself.

Start accountability where you are

Accountability builds personal, cultural, and organisational norms. And as usual, change starts with the mirror. I suggest:

• Ask obvious questions, even when they feel awkward
• Take answers seriously, and ask clarifying questions to show you are listening
• Follow up when you say you will, especially when it would be easier not to

I saw Dave Farley consistently model these behaviours at LMAX. Senior leaders create accountability cultures when they recognise that their actions have a disproportionate influence, and they have a responsibility to set the standard – because many people can’t or won’t speak up until leaders do.

Assuming that people need your help to prioritise kindness over niceness, by asking and answering questions openly, is a good place to start. It can feel uncomfortable. But in my experience, navigating a tricky conversation to learn together creates deeper trust and stronger relationships, as well as organisational learning. I’ll continue holding myself and others to account, and teaching other people how to do the same – accountability is at the intersection of my personal values, and it defines who I am.

Acknowledgements

Thanks to everyone who holds me to account, including Rupa Kotecha-Smith, Alun Coppack , Bethany Pascoe, and Liz Leakey . Thanks also to Accelerate by Dr. Nicole Forsgren et al, Crucial Accountability by Kerry Patterson et al, Unaccountability Machine by Dan Davies, and Zen and the Art of Motorcycle Maintenance by Robert Pirsig.

At Equal Experts, I have the benefit of working on my leadership skills with an occupational psychologist, Emily Morris . Recently, Emily gave me a powerful self-awareness tool: identifying my personal values.

I’m values-driven. I’m always delighted when people like Chris O’Dell , Dave Farley , Liz Leakey, and Thomas de Cad’oro Granier act in ways that just feel right to me. I’m puzzled when other people’s actions feel wrong, and frustrated when I don’t know why I’m puzzled. My values run so deep, and are so instinctive, that I’ve never really examined them.

Emily suggested I make the time to understand myself better. So, I trained ChatGPT on anonymised life moments – childhood and adulthood, personal and professional – where I instinctively agreed or disagreed with someone’s choices. I pushed until the reflections had emotional resonance, and surfaced the values that shape my beliefs and behaviours.

I’d recommend understanding your own personal values. It’s helped me to see where I will and won’t naturally align with people. Having a compass helps me to lead with more clarity and consistency, even when I stumble. Here are some examples and explanations.

Truth

I interviewed for a job that implied leaving person X for person Y. I tested Y by asking what do I tell X, and they said don’t worry, I talk with X all the time. But when I checked with X, they hadn’t talked with Y in a year. I cancelled all interviews.

And a school teacher warned me that my child was saying in the playground their parents always told them the truth. When I confirmed it, the teacher was horrified!

Truth is my core value. I feel like myself when there’s truth in words (honesty), actions (integrity), and expression (clarity). I’m looking for what’s real and right, not easy and empty.

Commitment

A colleague corrupted a live database, causing a substantial revenue loss. They fixed the mistake, participated in the post-incident review, and didn’t blame anyone else. I was impressed, and still cite it years later as a great example of accountability.

And I spent 290 hours playing TOTK. I was alarmed to learn my completion rate was only 62%. Sometimes, I still think about that 38%…

Commitment is about me sticking with what matters. That’s commitment to people (loyalty), outcomes (accountability), and actions (dependability). I don’t commit lightly, but when I do, I’m all in.

Freedom

I helped some colleagues from an outsourcing firm ditch their company visas for their own. I hated the idea that if they said anything critical about their employer, their careers could be at risk.

And I worked at a company where architects dictated everything to teams, from which libraries to use down to how to write code comments. It was a technology autocracy, with a corrosive effect on culture.

Freedom means having the room to think and act for myself. It’s freedom in decision making (autonomy), actions (agency), and speaking out (expression). Success doesn’t come from command and control. It comes from encouraging people to use their judgement, take ownership, and ask for help when they need it.

Fairness

I’ve tried to be an ally to under-represented people. I’ve been in so many teams, attended so many events, and worked at so many companies that were dominated by middle-aged white men. The lack of diversity had a negative impact, in so many different ways.

And I love that Equal Experts links pay to industry benchmarks, runs a profit share scheme based on tenure, and is now in employee ownership. I’ve seen other companies struggle with the transition from founders to new owners, and that isn’t the case here!

Fairness means creating conditions where everyone can succeed. I want fairness in access (opportunity), credit (recognition), and help along the way (support). I’ve learned that meritocracy doesn’t exist, and I want people to have similar opportunities to me, especially where systemic barriers have made life harder.

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 🙂