Limited by Sleep

I told my team I couldn't carry on as we were, and I had no idea what the alternative was

Fri, 18 Sep 2026 09:00:28 +0000

I told my team I couldn't carry on as we were, and I had no idea what the alternative was.

For most of my career I believed a leader earns the right to raise a problem by arriving with the answer attached. Bring solutions, not problems. Following that rule kept me quiet for months at a time.

Eventually I hit my limit. A working arrangement had stopped functioning, I could see that clearly, and I had nothing resembling a recommendation to put beside it.

So I said the smallest true thing available to me. I can't carry on like this, and I don't know yet what the fix is.

Almost everyone else had reached the same conclusion long before I opened my mouth. They were waiting for someone to spend the social capital first, because whoever names the problem carries the risk of being seen as the difficult one.

We worked out the answer together, and it was better than anything I would have arrived with on my own.

Naming a problem you cannot solve converts a private worry into shared work, and the shared work is what produces the answer.

If you are carrying something you cannot fix yet, say it anyway. You are almost certainly not the only one holding it.

You cannot understand a team from the outside

Thu, 06 Aug 2026 08:45:01 +0000

You cannot understand a team from the outside, and you cannot understand it by looking at one layer of it. I have never managed to assess a team properly without spending real time inside it first.

The teams I work with are usually software or DevOps, so I am reading several things at once and none of them are sufficient alone.

There are the humans. Whether people have energy left, whether they rely on each other, whether the quiet person in the retrospective has always been quiet or has recently gone quiet.

There is the technical picture. Architecture, how the codebase is put together, how testing is done, what technical debt exists and whether any of it is being paid down. The decisions matter less than the reasons behind them, and those are rarely written down anywhere.

Then there is how work arrives and moves. Whether retrospectives produce change or just recur. Whether the backlog is ordered and cared for or simply exists. Whether anyone owns the product properly, or whether requests turn up already shaped in a way that cannot be built well.

These layers explain each other. A codebase tells you about the pressure people were under when they wrote it. A retrospective that raises nothing tells you what the team believes about whether change is possible.

I also have to be honest about my own position. Early on, what I am told reflects how much trust I have earned rather than how things really are, and taking week one answers at face value has led me to the wrong conclusion more than once.

This is why I stopped comparing teams. What moved the needle with one can be the wrong intervention entirely for another, and the only way to tell the difference is to be inside it long enough to see.

Rolling out a new tool takes a sprint

Fri, 17 Jul 2026 12:15:07 +0000

Rolling out a new tool takes a sprint. Getting people to change how they work takes months, if not a year. And the person that gap frustrates most is me.

I change quickly. When I see a better way of working I want to switch that day, and in the technical half of a transformation that speed is an asset. Stand up the pipeline, migrate the system, switch on the tool. Done, visible, measurable.

Then comes the human half, and my speed becomes the problem. When someone agrees with the new way in the meeting and quietly reverts by Thursday, they're not resisting me. I'm not asking them to learn a tool, I'm asking them to stop trusting habits that made them successful. That takes as long as it takes, and no amount of my impatience shortens it.

I don't have a silver bullet for this. Waiting for people to be ready is the hardest part of leading change for me, and I still get it wrong. What helps is treating the message like the product and iterating on it. If the document didn't land, I try a demo. If the demo didn't land, I sit with one person and let them try it themselves. Same change, different door.

I'm watching this exact gap open up with AI. The tools arrived in months. The habits will take years. If you're frustrated at the pace, the pace isn't the problem. Expecting people to move at the speed of software is. I'm still learning that too.

The most useful thing in a retrospective isn't the feedback itself

Fri, 03 Jul 2026 10:47:25 +0000

The most useful information in a retrospective is rarely the feedback itself. It is who speaks, who stays silent, and how people talk to each other when something uncomfortable is on the table.

New leads pour their energy into the mechanical half of the job. Planning done, board tidy, every merge request reviewed. I did the same. What nobody put on my checklist was the other half, the one that decides whether any of the mechanics matter: how the people in the team are actually doing.

The good news is that you can observe team health with the same discipline you apply to a system.

Retrospectives are my first instrument, and they are not optional. Beyond the actions raised, they tell me whether people are willing to give feedback at all. Because if someone won't talk in a meeting designed for it, what else is going unsaid?

Spotify squad health checks are the second. Less deterministic, more honest, and they give you something factual to track over time rather than a vague sense that morale is fine.

The third is simply listening. How people speak to each other in meetings, who gets interrupted, whose ideas get built on.

None of these work as one-off exercises. Done regularly, they give you a baseline, and the baseline is what lets you spot drift early. Team health decays exactly like technical debt does. Quietly, gradually, and expensively if you only notice once something breaks.

Happy teams do better work. But happiness is not luck. It is something you monitor and maintain.

The hardest part of stepping up to lead wasn't the meetings

Fri, 26 Jun 2026 09:00:07 +0000

The hardest part of stepping up to lead was not the meetings or the politics. It was watching my team solve problems in ways I never would have chosen, and keeping my hands off the keyboard while they did it.

I still miss the code. Writing it is the most fun part of this job, and I have to remind myself most weeks that it is no longer mine to own day to day.

What nobody warns you about is how much of leading is letting go. Their implementation will differ from the one in your head. Sometimes it will be worse, often it will be better, and either way it will not be yours. That gap is where the real adjustment lives.

Early on I filled that gap with correction. I would step in, redirect, tidy up the parts that did not match my mental model, and tell myself I was raising the bar.

I was micromanaging. And micromanaging is distrust dressed up as standards. If I am rewriting your work to match what I would have done, I am telling you I do not trust you to do it without me.

The shift came when I accepted that my job had changed shape rather than shrunk. I am further from the individual lines now, but much closer to the architecture, the customer, and the reason any of it is being built in the first place.

You do not stop being technical when you lead. You stop being the one who has to be right about every detail.

That has taken me years, and I still catch myself reaching for the keyboard.

My daughter was three when she told me she couldn't be an astronaut

Fri, 12 Jun 2026 09:00:19 +0000

My daughter was three when she told me she couldn't be an astronaut.

Not because of the maths, or the danger, or the distance. Because she wasn't a boy.

We were watching a SpaceX launch together and I'd asked if she wanted to go to space one day. Her answer stopped me cold. "I can't, Daddy. I'm not a boy."

She was three. Nobody had ever told her that. Not me, not her mum, not anyone we'd let near her. And yet somewhere, from somewhere, she'd absorbed it.

We spent the rest of the morning looking at photos of female astronauts. We agreed that when the time came, her suit and helmet would be pink. She's older now and probably doesn't remember any of it. I think about it constantly.

What unsettled me most was trying to apply the lesson to my own career. I'm a British born Indian who grew up in a working class family. I'll never know which doors were closed for me and which ones I closed on myself, because that's exactly how it works. The outside gets in early, then it speaks in your own voice.

My daughter didn't think someone was stopping her from going to space. She thought it was simply a fact, like gravity.

The doors that close on people are rarely slammed. They close through a thousand subtle cues, and eventually we finish the job ourselves.

So watch both directions. What the world is telling the people around you about which rooms they belong in. And what you've quietly accepted about your own.

You won't understand AI until you've used it yourself

Fri, 29 May 2026 09:00:10 +0000

There's an entire industry now devoted to telling people what to think about AI, and it's easy to read enough of it to feel like you understand the thing. You don't. Not until you've used it yourself.

Reading feels like progress. You finish another thread, another newsletter, and you walk away convinced you're keeping up. But the understanding I actually trust came from doing the work, not from reading someone else's account of it.

I use it to prototype ideas I'd never have had time to build before, and just as often to think, as a sparring partner that pulls my arguments apart or a coach when I'm working through a decision. None of that is something you learn from a summary.

And it isn't a developer thing. The fastest way to understand what these tools can do is to point one at something in your actual week.

Ask it how to cut your meetings next week. Get it to help you plan next week's meals. Have it explain the evolution of cats in a way a child would follow, or why water expands when it freezes. Ask it to map out a realistic path to your next promotion.

None of those need code. All of them teach you more in ten minutes than another week of reading will.

So if you feel behind, stop reading about it for a bit. Try something, anything. Doing is the real work, and it's the only part that teaches you.

The best teams I've built were never the most talented on paper

Fri, 22 May 2026 09:00:07 +0000

The best teams I've built were never the most talented on paper.

When you're handed the job of building a team, the instinct is to collect the best players. The strongest CVs, the deepest experience, the person who can do the hardest thing in the room. I tried to build teams that way early on, and it taught me I was solving the wrong problem.

A team is not a list of names. I've watched a group of brilliant people deliver less than a group of solid ones, because the brilliant group never gelled. Everyone optimised their own piece and nobody minded the gaps between them. How a team works together, and what it produces as a unit, matters more than how good any individual is on their own.

It also has to have range. Can it handle a sprint, the short intense push when something genuinely has to ship? And can it hold a marathon pace for years without burning anyone out? A team that can only do one of those is fragile.

Then there's the part people miss most. A team is never finished. People grow, people change, people come and go. The team you built last year is not the team you have today, so you keep adapting it, reshaping how it works and who carries what as the people in it change.

Building a team is not a one-shot decision. It's a constant process. The names on it turn over, but the team carries on, and keeping it good is work that never really stops.

People assume agile teams skip the planning

Fri, 08 May 2026 09:00:11 +0000

People assume agile teams skip the planning. In my experience it's the opposite. I plan more as an agile lead than I ever did on a waterfall project. The difference is when.

I've seen teams that do all their planning in a single quarterly session. Detailed roadmaps, ticket-level breakdowns, the lot. Then those tickets flow straight into sprints with little or no further thought. By the time the work reaches a developer, the plan is months old and based on what was true at the start of the quarter, not what is true now.

The cracks tend to show up in review. Issues that should have been spotted before a single line of code was written instead surface after the work is built. That's one of the most expensive places to catch a problem. The cheapest place is in a planning conversation, when nothing has been committed yet and a five-minute chat can change the entire approach.

People look at a sprint planning session and assume that's all the thinking that happens. They miss that there are at least three planning passes before code is written. Roadmap, shaping, refinement. Each one with better information than the last.

Waterfall does the most planning at the exact moment it has the least information to plan with. That's the bit that catches people off guard when I lay it out.

I plan more in agile, not less. I just don't pretend I knew everything in January about what would matter in April.

The pressure to do more never stops, it just changes shape

Fri, 17 Apr 2026 11:15:27 +0000

The pressure to do more never really stops. It just changes shape.

As a dev, the question was nightly: could I finish one more task before logging off? Get a head start on tomorrow, or call it a day?

As a lead, the question became: could I push the team for more next sprint? We overdelivered. Do we stretch, or do we rest?

Same question, different chair. And the right answer is almost never obvious in the moment.

I've drawn the line too late more times than I'd like to admit. In the better moments, I've caught it early enough to change course. The difference between the two isn't willpower. It's inspection.

Not the Agile kind. The human kind.

Asking myself what's actually going on, not what I'm telling myself. Asking my team how they're really doing, not just how the sprint is progressing. And asking about things that have nothing to do with work at all.

People aren't resources. The language of capacity and velocity makes them sound like they are, but they're not. Two people sitting next to each other, doing identical work, can have wildly different limits on any given day. You won't know which is which unless you ask. And unless they trust you enough to tell you.

I don't always get this right. But the times I've got it most wrong have almost always been the times I forgot to ask.

Every sprint the team's work is visible. The manager's isn't

Fri, 03 Apr 2026 12:43:18 +0000

Every sprint, the team's work is visible. Tracked. Inspected. Improved.

The manager's work? Nowhere to be found.

We spend hours refining stories, estimating effort, reviewing what got done and what didn't. We build entire rituals around making the team's output transparent. But the person with the most influence over whether the team succeeds or fails? Their commitments live in private notebooks and one-to-ones that nobody else sees.

I noticed this gap in my own practice. When something came up in a retro that I needed to fix, or when I told the team I'd sort something out, I started putting those tasks on the board. Not every sprint. Only when I'd made a specific commitment. But the effect was immediate. The team could see I was holding myself to the same system I was asking them to work within.

It changed the dynamic. Accountability stopped being something that flowed in one direction. When my task slipped, they could see it. When I delivered, they could see that too. It levelled things in a way that no amount of "open door policy" talk ever could.

Most Agile implementations have a blind spot here. We track velocity, cycle time, and sprint goals for the people doing the work. We track almost nothing for the people shaping the conditions the work happens in. If you believe in inspect and adapt, that belief shouldn't stop at the management layer.

The question isn't whether your team is improving. It's whether you are, and whether they can see it.

They didn't think they could build something like that

Mon, 23 Mar 2026 10:00:08 +0000

Someone I'm mentoring told me they didn't think they could build something like that.

Two hours later, they pushed a working app to GitHub.

We had a pairing session this weekend. They chose the idea: a Pomodoro timer app for macOS. They drove. I guided. We built it using Claude Code and Cowork, tried some interface approaches we hadn't explored before, and talked through a lot of it as we went.

It wasn't about the app. It was about the moment they realised they'd actually made something, from scratch, in an afternoon.

That shift in what someone believes they're capable of is one of the most rewarding things to witness in mentoring. And it's arriving faster now than it ever has. The distance between an idea and a working thing has collapsed. A lot of the friction that used to slow people down, environment setup, knowing which tools to reach for, has been dramatically reduced.

What that means is the real bottleneck is increasingly just the decision to start. Most people don't, not because they lack capability but because they haven't seen proof of it yet.

Two hours. A working app. A new baseline for what's possible. That's what playing with an idea looks like.

I used to kill ideas before they had a chance

Tue, 10 Mar 2026 12:32:00 +0000

I used to kill ideas before they had a chance.

Not deliberately. I'd have a thought about something that could work better, a tool that should exist, a process worth automating. Then the mental maths would kick in. How long would that take to build? Do I have the bandwidth? Is it worth the investment? The answer was almost always no, and the idea would quietly die.

That filter doesn't apply anymore.

AI hasn't just made execution faster. It's removed the reason most of us talked ourselves out of trying things. The gap between "interesting idea" and "working prototype" has collapsed from weeks to hours. Ideas that felt unrealistic six months ago are now something you can prove out in an afternoon.

Which means the bottleneck has shifted. It's no longer about capacity to build. It's about the quality of what you choose to build. Your ability to spot problems worth solving, to connect dots others miss, to think creatively about what should exist. That's the skill that matters now.

If you're not sure where to start, try this. Look at your calendar for the past week. Write down every type of work you did. Find the 20% that consumed 80% of your time, or the tasks you actively dreaded. Those are your first ideas. Those friction points you've been tolerating are now problems you can actually solve.

And you don't need to arrive with a solution. Just the problem. Open a conversation with an AI tool and start exploring it together. Try two approaches, try five. The right answer will emerge. And while you're solving that problem, you'll be learning how to use the tool itself, which is far more effective than any tutorial or course.

Start capturing ideas like they matter. Because for the first time, you can actually act on most of them.

The hardest lesson I learned as a tech lead wasn't about architecture or code quality

Sat, 07 Mar 2026 09:00:00 +0000

The hardest lesson I learned as a tech lead wasn't about architecture or code quality. It was about knowing when to step back.

Early in my career, I reviewed every pull request, attended every standup, and had an opinion on every decision. I thought that was leadership. It wasn't. It was a bottleneck wearing a leadership badge.

The shift happened when I started asking myself one question before jumping in: "Will this team be stronger if I stay out of this?"

Most of the time, the answer was yes.

When you stop being the person who approves everything, something interesting happens. People start owning their decisions. They debate more thoughtfully because the outcome is genuinely theirs. They grow faster because they're not waiting for permission.

The best engineering managers I know have mastered the art of strategic absence. They're not checked out. They're deliberately creating space for their team to step up.

It feels counterintuitive. Leadership as subtraction. But the teams that scaled best under me were the ones where I made myself progressively less essential.

Your job as a leader isn't to be needed. It's to build something that doesn't need you.

The best teams I've led weren't close from team building exercises

Wed, 04 Mar 2026 10:00:25 +0000

The best teams I've led weren't close because of team building exercises. They were close because we'd earned the right to relax together.

When my team finished a sprint with time to spare, I'd sometimes just set up a call. No agenda, no work talk, just conversation. Some people joined, some didn't. Some used the time to chip away at tech debt they'd been itching to fix. Both were fine.

Thursdays after a strong sprint, a few of us would go out after work. Not organised, not mandatory, just a natural thing that happened because the work was done well. Planning was wrapped up before we headed out, so Friday was genuinely relaxed. Sprint reviews, retros, a calmer rhythm after two weeks of focused delivery.

None of this was a team building strategy. It was a side effect of trust. When people know the work is solid and nobody's going to fill their downtime with more tasks, they open up. You hear about weekends, kids, hobbies, the random things that make someone a person instead of a Jira ticket assignee.

I think we underestimate how much of team strength comes from these small moments. Not the structured icebreakers or the forced fun. The unplanned conversations where you discover your developer is obsessed with sourdough or your QA lead has strong opinions about Formula 1.

In tech, people often get labelled as "not great with relationships." I don't buy that. Put those same people in a room talking about something they care about and they'll go for hours. The problem isn't that developers can't connect. It's that most workplaces never create the space for it to happen naturally.

Building a team people want to be part of isn't someone else's job. Not the scrum master's, not HR's. It starts with the lead deciding that relationships matter as much as the backlog.

Early in my career I was told not to use open source software

Fri, 20 Feb 2026 12:05:36 +0000

Early in my career, I was told not to use open source software. Company policy. Too risky, too uncontrolled, too much liability.

Then it was Stack Overflow. Don't copy code you don't understand. Don't trust answers from strangers on the internet.

Then ChatGPT arrived and the message was the same. Don't use it for work. Don't paste proprietary code into it. Don't trust what it gives you back.

Now it's AI coding agents writing code and committing changes that developers haven't fully reviewed. Same fear, same response. Ban it. Block it. Pretend it isn't happening.

To be clear, how you use these tools as a developer matters enormously. Blindly accepting code you don't understand is a problem regardless of where it came from. But that's a different conversation. What I want to focus on is the company policy side, because whether leadership approves or not, adoption is happening. You cannot stop it.

I've watched this cycle repeat for over fifteen years and the outcome is always identical. The tools win. Developers find ways around the restrictions because the tools make them more productive, and productivity is hard to argue with.

The amount of energy organisations pour into fighting adoption is staggering. Policy documents, compliance reviews, monitoring tools, disciplinary conversations. All to delay the inevitable by a few months while competitors gain ground.

This is where technical leaders who still code make a real difference. They understand what developers are actually using day to day, not what the policy says they should be using. That perspective is invaluable when setting realistic policy and explaining to senior leadership what's actually happening on the ground. I've found this to be the single most useful thing about staying hands-on as I've moved into leadership.

Most companies focus entirely on what they're trying to stop and never ask what they're actually trying to protect. If the real concern is IP leakage, solve for IP leakage. If it's code quality, solve for code quality. Banning the tool is treating the symptom and ignoring the cause.

Nothing stays the same for long. The only question is whether you adapt before or after it costs you.

How quickly can a new starter commit code?

Wed, 18 Feb 2026 13:41:38 +0000

How quickly can a new starter commit code? That question tells you more about your project's health than most metrics on your dashboard.

I've used this as a benchmark for the last 10 years, whether joining a team or leading one. The range is wild. Some teams have people shipping on day one. Others take weeks before someone can even run the application locally.

A slow time to first commit usually points to deeper problems. Fragile setup processes held together by tribal knowledge. Missing tests that would help someone understand what the code actually does. An assumption that documentation will cover the gaps, when half of it is outdated and the other half assumes context nobody wrote down.

I stopped treating onboarding documentation as the safety net a while ago. The real documentation is the code, the tests, and whether a fresh install actually works. If someone can't clone a repo and get running without pulling three people into a call, that's not a new starter problem. That's a team problem.

One thing I always tried to keep available was a handful of small tidying tickets. Not throwaway work, real tasks that needed doing but were low risk and well contained. Nothing gets someone feeling part of a team faster than shipping something on their first day. It builds confidence, gives them a reason to touch the codebase, and quietly proves the whole setup actually works.

The time it takes a new person to contribute isn't just about them. It reflects the care a team puts into how they work together.

Your customers have already accepted problems you haven't found

Fri, 13 Feb 2026 10:00:12 +0000

Your customers have already accepted the problems you haven't found yet.

I asked a customer to show me how they were using a feature my team had just built. Within minutes, I watched them switch tabs repeatedly, hunting for data that wasn't on the page, copying it back across manually. Every single time they used the feature.

It wasn't in the original ticket. We'd never discussed it in planning. I'm not a daily user of the product, so it hadn't occurred to me either.

The fix took very little time. When they tried it again, the difference was immediate. But here's what stuck with me: they were never going to ask for that change. They assumed the tab-switching was just how it worked. To me, they were working around a broken system. To them, it was simply the system.

This is the problem that no amount of feedback forms or sprint reviews will surface. People adapt to friction so quickly that it becomes invisible to them. If clunky is all you've ever known, clunky just feels like normal. You don't file a ticket for normal.

The most impactful improvements I've made haven't come from feature requests. They've come from spotting the workarounds that nobody thought to mention, the small inefficiencies that users had long stopped noticing because they'd built their habits around them.

If you're only fixing the things people complain about, you're missing the bigger picture. The real friction lives in the things they've stopped complaining about.

Every skill that transformed my career, I learned before I had to

Tue, 10 Feb 2026 12:33:12 +0000

Every skill that transformed my career had one thing in common: I chose to learn it before anyone told me to.

I taught myself Python because I could see it would change how I worked. I invested time in agile practices because I believed they'd make me a better leader. Every significant skill that shaped my career came from a deliberate decision to learn something before I was forced to.

So when I ask people how much time they're investing in learning AI, and the answer is "I've played around with ChatGPT a couple of times," it worries me.

Playing around isn't learning. It's tourism.

The pace of change with AI is unlike anything I've seen across my career, and I've lived through a few shifts. What was impressive six months ago is already table stakes. The gap between people who are actively learning and those who are waiting isn't growing gradually. It's accelerating.

The people who will struggle most aren't those who lack talent. They're the ones who keep treating this as something they'll get around to eventually. "Eventually" has a way of becoming "too late" when the landscape moves this fast.

If you want to start but don't know where, drop me a message. I'll share the free resources I've been using myself. No courses to sell, no agenda to push. I've just seen too many talented people fall behind because nobody nudged them early enough.

Most companies run their AI strategy like a waterfall project

Fri, 06 Feb 2026 11:28:01 +0000

Most companies are running their AI strategy like a waterfall project. And it's going to cost them.

I've spoken to a number of organisations over the past six months about how they're approaching AI. The pattern is almost always the same. They form a committee, draft a strategy document, plan a phased rollout, and aim for a big coordinated launch. Meanwhile, the technology shifts three times before the first phase is complete.

These are the same companies that claim to run agile. They operate sprints for their day-to-day delivery, but the moment something this significant arrives, they default straight back to waterfall thinking. Big plan, long timeline, late delivery.

AI doesn't reward that approach. It rewards small experiments, fast feedback, and constant adaptation. It rewards the company that gives a team two weeks to test a use case and report back, not the one that spends six months building the perfect AI policy before anyone touches the technology.

This is where 20% time stops being a Google-era novelty and becomes a genuine competitive advantage. The companies that will pull ahead aren't the ones with the best AI strategy deck. They're the ones creating space for their people to experiment, learn, and feed those learnings back into how the organisation works.

The gap between Company A and Company B won't be who adopted AI first. It will be who learned to adapt fastest.

If you're leading a team and your AI approach involves a committee, a twelve-month roadmap, and a phased rollout, I'd challenge you to try something different. Pick one team, give them a real problem, let them experiment for a fortnight, and see what comes back. That single experiment will teach you more than any strategy document.

I used to get frustrated that designers couldn't just get it done

Tue, 03 Feb 2026 10:48:33 +0000

I used to get frustrated when designers couldn't just "get it done" in a sprint.

Why couldn't they estimate like developers? Why did everything need more time?

Then I realised I was asking them to work against the very thing that made them valuable.

A developer's satisfaction often comes from shipping. A designer's comes from getting it right. These aren't compatible timelines, and I was trying to force one into the other.

So I changed my approach. I gave design work the breathing room it needed, but coached the designer to break their work into smaller, deliverable sections. Not compromising on quality, but finding natural breakpoints where developers could start building while the full vision continued to evolve.

The team got faster. Not because anyone changed how they thought, but because we stopped fighting each other's rhythms and found a way to sync them.

Different minds aren't a coordination problem to solve. They're the reason the work is good. Your job as a leader is to find the shape that lets each one thrive.

I still believe in 20% time

Fri, 30 Jan 2026 10:00:06 +0000

I still believe in 20% time.

Not because it's trendy. Because sprint-to-sprint thinking creates tunnel vision.

Some leaders see it as wasteful. "We can't afford to have people not delivering features."

But here's what they're missing.

Turning a manual job into automation. Adding tests to an uncovered area. Trying a library that might simplify everything. These aren't extras. They're part of the process.

When you don't protect time for this, you end up living in a messy house. Every time you want something from the cupboard, you have to move four boxes, pull the door just right because otherwise it gets stuck, then put everything back or you can't see the floor.

You can live like that. People do. But eventually you stop opening that cupboard at all. You work around problems instead of solving them.

20% time is protected space to step back and view what you're building, and how, in a different light. Not just for developers. Product people. Designers. Anyone whose work compounds.

The dividends don't show up in this sprint. They show up in the team that's still sharp and engaged six months from now.

Take a moment. Spend some time. Ask how you could do something better.

I spent two weeks building a filtering system nobody needed

Wed, 28 Jan 2026 12:24:59 +0000

I spent two weeks building a data filtering system with custom views and display options.

Then I watched a user work.

She opened my carefully designed interface, used a browser extension to capture the table, dumped it into Excel, and started pulling in data from other sources.

She didn't need better filtering. She needed the data out so she could combine it with everything else she was working with.

An export function. That's what would have helped her. A few days of work, not two weeks of overengineering.

I'd built a solution to a problem I invented. The real problem was obvious the moment I sat next to her and asked "show me how you actually do this."

Now that question is where I start, not where I end up after the build is done.

User stories aren't requirements to satisfy. They're invitations to understand someone else's reality before you write a line of code.

Technical debt doesn't announce itself

Fri, 23 Jan 2026 11:28:22 +0000

Technical debt doesn't announce itself.

It builds in the background while you're shipping features, celebrating launches, and hitting every deadline.

Then one day a change that should take hours takes weeks. And you can't explain why to anyone outside the team.

I've seen both sides of this.

Teams that paid the debt. Got deployments fully automated. What used to be hours of manual work became minutes. They moved faster than they ever had.

And teams that didn't. "This is how we've always done it." They kept paying the interest, sprint after sprint, looking for other reasons for what it could be. Anything but paying the debt.

The cruel part? Debt accumulates fastest during your successful periods. Every shortcut taken to ship on time. Every "we'll come back to this" that never got revisited.

You don't feel the weight until you try to move fast again and realise you can't.

The speed you're celebrating today might be borrowed from next year.

Worth asking: which team are you on right now?

How long would it take to build an app? I told him a weekend

Tue, 20 Jan 2026 09:00:00 +0000

Someone I know who runs a small business asked how long it would take to build an app like the one I'd just shown him.

A year ago, I'd have said weeks. Maybe months.

I told him a weekend.

The technical barrier is nearly gone. What used to take me three weeks now takes three days. AI has changed the maths completely.

But removing one constraint just moved me to the next.

When you can build almost anything, the bottleneck shifts. Now I'm limited by time and ideas, not capability. And with so much suddenly possible, it's dangerously easy to get distracted.

So I've gone back to basics. Agile. Not for managing development cycles, but for managing my own focus. Failing fast. Killing ideas that aren't working. Staying ruthlessly prioritised.

Because the uncomfortable truth is this: I'm learning faster than I ever have, and I still feel behind. Every week there's something new. The pressure to stay ahead is relentless.

And this is the worst AI is ever going to be.

I think about what this means for the next generation entering the workforce. The rules they'll play by won't look anything like the ones I learned.

I don't have answers. But I know standing still isn't an option.

For 3 sprints in a row your team overdelivers, you face a choice

Fri, 16 Jan 2026 09:00:00 +0000

For 3 sprints in a row your team overdelivers, you face a choice.

Do you raise the target? Push for more?

I used to think that's what good leadership looked like. Maximising output. Rewarding success with higher expectations.

Then I learned the difference between a team that's performing and a team that's sustainable.

The symptoms of pushing too hard aren't always obvious. People still hit deadlines. Code still ships. But the Spotify health checks start showing strain. The quiet ones get quieter. Your best people start updating their LinkedIn profiles.

With my strongest team, when we finished a sprint early, I didn't raise the bar for the next one. I gave them the remaining time to invest as they saw fit, as long as it served the project.

Some tackled tech debt. Others experimented with new tools. A few did training. Some just talked.

These weren't breaks. They were investments.

That team delivered consistently for over two years. Not because I pushed them harder, but because I didn't.

Sustainable pace isn't about doing less. It's about doing more for longer.

The hardest moment in my leadership journey wasn't a project failure

Tue, 13 Jan 2026 09:00:00 +0000

The hardest moment in my leadership journey wasn't a difficult conversation or a project failure.

It was realising I was no longer the best engineer on my team.

I'd hired well. Trained well. And suddenly the people around me were coming up with better solutions than I could.

My first instinct was to fight it. To find reasons why my approach was still better. To pull rank when I disagreed with their decisions.

But that's ego talking, not leadership.

The real shift came when I stopped asking "how do I stay the smartest person here?" and started asking "how do I make myself redundant?"

Now I look forward to being wrong. When someone on my team has a better idea than me, it means I've done my job.

Your role as a lead isn't to have the best answers. It's to build a team that doesn't need you to.

Most advice you give disappears into the void

Fri, 09 Jan 2026 09:00:00 +0000

Most advice you give disappears into the void. You say something, people nod, and you never find out if it mattered.

Yesterday I got a reminder that sometimes it does.

A few months ago, I ran an AI workshop. Afterwards, a senior engineer was stuck overthinking an idea. What if it fails? What if nobody uses it? How will I monetise it?

My response: Does it matter? Build it for yourself. Don't bolt on features for a future you can't predict. Try it, fail fast, learn, repeat.

Standard agile thinking. I've said versions of this hundreds of times.

Yesterday, that same person sent me an app they'd actually built.

That's the thing about encouragement—the feedback loop is mostly invisible. You plant seeds and walk away. Most never grow. But occasionally one does, and you only know if someone decides to tell you.

If you've ever nudged someone and wondered if it mattered: it might have. You just don't know yet.

I've worked in teams of 3 and teams of 300

Tue, 06 Jan 2026 09:00:00 +0000

I've worked in teams of 3 and teams of 300.

Neither is better. They're different games entirely.

In a small company, you touch everything. Deployment, customer calls, hiring, the lot. You make real decisions because there's nobody else to make them. The learning is brutal and fast.

In a large company, you get to think. You can run experiments that would sink a startup. You have specialists to learn from. Failure doesn't threaten the project.

Here's what took me years to understand: the real advantage comes from experiencing both.

When you've only worked in one environment, you don't know what you're missing. You assume the way things work is the way things have to work.

Move from a startup to an enterprise and suddenly you see the value of process, documentation, and thinking beyond next week. Move the other way and you realise how much faster decisions can happen when there's no committee.

Every company is different, but the comparison itself is the education. You start recognising patterns. You bring ideas that seem obvious to you but revolutionary to teams who've never seen another way.

The engineers and leaders I've worked with who grew fastest didn't just climb a ladder in one place. They moved between both environments. Not constantly, but deliberately and carried the lessons with them.

There's a line in the BlackBerry film that struck a nerve

Fri, 02 Jan 2026 09:00:00 +0000

There's a line in the BlackBerry film that struck a nerve.

"Why do you think these guys work 80-hour weeks?"

I've been in rooms where that question was never asked. Where the assumption was simple: push harder, demand more, and people will deliver.

They do. Until they don't. And by then, you've lost something you can't get back.

I spent years as a team lead thinking about this. Not how to get more from people, but what makes them actually want to give it.

Fear works short-term. So does money. But commitment? That comes from somewhere else.

Feeling heard. Having autonomy. Knowing your lead sees you as a person, not a line on a spreadsheet.

The stick gets compliance. The carrot gets discretionary effort.

If you're leading a team, ask yourself honestly: why do your people show up?

If the only answer is "because they're paid to" — that's a warning sign, not a win.

Helicopter view and detailed viewed, small company vs big company

I've read the same book every year for 10 years

Mon, 29 Dec 2025 09:00:00 +0000

I've read the same book every year for 10 years.

Not because I forgot what happens. Because I'm not the same person who picks it up each time.

The Phoenix Project found me in 2014, a Django developer at Sky learning mostly by stumbling. I thought good code was the job. This book showed me the job is much bigger than that.

It reframed how I saw organisations, bottlenecks, and why some projects succeed while others quietly suffocate.

I re-read it before interviews. Before big meetings. I've even told interviewers about it—if they haven't read it, I know we'll have an interesting conversation.

When someone I'm mentoring asks how to understand what makes projects actually work, this is the homework I give them. Every time.

The strangest part? The character I identify with keeps changing.

Over the years I've been all of them at some point. I'm still learning which one I am today.

That's what a great book does. It meets you wherever you are and shows you something new about where you've ended up.

What's a book you keep returning to?

I still use RSS feeds

Wed, 24 Dec 2025 09:00:00 +0000

I still use RSS feeds. Yes, they still exist. Yes, I'm probably showing my age.

Every day, I scan what's new in the areas I care about. It's not just tech, it's food, design, ikea hacks, economy, science, games... Most of it I skip. Some I save for later. Occasionally something sparks a quick experiment.

Technology moves fast. AI has made it relentless. You can't stay on top of everything—but you can keep a pulse on the trends that matter to you. That investment compounds.

What separates people in this industry isn't just what they know today. It's the habit of continuous learning. The willingness to tinker. To try something small, learn from it, and move on.

Career advice: always have a tiny project on the side. Not a startup. Not a hustle. Just something you're tinkering with. Enjoy your human curiosity.

AI has made this easier than ever. You can prototype an idea in hours that would have taken weeks. Try it. If it's rubbish, bin it. No harm done. Get used to that process.

Recently I came across a project called Beads—a memory system for AI coding agents. My initial reaction was that it wasn't for me, but I trusted the author's track record and figured it was worth an hour of my time to try it. I've been pleasantly surprised.

So here's my question: what's your next tiny project?

Not a grand plan. Think agile. What could you build or learn in a day or two? What's been sitting in your "I should try that" list?

I'm genuinely curious what people are tinkering with right now.

I've spent years giving career advice in 1:1s

Mon, 22 Dec 2025 09:00:00 +0000

I've spent years giving career advice in 1:1s. I never shared any of it publicly. Not because I didn't think it was valuable but because I was scared of what people would think. Would former colleagues roll their eyes? Would people think I was being preachy? Would I look like every other person on LinkedIn trying to build a "personal brand"?

That fear kept me quiet for a long time.

But here's what changed: I realised I was limiting my impact to the handful of people I happened to work with directly. The conversations I've had with mentees about career pivots, about navigating technical leadership, about the mistakes I made so they don't have to. Those shouldn't be locked behind the accident of who ended up on my team. So I'm trying something. Treating this like any good agile practitioner would: try it, learn from it, iterate.

I don't know if this will work. I don't know if anyone will find it useful. But I know that staying silent because I'm worried about judgement isn't a good enough reason anymore.

Let's see where this goes.