The Core Competency Test
Engineers love building things. It's intellectually satisfying to create something from scratch. But Staff engineers know that code is a liability, not an asset. Every line of code you write must be tested, debugged, documented, and maintained — potentially forever. The question is never "Can we build this?" (you almost always can). The question is "Should we?"
The "Innovation Token" Theory:
Coined by Dan McKinley in his essay "Choose Boring Technology," the idea is that every engineering organization has a limited budget of complexity it can absorb. Spend it wisely.
You only get 3 Innovation Tokens for any project:
- Running PostgreSQL for your database? 0 tokens. It's boring, proven, and well-understood.
- Using Kafka for your message queue? 1 token. It's powerful but operationally complex.
- Writing your own distributed consensus algorithm? 3 tokens. You just spent your entire budget on one decision.
The point is not that novel technology is bad. It's that every non-standard choice adds operational burden, hiring difficulty, and cognitive load to your team. Spend those tokens on the things that are genuinely core to your competitive advantage.
The Decision Matrix:
When evaluating build vs. buy, work through these questions in order:
- Is this our core business? Uber builds its own matching engine — that algorithm is the product. Uber buys its payroll software. Never build what you can buy for the things that aren't your competitive differentiator.
- Does a commodity solution exist? Don't build a real-time chat system; use Stream or Sendbird. Don't build an authentication system; use Auth0 or Cognito. The commodity solution has been battle-tested by thousands of companies.
- What is the Total Cost of Ownership (TCO)? Building feels "free" because you're paying with engineering time, not a credit card. But a custom-built solution costs: initial development (weeks to months), ongoing maintenance (bugs, security patches, upgrades), documentation, onboarding new engineers, and the opportunity cost of everything else those engineers didn't build. A $50k/year SaaS contract often beats a "free" internal tool when you account for TCO honestly.
- What is the vendor risk? Buying creates dependency. If the vendor raises prices 10x or shuts down, you're stuck. For truly critical infrastructure, owning the code may be worth the cost.
A classic Staff-level interview question is: "Would you build or buy a search feature for your e-commerce platform?" The trap is answering based on technical preference. The correct framework: "It depends on search volume, query complexity, and team expertise. For most companies, Elasticsearch or Algolia is the right answer — they've solved relevance ranking, typo tolerance, and scaling problems that would take a team months to rebuild. The only reason to build custom search is if your query patterns are so domain-specific that no existing solution fits — which is rare." This answer demonstrates business judgment, not just technical knowledge.