People often ask how to apply the engineering principles I talk about.

My answer — “it depends” — isn’t a cop-out. It’s a recognition that teams and contexts vary. But across high-performing teams I’ve led, some patterns consistently work (yes, in the real world; yes, in large orgs; yes, in regulated industries).

Here’s what that looks like:

Be a real team.

Not just engineers. A cross-functional group: engineering, UX, product, QA, domain experts — collaborating daily. We need some process, but the real value comes from interactions. Colocation is optional. Real-time collaboration is not. The best teams I’ve worked with mobbed for 4–6 hours a day. If not that, then rotating pairs. If not rotating pairs, then just pairs. Solo work? Only for trivial, isolated tasks.

The Forest and Desert metaphor is a compelling way to highlight the communication gap between software teams in different working conditions, but it risks slipping into absolutism and evangelism.

I don’t like it.

It sets up a dichotomy where the Forest is seen as the enlightened, flourishing state of software development (agile, tested, customer-focused) while the Desert is a place of dysfunction, scarcity, and struggle. This framing is seductive, but ultimately incomplete and potentially harmful.

I made a huge mistake early in my career. I thought I was going to get fired. My manager just said, ‘Just learn from it.’

I saw this quote from a junior engineer reflecting on their early experience, and while it sounds enlightened and kind on the surface, it’s actually not the right stance.

A better response would have been: “Let’s all learn from this. How do we fix the environment so that an engineer—especially someone new—was in a position to make that mistake in the first place?”

“Adding manpower to a late software project makes it later.” — Fred Brooks, “The Mythical Man-Month”, 1975.

I think we should stop calling these kinds of observations “laws.” It feels like we’re borrowing the authority of science too freely. Brooks’s Law isn’t a natural law. It’s an observation about what happens when teams are poorly structured and managed under pressure.

That said, the insight still matters. Adding people to a late project often makes it later, especially in waterfall-managed environments. But a lot has changed in 50 years.

I understand that many teams might find moving to trunk-based development challenging due to a number of reasons (environmental and cultural factors included).

It can feel like too big a shift from long-lived branches and traditional post-development code reviews. However, it does not need to happen all at once. In fact, it should be treated as an agile project: the key is to adapt gradually, breaking the process into small, manageable steps and refining it over time.

It’s a common trap in software teams: treating architecture, security, and quality as someone else’s job. We push those concerns off to specialists, assuming they’ll catch whatever we missed. The architect will figure out how it all fits together. Security will review it before launch. QA will test it thoroughly.

But when we depend entirely on someone else to validate our work (through CABs, architecture reviews, quality gates, or security assessments) we’re not just asking for feedback. We’re quietly delegating ownership. And when that happens, the quality of our output inevitably suffers.