"Okay, But Our Team Is Different"

The Universal Snowflake

When writing this piece, I'm on my long-awaited vacation. Instead of my regular format, I wanted to try something new—a short essay on one of the subjects that bugs me in engineering management.

Let me know if you like this form. I have more of these pieces on my shelf.

---

Every engineering team is a beautiful, unique snowflake. Just ask them.

"Continuous delivery sounds great, but our compliance requirements..."
"DORA metrics don't apply because our domain is..."
"Shift-left testing won't work since our legacy system..."
"Data-driven culture? Well, our stakeholders prefer..."

I heard all variations of these hundreds of times.

The phrase "our team is different" has become the engineering equivalent of "it's not you, it's me"—a polite way of saying "we're not ready to change, but we'd rather blame circumstances than admit it."

The Psychology of Special

Why do smart engineers consistently believe their situation is uniquely insurmountable? It's easier to be a victim of circumstances than an agent of change.

Admitting your practices could improve means acknowledging you've been doing things suboptimal lying. It's psychologically safer to externalize the problem.

This mindset is often reinforced by confirmation bias, where teams selectively focus on evidence supporting their belief in uniqueness, and loss aversion, which makes the potential pain of change feel disproportionately greater than the benefits of improvement.

“We cannot write unit/functional tests. We would need to mock tens of dependent services”.

The Legacy Thinking

What if your team isn't actually as special as you think?

Maybe your legacy code isn't the problem—maybe the real legacy is how your team thinks about its uniqueness. Perhaps the "special challenges" are less about technology and more about mindset.

Imagine, for a moment, a world where your team isn't exceptional.

Your "unique" challenge of old architecture? Everyone has tech debt.

Your struggles with convincing stakeholders? Everyone has stakeholders who think "agile" means "faster waterfall".

Your "end-stage" testing? Every QA team once believed they were guardians at the gate, rather than co-drivers.

Suddenly, it's liberating. Because if your team isn't special, then maybe those industry best practices aren't unreachable ideals—they're actually just proven strategies waiting for you to swallow your pride and adapt them to your context.

What If

Instead of defending why you can't adopt proven practices, try asking different questions:

• If you found out a team with your exact constraints was doing continuous delivery, would you assume they're lying, lucky, or just... started?

• What if your "unique constraints" are actually shared by dozens of other teams who've solved them? How would you find out?

• If your current practices are so well-suited to your special circumstances, why aren't other teams copying you?

• What if the reason "best practices don't apply" is that you're solving the wrong problems?

These questions hurt because they force you to confront an uncomfortable possibility.

Your Choice

Every time you say "our team is different," you're making a choice. You're choosing the comfort of the status quo over the discomfort of change. You're choosing to be special rather than effective.

While you're protecting your uniqueness, other teams are building competitive advantages by adopting practices that work. They're shipping faster, failing cheaper, learning quicker, and sleeping better.

Don't Try to be Unique

What if you spent less energy defending the uniqueness of your problems and more energy experimenting—even recklessly—with these annoyingly effective practices?

What if you stopped asking "Why won't this work for us?" and started asking "What would we have to change to make this work?" The first question is a dead end. The second is a roadmap.

Maybe, just maybe, your team isn't as special as you think—and that could be the best news you've heard all year.