Leadership musings and hackery from the Perl generation...
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.
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.
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 negative impact on team culture and effectiveness.
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.
There's a distinct pattern I've noticed whenever someone asks an AI to generate copy: the immediate retreat to bullet points. It's as if these systems have an inbuilt aversion to crafting genuine narratives, instead preferring to spew disconnected fragments of thought onto the page.
Ever found yourself in a meeting where your brilliant idea fell flat, not because it wasn't good, but because of how you presented it? I have, more times than I care to admit. Ever wondered why some people’s ideas tend to be accepted more than yours? If might simply come down to how you start your pitch.
There's a concept in outdoor adventure circles called "Type 2 Fun." Unlike Type 1 Fun (immediately enjoyable activities), Type 2 Fun is often not fun at all while you're doing it but becomes enjoyable in retrospect.
I discovered this firsthand during my first half-marathon. Mile 10 was pure agony—legs burning, lungs screaming, mind begging me to stop. Nothing about that moment felt "fun." Yet crossing the finish line delivered a satisfaction that immediate pleasures rarely provide. Looking back, that gruelling experience transformed into one of my proudest memories.
This paradox perfectly describes the reality of engineering leadership in startups.
As an engineering leader, mentioning that you track lines of code (LOC) is often met with immediate pushback. "We deliver so much more value that producing code!” "Lines of code don't measure quality!" "You'll incentivize bloated code!" "The best engineers delete code!" “Outcomes over outputs!”. All valid comments in some contexts, but they miss a crucial point: quantitative metrics, when used appropriately alongside qualitative data, provide valuable insights into team performance and health.
Cross-functional teams have become the backbone of modern product companies, bringing together product managers, engineers, and designers to tackle complex customer problems. But while these teams promise better decisions and greater autonomy, many organizations struggle with fundamental questions: How should teams be structured? What problems should each team own? How do you ensure they maintain long-term customer focus rather than getting lost in feature delivery? Team Charters offer a powerful solution to these challenges, providing teams with clarity of purpose and the foundation for true customer obsession.
It can be hard to know where to start when defining a strong organisational culture for a product business. One thing is for sure though, great product and tech businesses all share on thing in common: a culture that seeks to achieve product, engineering and operational excellence for its customers. Depending on what your teams do, these customers may be internal or external, but the goal is still the same: ensuring customer success.