Picture the scene. A new engineer joins your team. They look at the build pipeline and ask why integration tests run against three different databases. The answer comes back fast: "It's best practice."
They look at the code review process. Two approvals required, one from outside the team. Why? "Best practice."
They look at the on-call rotation. One week shifts, even though everyone agrees a week of broken sleep wrecks people. Why? "Best practice."
After three weeks they stop asking. They've learned the rule. Shut up, do the rituals, ship the work.
This is the moment your team died and nobody noticed.
"Best practice" is a thought-terminator
Two words. Four syllables. They end every conversation worth having.
The phrase tells you nothing about the problem you face. It tells you nothing about your codebase, your customers, your team's experience, or the tradeoffs the original author was wrestling with. It tells you one thing and one thing only... someone, somewhere, at some other company, did this thing, and it worked for them.
Possibly.
I've watched architects pull out reference architectures from companies a hundred times the size of the team they were advising. I've watched leads insist on full twelve-factor discipline for a side project running once a quarter. I've watched teams add three layers of abstraction because Robert Martin wrote a book in 2008.
None of it stops to ask the only question worth asking. Does this fit the work in front of us right now?
The cargo cult problem
Richard Feynman... a physicist, not a software guy, but stay with me... told a story about post-war Pacific islanders who'd seen US military planes land during World War II, drop supplies, then leave. The islanders wanted the supplies to come back. So they built bamboo runways, bamboo control towers, bamboo headphones. They lit signal fires.
The ritual was perfect. The form was perfect. The supplies never came.
Software has its own version. There's even a name for it: cargo cult programming. Copy the pattern without understanding why the pattern exists. Add the abstraction because the senior engineer at your last shop added one. Run standup at 9:15 because Atlassian's blog post said so.
Form perfect. Supplies never come.
The dirty secret of "best practice" is it's nearly always cargo cult thinking in a button-down shirt. Someone solved a real problem at a specific company at a specific scale with a specific team... and you copied the answer without copying the problem.
What the research says about trust
Here is what kills me about the "best practice" obsession. There is a decade of solid research telling us the one thing predicting whether a software team performs well... and it isn't the practices.
DORA, the research group behind the annual State of DevOps reports, has been studying tens of thousands of engineering teams for over ten years. Their finding is uncomfortable for anyone selling frameworks for a living: "a high-trust, generative culture predicts software delivery and organizational performance in technology".
Read it again.
Not microservices. Not trunk-based development. Not pair programming. Not whatever the latest McKinsey deck is selling. Trust.
The same DORA research found a culture of psychological safety predicts software delivery performance, organizational performance, and productivity. Translation... when people on your team feel safe to push back, ask dumb questions, admit they broke something, and disagree with the lead architect, your code ships faster and your customers get better software.
When they don't, no practice (best or otherwise) saves you.
What it looks like on the ground
Replace "best practice" with "we trust each other to think" and watch what happens.
The new engineer asks why three databases. Instead of "best practice" they get: "Two years ago we had a Postgres bug hit production because we only tested on MySQL in CI. We added the others. Honestly, we should drop one of them now... want to take a look?"
This is a different conversation. It tells the new person what the team has been through. It admits the practice has a shelf life. It hands them the problem instead of the answer.
Same with code review. "We need two approvals because a senior left six months ago and we're still rebuilding context." Honest answer. Also a temporary one. The practice serves a real need at a real point in time.
Compare with "it's best practice." This trains your team to stop thinking. Once they've stopped thinking, no leadership pep talk about innovation is going to start them up again.
The architect's job is not to bring the practices
I've been an architect. I've also worked with architects who were wrong about almost everything except one thing... they trusted their teams to figure it out together.
The bad architects show up with a binder. Reference architectures. Patterns. ADRs they wrote at the last place. They walk through the deck, point at the diagrams, and tell you which part of your system is broken.
The good architects show up with questions. What's slow? What breaks at 2am? What is the team scared to touch? What did the last big incident teach you? Which decisions feel locked in but shouldn't be?
The bad architect imports best practice. The good architect grows trust... and the practices fall out of the trust as a side effect.
You know which kind your engineers want.
You know which kind ships software.
What to do tomorrow morning
Three things.
One. When someone on your team says "it's best practice," push back gently. Ask: "Best practice for what specifically? What problem does it solve? What is the alternative we would be giving up?" Make the phrase do some work or kick it out of the conversation.
Two. Read the DORA research yourself. Not a summary. The actual reports. Read them with your team. Argue about them. The research isn't sacred, but it will change how you think about what "good" looks like.
Three. Ask your team... openly... whether they trust each other. Whether they trust you. Whether they feel safe pushing back when you say something wrong. Listen to the silence in the answer. The silence is the gap between the team you have and the team shipping great software.
I've written before about how trust isn't a vibe... it's a business model. The same idea applies here. Trust isn't soft. It is the highest-leverage technical decision you will make this year.
Next time you're tempted to invoke "best practice" to end an argument... try invoking trust to start one instead. See what your team builds when you give them the problem instead of the answer.
What's one practice on your team nobody is allowed to question? Start there.