Traditional Engineering has a productivity problem — and nobody is talking about it
TLDR: We’re tackling an enormous problem in non-software engineering that is systematically under-served by incumbent knowledge management solutions. This problem is not obvious to outsiders, but sharply frustrating to insiders. Engineers (our users) are voting with their feet by implementing costly workarounds to incumbent solutions, which demonstrates how much this omitted use case matters to them. Thea addresses this hidden use case with an ML-enhanced email extension product that simplifies data management for non-software engineering teams at the earliest, most consequential stages of projects.
If you’d like to connect with us or follow our progress, you can do so here.
Where’s my flying car?
If you’re in tech, you’ve likely heard of the supposed Great Stagnation of our times. Something happened in the 1970s and now suddenly the world of bits dominates all technological progress, while the world of atoms has been left behind in the dust. Peter Thiel, Tyler Cowen, and others have famously quipped:
But do they have a point? As an example: in its early days, Instagram was valued at ~$1B (2012 Facebook acquisition) while employing only 6 software engineers. Contrast this with a more traditional engineering company in the world of atoms like Rolls Royce: in 2018 it employed ~17,000 engineers of different disciplines (mostly non-software!) but its market cap was only ~$27B.
It’s only a single example and perhaps a crude comparison of value, but the disconnect between software and non-software is real and obvious. The question remains worth asking: why are software engineers producing multiple orders of magnitude more value than their non-software engineer counterparts?
Thiel’s view on this is clear: any engineering discipline (Mechanical, Chemical, or Nuclear Engineering say) except for Computer Science is a disastrous career choice. Computer Science emits a lonely, “narrow cone of progress” like a flashlight in the dark, while non-software engineering blindly stumbles along behind. But we at Thea know it doesn’t have to be this way.
Alright, I’ll bite — so how did we get here?
Indeed. What's causing the dramatic productivity gap between software engineering and non-software engineering? We see two main reasons:
1 — Greater Regulation
Non-software engineering is significantly more regulated. There are more standards governing the design of an airplane than the development of a food delivery app. This is a good thing. However, non-software engineering teams are left to absorb this additional compliance overhead. All the while the global trend of increased regulation continues.
2 — Software Is A Different Beast
A key difference between software engineering and non-software engineering is the cost of building. When the product exists in bits rather than atoms, it’s comparatively cheap to develop complex systems.
To bridge this gap non-software engineers have developed complex Computer-Aided Engineering (CAE) tools to bring more of their work into the domain of bits. It’s been hugely successful so far, but it’s also created a data problem. The data non-software engineers generate and work with today exists in fragmented, sometimes physical, and often unstructured locations and formats.
At Thea we’re tackling both problems, starting with the second and then expanding into the first.¹
This problem doesn’t sound all that new, surely this has been solved by now?
Well, yes and no.
There are plenty of tools around today for managing non-software engineering data and reducing the effort of compliance. The established incumbents include Siemens, PTC, Autodesk, and others. They are essentially database solutions to a database-shaped problem. This family of tools is typically called Product Data Management (PDM), or more broadly Product Lifecycle Management (PLM).
So what’s wrong with PDM/PLM systems?
Good question. You wouldn't know from the outside. But once you work in engineering companies using PDM/PLM you’ll notice something odd. You’ll find that engineering teams tend to avoid using their PDM/PLM at the earliest stages of projects.
Why? This early stage of a project is well-studied and has a name: it’s the Fuzzy Front End (FFE). It’s the stage of a project that is most vague, where the requirements are at their most undefined, and the solutions engineers are developing will change frequently. And usually, it’s borderline chaotic.
Let’s take some examples of what you might see engineers doing in the FFE:
- Avoiding their PDM/PLM completely and storing files in the cloud (e.g. GDrive or Dropbox) while manually maintaining version control through file name conventions.
- Taking photos of team whiteboarding sessions on their phones and then sending them to the project team via email or Slack. Then, days later, being confused about which image captured the latest agreed design revision.
- Searching their inbox for that latest customer requirements list .pdf or .ppt file. Maybe a colleague received it — better call her quickly to find out!
PDM/PLM systems serve a purpose: they provide visibility into the project, traceability of the different connected parts, and accountability on who signed off particular engineering decisions. These systems are designed to allow the company to pass ISO, regulator, and customer audits.
All of the above requires the data entered into PDM/PLM to be hard and slow to change once it’s locked in. This is antithetical to the nature of the work engineers do in the FFE. Engineering teams en masse are revealing their preferences by deliberately sidestepping their PDM/PLMs in the FFE. They’re voting with their feet to show us that there’s a use case here that’s not being addressed. None of the incumbent solutions is serving that use case in the FFE today.
So what ends up happening instead?
In the absence of appropriate tech, two non-tech coping strategies emerge:
1 — Throw more person-hours at the problem: many engineering companies resolve the mess of the FFE by hiring teams of project managers. These project managers manually ensure the integrity of the data in PDM/PLM systems and enforce their team’s data management discipline. This is an expensive way to solve the problem. For smaller companies, it’s a luxury they can’t afford.
2 — Rely on organizational processes: in some cases, the project’s stakeholders throw up their arms and accept that they’ll have minimal visibility, traceability, and accountability during the FFE. This is especially true in larger organizations with thousands of employees. Instead, the project stakeholders will wait for a natural project milestone in their waterfall-style process to make decisions.
Usually, that milestone is the first Design Review. It’s a meeting with a deadline by which all of the project data needs to be up-to-date and ready for review. In practice engineering teams work for weeks or months outside PDM/PLM and then scramble, a week before the Design Review, to upload everything for the deadline.
Fine, so things are a little messy at the beginning — isn’t that normal, is this really a problem?
Yes, it is a problem. And no, it shouldn’t be normal because this chaos is costing engineering companies dearly. Getting things wrong during the FFE has an outsized, downstream impact on the entire rest of the project. There is significant evidence that most of a project’s cost, quality, and schedule are largely locked-in by decisions in the FFE.
You’d be shocked to learn how much critical, technical data for non-software engineering projects lives in locations it shouldn’t. It sits in random sketchbooks, on rogue printed drawings, in email inboxes as attachments, in Slack/Teams channel messages from a month ago, or as photos on engineers’ personal phones. During the FFE it’s just generally hard to understand what’s going on in real-time, week by week. Any experienced project manager at larger engineering organizations will tell you likewise (as they pull at their hair).
For example, imagine the common case of discovering that a last-minute tooling change is required on a six-figure injection molding die. Often the cause is traced back to some minor detail of the early design that the engineering team failed to assess for feasibility during the FFE. Errors like this happen far more often than they should.
Great, so how should we approach the FFE?
At Thea, we’re interested in helping non-software engineers better manage the early project itself, as well as its output: the specification. The project and specification grow in parallel into a graph-like structure. In CAD software this structure is called the feature-tree. Over time the structure expands and its nodes are revised and the edges are reassigned. Giving engineers better visibility of this structure in real-time empowers them to better assure the project's quality, costs, and schedule. Now we’re no longer just fixing early errors late after the fact.
In short, this is what we see as Thea’s mission:
Thea reduces uncertainty in the early stages of non-software engineering projects in mature, regulated markets.
Awesome, so what Thea’s solution?
Thea is an email, Slack, and Teams extension that crawls non-software engineering teams’ communications. It extracts rogue, uncaptured, project-relevant files and automatically clusters them (using ML techniques) for easy review in-real time and also for use in compliance documentation.
This is our master plan:
Start with better tools
We’re developing software tools to improve real-time visibility during the FFE. These tools allow non-software engineering teams to deliver higher quality projects, closer to predicted timelines.
Then automate away the overhead caused by rote compliance work
Let’s dream big! What could Thea turn into over the next 15 years? Over time we envision a world where Thea works in the background to capture the shape and structure of any non-software engineering project in real-time. That way engineers never again have to spend their attention searching for data or entering it themselves to update the project. Think of Thea as your automagical engineering stenographer.
In the same stroke, we address the growing compliance overhead problem. Once Thea has diligently documented your project in the background, it’ll be ready for one-click internal review. Likewise, you’ll then be able to export your project in your local regulator’s preferred format for external review and approval. We want future engineering workflows to no longer be interrupted by rote compliance work or rote data capture. A human engineer’s input should come only when the nuance of their fine-tuned judgment (which they spent years qualifying for through school and their career) is actually required.
Where do we go from here?
We’re glad you asked. Stay tuned to find out! We’ve started this journey and would love for you to follow our progress. The best way to do that is to sign up for our monthly newsletter here.
If what you’ve read here resonates with you we’d LOVE to talk to you about your experience with this problem. Talking to people like you and hearing your feedback helps us develop Thea to better suit the needs of non-software engineers the world over. Please get in touch here.
Finally, if you’re intrigued by this mission, then we want to hear from you too. We’ll be hiring an exceptional dream team soon! Please get in touch here.
¹Aside: the COVID-19 vaccines are a hopeful sign of change in the world of atoms. Their speed of development has been unprecedented and inspiring. Emergency regulatory relaxation and better engineering tools and techniques both played a role in achieving this incredible outcome.
