The 14 Hours: How Hardware Engineers Lose Half Their Week to Tracing Their Own Work
INCOSE published its 2026 Systems Engineering Productivity Survey in February. The headline number stopped people: experienced systems engineers in complex hardware programs report spending an average of 14.2 hours per week on tasks they describe as reconstructing context. That is finding the latest revision of a requirement, hunting the ECN that justified a change, locating the test report that proved a margin, and rebuilding the rationale before they can do actual engineering work.
What 14 Hours Actually Looks Like
The study broke down the lost hours by activity. Searching across disconnected tools (PLM, requirements manager, network drives, email, chat) accounts for 4.8 hours per week. Manually rebuilding traceability between requirement, design, and test artifacts accounts for 3.6 hours. Reformatting data for review meetings accounts for 2.9 hours. Resolving conflicts between document versions accounts for 1.7 hours. Confirming nothing has changed since the last review (the most demoralizing activity, per the qualitative interviews) accounts for 1.2 hours.
A senior systems engineer in France earns roughly €85,000 fully loaded per year (Apec Hardware Salary Report, 2025). Fourteen hours per week is 35 percent of capacity. The direct cost per engineer is around €30,000 per year, before counting the cascading delays this drags into the program.
Why It Happens
The root cause is structural, not behavioral. Modern hardware programs use between 8 and 15 distinct engineering tools. CAD lives in CATIA or NX. Requirements live in DOORS or Polarion. Tests live in HP ALM or qTest. Procurement lives in SAP. Software lives in Git. Communication lives in Teams or Slack. Each tool was best in class when it was selected. Together they form a fragmented context where no single person can see the full picture.
The traceability matrices teams build to bridge this gap are themselves manual artifacts. Excel files maintained by a single owner. The day that owner is on holiday is the day a review fails.
The Productivity Multiplier of a Connected Graph
The same INCOSE study followed a control group of teams using graph-based engineering platforms (Aras Innovator, Siemens Polarion ALM with knowledge graph extension, and emerging tools like Koddex). These teams reported 4.1 hours per week on the same context-reconstruction activities. That is a 71 percent reduction.
The reason is not magic. When every artifact is a typed node and every relationship is an explicit edge, finding what you need is a query, not a search. When the system computes the impact of a change automatically, you do not rebuild the traceability matrix before every review. When the dossier is a projection of the live graph, you do not reformat anything.
What Senior Engineers Should Do Now
The first move is measuring. Most engineering directors do not know how their team spends time. A two-week activity log, even on a sample of senior engineers, will surface the same 14-hour pattern. The second move is auditing the toolchain. Every tool that does not write into a shared graph is a future hour of context reconstruction.
The third move is structural. Picking a graph-based engineering backbone and migrating critical artifacts (requirements, BOM, verification matrix) into it is the only intervention that compounds. Process improvement on top of fragmented tooling does not.
Koddex exists to recover those 14 hours. Engineers do not deserve to spend a third of their week proving their own work happened.
