Pouring Concrete
A Type 1 decision is like pouring a concrete foundation for a building. Once the concrete sets, you cannot un-pour it. You can build on top of it, patch it, or demolish it at enormous cost — but you cannot simply go back to the state before you poured. The structure of everything above depends on what you committed to below.
In engineering, Type 1 decisions are the ones that shape your system's architecture, your team's capabilities, and your company's trajectory for years. They are not inherently bad — every system requires foundational choices. The danger is making them hastily, without understanding that you're walking through a one-way door.
Characteristics of Type 1 Decisions:
| Property | Description |
|---|---|
| Reversal Cost | Extremely high. Requires re-architecture, data migration, contract renegotiation, or retraining an entire team. |
| Blast Radius | Large. Affects the entire platform, all customers, or the company's strategic direction. |
| Information Asymmetry | Lower than you'd like. You often can't fully test the decision before committing. |
| Time Sensitivity | Usually lower. Taking an extra week to decide correctly saves months of rework. |
Concrete Engineering Examples:
- Choosing the primary cloud provider (AWS vs. GCP vs. Azure) — once your infrastructure, IAM policies, networking, and dozens of managed services are built on AWS, migrating to GCP is a multi-year, multi-million-dollar effort. Every service you add deepens the lock-in.
- Selecting the core programming language for your backend — choosing Go means hiring Go developers, building Go tooling, training in Go idioms. Switching to Rust two years later means rewriting hundreds of thousands of lines of code and rebuilding your entire hiring pipeline.
- Deprecating a public API endpoint used by external customers — once customers have built integrations against your API, removing an endpoint breaks their systems. You've made a public contract. Breaking it destroys trust and may violate SLAs (Service Level Agreements — contractual promises about availability and behavior).
- Changing the fundamental data model of your core database — migrating from a relational schema to a document model (or vice versa) when you have terabytes of production data and hundreds of queries depending on the current structure is a months-long project with significant risk of data loss or corruption.
- Choosing a multi-year enterprise contract with a vendor — a 3-year commitment to a specific observability platform means your dashboards, alerts, runbooks, and on-call workflows all depend on that vendor's query language and data model.
Strategy: Deliberate and Document
Type 1 decisions deserve structured processes. This means:
- Write an RFC (Request for Comments) or ADR (Architectural Decision Record) — a document that states the problem, lists the options considered, explains the trade-offs, and records the final decision with its rationale. The act of writing forces clarity that verbal discussion rarely achieves.
- Seek diverse input — involve people who will live with the consequences. A database choice affects backend engineers, SREs, data engineers, and finance (cloud costs). All should have input.
- Set a decision deadline — deliberation is valuable, but unbounded deliberation is its own form of paralysis. Set a date: "We will decide by Friday. All input must be submitted by Thursday."
- Accept imperfect information — you will never have 100% certainty. The goal is to reach ~70-80% confidence and then commit. Waiting for certainty on a Type 1 decision is just as dangerous as rushing it.
Key Point: The subtlety that separates senior engineers from mid-level ones is recognizing that some decisions look like Type 1 but are actually Type 2 in disguise. "Choosing a database" sounds irreversible, but if you're building a new microservice with 10 users and no production data yet, switching databases next month costs almost nothing. Context determines the type, not the category of technology. Always ask: "Given our specific situation right now, how hard would it be to reverse this?"