Technical Decision-Making Without a CTO — Designing 'Who Decides What' with Just PMs and Engineers
When the unspoken assumption that “someone will make the call” breaks down, technical development at CTO-less startups grinds to a halt — or someone starts making unilateral decisions that compound into architectural choices that become impossible to unwind later.
CTO hiring is not the only solution. By designing technical decision-making as a structure, you can embed governance into the organization that functions even without a CTO. This article maps out the decision-making vacuum patterns that CTO-less startups typically fall into, and presents a minimum viable technical governance setup that PMs and engineers alone can operate.
The Technical Decision-Making Vacuum in CTO-Less Startups
The decision-making vacuum tends to appear in three recurring patterns.
Pattern 1: “I thought the other person was handling it”
PMs assume technical decisions belong to engineers. Engineers assume specifications are finalized by PMs. Non-functional requirements (performance, security, scalability) fall into no one’s jurisdiction and get left unaddressed. The problem is that non-functional requirements are precisely the decisions that determine whether a system remains sustainable.
Pattern 2: “The lead engineer decides everything”
One person is responsible not just for implementation decisions, but also for architecture, technology selection, and hiring criteria. This works short-term, but when that person leaves, the reasoning behind every decision disappears with them. A lead engineer in “decide everything” mode is also chronically overloaded, with a real risk of burnout.
Pattern 3: “Every decision starts from zero”
Similar judgments get re-debated in meetings every time. “Should this API be REST or GraphQL?” “Should this data live in the DB or the cache?” Without established criteria, discussions drag on until they finally converge. Worse, consistency breaks down, and looking back you find contradictory design choices coexisting.
What all three patterns share is the absence of a decision-making template. When a CTO is present, they naturally fill this role. Without one, the template needs to be provided by structure rather than by a person.
The Three-Layer Decision Model
The starting point for organizing technical decisions is distinguishing which layer a given decision belongs to.
| Layer | Focus | Examples | Frequency | Reversibility |
|---|---|---|---|---|
| Technology Strategy | ”Why this technical direction?” | Build vs. buy, platform selection, scaling approach | Quarterly to annual | Low (high change cost) |
| Architecture | ”How should this be designed?” | Database schema, service decomposition, API design patterns | Monthly to quarterly | Medium |
| Implementation | ”What exactly do we write?” | How to implement a function, which library to use | Daily to weekly | High (localized) |
These three layers differ significantly in scope of impact and reversibility. Implementation decisions are localized and easy to reverse. Architecture decisions affect months of development and carry high change costs. Technology strategy decisions touch the company’s business model — if you head in the wrong direction, recovery can take years.
For CTO-less startups, the most critical risk is the architecture layer going unowned. Engineers handle implementation daily, and CEOs or PMs engage with technology strategy through questions like “what do we want this product to become?” But the architecture layer sits between them, and for that very reason it tends to become hollow.
For a deeper look at architecture judgment and evaluation frameworks, see Architecture Patterns for Decision-Makers: Monolith, Microservices, and Serverless as Judgment Axes.
Who Decides What: Designing a Decision Ownership Map
The first step to closing the vacuum is making each layer’s decision owner explicit. Below is an example ownership map for a typical CTO-less startup (CEO + PM + Lead Engineer + a few engineers).
| Decision Type | Owner | Consult | Final Decision Method |
|---|---|---|---|
| Changing the core technology stack | CEO / PM | Lead Engineer | Consensus (all agree) |
| Architecture approach for new features | Lead Engineer | PM | Lead Engineer alone |
| Refactoring prioritization for existing features | Lead Engineer + PM | CEO | Written proposal → approval |
| Adopting a new external SaaS tool | PM + Lead Engineer | CEO | Branching by cost threshold |
| Daily implementation judgment | Assigned engineer | Lead Engineer | Assigned engineer alone |
| Infrastructure / security configuration changes | Lead Engineer | CEO | Slack notification before change → approval |
| Technical evaluation for new engineer hires | Lead Engineer | PM / CEO | Lead Engineer alone (final hire/no-hire is CEO) |
Two principles matter when designing this map.
Principle 1: Separate “owner” from “final decision method”
The owner is “the person accountable for this judgment,” which does not mean they always decide alone. Using a combination of consensus, proposal-then-approval, and solo decision-making lets you balance speed and quality. The higher the importance and lower the reversibility, the more a decision should move toward consensus; the more routine and reversible, the more it should lean toward solo decision.
Principle 2: Build in objective criteria like cost thresholds
“Adopting an external SaaS is a PM + Lead Engineer call, but anything over ¥100K/month requires CEO approval” — branching the decision path by a number prevents delays. It also automates the “who should I ask?” question.
Lightweight Technical Governance: ADRs, Tech Standups, and Escalation Criteria
An ownership map alone is not enough. Actual operation requires records, regular review, and escalation rules.
ADRs (Architecture Decision Records)
An ADR is a one-page document capturing the context, options considered, decision, rationale, and tradeoffs for a technical choice. The minimum format requires five fields:
- Context: What needed to be decided
- Options: What was considered and the pros/cons of each
- Decision: What was chosen
- Rationale: Why that option was chosen
- Consequences: The tradeoffs this decision introduces
ADRs can simply be saved as Markdown files in your GitHub repository (e.g., docs/adr/001-database-selection.md). The key is preserving the “why” behind each decision, so that anyone looking back can immediately answer “why was this chosen?”
In CTO-less teams, the reasoning behind decisions tends to live in individuals’ memories. ADRs convert that into organizational memory. If the lead engineer leaves without ADRs in place, all the assumptions underlying your design leave with them.
Tech Standups
Establish a 30–60 minute technical standup — weekly or biweekly — centered on the lead engineer. Limit the agenda to these three items:
- Share ongoing technical blockers (catch problems early)
- Pre-align on upcoming design decisions (prevent rework)
- Create or review ADRs (maintain decision records)
It is important that PMs attend. Keeping technical discussions within the engineering team makes it easy for business requirements and technical judgment to diverge. When PMs are in the room, “this technical constraint affects that feature’s schedule” gets translated in real time.
Keep the standup to 30 minutes by sharing the agenda in advance. The psychological overhead of “this is going to turn into another long argument” is what kills recurring meetings.
Escalation Criteria
Define explicitly who escalates to whom and under what circumstances. The following are criteria that work well in practice.
Engineer → Lead Engineer
- Stuck on a design decision for more than 2 hours
- Multiple technical options have surfaced and a comparative evaluation is needed
- A design change appears likely to affect other components
Lead Engineer → PM / CEO
- A change in technical direction requires a business judgment call (e.g., changing the level of dependency on an external API)
- The team’s workload has become unsustainable
- Considering outsourcing or tool procurement
- A security or compliance risk has been discovered
The “escalate after 2 hours of struggling” criterion looks simple, but without it, the psychology of “I don’t want to bother anyone” takes over, and engineers bottle things up. Making the criteria explicit reframes escalation from “something people do when they can’t handle it” to “following the right process.”
When to Bring in Outside Help
Even with this governance in place, there are situations where trying to handle everything internally is the wrong approach.
When a fundamental platform redesign is needed (migrating from monolith to microservices, switching cloud providers, etc.), experienced outside perspective is essential. A wrong call can consume months of engineering resources.
When security compliance must be achieved (data privacy regulations, SOC 2, PCI-DSS, etc.), you need someone with specialized compliance expertise. “It’s probably fine” has a way of becoming a serious problem when auditors show up.
When CTO-level technology strategy decisions are needed repeatedly (major technical partnerships, critical hiring decisions, due diligence for an M&A process) it makes rational sense to engage a technical advisor or external consultant.
Specific options for supplementing technical capability without hiring a CTO — including how to choose between a technical advisor, fractional CTO, outsourcing, and in-house hiring — will be covered in a follow-up article.
Conclusion: Technical Decision-Making Architecture Is Never Finished
The ownership map, ADRs, tech standups, and escalation criteria described here are simple mechanisms. But the difference between designing them from scratch with intention and running them on autopilot has an outsized impact on the organization.
As a startup’s phase changes, the scope and depth of technical decision-making changes with it. Architecture judgment looks different before and after product-market fit. Revisiting the ownership map and ADRs regularly is what preserves long-term technical health.
For guidance on when to make a CTO hire, see When and How Startups Should Hire a CTO. For a catalog of technology risks that tend to surface after investment in CTO-less organizations, see 10 Technology Risks That Emerge After Investment.
Tied Inc. offers technical governance design support for CTO-less startups, along with ongoing technical advisory tailored to each growth stage. Feel free to reach out.