Leadership musings and hackery from the Perl generation...
A rant about oversized pull requests did the rounds on Hacker News this week, and every engineering leader I know would nod along to it. I think it aims at the wrong target. Size was always a proxy for reviewability, and AI has broken the proxy. The teams struggling right now are not drowning in big pull requests. They are drowning in all of them. Small PRs were never asked for because they are…
Somewhere in your organisation, two teams are solving the same problem and neither of them knows about the other. When you find out, your instinct will be to stop one of them. Hold that instinct, because the alternative you are picturing, one team and one clean solution, is rarely the alternative on offer. The real choice is usually between having two of something and having none of something, and…
I've spent the last few months building features alongside my engineering team. Not because I had to, but because I wanted to understand what AI-assisted engineering actually feels like at the coalface. It made me a sharper leader. It also nearly made me a bottleneck. Getting back close to the tools was a deliberate choice. As an engineering leader, it would be easy to operate entirely in the…
Somewhere in your organisation, right now, a decision is not being made because of something you said six months ago. You don't remember saying it. The context is long gone. But the guidance has hardened into a rule, and the rule is being enforced by people who have never spoken to you. Newton's first law says an object in motion stays in motion until acted on by an external force. Leadership…
The best engineers have always been generalists with spikes of deep expertise. AI hasn't changed that. What it has changed is the timeline. You used to have years to broaden your skills across the stack. Now you have months, and the engineers who treat breadth as someone else's problem are finding out what happens when the market stops rewarding narrow specialism. The original Renaissance…
AI coding tools have made it possible for engineering leaders to be deeper "in the code" than at any point in the last decade. That sounds like a win, and in many ways it is. But there's a trap hiding inside the dopamine hit of shipping features yourself: the more time you spend building, the less time you spend leading. And the parts of your job you're neglecting are often the ones your…
I recently spent an unreasonable amount of time getting the Clipsal C-Bus Toolkit to talk to a remote C-Gate server. What started as a straightforward "it won't connect" turned into one of the most layered debugging sessions I've had in a while. If you're running C-Gate on Linux with Java 17 and trying to connect the Windows-based C-Bus Toolkit remotely, this post might save you a weekend. My…
Every organisation hits moments where a decision needs to be made and not everyone agrees. The best teams move forward together anyway. The worst ones splinter into factions of quiet resentment and passive resistance. The difference between these two outcomes often comes down to whether people truly understand what "disagree and commit" actually means in practice. A principle more cited than…
Most engineers have been in that meeting. Someone proposes an architecture, a migration plan, a new tool - and something in your gut tightens. You don't agree. You're not bought in. But instead of saying that, you do what engineers do best: you intellectualise it. You poke holes in the proposal. You counter with your own alternative. You debate the technical merits. And somehow, despite all that…
You're frustrated with someone on your team. They're not meeting your expectations, they're not "getting it," and you can feel resentment building every time they miss the mark. You've been giving them direction, assigning tasks, course-correcting their work - and yet nothing changes. Before you conclude that this person isn't capable, it's worth asking a harder question: have you actually told…
Most founders and engineering leaders I meet share a dirty secret: their playbook is someone else's. They benchmark on competitors, cargo-cult processes from previous employers, and import org structures wholesale from companies operating at completely different scales and stages. It feels safe. It feels informed. But as Apple's CFO Kevan Parekh once said , when you benchmark on others, you risk…
Every DORA metric, every PR cycle time report, every deployment frequency chart your organisation produces is a performance review of engineering leadership. We just refuse to read it that way. The excuse era is over For years, engineering managers could hide behind the inherent complexity of software development. "This work is hard to estimate." "Coding takes time." "You can't rush quality."…
There's an old political adage that says "if you're explaining, you're losing." It's usually applied to campaign messaging, but there's a version of this that plays out constantly in boardrooms and executive meetings. When a senior leader immediately shifts into teaching mode to justify a decision, they often invite more scrutiny than they deflect. The instinct that got you here, is not what will…
Professional developers don't vibe, they control The phrase "vibe coding" has entered the lexicon to describe a workflow where developers prompt an AI, accept the output, and hope for the best. It sounds efficient. It feels modern. And for production systems, it's genuinely dangerous. The distinction between developers who vibe and those who control their AI tools is quickly becoming the most…
The code review, that sacred ritual of software engineering, is dying. Not because we've abandoned quality or stopped caring about our craft, but because the ground beneath it has fundamentally shifted. In the age of agentic AI, the pull request as we know it has become a bottleneck masquerading as a best practice. What We Actually Got From Code Reviews For decades, code reviews served multiple…
The return-to-office wave sweeping through tech has become one of the industry's most contentious debates. After years of proving remote work could function, many engineers feel blindsided by mandates pulling them back to commutes and open-plan floors. I understand the frustration - but I've also come to believe that in-person collaboration, done thoughtfully, creates something genuinely difficult…
If your engineers build systems but never get woken up when those systems fail, you don't have DevOps. You have developers who throw code over a wall to someone else. The "Ops" in DevOps isn't a label - it's a commitment to owning what you build, all the way through to 3am when it breaks. Ownership Requires Consequences True ownership means feeling the weight of your decisions. When an engineer…
Process is comfortable. It gives us checklists, meetings, and the satisfying feeling that we're being rigorous. But here's the uncomfortable truth: most process exists to make us feel like we're solving problems, not to actually solve them. The real leverage comes from mechanisms, systems designed so thoroughly that the right outcomes happen by default, not by heroic effort or perfect compliance.…
It's a common scenario: a team member expresses frustration to their manager about a company policy, a client issue, or an internal process. The manager, wanting to build rapport, nods along and perhaps adds a complaint of their own. The intention is often to connect, but this act of commiseration is a counterproductive habit for leaders. It trades a moment of superficial agreement for a long-term…
In tech companies across Australia, 'tech debt' is thrown around as a catch-all excuse for prioritising certain engineering work. But this concept is often misunderstood and can be harmful to technical roadmap planning. The Origin Story: What Tech Debt Was Meant to Be When Ward Cunningham coined 'technical debt' in 1992, he described a specific phenomenon: making conscious trade-offs between…