The less obvious: operating principles for high-performance teams

There is no shortage of advice on how to run a technology team. Hire smart people. Communicate well. Build the right thing. Ship frequently. These are the foundations, and they’re well understood.

But here’s what I’ve noticed over thirty years of building and leading technology organisations: the teams that truly excel aren’t just doing the basics well. They’ve figured out the less obvious stuff. The operating principles that don’t appear in blog posts about “how Google does it” or “the Netflix culture deck.” The quiet decisions about structure, flexibility, and discipline that separate a team that delivers from a team that merely functions.

The problem with best practice

There is a lot of good information online about how to run engineering teams. The trouble is, most of it comes from organisations with thousands of engineers, effectively unlimited budgets, and problems that bear very little resemblance to yours. What works at Google, with its army of SREs and custom-built infrastructure, is probably not the best fit for your team of fifteen engineers at a PE-backed growth company trying to hit next quarter’s targets.

And yet, time after time, I see CTOs and engineering leaders importing practices wholesale from these very large scale companies, then wondering why their teams grind to a halt under the weight of process. The intent is sound. The fit is wrong.

The principles that matter at the 5-to-100 person scale are different. Not because the big companies are wrong, but because context is everything.

Rules, flexibility, and knowing the difference

One of the questions I get asked most often is: where should we be rigid and where should we be flexible?

It’s a good question, and the honest answer is that it depends. But not in a vague, unhelpful way. There are areas where hard and fast rules genuinely protect you. Security practices. Deployment safeguards. Incident response protocols. These benefit from consistency and discipline. You don’t want creative interpretation when production is on fire.

But there are other areas where rigid rules do more harm than good. How teams organise their work. How they estimate. How they structure their day. How they measure progress. These need guardrails, not handcuffs. A principle that says “we review every deployment” is rigid for good reason. A principle that says “every team must run two-week sprints with a Wednesday planning session” is rigid for no reason at all.

The skill is knowing which category you’re in. And being honest when something you’ve treated as a hard rule is actually just a habit.

21 principles from the real world

Over the course of my career, working across multiple organisations of varying sizes, sectors, and stages of maturity, I’ve distilled what I’ve seen work into a set of 21 operating principles. These aren’t theoretical. They’re born from extensive experience of what has actually moved the needle in real teams, building real products, under real commercial pressure.

Some of these principles will feel familiar. Others might challenge assumptions you didn’t know you had. That’s rather the point.

The cheatsheet

I’ve published the full set as a single-page reference: 21 Operating Principles for High-Performance Teams. It’s designed to be practical, scannable, and useful whether you’re a CEO trying to understand why your tech team isn’t delivering, or a senior engineer wondering why good people and good intentions aren’t translating into good outcomes.

Have a read. Disagree with a few. But try applying the ones that resonate, and see what changes.