Part 1 asked why systems engineering, the work every downstream decision inherits, is so often the last thing funded. I deferred the answer on purpose, because the usual explanations are easy to argue about and hard to act on.
Four posts later, the diagnosis is on the table. The work at the top of the V is a graph of decisions across role handoffs. Rationale can only be captured while the work is happening. Each lap around the V needs what the previous laps recorded. Retrofitting rebuilds links between artifacts that survive and cannot rebuild reasoning that never became an artifact.
Here's the part that should bother anyone in this field: none of this is new, it has been known since the 1970s.
So the question stands, and it deserves a better answer than "startups move fast."
The forcing functions
Look at the five roles from Part 2 again, but ask a different question of each one. Not what they own, but what makes a company hire for the role?
Product Manager. Customers. The moment there is someone paying for the thing, somebody has to own what the product means to the customer. If nobody does, sales promises things engineering hasn't built, and that failure is loud and immediate.
Component Owner. The prototype. You cannot build a complex system without someone designing its components. This role is forced into existence by the product itself.
Systems Test Engineer. The build. Once something integrated exists, somebody tests it. The prototype not working is in itself the forcing function.
Compliance / Homologation Engineer. The regulator, or the customer's procurement process. A certification deadline is somebody else's clock, and missing it stops shipment. As direct as forcing functions get.
Systems Engineer. Nothing.
That's the answer. There is no event whose occurrence requires a systems engineer to exist. The symptoms of not having one are all delayed and attributed elsewhere: silent requirement drift, interface assumptions that don't match, unrecoverable rationale, traceability with holes.
When the first integrated build has an interface mismatch, the retrospective says the two teams should have communicated better. When a trade study gets re-run because nobody remembers why the first answer was the first answer, that's filed as wasted effort, not as a missing discipline. When the compliance scramble happens, it's blamed on the regulator's timeline.
Every one of those is a systems engineering failure, and none of them announces itself as one. SE is the only role on the V whose absence is exclusively visible through failure of other roles.
That's a much more uncomfortable answer than "we didn't have budget," because it means the feedback loop that would tell a team to hire a systems engineer is broken by construction. You can't learn this lesson from your own dashboard.
The reasons that are also true
Three conventional explanations are real, and each is more tractable once you see the forcing-function problem underneath.
Funding pressure. An early-stage company building a complex system is buying evidence that the thing can be built at all. Against that, a systems engineer looks like overhead: a hire who produces no component, no test and no demo. The honest version of this objection isn't "we can't afford rigor," it's "we can't afford a role whose output we can't see." Fair. The response isn't to hire a systems engineer on day one; it's to notice that the work is happening anyway, badly, and to decide who owns it.
Speed versus rigor, as a false binary. The framing assumes rigor is a tax on velocity. On one lap, it roughly is. Across four laps, it inverts, which is what Part 3 was about. Most teams never see the inversion because they're reasoning about the sprint in front of them, and there's nothing irrational about that. It's a horizon mismatch.
Tooling built for someone else. This one I have no sympathy for the industry about. The established requirements tools were built for large OEMs with dedicated process organizations. They're priced for those organizations, take months to deploy, and assume a process maturity the buyer is supposed to already have. A forty-person startup evaluating them concludes, correctly, that the tool is not for them. Then it concludes, incorrectly, that the discipline isn't either. The tooling has been standing in for the discipline, and when the tooling doesn't fit, the discipline gets dropped with it.
What early SE actually means
The usual objection to all of this is "we're not going to write a 400-page specification before the first prototype." Nobody's asking you to. That isn't the argument, and it never was.
The minimum viable top of the V is small:
- Stakeholder needs and concerns, written down.
- Requirements with IDs and owners, even if there are only forty of them.
- An architecture sketch that names its interfaces.
- Links captured as the work happens, rather than rebuilt before an audit.
- Decisions recorded with the alternatives that lost, and why.
That's it. Nothing on that list requires a dedicated hire on day one, a heavyweight tool, or a process organization. Every item is work the team is already doing implicitly. The difference is whether the result is kept.
The last item is the one I'd defend hardest, because it's the one with the asymmetric cost. A paragraph at the moment of decision, versus impossible a year later. If a team takes one thing from this series, it should be that.
Who actually decides this
In my experience the deciding factor isn't process maturity or company size. It's whether anybody holds the horizon.
Most roles on a complex-systems program are correctly optimizing for the next milestone. Systems engineering is the role that optimizes for the fourth lap, and until someone is explicitly accountable for that, the fourth lap has no advocate in the room where the roadmap is set.
The only person who can play that role early is a founder, because they're the only one whose time horizon is the company's rather than the sprint's.
So the answer to the title question: systems engineering ends up at the end of the roadmap because nothing forces it to the front, its absence is invisible until it's expensive, and the tooling that claims the category has priced and scoped itself out of the market that needs it earliest.
The first two are structural. The third one is a choice somebody made, and it can be unmade.
The series
- Part 1: Systems engineering happens at the top of the V. So why is it always the last thing funded?
- Part 2: What early systems engineering actually buys you.
- Part 3: The compounding cost of deferred systems engineering.
- Part 4: Why "add SE later" is a graph problem, not a process problem.
- Part 5: This one.
The question I asked in Part 1 still stands, and I'd still like the answers: when did systems engineering actually arrive on your program, and what forced it?
Srivardhan Chandrapati is the founder of SysenAI. He spent about twelve years in systems engineering and functional safety across advanced mobility and energy, at Cummins, Rivian, EnerDel, Fisker and BorgWarner, and now builds from Bengaluru.
The sources cited across this series are listed in full in Parts 1 to 4.