I am an Engineering Director by trade, so I spend my time either leading or helping others to lead. Spending my time doing this for upwards of fifteen years has allowed me to gather a few useful insights, observations and thoughts.

I’ve been recording these on LinkedIn for the past few weeks, generally as they come to mind; inspired by something that happened to me that day.

LinkedIn is an increasingly uninspiring place to be though - at best a walled garden for job seekers and at worst a generic social media cesspit. So as a tiny act of defiance, I’m going to copy all the posts onto this page on my own website where anyone can read them for free.

12th May 2025

Leadership tip of the week: What defines your team’s mindset, Completion or Maintenance?

Given that, as engineers, we’re here to get stuff done - and the negative vibes around the word “maintenance” - the answer is maybe not what you think!

Focus on Completion and you’re likely driven by deadlines. Defining blocks of work, setting targets and going all-out to hit them. “We can relax when the new version is released”, “just one big push to finish this project”, “we’ll fix that issue when we’re not so busy”…

Like that time’s ever coming 😂

Focus on Maintenance and you’re building ways of working that make your team productive every day. You accept that deadlines are never ending, nothing is ever complete. You deliver incremental positive changes every day at a steady, sustainable pace.

The erroneous belief that Completion is even possible causes all kinds of negative behaviours in teams. Tech debt, burnout, hyper-descoped MVPs that leave customers underwhelmed…

Build your team in maintenance mode. Encourage ways of working that can continue indefinitely. Balance delivery with learning, best practice and high quality every day.

You’ll go quicker that way, be more confident and be HAPPIER in the process.

1st May 2025

Leadership tip of the week (and it’s a difficult one): You can’t fix it by working harder!

Most of us came to leadership from the ranks. Moving from Individual Contributor to Manager in some form or another. We probably got promoted because we were good at what we were doing, which is odd if you think about it, but having an appreciation for what our teams do is no doubt beneficial.

So when things aren’t going as fast as we’d like, the temptation is always there to jump in and help. Write a bit of code, cover some of the meetings… just a couple more individual contributions to keep the wheels turning.

It is often excruciating to watch your team beavering away when you’re not actually all that busy yourself. Worse to sit idly by while you miss a delivery deadline or sales target. You feel like a sell-out. Lazy. Unproductive. The temptation to jump in and do something is very hard to resist.

But resist you must!

The problem is that what keeps you busy as a manager (meetings, team changes, process tweaks, new projects etc) can be incredibly disruptive and needs to be delivered slowly and carefully. Changes need time to bed in, people don’t like meetings, there’s only so much career guidance you can give people in any given week 😉

Your success criteria as a leader is not how busy you are - it’s how much positive impact you have… and that’s best served from a calm and well informed place, after careful thought and with appropriate follow-up. Trust me, you’ll have a much more positive impact on your team if you’re not snowed under with work!

It’s absolutely possible to be a good leader in a bad team. Your success rests on the delta not the absolute: how much better your team is today, compared to last time around.

So next time you find an empty slot in your calendar, resist the urge to fill it with a meeting, surrender your git credentials and spend the time thinking about how you can delegate something else to free up some more time tomorrow.

You are there to support your team, take the rap when things go badly and always have a plan to be better next time - doing the work is no longer why you’re here!

15th April 2025

Leadership tip of the week: False consensus is the team killer!

We’ve all been in one of those meetings - someone made a statement about how things should be, someone else offered a counter opinion, a third person adds their view… The conversation bounces round the room getting more heated as it goes; it feels like everyone needs to offer a counter opinion; voices start to raise; it’s uncomfortable for everyone…

…then someone says “hey, what are we even arguing about - I think we’re in violent agreement!”. Everyone relaxes - they don’t have to argue any more; the social tension goes away and the conversation moves on.

If we’re in agreement, I guess that means everyone sees it the way I do… right?

False consensus is when everyone thinks they agree, but actually everyone has a very different mental model of what they’re agreeing to. When they leave the room, everyone will head off in different directions. It undermines trust: “why isn’t Barry doing what we agreed?”. It wastes time. It kills teams.

What can you do?

• Stop speaking, start listening. Ask people for more detail, dig into their viewpoint, even if it conflicts with your own. Especially if it conflicts with your own. Understand their motivations.
• Write it down. Nothing flushes out a false consensus quicker than a written statement in the minutes or drawing on a whiteboard. Keep adjusting and amending until everyone feels it matches their understanding.
• Don’t feel awkward about disagreeing! So often we back away from discussions because it’s mentally draining to disagree. Remember, it’s not personal. It’s not you versus them. It’s just some people trying to find the best outcome.
• Instead of pushing the room to accept a general consensus, start to capture the places you do see agreement, and chip away one at a time. This will help break the tension too.
• Socialise your key points before the meeting. Meetings are a terrible place to make decisions. Speak to your stakeholders one at a time in advance and build genuine consensus one by one.

I look forward to an abundance of comments violently agreeing with my viewpoint on this. Now… on to the next agenda item…

2nd April 2025

Leadership Tip of the Week: How to feel about team growth

A common mistake I see among new engineering leaders is to think about team growth and hiring the wrong way round. Let me explain:

As engineers, we’re constantly under pressure to deliver. There are never enough hours in the day. The demands are relentless. It takes unbelievable strength of mind just to keep delivering quality products under unyielding pressure. Battling with the incessant demand for new features and unbreakable laws of quality and best practice is all-consuming.

All we need is a bigger team. Just… one… more… dev…

Inevitably, you find yourself in a meeting with senior leaders, making a case for more investment, feeling like it’s your job to convince them, that you’re accountable: if you “lose” you’ll shoulder the burden of failure.

STOP.

Keep playing it this way and you’ll hurt yourself. Trust me, I’ve been there, and it’s no fun.

Some years ago I learned the reality of the situation. In the middle of an all-too-familiar pitch to various CxO’s I suddenly realised that I held all the cards. This revelation changed my whole career and the stress fell away instantly…

What changed is that I realised that it’s all just a transaction.

What engineering teams deliver is broadly constant. Sure, you can tweak it up and down by working smarter, paying off tech debt, hiring great people - but at the end of the day, one team can deliver one team’s worth of stuff per day.

It doesn’t matter what Salespeople promise to customers. You can draw whatever you like on a Gantt chart. You can promise the moon to the King of the World… At the end of the day it comes down to Engineers doing real work, bounded by the laws of physics. If you’re doing your job well (and I believe you are), there’s a maximum to what you can do with the time you have.

Think about things this way and the whole thing turns into a simple trade: “If you give me X more engineers, I will give you Z units more value. If you don’t, we’ll just carry on at the speed we’re going. No worries”.

And this is how senior leadership are thinking about things: “Is it worth investing $X to realise $Y of revenue?”.

Think of yourself as an advisor - your role is to identify and present options, but your success doesn’t ride on the decision that’s made. Your role as an engineering leader is to get the best out of the team you have and point out opportunities to grow when appropriate. Sometimes that will align with what Finance, Commercial and the gang need - sometimes it won’t. No biggie!

Not only will thinking about your team this way make you happier and less stressed out, it will also make you look like a legend when you present your next investment case. No longer will you look weak - pleading for more people to get things done. Instead you’ll look like an expert, identifying an investment opportunity to deliver real value… or not. No big deal.

24th March 2025

Leadership Tip of the Week: Get promoted by drawing pictures!

If you want to succeed in the world of Software, Engineering, Data… get from mid level to senior and beyond… spend your time learning two skills: hashtag#Drawing and hashtag#Storytelling.

These two ancient skills, that date back to pre-history and drive our very existence as a species, can also get you promoted!

Coding is how we communicate to a computer what we want it to do. Whether it’s some low level C++, a python notebook, terraform or CSS - code is nothing more than a clear and convenient way to express something we want to happen. Even if you’re doing prompt engineering with AI, you’re using a more verbose and less elegant language to do it.

What we don’t talk about enough is how we communicate with other humans. How we convey our intentions and compare our ideas with other engineers; how we understand and agree the “what” and the “why” with our users.

Over the years I’ve learned that the more senior an engineer is, the more likely they are to either grab a whiteboard pen and start to draw or explain their thoughts with a metaphor.

Code is actually a terrible way to convey the way a complex system hangs together with another engineer and it’s an absolutely atrocious way to understand and refine the requirements and motivations of a user, customer or stakeholder.

So grasp every opportunity to draw a diagram; challenge yourself to explain a complex system to a layperson. Get your team round a whiteboard. Create a system diagram or adopt the ones you have and keep them up to date.

This is the path to greatness!

AUTHOR’S NOTE: Terrible diagram shown for illustrative/ironic purposes only. Don’t @ me.