Stop copying, start thinking

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.

How the instinct to explain may be your undoing

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.

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 important skill gap in our industry.        

Pull requests are dead, long live pull requests

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.

In-person by default: Relearning how to build effective teams post covid

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.

You don't have a DevOps team if nobody's on call

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.

Mechanisms over process: Building systems that make success the default

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.

The pitfall of commiseration

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.