You Get Three Tokens
The rule is deceptively simple: You get approximately three "Innovation Tokens" to spend on your entire technology stack.
An Innovation Token represents your team's finite capacity to absorb the operational, cognitive, and organizational cost of technology that is not yet well-understood by the broader industry. The number three is not sacred — it is a heuristic. The point is that the number is small and fixed, regardless of how smart your team is.
Think of it like a moving budget. You can afford to hire specialists to move your grand piano (one expensive, complex item), but if you try to hire specialists for every piece of furniture in the house, you run out of money before the truck is loaded. The piano is worth the cost. The bookshelf is not.
Here is how the token economy works:
Boring Tech (Cost: 0 Tokens): Technology that is well-understood, widely deployed, and operationally stable. It has been in production at thousands of companies for years. Its failure modes are catalogued. Its edge cases are documented. Its ecosystem of tooling is mature.
| Category | Boring Examples |
|---|---|
| Database | PostgreSQL, MySQL, Redis |
| Language | Python, Java, Go, JavaScript/TypeScript |
| Web Server | Nginx, Apache |
| Hosting | AWS EC2, standard VMs, managed Kubernetes (EKS/GKE) |
| Queue | RabbitMQ, Amazon SQS |
| Monitoring | Prometheus, Grafana, Datadog |
Why boring tech costs zero tokens: if it breaks at 3 AM, you can paste the error message into a search engine and find 10,000 Stack Overflow answers. You can hire someone who already knows it. Your on-call engineer does not need to read the source code to debug it. Backup strategies, migration paths, and security hardening guides already exist.
Exciting Tech (Cost: 1 Token): Technology that is bleeding-edge, niche, or "best in class" for a narrow use case but operationally complex or immature.
| Category | Exciting Examples (context-dependent) |
|---|---|
| Database | CockroachDB, ScyllaDB, a custom graph database |
| Language | Rust (for a web team with no systems programming background), Elixir, Haskell |
| Infrastructure | Self-managed Kubernetes (for a 5-person startup), custom service mesh |
| Architecture | Event sourcing with CQRS, custom distributed consensus |
Why exciting tech costs a token: if it breaks, you are the community. You will read the source code to debug it. You will file the GitHub issue that becomes the documentation. Hiring experts is hard and expensive. The monitoring plugin does not exist yet — you will write it. The backup strategy is "we think this works, we haven't tested a restore."
The Strategic Principle:
Spend your tokens only on the thing that gives your business a competitive advantage — the thing that makes you you.
Consider these examples:
Company: Machine Learning startup doing real-time fraud detection
✅ Spend a token on: Custom GPU cluster orchestration (this IS the product)
✅ Spend a token on: A specialized streaming database for sub-millisecond queries
❌ Don't spend a token on: A trendy frontend framework (use React or Vue)
❌ Don't spend a token on: A custom deployment pipeline (use GitHub Actions)
Company: Online flower shop
✅ Spend a token on: Maybe a novel recommendation engine for bouquets
❌ Don't spend a token on: A graph database for inventory (use PostgreSQL)
❌ Don't spend a token on: Kubernetes for 200 requests/minute (use a PaaS)
❌ Don't spend a token on: Rust for the backend (use Django or Rails)
The key insight is that every token you spend on plumbing is a token you cannot spend on your product. If you blow all three tokens on your deployment pipeline, your message queue, and your programming language, you have zero capacity left to absorb complexity in the area that actually differentiates your business.
When asked "How do you evaluate new technology for a project?" in an interview, resist the urge to list technical criteria alone (performance benchmarks, feature comparisons). Start with: "First, I ask whether this is an area where we need to differentiate or an area where we need reliability. For commodity concerns, I default to boring, proven technology. I only accept the operational cost of novel technology in areas that directly create competitive advantage." Then discuss technical criteria. This signals strategic thinking, not just technical enthusiasm.
Key Point: The token count is not about the technology itself — it is about the gap between your team's current expertise and the technology's operational demands. PostgreSQL is "boring" for most teams, but if your entire team has only ever used MongoDB, PostgreSQL costs you a token too. Context matters. The question is always: "How much unknown operational complexity are we absorbing?" A technology graduates from "exciting" to "boring" as your team's expertise and the industry's collective knowledge both mature — which means token costs are not static. Reassess your stack annually.