What Good Looks Like

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.

Start from a problem, not a requirements list.

Work begins with a real-world problem — not a backlog handed down from above. Engineers aren’t just executors. They’re problem solvers. Start from customer or proxy stories. Don’t aim for full specs — just enough to talk and explore. We use Acceptance Test-Driven Development (ATDD) to align on behaviours, edge cases, and expectations. QA, product, and domain experts all contribute. Then we implement with TDD. ATDD = shared understanding (outer loop) TDD = quality design (inner loop)

Integrate continuously.

Every behaviour goes through local validation and merges straight to trunk. No branches. Each commit creates a release candidate, further validated (performance, security, compliance, etc). Most confidence comes at commit time. Once approved, the candidate goes to production using the appropriate deployment strategy (canary, blue/green, etc). If issues arise, we roll back fast and alert the team.

Work on one thing at a time.

Pull from a short, prioritised backlog. One item. Together. This focus reduces waste and boosts speed. Exploratory testing happens in parallel. Frequent releases mean faster feedback. Weekly (or more frequent) working sessions with stakeholders let them try the product, suggest changes, and explore ideas — with UX input especially valuable.

Reflect regularly — and commit to how you work.

Weekly or biweekly, the team stops to reflect on:

• Collaboration
• Motivation
• Pace
• Quality
• Friction points This is a “we not I” moment. Honest conversations in a safe space. Small tweaks here drive big, sustainable gains.

Final Thoughts

I know, these ideas may sound alien to a lot of teams and organisations, but this is also why I’m unapologetically strict about trunk-based development, test-driven development, and team-focused development: I’ve seen them produce outstanding results — over and over again.

Someone will say, “But you need mature teams to do that!” We cannot buy mature teams. We need to build mature teams — and we build them starting from these principles.

Originally posted on LinkedIn.