Leadership musings and hackery from the Perl generation...
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.
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.
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 effort, nothing changes. The decision rolls forward and you leave the room frustrated, wondering why nobody listened.
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 them what the problem is?
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 getting get bad ideas. When you look inward at the details of your own business and team and solve from first principles, you build something worth having.
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." These weren't lies exactly, but they were convenient shields against accountability.
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 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 important skill gap in our industry.
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.
Remote work solved for productivity in isolation. What it couldn't fully replicate was the ambient awareness that comes from proximity - overhearing a conversation that changes your approach, the quick whiteboard session that untangles a problem in minutes rather than days of async back-and-forth, or the organic mentorship that happens when junior engineers can observe how senior colleagues navigate ambiguity.