ReEngineering the Engineer: Do You Hear What I Mean?
We’re working on a project that involves the demolition of a multi-story existing building with new construction going back in its place. The programming of the new building requires elevator shafts adjacent to the building that remains. Not only will there be an existing basement wall that remains, but construction of the new elevators requires a 5-foot undercut for the elevator pits, plus another 4 feet for a mat foundation. And (of course) the basement walls to remain are braced by the building to be demolished.
This is just as much of a soils bracing/stability problem as it is structural. We worked through the demolition drawings very early, prior to any real design work, because it was going to take several months to get the existing building down. We provided some preliminary locations of soil nails and forces based on the reinforcing in the existing walls. That ultimately required some negotiated locations and loading for the soil nailing based on accessibility constraints.
During construction, the special inspector for the nailing asked some innocent questions about the project as a whole, and it dawned on everyone that perhaps we should look a little further ahead to see if there are things we could be doing/considering now to make life (i.e., cost) easier later when the new foundations go in.
With construction/demolition underway, time is a big deal, so we all got on a conference call to talk through the issues: structural engineer, soils engineers, general contractor and the owner. Then the fun started …
Do You Speak My Language?
We engineers have a technical language that most people have a difficult time following. There are Codes, abbreviations and construction lingo we understand and use all the time, but it sounds relatively foreign to the non-technical crowd. In this particular example, the owner has a good understanding of engineering and construction, but that’s not always the case.
The structural and soils engineers were generally monopolizing the conversation. As we got deeper and deeper into the issues, I started losing track of what the other engineers were saying. They were using words that could have multiple meanings; using soils terms and processes I wasn’t familiar with; citing Code and design guide references; referring to “north” and “south” (which are rarely up and down on the page); etc. It was obvious everyone else was getting lost as well.
Communication Is Key
Despite all our great engineering education, that’s not enough to make us effective engineers. Sitting at our desk grinding out numbers isn’t the way most of us finish our careers. Eventually, we have to talk with people; and they’re typically not engineers and don’t have the same language set and knowledge to understand some of the challenges we have to deal with. But we oftentimes have to help them understand the issues because it’s typically their money. So on top of our regular engineering skills, we also need to develop good communication skills.
The phrase “dumbing down” sounds condescending, but it’s essentially what we need to do—without offending our audience. There are plenty of terms we use regularly that most folks don’t: lateral active/at-rest/passive pressures, surcharges, torsion, dynamic analysis, etc. As we’re telling our story, we need to be thinking ahead of the terms we want to use so we can replace them with terms that match our audience.
Yes, there is some “reading the room” involved here. How you talk to inside folks at the contractor’s office will differ from the site superintendent and the architect and the owner and even other engineers.
When explaining a problem and using drawings as a reference, I try to avoid vague or ambiguous terms. I typically resort to left/right/up/down/in/out on the page or plan north/south to avoid any confusion with true north/south. Of course, there may be times when true north/south really is more appropriate or effective. That comes back to reading the room.
When a discussion has many interjections, it’s sometimes necessary to regroup and start from the beginning to walk the audience through a problem so everyone can get back on the same page. Same rules apply here. Try to keep the language simple and take them through the issue step-by-step. Help them “see” the issue from start to finish. We’re used to seeing problems in a linear fashion or 3D, but our audience typically is not.
And continue reading the room. That’s a lot easier in person, but it applies to virtual meetings as well. If you’re getting the “deer in the headlights” look, stop and try to get them to explain where they got hung up, and try a new approach to help them understand. We do this all the time in our engineering analysis: try and try again. We just need to take that skill set and expand it to communication skills.
When you get good at it, however, effective communication is a definite plus, and your clients will want to work with you more and have you involved in their projects. You’re helping them understand the issues, instead of just saying “yes/no” or “you can’t do that.” They’re learning something, and you start accumulating some “street cred.” It takes practice, but effective communication, done well, is just another tool that helps separate you from the rest of the crowd.