PM and engineer responsibility split: drawing the requirements-versus-engineering line without a CTO
The most overlooked organizational issue in a CTO-less startup is not “decision-making structure” but “role boundaries.” Technical decision-making at CTO-less startups covered mechanisms like decision-owner maps and ADRs (architecture decision records), but even well-designed mechanisms fail if the PM and engineers don’t agree on where their own turf ends. This piece drops one level below that decision-making structure to focus on the finer-grained question: what, exactly, does a PM own versus what does an engineer own?
Where responsibility gets dropped or fought over
In teams with a CTO, the CTO acts as a buffer between business requirements and engineering execution. Without one, the PM and engineers face each other directly, and three patterns emerge repeatedly.
Pattern 1: Blame-shifting
When performance degrades or bugs pile up, the PM tends to frame it as “an engineering quality problem,” while engineers frame it as “requirements were vague, so we had constant rework.” Both framings are partially true, so responsibility stays undefined and only the conflict remains.
Pattern 2: The gap nobody owns
Non-functional requirements — security posture, performance targets, error-handling policy — don’t attach to any specific feature request, so they look like they belong to both the PM and engineering, and neither raises a hand. The gap only becomes visible once an incident happens.
Pattern 3: Normalized overreach
The PM starts dictating API implementation details or database schema, or engineers end up deciding feature priority and business impact on their own. Decisions look fast in the short term, but mismatched expertise leads to accumulating judgment errors.
All three patterns share a root cause: two different kinds of judgment — “what/why” and “how” — get mixed into the same conversation with no clear line between them.
The requirements (what/why) vs. engineering judgment (how) boundary
The starting point for making role division actually work is separating decisions into two layers.
| Layer | Content | Primary owner | Typical question |
|---|---|---|---|
| Requirements (what/why) | What to build, and why it matters now | PM | ”What user problem does this solve?” “Why does this need to happen now?” |
| Engineering judgment (how) | How to build it, and what trade-offs to accept | Engineer | ”What data structure fits?” “Synchronous or async?” |
This split isn’t novel — it’s a standard product management principle. What breaks it in practice isn’t ignorance of the principle; it’s that some decisions genuinely sit on the boundary. Three types of decisions blur the line most often.
Boundary case 1: Non-functional requirements
“Response time under two seconds” or “handle 1,000 concurrent users” are business requirements (why) whose implementation is entirely an engineering judgment (how). If a PM says “make it faster” without a number, the engineer has no way to know what to prioritize.
Boundary case 2: Tech debt repayment
“Should we refactor this code?” looks like a pure engineering (how) question, but time spent refactoring is time taken from new feature work — which makes it, in effect, a business priority (what) decision.
Boundary case 3: Phased implementation strategy
“Ship a minimal version now, replace it with a proper implementation later” spans both a business speed requirement (why) and technical feasibility (how).
The fix is not to force each boundary-case decision into one camp’s exclusive jurisdiction. Instead, both sides bring their own numbers and criteria to the table and reach agreement together — that’s what prevents both overreach and the ownerless gap. The next section applies this to prioritizing non-functional requirements and tech debt repayment specifically.
Who prioritizes non-functional requirements and tech debt repayment
The most frequent source of friction on boundary decisions is prioritizing non-functional requirements and tech debt. The principle here is not “one side decides” but the PM states the business constraint in numbers, the engineer states the engineering estimate in numbers, and priority gets set at the intersection.
In practice, that runs as a three-step process:
- The PM articulates business impact: ask the engineer “if we leave this refactor for another month, how much longer does the lead time for new features get?” and translate the answer into business terms — velocity, incident frequency, customer impact.
- The engineer provides a technical estimate: effort required to pay down the debt, probability of an incident if it’s left alone, and blast radius.
- Both sides score priority against a shared formula: something as simple as “business impact × probability ÷ effort” lets the item sit in the same backlog as feature work, compared on equal footing.
The key point of this process is that tech debt repayment doesn’t get quarantined as “an engineering-only concern” — it gets prioritized on the same footing as the business backlog. Quarantine it, and repayment always loses to new feature work. For the concrete risk patterns tech debt creates at startups, see What tech debt actually is, and how it shows up at startups.
The same logic applies to non-functional requirements. Instead of “make it faster,” a PM bringing a concrete number — “get the main screen’s first paint under two seconds” — lets engineers narrow down implementation options. Without a number, an engineer handed a vague mandate has no way to judge “how much is enough,” and tends to swing toward over-engineering or under-delivering.
Making PM–engineer collaboration actually work day to day
Understanding the principle doesn’t help if there’s no operational mechanism behind it. Three mechanisms tend to hold up in practice.
A shared vocabulary
Build a reference mapping business-impact metrics (conversion rate, churn, support ticket volume) to engineering metrics (response time, error rate, deployment frequency), so PMs and engineers can talk in the same terms. This lowers the translation cost of turning “this matters technically” into language a PM can act on.
Naming the type of discussion in every meeting
At the start of each planning session or sprint review, state upfront whether an agenda item is a “what/why discussion” or a “how discussion.” That single habit prevents a PM from drifting into implementation details, and prevents engineers from drifting into business-priority calls that aren’t theirs to make alone.
Sharing a decision log
Boundary decisions — non-functional targets, tech debt priority calls — should be recorded somewhere retrievable. Without a record, the same debate resurfaces every few months, with both sides misremembering what was actually agreed.
These mechanisms compound with the technical standups and ADR practice covered in Technical decision-making at CTO-less startups — pairing the decision-making “structure” with this role-division “granularity” is what makes both hold up in practice.
Anti-patterns: the PM who delegates everything, and the engineer who disconnects from the business
Teams that fail to design this boundary well tend to fall into one of two opposite failure modes.
Anti-pattern 1: The PM delegates everything technical
“I’ll leave the technical stuff to engineering” sounds like trust, but in practice it withholds the business-side inputs — non-functional targets, tech debt priority — that only a PM can supply, while abdicating the decision itself. Engineers end up making technical calls with no visibility into business impact, so priority ends up set purely by engineering judgment. When a PM later asks “why did we refactor before shipping this feature,” the answer is usually this kind of delegation.
Anti-pattern 2: The engineer disconnects from the business
The mirror image is an engineer who settles into “I just implement what I’m told” and stops raising non-functional risks or architectural concerns with the PM. Without visibility into business KPIs or usage patterns, engineers can end up spending time on optimizations that are technically sound but commercially unnecessary. How well an engineering org stays connected to the business overlaps with the evaluation axes covered in How to evaluate the health of an engineering organization.
The fix for both anti-patterns is the same: stop treating boundary decisions as something to hand off to the other side, and start treating them as something both sides bring inputs to and jointly resolve. Both delegation and disconnection ultimately come from the same instinct — staying out of the other person’s territory. But because boundary decisions were never anyone’s exclusive jurisdiction to begin with, that instinct needs to give way to genuine collaboration, which is as much an organizational design question as an individual mindset one.
The AI-era shift: as AI absorbs more of “how,” engineers move closer to “what”
Everything above assumes “the PM owns what/why, the engineer owns how.” That assumption is itself starting to move as code-generation AI and AI coding agents become production-usable.
A meaningful share of implementation work — boilerplate CRUD generation, test-code authoring, refactoring that follows an established pattern — can already be delegated to AI. What that shift means isn’t just “development gets faster.” It means the center of gravity in the engineer’s role moves from “can implement this correctly” to “can judge what to have built, and how to verify and integrate what AI produces.” In effect, the engineer’s turf takes a step from the how side toward the what side.
The opportunity this creates for PMs and PdMs is concrete. Historically, PMs had to scale back feature requests out of concern for implementation cost or technical feasibility, and spend time reconciling implementation details with engineers. Once engineers also participate in what-side judgment — “which feature actually solves this user problem,” “does this AI-generated implementation meet the business requirement” — PMs and PdMs are freed from implementation detail and can more easily build an environment where they concentrate resources on why: why this should be done at all, and what the business impact is. This isn’t so much “the PM gives up how” as it is “the organization redesigns the engineer’s turf toward what, so PMs and PdMs can concentrate on why.”
Two caveats matter here. First, AI can absorb only part of how, not all of it. Decisions with a large blast radius and high reversal cost — architecture calls, non-functional trade-offs, security and data-integrity judgment — still require engineering expertise. If anything, the “meta-how” skill of evaluating whether AI-generated code is sound becomes more important, not less. For how to evaluate the quality and tech-debt risk of AI-generated implementations, see Tech debt risk from AI-driven development: an evaluation framework for investors and DD teams.
Second, this shift doesn’t happen without organizational scaffolding. It requires redesigning evaluation criteria — shifting how engineers are assessed from “implementation speed” to “judgment and the ability to vet AI output,” and shifting how PMs/PdMs are developed from “understanding implementation” toward “resolution on business impact.” Without that scaffolding, “engineers and PMs doing the same thing” just makes accountability blurrier, and the blame-shifting pattern from the opening of this piece resurfaces in a new form. The boundary line itself isn’t fixed — it needs to be operated as something that keeps moving with what AI can actually do.
The boundary isn’t drawn once — it’s operated continuously
The PM–engineer responsibility split isn’t something you settle with a single clean line. Non-functional requirements and tech debt priority are boundary-case decisions by nature, requiring ongoing joint agreement rather than a one-time jurisdiction call, and AI’s advancing capability means the how side itself keeps shifting hands. What matters is agreeing upfront that boundary decisions get handled jointly — so that when overreach or delegation happens, the conversation isn’t “whose call was this,” but “let’s apply the process we already agreed on.”
If a CTO-less team is struggling to design this role split on its own, When should a startup hire a CTO covers how to judge the right timing for that hire. An external technical advisor working through this role-design process alongside the team is another option. Tied Inc.’s startup advisory services support everything from this kind of organizational design to ongoing technical advisory, and inquiries are welcome via our contact page.