Telling People No 1

[SteelPE]

I have had an issue throughout my short career with telling people no. I like to consider myself a somewhat logical person. I like to make sure I can prove a design works rather than just wing it.

Throughout my career I have had numerous GC's and clients come to me with questions and alternative ways to build things. Sometimes I accept their proposals, other times I don't. Early in my career, when I was working with my mentor, if I would reject someone's proposal to change a design and they would refuse to accept no for an answer.... they would push until I relented until I presented their solution to my boss/mentor.... who would tell the GC/client no and the GC/client would accept this and move on. Easy peasy for them.... extremely frustrating for me. I always chalked this up to my mentor being older.... or having a British accent.

As I have gotten older, my mentor unfortunately passed away and I moved on to be a consultant. A few times per year, I have contractors come to me for alternative solutions to make something easier or fix an issue that the contractor created themselves. If it's something that I can prove will work with the #'s then I usually accept their proposal, if it's not, then I tell the client no. 1-2x per year I get clients/GC's who refuse to take no for an answer (usually it's a GC's who messed something up in the field and want me to fix their mess up with a subpar repair). When it comes to GC's I tend to take a soft approach.... but when pushed repeatedly I with then resort to an extremely aggressive means that will get my point across. With clients, I tend to stick to a softer approach. Usually the clients don't push as much as the GC's will.

How do you get people to accept that they can't do what they want to do other than speaking with a British accent? or is this just something that everyone has to deal with and I need to take a more calm and rational approach (like just hanging up the phone)?

 

[SWComposites]

Its a common problem in other industries also. One just has to be calm, firm, and clear with your rationale for why you are saying "no". And I have resorted to saying "I'm not compromising my reputation by putting my signature on something that is not acceptable." You can also reference codes, regulations and calculations supporting your position. I always try to offer alternate solutions whenever possible. And try to understand the full situation, as often people don't describe the full situation or condition when asking for a repair or something, and when you dig into it then alternatives become easier to define. Now, if you are not getting paid to fix their problems then you have to put boundaries on it. And if you get a reputation for "easy to roll" then you will have lots of problems.

 

[Gr8blu]

I try to couch it in terms of risk - to them, not me.
For example - doing it your proposed way gives a 1-in-2 chance the item will break prematurely, resulting in potential personnel injury (or some estimated lost production $$). If we do it the right way, some of that risk is still there - but instead of it being 1-in-2 it's around 1-in-200. Then I ask them what their "pucker factor" is for the project.

 

[KootK]

I don't know of a silver bullet answer to this, especially when the line between contractor persuasion and outright bullying starts to get a bit blurry.

I would like the answer would be for us to have great credibility technically. But I find that of little real value. Contractors, if they care about technical credibility at all, seem to largely see it as a commodity. Something that eveyone with a PE has. And why shouldn't they? That's pretty much the message we put out into the world.

The strategies that I have employed with some success have been focused on establishing a different kind of credibility: being perceived as a "reasonable" project partner. Reasonable, from the contractor's perspective.

Specifically.

1) 80/20. Eighty percent of the time I try to say yes to requests thought to improve economy. That, I feel, gives me credibility on the rare occasion when I choose to die on a particular hill. It's a version of not crying wolf. If I behave as if everything is a big deal, then nothing will be a big deal. I feel that I have to pick my battles. I will even go so far as to permit mildly sketch solutions in areas that I feel are of little importance precisely so that I can spend that capital when something truly important crops up.

2) 2/3rd Percentile Calibration. I imagine all of my competitors lined up in order of increasing permissiveness. Then I contemplate the guy that would land 2/3 of the way up and try to push myself to do what I think that guy would do. This requires knowing the pulse of your particular market fairly well. A lot of the ideas that contractors come to me with have previously been implemented on projects where they have worked with other engineers that allowed it. I can't afford to be the one guy that makes all things not work.

3) I try pretty hard at the beginning of projects to steer the overall system selections towards conventional solutions. When I get permissive / fancy with the overall system selection, I often find that details crop up down the road that nobody has properly thought through. And then there is great pressure for me to "make something work" because I bought into the original system selection that generated the condition. I can't wait until cranes are on site to change my mind about using hollowcore.

 

[LittleInch]

They are very wise words, as usual, from KootK.

I was going to write something similar - choose your battles / hills to die on carefully.

One way to get over this is maybe along these lines to the GC and or client.

I have carefully considered your proposal / request and my professional judgement is that it will not satisfy the codes / requirements / too high risk ( take your pick) because of x, y and z. At the end of the day, it is my PE stamp and my liability in the event of failure or lack of compliance and I am not willing / able to make this change / do what ever it is that they request. You could add "other Engineers may have a different opinion, but then they will need to take full responsibility for the whole design", but then they just might take you up on that idea....

So as said, choose your hill to die on carefully and try not to get "aggressive". Whilst GCs can be a bit less errrr formal than maybe other professions, it isn't usually personal, it's just business.

 

[Lomarandil]

I find most contractors understand the concept "There are solutions which clearly work, there are solutions that clearly don't. There are a range of solutions which probably work in reality but don't work on paper. You come to me to get a stamped document that an owner/regulator will approve, and for that I have to show it working on paper".

 

[phamENG]

I find most contractors understand the concept "There are solutions which clearly work, there are solutions that clearly don't. There are a range of solutions which probably work in reality but don't work on paper. You come to me to get a stamped document that an owner/regulator will approve, and for that I have to show it working on paper".

Sorry, Lo - I don't really like this approach. To me, it implies that we are not capable of modeling the physical behavior of the things we're designing with any sort of accuracy. Sure, we can't always get it just right and we have limitations, but we can get close enough for most things. It probably comes down to a semantics question, and it's important for everyone to apply the same meanings to the words we're using. When you say "works", I'm assuming you mean it is code compliant. When a contractor says "works", they usually mean "it doesn't fall down." When you say "it doesn't work" and they build it and say "look, it isn't falling down so it does work" - you're both right for your own definition of what works.

So, then, it's not really a question of whether or not it "works." It's a question of whether or not we can all rely on it to work under the maximum design load for the service life of the structure. Because that's what the code is requiring, and the contractor can't point to anecdotal evidence of it not falling over when he did it last month. From there, two general options exist: we prove that it will work based on an analysis and application of required reliability provisions laid out by the code or as otherwise defined in collaboration with the owner if going above and beyond code minimums, or building it and performing a compliant load test to confirm it really does "work."

 

[Lomarandil]

Being on the construction side, my definition of "works" is mostly the contractor definition, real world performance.

Frankly, the longer I practice, the wider that range of "works in reality but not on paper" gets, because I see more and more things that don't calc standing. With the understanding that the socially and code-acceptable margins built in through factors of safety are usually pretty wide. I don't choose to live inside those margins, but some of my clients choose to do it (deliberately or turning a blind eye).

Now, I fully agree -- past performance is no indicator of future results. I don't know whether what the contractor has done before worked legitimately, or because they had more material strength or redundancy present, or it just never saw the design loading. Or it did, and they were just living inside the factor of safety -- not compliant with the code, but still complying with the laws of physics. So I perform that analysis or that load test, and put my stamp on it. That's my role. If I can't get those to work, the contractor gets to decide how much risk they want to assume.

 

[human909]

Almost "anything" is possible if you throw enough time, energy and money at it. So there is a possibility that you are saying "No" too often. If the sensible answer is "No." then explain it in those terms or in terms of risk. But often if you dig into things you might eek out a workable yes.

I've done several HEAVY move projects where the structural and geometric constraints were a nightmare. Limited cranage options due to access, limited skating options due to a weak floor and limited options to strengthen the floor. But no wasn't an acceptable answer. The answer was complex with skates, floor rails, monorails, custom jigs etc...

It was challenging and stressful but also very rewarding (job satisfaction and financially) for all involved.

1) 80/20. Eighty percent of the time I try to say yes to requests thought to improve economy. That, I feel, gives me credibility on the rare occasion when I choose to die on a particular hill. It's a version of not crying wolf. If I behave as if everything is a big deal, then nothing will be a big deal. I feel that I have to pick my battles.

Agreed.

3) I try pretty hard at the beginning of projects to steer the overall system selections towards conventional solutions. When I get permissive / fancy with the overall system selection, I often find that details crop up down the road that nobody has properly thought through.

I recently made the mistake of choosing an unconventional solution on a project due to the GC desire for a faster time frame. The contractor was my client. The conventional one was easy engineering but a longer lead time. That unconventional solution gave no end of headaches down the track from the end client. My desire to please the GC, gave everybody headaches.

Still at least my client recognised that my choices was only due to their own pressuring. I didn't lose a client or business.

 

[GaStruct]

I agree with picking your battles and for a while I was close to the 80/20 as mentioned above but I'm probably at 30/70 now. Recently, I have been strict about following the construction documents from the get-go and not trying to get any of their sketchy fixes to work for field errors. My logic is that they bid the job so they need to do it as shown or not do the job. There should be no surprises during construction.

I will say that most of the contractors I deal with purposely ignore the drawings, are too lazy to thoroughly look at them, or just want to make it easier for them at the expense of quality. A lot also just like to fight with the engineers and be difficult. Hence my new stance. An honest mistake in the field or thoughtful questions/suggestions by a genuine contractor yields a different response from me. Although this is rare!

When things arise, I simply tell them what they are proposing does not work and they need to do it "x" way. I'm as short and direct as possible. They argue with me less this way.

Maybe I'm harsh but contractors will relentlessly change your design to something subpar and then look to you to approve it if you let them too often.

 

[ghostdigital]

In my aerospace engineering-design world we have customer defined performance and functional specifications that we must meet with the end item. The most common pain point are those personal preference changes that occur just before the schedule requires the engineering drawings to be released to manufacturing. Even worse is when a change in required post engineering drawing release, therefore, we try to practice concurrent communications during the design cycle to ensure everybody in on the same page and has an opportunity to provide feedback.

When a customer proposes a late game specification change, they are expected to pay for that effort and the schedule may be changed as well. Knowing personal preference changes vs right or wrong as well as costing impacts is helpful when understanding the proposed changes. Manufacturing changes maybe proposed due to a non-manufacturable feature or requirement however these challenges can be mitigated with a manufacturability review pre-engineering drawing release. In general, we don’t accept end items that are not manufactured to engineering drawing requirements.

 

[Enhineyero]

Steps I take as follows:
1. Try to explain in simple terms why proposed solution will not work.
2. Try to supplement this with risk vs reward discussion. Most GC appreciate this because if anything goes wrong after construction its usually the GC who is asked to fix a defect.
3. If they still insist. I tell them I will not sign-off on this proposed fix and they can proceed at their own risk.

They usually backout after that.