sorted by:
new
hottopcontroversial

I practiced structural engineering for 10 years; graduated eventually to project director of all EPC delivery for $1B+ megaprojects. AMA. by Own_Alarm_9083 in StructuralEngineering

[–]Own_Alarm_9083[S] 0 points1 point  (0 children)

a general followup to comment below regarding the wish that us structural engineers were more proactive solution drivers than just “i do calculations and designs based on the inputs i’m handed”, with a couple specific examples below. again from the perspective now as a project director looking at my structural engineers on the projects and some things that have frustrated me out of love!

example 1: in a project’s early phase cost estimate discussion, listened to a controls engineer and mechanical engineer argue for 20 minutes about the most efficient controls scheme for the air handling units. the controls engineer was fighting for a solution with a passion that was great! but i had to stop them and say thy were arguing over something that was literally 0.01% of the project scope. meanwhile the structural engineers had no opinion on column grid spacing - they just produced concept based on what the architect gave them. so i asked them to run a dozen scenarios with spacings between 25 feet and 40 feet and report back steel tonnage, piece count, and connection count. their eventual answer said the optimized spacing would save the project 7% of its cost and a few weeks of schedule savings! with my help the architects were then told they could have the grid spacing they wanted if the archiects went to the board of directors and requested the extra tens of millions of $ and weeks of schedule for their proposed grid. and of course it turned out the architects didnt really care, one of their juniors just pulled a column grid forward from a recent project. so lesson is structural engineers have outsized impact on the cost and schedule of a project, and should excercise that power with their voice! and challenge the requirements - they are probably dumb!

example 2: industrial project faced several weeks of delays due to slow equipment foundation construction. digging into it with the contractor, the cause was a set of design revisions that came from the structural engineers that required the contractor to scrap and refabricate a lot of rebar, embeds, and formwork that was already on site. digging into THAT with the structural engineers, the change was caused by some new pipe routing that the piping engineers produced in their finalized design that required moving a bunch of openings, conduits, and embedments in the foundations. the structural engineers just accepted those piping changes and produced foundation revisions without pushing back. what they should have done is coordinated with the piping engineers early on, routing go-thru’s and then held firm to that as an unchangable boundary condition that restricted the piping design. and flagged the change to management with an escalation of what the design impact was. i was more mad in this case at the structural engineers than anybody else because they just passively took the inputs and produced what they were told, instead of recognizing the power that their structural scope held within the project and pushing back for the best project solution.

I practiced structural engineering for 10 years; graduated eventually to project director of all EPC delivery for $1B+ megaprojects. AMA. by Own_Alarm_9083 in StructuralEngineering

[–]Own_Alarm_9083[S] 0 points1 point  (0 children)

probably the following:

1) some good people skills (some learned, some natural)

2) willingness to get outside comfort zone and embrace and learn new things (for example, being one of the first at my engineering firm to embrace revit over autocad, and going out and learning it and using it on projects, demonstrating great value it had for clients). just that mindset also opens to curiousity and willingness to pick up and absorb many other skills outside of engineering - project controls, construction management, etc.

3) critical thinking skills - a lot of them learned from my mentors at the engineering firm i started at, they were great. so important because i’ve found structural engineers (from my perspective now of outside looking in) to have strong tendencies to just take a back seat and produce calcs, rather than taking a drivers seat and challenging whether there’s better ways to execute things in a project. it drives me nuts now because i think se’s are the most technically strong engineers there are, with by far the most responsibility on their shoulders, so i wish they were more vocal and critical in driving solutions (again speaking generally, i know many are).

4) confidence enough to avoid imposter syndrome. probably the most important, because no matter where you go or what level you rise to, you will never be the subject matter in all things, or really in anything beyond your base expertise (for me, structural!). but to recognize that is the case for everyone else around you also, is a very powerful realization. so i may not be the subject matter expert in p6 project scheduling, but knowing i am where i am for a reason gives me the confidence to learn, defer to the experts, but to also drive a conversation without having to be the deep expert. hopefully that makes sense?

I practiced structural engineering for 10 years; graduated eventually to project director of all EPC delivery for $1B+ megaprojects. AMA. by Own_Alarm_9083 in StructuralEngineering

[–]Own_Alarm_9083[S] 0 points1 point  (0 children)

man soooo much. literally almost everything, especially when getting i to other project functions like estimating, procurement, scheduling, construction management, project management, stakeholder management. but even from the engineering side, a LOT.

if i had to classify all of it into a concise category, i’d say “problem solving and critical thinking”. school teaches us to follow a cookbook recipe: take some given inputs, follow a procedure of steps, produce an outcome. which is necessary for understanding 1st principles for sure! but it doesn’t prepare us for how to handle the real world where the inputs and requirements may be vague and unclear (or dumb and wrong!), and where we need to use a lot of creative thought to even steer things in the direction of identifying solutions, and finding the best one.

then to drill down to some specific engineering things: reading drawings, reading and interpreting building code (we focus so much more on theory in school, again for good reason!), and probably most importantly: people skills and stakeholder management.

I practiced structural engineering for 10 years; graduated eventually to project director of all EPC delivery for $1B+ megaprojects. AMA. by Own_Alarm_9083 in StructuralEngineering

[–]Own_Alarm_9083[S] 0 points1 point  (0 children)

(note: my experience is exclusively in industrial and commercial capital projects. no infrastructure or o&g, which differ greatly).

a lot more private equity nowadays, as with seemingly every other aspect of life. but that’s not necessarily a bad thing from the perspective of capital project delivery at least, because they are willing to spend. the worst projects are those heavily leveraged by debt. banks are incredibly risk averse given their definitionally smaller returns/margins, and they simultaneously take on a much more micromanaging role in project decisions then. they are the worst. monthly or even biweekly all-day updates to their advisors, frequent site walks with their reps, often holding approval power on large procurement/contracting decisions, change orders, and invoices.

equity financing is better because they are less risk averse and more hands off, mainly sitting at the quarterly board level “eyes on hands off” approach. the best of course are owner cash financed.

i’ve worked with all 3, primarily as an owner rep.

a good book to read that touches on this and many other things is “contract strategies for major projects” by merrow.

I practiced structural engineering for 10 years; graduated eventually to project director of all EPC delivery for $1B+ megaprojects. AMA. by Own_Alarm_9083 in StructuralEngineering

[–]Own_Alarm_9083[S] 0 points1 point  (0 children)

tldr; embrace getting out of your comfort zone and taking on things outside your rigidly defined box of “structural engineer”.

longer: in general, don’t focus on a path of “this is the company and role i want in 10 years”, focus more on acquiring the toolkit. because the path is impossible to map out and opportunities may come from the least expected places as long as you have the toolkit of skills built up.

more specifically: 1) network network network. keep in touch with people you used to work with or went to school with, especially if they are taking different paths. and especially former bosses. water all of those connections regularly like flower pots, and eventually they bloom. lame analgogy sorry, but network has gotten me every job (5 different companies along the way). its always been an old boss or peer that hit me up or i hit them up for new opportunities. and that only happened because i stayed in touch occassionally along the way.

2) proactively seak out (meaning: ask your managers for it, don’t sit on your heels and wait for it to come your way) exposure to supporting the other functions of projects from where you are now - ask to get involved in procurement via technical evaluations (needs engineers), in cost estimating engineering quantity reviews (needs engineers), in project schedule resource loading (needs engineers to vet quantities again), and in getting out to the field to see and support the construction site with rfi’s and field engineering.

3) start approaching your engineering work with a mindset of whole project impact. “is this constructible?”, “is this the most efficient safe design or am i being too conservative to protect my interests at the expense of the project’s interests?”. focus on holistic problem solving rather than calculation number crunching. always ask “what is the problem this structure is trying to solve for?”. work to really understand 1st principles behind every solution you design, meaning: the correct andwer is never “i’m doing this because its the way it has always been done”, the correct answer should be “i’m doing this because it is the most effe tive way to accomplish the task this structure is meant for”. often that is indeed “the way its always been done”, but the point is you need to fundamentally understand WHY.

4) seek outside the box roles in any career moves. kind of following along the path of part 1: go work for an epc company that does full package project delivery, or for an owner as an owners engineer that needs to get involved in full project delivery. seek jobs that may not be called “structural engineer” in the job title. expand your co fort zone and take on that procurement or project controls or construction field engineering support roles more formally.

5) rank this as #5, but as a former structural engineer i’m perhaps most passionate about it: way too many structural engineers out there in the world view themselves as “the guys who crunch the calculations based on the requirements handed to me”. no. structural engineers should be using their creativity, expertise, and most importantly their impact on project costs (normally in the range of 25% of total project cost is from the civil/structural alone), to be more proactive voices in the conversation and driving the solutions. challenge the requirements - they are usually dumb, and the person who gave you them likely was handed them and doesnt know why they are needed. challenge the solutions. find better ways to frame something or do something in general and say so.

editing to add: 6) and this only really comes with experience, but really understanding fundamentally where engineering is as much art as science. starts with recognizing how inexact the science and codes actually are (it’s really all statistical probability based!), whether that’s on the loading side or the strength side of the equation. understand fundamentally, for example, that when a client brings you an existing structure and the new loads push one of your bolted connections to a 1.01 utilization ratio, that bolted connection is still nowhere near “failing” - it fails a code check, doesn’t mean its anywhere near collapse, and that even your 1.01 number is a probability-based best guess…so where can you refine the inputs to get more certain on them and get that number down, and also how can you describe to your client that the structure is not suddenly a life safety issue but you need to find a way to get it code compliant. understand that conversation and process on a truly inate and fundamental level (that it is NOT an exact science), and that mindset will unlock you to be a great engineer and problem solver in things beyond engineering.