When Should a Hardware Company Hire Its First Dedicated Systems Engineer?
The question, submitted by a CTO at a 30-person hardware startup:
“We have 30 engineers — firmware, mechanical, electrical, a couple of software folks. Things are getting complicated. Integration is taking longer than it used to. We missed an interface spec last sprint and it cost us two weeks. Do we need a systems engineer? Or are we just bad at communication?”
You’re probably not bad at communication. You’ve outgrown the coordination structure that worked when you had 10 people. Those are different problems with different solutions, and conflating them leads either to an expensive hire that solves nothing or another year of accumulated technical debt while you wait for a “real” systems engineer to justify the headcount.
Here is a direct answer.
What Systems Engineering Actually Is at a Small Company
At a large aerospace or defense prime, “systems engineering” means a department, a process framework (often MIL-STD-882 or INCOSE-derived), a requirements management database, and a team of people whose job is to ensure the system-level view stays coherent as hundreds of engineers work in parallel.
At a 30-person hardware startup, none of that exists — and most of it shouldn’t yet. But the underlying need that systems engineering addresses is the same regardless of company size: someone has to own the model of how the whole system fits together, and that model has to be legible to everyone building parts of it.
At your scale, systems engineering is four specific practices:
1. Requirements decomposition. Customer or product requirements get broken down into engineering requirements that individual subsystems can actually implement and verify. Without this, firmware writes to one spec and mechanical designs to another, and both are technically “correct” and functionally incompatible.
2. Interface definition and control. Every boundary between subsystems — electrical, mechanical, thermal, software, protocol — gets explicitly defined, documented, and change-controlled. Not in someone’s head. Not in a Slack thread. Somewhere findable.
3. Verification traceability. Every requirement has at least one test that confirms it’s met. That connection is written down. When a requirement changes, someone knows which tests to re-run.
4. Failure and risk tracking at the system level. Someone is asking “what happens if this subsystem underperforms?” across the whole product, not just within each discipline.
If your team is doing these four things — even informally, even in spreadsheets — you are doing systems engineering. The question isn’t whether you need a systems engineer. The question is whether your current approach to these four practices is still working.
The Signals That Tell You It’s Broken
The interface mismatch that cost you two weeks is not the cause of your problem. It’s a symptom. Here are the patterns that indicate informal coordination has structurally broken down:
Interface mismatches at integration. When two subsystems built by competent engineers don’t fit together — electrically, mechanically, in terms of data format or timing — the root cause is almost always an interface that was assumed rather than specified. One person remembered a conversation differently. A spec changed and the downstream team wasn’t notified. At 10 people, you can recover from this with a stand-up. At 30, you can’t.
Requirements that live only in someone’s memory or email thread. If the answer to “what does this subsystem need to do?” requires finding a specific person and asking them, your requirements are not actually documented. They’re tribal knowledge. When that person is out, on another project, or has left the company, you have a gap. More immediately: when a customer asks for a requirements trace for their audit, you don’t have one.
Test cases that aren’t connected to requirements. Your test engineers are writing tests. Your systems team is updating requirements. Nobody has checked whether the two are actually aligned. This means you can pass all your tests and still ship something that doesn’t meet spec — because the tests weren’t written to the spec, they were written to someone’s interpretation of what they thought the spec meant last quarter.
Integration is the first time subsystems meet. If the firmware team and the hardware team are each building to their own internal specs and the first real integration happens late in the program, you will pay at integration for every interface assumption that went undiscussed. The cost compounds with each additional subsystem.
Nobody can answer “what changed and what does that break?” When a requirement changes — because the customer asked, because physics intervened, because someone realized the original spec was wrong — someone needs to trace that change through the system: which designs depend on this requirement? Which tests verify it? Which interfaces does it affect? If the answer is “we’d have to ask around,” your change management process has become a manual research project.
If you recognize more than two of these patterns, your team has outgrown informal coordination. That’s the diagnosis.
Dedicated Hire vs. Adopted Practices: How to Decide
This is where a lot of CTOs make the wrong call in both directions.
When you need practices, not a person: If your team is willing to adopt structured requirements management, interface control, and traceability — and someone currently on the team has the capacity to drive that adoption — you may not need a dedicated hire yet. What you need is a shared system for capturing and maintaining the information that currently lives in people’s heads. A practices-first approach can work if the engineering leads are bought in and the tooling is genuinely usable.
When you need a dedicated hire: A dedicated systems engineer is warranted when the complexity is structural — when there are enough concurrent subsystems, enough external interfaces, and enough customer-facing requirements that no currently-employed engineer has both the mandate and the bandwidth to own the system-level view. Practically, this usually happens somewhere between 25 and 50 engineers, depending on product complexity. The aerospace-adjacent rule of thumb is roughly one systems engineer per 10-15 discipline engineers on a complex hardware product, but this varies significantly.
The more honest signal: if your best systems-level thinker on the team is spending more than 30% of their time on cross-functional coordination and integration debugging, you are already consuming the equivalent of a dedicated systems engineer — just at a much higher cost per hour, because you’re pulling it from your highest-leverage technical contributors.
The other hiring signal is external pressure. If a Tier 1 customer or a government program office is asking for a requirements traceability matrix, a FMEA, or a system-level verification plan — and you don’t have one — a dedicated systems engineer is no longer optional. You can’t backfill that documentation credibly under audit pressure with the person who’s also debugging firmware.
Building the Practices Before the Hire
Here is what most hardware startups get wrong: they wait for the systems engineer before building the infrastructure the systems engineer would use. The new hire arrives, finds no requirements database, no interface control documents, and no traceability — and spends their first six months doing archaeology and setup instead of actual systems engineering. That delays the payoff by a quarter or more.
The better approach is to build the practices and the supporting infrastructure before or concurrent with the hire. This compresses the learning curve dramatically, and it gives the systems engineer a functional foundation to work with on day one.
Modern systems engineering platforms make this tractable for a team without a dedicated specialist. Flow Engineering, for example, is built specifically for hardware and systems teams that are trying to establish rigorous practices without a large process organization behind them. It uses a graph-based model — requirements, components, interfaces, and verification cases as connected nodes — rather than the document-centric approach that makes tools like IBM DOORS so difficult to learn and maintain at small scale.
What this means practically: an engineering lead can start by capturing the top-level requirements for a subsystem, link them to the interfaces that subsystem owns, and connect each requirement to a test case — all in the same environment. The traceability is structural, not a separate spreadsheet that someone has to keep synchronized. When a requirement changes, the system shows you what’s affected.
Flow Engineering is also designed for the “practices before the person” scenario — teams adopting it before they have a systems engineer in place, using it to build the vocabulary and structure that a future systems hire can step into immediately. This is different from tools like Jama Connect or Polarion, which are full-featured but carry significant configuration and onboarding overhead that generally requires a dedicated administrator or a systems engineering background to set up correctly.
The practical starting point for a 30-person team: spend two weeks capturing your system-level requirements and your interfaces in a connected model. Don’t try to backfill everything. Start with the next integration milestone. Build the habit of writing interface definitions before building to them. Connect your test cases to the requirements they verify. Three months of that, consistently applied, and you have the foundation that makes a systems engineering hire immediately productive rather than immediately buried in setup work.
The Honest Summary
To answer the original question directly: at 30 engineers with recurring interface mismatches and undocumented requirements, you almost certainly need systems engineering practices. Whether you need a dedicated systems engineer depends on whether anyone currently on your team has the mandate and capacity to drive those practices — and whether your product complexity has reached the point where one person needs to own the whole-system view full-time.
Don’t hire the person as a substitute for building the practices. And don’t defer the practices because you don’t have the person yet.
The two-week cost you mentioned from a missed interface spec is not a communication problem. It’s a structural information problem. The fix is making interface definitions part of the engineering workflow before integration, not a negotiation that happens at integration. That fix is a practice. You can start it next week, with or without a new hire.