A Tale of Passion vs Paperwork

We get inspired by the creativity in engineering.

It should be innovative. It should feel like problem-solving. But how often do we find ourselves tangled in administration, feeling more like an office clerk than Tony Stark? Exhilaration at new ideas turns to dread after a glimpse of the acronym soup of the ARP4761A standard.

Creativity gets smothered under paperwork and protocol. Back at university we do get warned that individual design projects don’t really represent engineering in industry - but wow does that hit like a freight train in the first graduate job.

When engineering feels like a constant uphill battle against bureaucracy, fewer revolutionary ideas see the light of day. The world misses out on game-changing technology.

There's an undeniable allure to Tony Stark creating Iron Man in a cave. An individual crafting marvels (pun intended) without the constraints of group politics or bureaucratic overhead…

While most of us don't have billionaire genius playboy credentials, the scene resonates because it embodies our ideal engineering vision: pure, unencumbered invention.

Inventing solo means less admin, but also an excellent ability to iterate - to incorporate insights and constraints from one sub-system directly into another as we go.

But today's biggest innovations are rarely solo endeavors. They involve domain experts combining their knowledge into truly mind-bending machines. It's this blend of individual genius and team synergy where the magic should happen.

The Chaos of Concurrent: Where It All Falls Apart

Concurrent Engineering has been around since the ’60s when Toyota tried to eradicate the idea of separated project stages for design, manufacture, testing, and full production. Agile itself actually grew out of Concurrent’s fertile soil.

Now, few don’t use at least some form of concurrency. CAD allowed systems to be defined spatially and developed with predefined interfaces. CAE allowed analysis and testing to be simulated digitally before prototypes were even produced.

The boundaries of design, manufacturing, and testing are becoming even more blurred with digital twin technologies and an increasing propensity to build and iterate rather than get something to 100% on paper before cutting metal.

But Concurrent Engineering is still far from an exact science.

In the early phases of developing a system, uncertainty and creativity rule. CAD isn’t more than a boxy space constraint. Simulations can’t be run until you know what you’re simulating.

In this phase, spreadsheets, MATLAB, and Python scripts are the go-tos. Our source of truth is our notes from the last design review. Everyone is full of ideas.

Collaboration between engineering domains is essential but difficult. MBSE claims to be solving this problem, but try explaining SysML to your Structures team and see how much enthusiasm you get.

There’s always a feeling we need to be more organised to stop everyone from shooting off in different directions. But slowing down is out of the question.

Modern Engineering’s Bottlenecks: Communication & Integration

The pain in modern engineering is driven by a continuous need to keep everyone on the same page.

We seem to have settled on a ‘solution’ of long email chains, never-ending design reviews, and thousands of pages of documentation. We then address additional complexity by adding headcount and layers of hierarchy (and paperwork).

We want to test assumptions rigorously in the earlier stages of design, but that requires continuously gathering each engineer’s information in one place to verify against requirements. Hence the overbearing administration.

Each department, team, and engineer then can’t take a systems mindset if we try and abstract the systems-level thinking into SysML or a requirements database.

In large-scale, complex development, the role of Systems Engineering is to anticipate integration issues ahead of time.

This goal is hamstrung by a lack of comprehensive oversight of what is happening in a project, especially before it materializes in CAD or is manufactured - by which point it’s too late. We’re left developing a complex closing system for our stable door when the horse is many miles down the road.

The bottleneck in rapidly iterating through the design, build, and test cycle isn't engineering speed. It’s the pace of gathering and disseminating data.

To go faster, we need to be using modern tools to replace control boards and engineering change documents. 21st century engineering needs 21st century tools.

The Requirements for a 21st Century Requirements Tool

Discussion and iteration are slow in these old solutions but need to be front and center in the new ones. New requirements tools need to look and feel closer to a social network than a database with a bad UI.

So, if we're daydreaming about the ultimate requirements tool, what's on our wish list?

- Eliminating silos without putting the burden on engineers

You can’t be an engineer for long without being forced into rework as a result of accidentally using old data. It's imperative that everyone - from internal teams to the furthest flung suppliers - operates from a single source of truth.

Silos pop up due to domain-specific processes, geographic divides, or even just team hierarchy. The burden of integrating these silos should fall on our tools, not on engineers chasing updates and attending five ‘sync’ meetings a week.

Proper tool integration should be the ability to search somewhere for a tank capacity or motor power, and instantly getting the latest data. That means pulling data continuously from the latest Excel models, Python scripts, and CAD models.

- Mechanisms that encourage the team to rapidly iterate

If the burden of making changes is high, it discourages iteration. I would argue that the more changes are happening every day, the healthier your engineering process is.

Think how difficult it would be for you to go into your system now and make a significant change to the design. Appealing?

A tight feedback loop is the lifeblood of iterative design, so we can’t pull humans out of the loop and eliminate oversight. But a modern tool should tap the right folks on the shoulder and offer context.

Reviews should be managed and recorded without us lifting a finger, creating an auditable trail without any extra workload.

- Ending the idea of requirements as contracts and encouraging constant trade-offs between sub-systems

If we treat requirements as fixed interfaces it encourages us to go away into our silos and assume nothing will change before we revisit the boundaries at the end of the project.

Below the top customer-level, requirements should be viewed, not as immovable objects, but as ice breakers for teams to constantly negotiate and swap trade-offs across the entire system.

How we store and view requirements should encourage challenging initial assumptions and striving for a global, over local, optimum. It should encourage changing requirements, feeding analysis updates to them, and discussing them.

A platform for engineers to speak about the future of engineering

Some say "there's nothing left to invent!". That seems less a reflection on our capability to innovate, and more a reflection on the limitations of traditional engineering approaches.

We’ve always wanted somewhere to go to hear engineering stories. Despite a few podcasts here and there, we’ve been largely disappointed.

To that end, we decided to create a webinar series, “Beyond Blueprints”, to share insights about amazing projects and thoughts on where engineering as an industry can improve.

If you enjoyed reading this (or vehemently disagreed) and have your own opinions about the future of engineering, then we’d love to have you on the webinar. Drop us a line at michael@flowengineering.com.