How to respond to "this MUST be done" when I don't know how to do "this"?

Question

I work as the only engineer at a small company (20 employees) in the manufacturing sector. I've been with the company for three and a half years and feel I've added significant value to their systems in this time - and many times my bosses have said they are impressed by and appreciate projects I've completed.

There have been a few difficult to diagnose problems that have been going on for these years. While I have invested a lot of time in research, reaching out to vendors and other potential knowledge sources, and testing - and have managed to reduce the severity, frequency, or both - I have not "solved" these problems and my work with them is ongoing.

Whenever there is a flareup of these issues, I get called into a meeting with my two bosses to get a lecture on how serious these problems are, that we HAVE TO find the root cause and they MUST BE fixed. My first tack of response is to go over the investigative steps I have taken, the results of each step, and the progress that has been made in reducing severity and frequency. While I think this helps to a point, it is typically not accepted as sufficient to end the meeting, and I get the lecture again.

If I run out of talking points and under pressure for an answer NOW say "I don't know at this time" I'm told, "Well, we pay you to know this" and get a lecture on how maybe I'm not the right fit for this position.

Is there any additional approach I could take to try to diffuse these (very stressful for me) meetings?

EDIT: A theme in the answers is to look for a consultant or other source of information (e.g. engineering.stackexchange) that would help bring in more knowledge. I'm thinking about how to propose sharing our problem in more detail to a forum.

For a consultant, given that my identification of equipment and software that would help in problem diagnosis has been rejected as too expensive (each item in the tens of thousands range), I'm concerned about budget of any consultant. Also, the problems are with a unique piece of heat treat equipment that the vendor has been unable to provide a fix for (although they've been vital in the mitigation I've managed so far) and I'm not sure how to identify someone with the right knowledge to have a good shot at the problem.

This may be going too off-topic to the original question, but any suggestions on finding a good fit consultant would be welcome.

Answer 1

What do you need in order to be able to solve the issues? Come back with a proposal.

Perhaps you need additional training in some technology or methodology to be able to do the root cause analysis. Perhaps you need a consultant (from a vendor or a third party) to come in for a period to help you diagnose the issue. Perhaps you need management to help you escalate your support requests. Perhaps you need upgraded software. Perhaps you need more time to focus on the issue and you need someone else to take on certain tasks for a while. None of these, presumably, come with a guarantee of success. But a plan for how you're going to move forward not only makes you seem proactive it lets other people assist you.

When you go to an expert (a doctor, a lawyer, a plumber, whatever), it's perfectly reasonable for that expert to determine that they need to get additional assistance. Your doctor might need to call in a specialist to help with a tricky diagnosis. Your lawyer might need to consult with an accountant to help her prepare some documents. In this case, you're the expert so you get to determine what additional assistance you need. Your managers likely don't care about (or, frankly, understand) the steps you followed to troubleshoot the issue, they just want to know what you need to solve the problem permanently.

If you have proposed solutions or at least things that would diagnose the problem and those solutions are rejected as too costly then you know that the business sees the cost of the problem as less than your proposed solutions and that you can calmly point this out when the problem flares up again. It's perfectly reasonable to say

"I know you want the root cause of the problem to be identified. I've proposed replacing the foo and upgrading the software on the bar. Either of those would likely solve the problem/ pinpoint the root cause/ etc. That proposal was rejected as too costly. If you would like to revisit that, I would be happy to get some up to date pricing from the vendor. Otherwise, I can continue to work on mitigating the issue but we probably won't be able to identify a root cause unless we get very lucky."

Answer 2

I work in manufacturing myself (HW test). You are dealing with recurring themes in manufacturing problems: "flare-ups" which occur seemingly without warning and where it is really hard to find and address root-causes.

Unfortunately, if you're the only engineer in the place you may find yourself overwhelmed some times regardless of how skilled you are and how hard you work. At the end of the day, product has to ship, people need to get paid and suppliers need to be scheduled. This stuff won't relent just because the problems are "hard".

You bosses feel stressed because they're afraid that one of the flare-ups are going to result in a line down with no way to predict when it is coming back up. I would not take their lectures too personally, you might really need help and it does not reflect badly on you to admit to that.

In other words, part of "owning" a problem is knowing when you're overwhelmed and when you need assistance. The way for you to "win" this hard situation is to coordinate a plan for getting help-- don't just put it on your boss' lap and make them solve it. The help you coordinate can come in different forms as Justin's answer outlines, but you want to involve yourself as part of the solution.

Answer 3

If you can't cure an intermittent problem, work out a set of changes that will help you diagnose it next time it does arise.

Answer 4

The attitude of your bosses is typical of managers without even a speck of technical knowledge or even average intelligence. They are merely bullying you rather than providing you with the budget and resources you need to fix the problem. They do not deserve your expertise and dedication.

To handle this situation, communicate the issues in detail to the vendor or manufacturer and keep a detailed record of what you have communicated and when, such as sent emails or copies of letters, online forms etc. Assure the thugs... er... your managers that you will be able to fix the issue as soon as you receive some additional information from the vendor or manager missing from the documents they provided.

If the vendor's response is insufficient to fix the problem then respond back with additional questions. Report to your bosses that you are still in discussions with the vendor and you are getting ever closer to fixing the problem any day now.

Meanwhile (and this is the most important part of handling such managers), look for a job in a better company. The people you now work for certainly do not deserve a dedicated employee like you. If you keep working for them you will lose. They will not hesitate to sack you at a time convenient for them. Better you leave at a time you choose before that. Besides, if dedicated employees slave away for such managers it will only encourage them to continue their perverse attitudes and they will get worse over time.

Answer 5

All of these responses, as you noted in your question, focus on solving the problems that lead to your uncomfortable encounters, in an effort to reduce or eliminate the encounters with your bosses. While you may need help with your approach on that, I think a more useful response is how you deal with the encounter itself - because in the world of engineering, you are likely to always face things like this. Bosses that don't exactly understand what you do, situations that arise without warning and meetings where you are supposed to talk about it.

The key here is to become the expert that they are asking you to be. Highlight your clear concern for the problem, and reassure your bosses that you are the guy for the job. Show them the experience you are gaining, the dedication you have and the effort you are putting in to make progress. They may not want to hire a new person knowing that they are investing a lot in you, in terms of time and experience - and your job is to convince them that they can't find anyone better.

First, if during the meetings you review your technical approach to the problem, steps you've taken, results, etc. and that does not end the meeting, then you were too technical. Your audience did not understand how what you said relates to their problem, and for all they know you are making it up. That does not build trust. You need to find a practice audience to explain the situation to that is equally technical to your bosses, and hopefully with other similarities. If that person can understand it, then maybe your bosses can.

Second, I don't know if you are doing this, but it sounds like you also need regular communication with them on these issues. It would probably be helpful to have weekly/bi-weekly/monthly meetings on your progress, and you lead the meeting. This will help you practice your communication, it will demonstrate to them that you care about the issues, it will demonstrate your sincerity in resolving the issues and it will also allow them time to think about and understand the problems when they are not in "crisis mode" and probably cannot focus on your work as much as they are on the crisis. Also, it will put you in the role of "authority" on the matter - in the other meetings, they lead and you get thrown around. With this, you are the lead.

If they refuse to do this or "don't have time" and cancel, make the request anyway, send them written reports anyway - on time, every time. Even if they throw them away, at least they have that as a reminder that you are putting in an effort. This may help with their technical education - you can force them to be more technical, but maybe they will pick up on a few things with these meetings. And even if they cancel, you were the one with the request - you were in front of the problem.

Third, start the crisis conversation with, "I've given you updates up to date X, and here's what I've learned since then." And add, "And I still can't guarantee that this won't happen again. Maybe this experience will lead to an answer, however, here is the downward trend to the occurrences, etc..." You mention that the issues are less frequent, saving money, etc. Quality control is about reducing error, not eliminating it. If you know that you have reduced the problem, then you need a chart or graph or something to demonstrate that. These meetings can be a reminder that you have improved the situation and, in that regard, you are the right guy for the job.

Fourth, you need to have several "to do" items when you walk out of the crisis meeting. Tell your bosses you will follow-up with an assessment / report of the current situation by tomorrow / next week. Be sure to send that report or have that meeting. Schedule it before they leave if you can - and if they cancel, send a report anyway. Show them that you are worried about this even when they are not and even after the crisis is over. Fundamentally, that is what they pay you to do. Worry about it and hopefully solve it.

Similarly, make it a point to do another follow-up later - maybe a week or month later. Sincerely analyze the problem, the data you got and then communicate the direct actions you took and/or things you did different based on the new experience.

At some point, they will be saturated with data, meetings and information about the issue. They will start to understand you, what you are doing and why they need you. Or else you will gain some great skills and be able to take those to a place where your work is better appreciated.

The key here is to learn how to handle the situation. Your bosses know that you are stressed by the meetings. They are being bullies. Bullies love it when you are scared because that gives them the control. When you start asking for more meetings, you hand them reports and you become confident that no one else can do this job better than you, then you begin to be in control and will start to have better meetings (or else you need to leave anyway).

Answer 6

Without a greater level of detail, it doesn't sound like you are being asked something you shouldn't be able to do. You are being to asked to do something you should be able to do.

The most effective means to end stress is to dig deep and solve the problems they are asking you to solve.

If you find yourself feeling that with a limited sounding-board of you, yourself, and you, it may be time to suggest that another engineer be brought on. If the new engineer DOES know how to solve these problems, GREAT! But even if he doesn't, it is much easier to work on the harder problems when you have someone to brainstorm and work with than to go it alone.

Answer 7

I've been on both sides of the table - the engineer who can't find the answer to a problem, and the manager who needs to show something to a stake holder and is blocked by an engineer who can't figure out the problem.

It sounds like the real problem is not that they won't give you more time - obviously they will have to give you more time until you solve your problems. It's just that they don't empathise with your situation, and instead put the blame on you apparently not doing enough.

The reason for this is because assuming someone is lazy and incapable to do a task is much easier than understanding the intricacies of the technical world. You understand that it's hard, but they don't. They'll just assume you're lazy.

I know that your situation might be incredibly different with lots of subtleties and the people you work with might not be the best, but a dialogue like this has helped me and other people I know:

• Manager : We're two weeks past the delivery date, and we're waiting you you for the Foo module.
• Engineer : Look. I know that this issue is causing our company significant problems, not to mention that you have to explain and account for the delays to the CEO and the customers.
• Engineer: I'm sorry about that, I really wish this problem had an easier fix and we're working hard to make this alright soon.
• Manager: I don't care. I need the fix RIGHT NOW.
• Engineer: Please try and understand, if there is something I could have done right now, I would have done it already. We're on the same team. These kind of things unfortunately tend to happen and we'll try to prevent it from happening later. But now we are working hard to fixing this.
• Manager: I don't think you're qualified for this. Maybe I should just hire someone else for this position.
• Engineer: It will take time to hire someone new and on-board someone else, so let me focus on solving this issue for now.

These are thoughts and guidelines that have helped me in the past:

• Understand and empathise with their urgency. It's quite likely that they've got a manager yelling at them - their performance reviews might depend on how quickly you deliver, or they might have to apologize to, or worse, lose a client or customer.
• Tell then that you're on the same team, and you're working towards finding a solution but sometimes software is unpredictable. If you can genuinely relate to their problem, most people will be able to relate to yours.
• Regular communication helps - if you're finding a problem or falling behind, drop a note saying that you're experiencing problems but are working towards fixing them and getting back on schedule. It's a whole lot better to do this than to see a delay of multiple weeks and then cut a sorry figure.
• Don't spend too much time defending, justifying or providing excuses. You may have very good reasons for not doing what was required, but they simply don't care. You may have had health or personal problems too - but ultimately what your higher-up will see is whether you did your work or not.

A few notes:

1. I might appear a bit callous and say the blame lies on you. That's not what I'm implying. I'm saying that most people simply lack the energy and emotional bandwidth to make the effort to really understand what your problems were. And unless you can do a good enough job of explaining them - they will take the easy way out and assume that you're lazy.

2. If you work with people who continually ignore your requests for help and refuse to understand your perspective - they may be toxic and if you can't deal with them your only option is to look for other jobs.

3. If you regularly find yourself unable to cope and missing deadlines and requirements - then you can consider requesting smaller and simpler tasks for sometime until you get up to speed. It's always better to be someone who actually delivers small tasks within deadlines and good quality - rather than someone who takes larger tasks and doesn't deliver at all.

Answer 8

1. I suggest reading about TRIZ https://en.wikipedia.org/wiki/TRIZ . In general, it is about making inventions, but it explains how to think about problems. Probably, you could borrow something. In particular, they tell you ask questions like "what would you do if you had infinite resource X" (zero/infinite time/size/etc).

(I myself found TRIZ an interesting reading, the idea was very promising, but it did not help to code typical tasks, find bugs in colleague's code, or invert workarounds for 3rd-party bugs. On the other hand, I learned something, but it's difficult to tell what namely I learned, probably, learned not to do what need not be done.)

2. Technically, in my area of expertise such intermittent errors can happen when multiple threads compete for shared resources. The synchronization primitives are even worse than global labels of the first programming languages of 1960-s or 50-s (they act globally, even if their syntactic visibility is restricted). A possible solution is to have a number of worker threads that pass Runnable-s between them. (That is, one thread per resource, the jobs are passed from one thread to another.) In code, it looks like

thread1_handler.post(
    boilerplateStuff{
        ... using the 1st resource ...
        thread2_handler.post(
            boilerplateStuff{
                ... using the 2nd resource ...
                ...and so on...
            }
        )
    }
)

That is, probably the problem may be solved by refactoring. Such refactoring cannot be done quickly, but if you have no other option...

3. If you have problems with a 3rd-party stuff, it may be helpful to ask that 3rd party for additional resources, e.g. for a bug fix or for additional docs. Use your manager's help to file the request. On the next meeting (when the issue flares again or when some amount of time passes, e.g. 2 weeks), you tell your manager that you need the 3rd party to provide that additional resource, and they do not reply.

Then your bosses will lecture the 3rd party.

(I very well imagine how the 3rd party manager sees a prototype and says: "It works! Excellent! We start sales next Monday!" and the engineers cannot explain that the prototype stores its state in a static global variable while the API suggests thread-safety. Seen this in a real library.)