The context trap. Netflix popularized microservices. Google invented Kubernetes. Amazon built their own everything. Spotify gave us the squad model.
These are real innovations from smart people solving real problems. They’re also almost certainly wrong for your organization.
I know that sounds harsh. Let me explain.
Netflix runs a global streaming platform serving hundreds of millions of users. Their engineering team is measured in thousands. When a monolithic architecture became a bottleneck to their ability to deploy independently and scale specific components, microservices made sense. For them.
If you’re running a 500-person manufacturing operation with a 15-person IT team, microservices will not give you Netflix’s agility. They’ll give you a distributed system you can’t staff, debug, or maintain. You’ll spend more time on service mesh configuration than on solving business problems.
Context matters. Scale matters. Talent density matters. The specific problems you’re trying to solve matter.
What works for a company in its specific situation may be entirely inappropriate for another. Every organization operates in a unique context shaped by its history, culture, resources, and market position. Ignoring these factors in favor of copying someone else’s playbook is a recipe for disappointment. Sometimes worse.
The counter argument I hear is: “But we should aspire to best practices.” Sure. But best practices aren’t universal. They’re contextual. The “best” practice is the one that solves your actual problem given your actual constraints. A perfectly executed strategy for someone else’s context is still the wrong strategy for yours.
Before you adopt any practice, tool, or org structure, map your context. What’s your scale? What’s your talent mix? What problems are you actually trying to solve? What resources do you actually have?
Then ask: Does this borrowed solution fit? Or are we building wooden airplanes hoping the cargo will come?