In that context, the question “What would you say you do here?” becomes less of a joke and more of a legitimate inquiry into whether the org...
In that context, the question “What would you say you do here?” becomes less of a joke and more of a legitimate inquiry into whether the organization is truly practicing systems engineering, or simply going through the motions.
“In my experiences across previous Fortune 500 companies from medical to defense, prior to formal MBSE adoption, I was already applying many of its core principles—developing system architectures through block diagrams, defining hardware and embedded interfaces, and using simulation tools like SPICE to model behavior before implementation. The main difference is that these activities were performed across separate tools (frustrating) and documents (if any) rather than within a unified system model.
MBSE essentially formalizes and integrates what experienced engineers have historically done intuitively.
” However just because you call something a "Duck" does not mean separate tools (frustrating) and documents (if any) issues are eliminated...
I still observe missing DHF (Design History Files) [missing or incorrect] data sheets and convoluted process that i have to fix...(through defense, aerospace, and medical devices ultimately leading to failures due to failed processes (EVEN IF YOU ARE IN EXPERT IN MBSE!!)
so not a DUCK!
Funny story ... I recently just had conversation with a hiring manager from a top defense company about high level requirements given to him/her that it might have well been called "a duck" (quack!) due to the over generalization of the requirements. "Might be some sort of capacitor...etc"
Leadership:
Well I'm an expert in MBSE so everything is fine.... lunch anyone?
The engineers will just have to fix it...
and thus the movie "Office Space" reference:
The famous line from Office Space—“What would you say… you do here?”—captures a dynamic that is surprisingly relevant in modern engineering organizations, particularly those attempting to implement Model-Based Systems Engineering (MBSE). In the film, the question exposes a gap between perceived responsibility and actual value delivered. In an MBSE environment, that same question can surface when leadership structures exist in name, but not in function.
In a poorly executed MBSE organization, leadership often defaults to administrative oversight rather than true systems engineering. Instead of defining architecture, enforcing requirements discipline, or driving technical decisions, responsibility is quietly pushed downstream. Issues are forwarded, meetings are scheduled, and models are requested,
but the underlying system-level problems remain unresolved.
This creates an environment where MBSE becomes a reporting mechanism rather than a design framework.
As a result, engineers are forced to absorb responsibilities that should originate at the systems level.
Engineers are not only designing hardware or developing software, but also reconstructing incomplete requirements, resolving architectural ambiguities, and maintaining the integrity of disconnected models.
The MBSE toolchain—whether SysML diagrams or digital models—becomes a patchwork effort to compensate for gaps in leadership rather than a proactive tool guiding development. Instead of enabling clarity, the model lags behind reality and is often updated only to satisfy process checkpoints.
This breakdown is frequently rooted in a misunderstanding of what MBSE is intended to achieve. Modeling is treated as an end in itself, rather than as a means to enforce traceability, validate design decisions, and maintain system coherence across the lifecycle. The presence of diagrams is mistaken for the presence of engineering rigor. However, without strong ownership of the system architecture and a commitment to using models as decision-making tools, MBSE devolves into a documentation exercise.
Ultimately, the failure is not in the methodology, but in its execution. Effective MBSE requires leadership that actively engages in systems thinking—defining interfaces, managing trade-offs, and ensuring alignment between requirements, design, and verification.
When that leadership is absent, engineers are left to bridge the gap, often at the cost of efficiency and clarity.
In that context, the question “What would you say you do here?” becomes less of a joke and more of a legitimate inquiry into whether the organization is truly practicing systems engineering, or simply going through the motions.
