If this is your first visit to the blog, I’ll point you to a brief introduction to structural engineering, about what I did do, before deciding to leave this industry. Some of the framework here was part of a Twitter thread I wrote last fall about why I was considering leaving the structural engineering industry. I ultimately decided to call it quits this spring after being unable to make meaningful changes to my role.
We don’t train young engineers to have successful careers, because those training them are using an outdated playbook. Several of the offices and companies I’ve worked for have espoused a “mentor/mentee” or “apprenticeship” type relationship as being key for developing talent. Having an effective mentor/mentee relationship takes a lot of work. At the same time, the design process has been accelerated based on unrealistic client demands and ever shrinking margins, so engineering practice has become more of an assembly line out of necessity to stay competitive.
This means I’ve met multiple (ex)engineers that have spent their first three years on nothing but shop drawings. Becoming well-rounded takes time and effort, and it’s easy to keep assigning junior engineers the same tasks because they’re “good” at it, and there just isn’t time to teach/mentor. In the SE3 Project 2018 survey, we asked engineers both how often they’d considered leaving and how much longer they planned on staying in this industry. Our findings showed a spike in the number of people considering leaving at that 2-4 year point. No surprise, since structural engineering education would have you believe you’ll be analyzing and designing an iconic super-tall building within the first few years of your career. I was fortunate to have good mentors throughout my career, but the mentorship issue has surfaced among many of the people I know who have left the profession.
Following the traditional path to becoming a structural engineer is also shockingly expensive. I’ve outlined the typical cost of licensure and professional development in previous posts. When I workshopped this blog post with a fellow ex-engineer, she mentioned that getting involved in these professional development activities (making it into an old boys’ club of a technical committee, or getting involved in marketing) is fully expected to even have the potential opportunity to move up. Few of these activities will be covered in full by any firm. At this point, even getting your PE is rarely incentivized; I know very few people that received even a spot bonus, and renegotiating salaries was out of the question.
This initial career dissatisfaction results from a distinct mismatch between education and practice, and it means that many young engineers move around…a lot. Almost everyone in my Stanford graduate class has worked at two or more firms amongst those whom I am still in contact; only a few of those are still engineers; 80% have left the profession. This is indicative of the larger issue of brain drain that is happening.
Brain drain[^1] is by far the biggest challenge facing the structural engineering industry right now. It is increasingly common for a megaproject to burn out an entire analysis/design team to the point that they all quit before the project has been completed. This means that aside from the SEOR (structural engineer of record) and a few stragglers, the company has effectively lost the ability to execute the same kind of work that will then be front and center of the PR material that will then be used to win new work. I’ve worked on two megaprojects where this happened and witnessed the fallout from lack of knowledge transfer on other projects several times as well.
One might argue that the deliverables required for construction documentation should guard against this lack of knowledge transfer, but the level of documentation required to execute a project is well below that of what is required to replicate the design processes of that project on another one, particularly when it comes to the state of engineering design software. These days, given how often software updates are rolled out with minimal feature advancements (usually related to BIM interoperability more than anything else), it’s entirely possible you won’t be able to open a two year old analysis model, let alone a ten year old analysis model. This isn’t because software has gotten better; it’s just because it’s on a subscription cycle.
The current workflow for analysis and design is extremely inefficient in the software I routinely used, and I’ve used a lot of commercial analysis software throughout my career. I’ve never worked for a company that trusted design modules (automated features in some software that do “hand calculations” for the user) in analysis software, for which I can’t blame them — I wouldn’t either.
This means workflows usually consist of exporting data to Excel, then running the data through a user-created structural design “hand calculation” spreadsheet (hopefully with detailed calculations steps as well as a batch calculation for demand to capacity summary sheets, but YMMV). These spreadsheets are often created by copy-pasting thousands of cells and drawing down lots of formulas, which are inscrutable for anyone other than the creator of the spreadsheet. Rinse and repeat every time we make a tweak to analysis model. While better/clearer presentation options have been available for decades through programs like Mathcad and TEDDS (neither of which I have used in practice because Excel is…practically free), the current barrier to better design calculations using open-source software has never been lower. If you can index-match in Excel, you can program standard variables in a Python Jupyter notebook and sort and filter your data with Pandas.
In terms of visualizing results, not much has changed in industry in the last ten years either. While architectural renderings grow ever more impressive, in the engineering industry, at best, you’ll be able to see individual results and enveloped force effects on structural members through a static or laggy viewfinder. At worst, you’ll have to manually encode camera angles to generate visible results, or the only option to view results at all is to extract a csv file.
Other industry challenges: standing up to architecture firms that have zero interest in sustainability (we literally cannot afford to do this anymore; I’ll expand on this further elsewhere); racing to the bottom in times of economic turmoil (twice since I started studying/working); and the general lack of computer literacy. We’ve also sold our souls to black box analysis programs, rather than building our own, so older technical engineers (rightfully!) distrust those results[^2]. This distrust is a constant pull towards the old ways of doing things with minimal software and against the new ways with more proprietary software than you can shake a stick at.
I have deeply struggled to find my footing in this industry since I don’t have a traditional engineering background despite the projects that I have been on, including several landmark projects. I started my career running complex erection analysis models in bridge engineering. Frustrated by the stone-age digital workflows I described above, I became interested in programming and computational design and attempted a PhD in the field. I won’t get into how much I regret that experience in terms of dealing with a sexist research group and program and a verbally abusive advisor, but it did instill in me just how important good mentorship is.
Despite all of this, I wanted to come back to the design industry to build things… with code! I still think that embracing digital technology is one of the best ways the profession can move forward. It frustrates me to no end that we are reinventing the wheel on every project out of sheer stubbornness. As a profession, we’re skeptics, which we have to be, given the amount of risk we take on. We do not trust open source software, even though we trust black box software that costs thousands of dollars in updates and maintenance fees, rarely changes for the better, and has no liability or transparency when bugs are frequently exposed.
I’ve worked on simple software tools for practical structural design tasks for several years now. I put particular emphasis on transparency and having exploratory user interfaces. I built these kinds of tools entirely in my spare time as a rough proof of concept, as no job has been able to support the kind of programmer/engineer hybrid model I’ve wanted. During my last two times interviewing for jobs, these examples have been great for the interview, but the job has still been the standard engineering job with little to no time for development.
I haven’t figured out how to put the two together — if my title says “structural engineer”, project work will always come first in a consulting environment, which will not lead to progress in software. I’ve wanted to have a foot in industry to be able to understand the pain points of design, but the frantic nature of project delivery today leaves little room for lessons learned, let alone innovation. My current goal is to join a small team and build effective software, learn as much as I can, and be close to the users rather than several degrees removed, as I’ve been through my entire career by the nature of a traditional structural engineering role. I want to build the tools to enable good design rather than build the actual buildings.
One of the best decisions I made in my career was to spend 3 months at the Recurse Center, which is why I’m doing it again. I learned more about software in those three months than I did in 3 years prior, and I’m excited to have the opportunity to further develop some of the projects I worked on in my first batch. I have quite a few new ideas pinging around in my brain!
While I have a few freelance opportunities to support myself, I’m looking forward to exploring new job opportunities afterwards; this time with the keyword “software” rather than “structural”.
[^1] I would love to know how many technical specialists were hollowed out of design firms during the recession (and how many more were lost during the pandemic), which has left a gap in expertise and has pushed work winners and PMs to the top of firms without sufficient knowledge transfer to those below.
[^2] Bridge and tall building companies used to write their own software because no commercial options existed. The bridge firm that I worked for in several offices had its own in house software, as well as its two sister companies overseas. However, during my time there, I saw a significant move towards requiring commercial software on projects (even for independent checks).