I’m not an engineer, but I work in IT and work with engineers, analysts, and management. I have no idea what your knowledge or background is, but the engineers may be reluctant to get too technical in fear of talking over your head. I would make clear to them that you need specific, technical details and not to worry about to much jargon. If they’re reluctant for other reasons, it may be an issue for your management to address.

Talk less, listen more.

They’re probably (no offense) nerds, so let them nerd out and listen to them.

Then actually act on what they say, and soon they’re be telling you more shit than you want to know.

My husband is an engineer. Screaming, “what the fuck are talking about?” is probably not the way.

Have you asked them why they are reluctant to turn over the deets?

I’ve certainly withheld info because explaining DMARC is a lot more time consuming then just saying it’s a special type of spam filter.

This post is a little too vague to give real advice. You don’t tell us what industry you’re in. You don’t tell us if the engineers are the end users of the software or processes you’re working on, or if they will implement the software or processes you’re working on.

If they’re the end users, they might be concerned that the changes you’re designing are going to make their jobs harder. A lot of changes in the past couple decades aimed at “efficiency” have involved making people take on more work for no additional pay, then firing the administrative staff or other engineers who used to do that work. Even if that isn’t the sort of project you’re working on they are reasonably wary based on past experience. Or maybe it’s not clear to you how this will make their life harder but management will find a way.

If the engineers are writing the software that you are helping design, how are you helping to make their jobs easier and more fulfilling? It’s an unfortunate fact that software engineers are sometimes treated like misbehaving vending machines that will produce software if you force them to. If they are writing the code, there’s a very good chance that they know more about this process than anyone else in the room, but are they treated like they know more than anyone else in the room? Is their expertise valued or are they treated like roadblocks when they give their expert opinions?

Accept “I have no idea” as an answer, and don’t use it as an opportunity to push things in the direction you want.
learn to account for people being wrong, and don’t punish them for it.

Engineers want to be accurate. They don’t want to give answers that they’re unsure about or just speculating.
Early in their careers they’re often willing to, but that gets beaten out of them pretty quickly by people with deadlines. Expressing uncertainty often means the person interprets the answer in the direction they want, and then holds the engineer to that answer.
“It could be anywhere from 2-8 months I think, but we won’t know until we’re further into the design phase” is taken as 2 months, planned around, and then crunch Time starts when it starts to go over. Or revising an estimate once new information or changing requirements are revealed is treated as incompetence, even though more work taking more time is expected.

It’s in the self interest of the engineer to be cagey. “I don’t like to give estimates this early” is much harder to turn into a solid commitment than an earnest best estimate given the current known state of the project.

Similar for resources required or processes. Anything you don’t say is unlikely to be held against you.

My experience is you get the best response if they understand why you need the information and at what level of detail. They seem to respond well to clarity, organization and logic (who doesn’t!), so prepare your communications to include the background they need (how does your request help them in the long run), what it is you need from them (and in what format), and when you need it by. Trust is built by demonstrating your value to them. Think about ways you can help them get the info to you (start the work for them, book time on their calendars to focus on the request, sit with them and help them produce the info).

Side note: engineers sometimes offer information that is not executive ready - you will either need to translate or tell the engineer who the audience is for the information.

please give an example interaction that was difficult?

The deeper I get into a subject involving engineering, the less I can relate what I know effectively. If I’ve done the thing many times, I can talk about it more freely.

It boils down to, “I don’t know what I don’t know.” The only thing I can do is explain the long path of stuff I’ve figured out in order to get where I am at in my understanding. I don’t have a clear overview scope. I’m aware I have likely made mistakes even within what I know.

If you are asking me for official statements that can come back to me, I’m going to be extremely cautious in what I tell you and only speak about things I am absolutely sure of and have triple checked. Most of what I’m sure of is going to be unhelpful surface level information. Professionally, telling you anything that could be wrong is career suicide. Reputation is the currency of an engineering career.

The engineers have their own tasks and deadlines to deal with, why are you talking to them directly to get the information you want? You need to talk to their project manager to either give you access to the database in question, write a tool that generates the report you need or write a one time query to get this information. All of these things take time and need to be planned and resourced. I hope you’re not just walking up to people and asking for random lists of customers that ordered more than once in the last year or whatever?

As an engineer with almost thirty years of experience, I don’t want to be on the hook for telling someone the wrong thing. Also, if you want an estimate there are lots of engineers who won’t want to give an estimate of 2 months when you’re expecting 2 days. Then we have to explain that the entire app is a fucking unmaintainable shit show because we’ve been doing two months worth of work in two days by cutting corners and writing shit code and we know it.

Also they could just be shy introverts. But it’s probably a reluctance to commit themselves.

I say all this like a universal truth, but just by reading all the responses here you can tell it varies from person to person. You have to assess your team and figure out each individual. My experience is it’s a trust/comfort thing, but that may not be your case.

I’m a software developer, and I sometimes if I’m asked how something works, I can find it difficult to explain things in a way that would make sense to the listener, whether they are a PM or the client.

Other times, depending on the question, I simply don’t know the answer, and it could take hours for me to gain enough understanding of the project to even respond intelligently.

As an engineer, I hate having to repeat the same thing again and again so take notes and make sure you understand them.

Secondly know the product or project intimately relative to your level. For example if I work on the project and I know it from the code and infrastructure and everything else in addition to how it works for the end user then the least I expect is that the person asking the questions has used the software with a demo account on UAT or something so that my answers will not to over their heads. Knowing the product will also allow you to talk to clients better and you will know what it can and can’t do.

I’m ok with someone if I see they are willing to make the effort regardless of their level, if someone is coming to me to do their work for them , then I lose my patience fast and will very soon be less helpful and prioritize my actual work over their bs.

Finally as I said we are often overworked and not looking to have more things to do. We are the ones that have to stay late to fix someone’s mess or get called to patch an emergency zero day in some software used by the company on a weekend. In addition we support everyone else as without us there is no product and no jobs for the rest of you. We are at the bottom of the pyramid holding the rest up with the CEO being the prick at the top.

Finally dont just engage when you need something, get to know them and see if you can help them with something. Maybe a heads up about a project or client to avoid or some thing.

It is good that you want to bridge the gap and I wish more in your position would do so.

After reading your replies, I am on edge.

Please consider the following questions.

What is the power dynamic?
Are there good reasons to stonewall you?

What happened to the first few teams you worked with? Did the engineers involved advance in their careers? Do they talk with you still? What about their prior interactions with your team and department? Do those engineers still work at the company?

If you are confident you are there to help then just speaking to them like people. Don’t bullshit them. Push them up in their careers when you can. Get them what resources you can. Support them in their goals. Do a good job and you won’t get them to shut up.

They are probably unsure of your motives; are you analysing the business or analysing them? Software problems are extremely hard to estimate unless there is almost complete disclosure and discovery. It’s like asking people how long a crossword is going to take without seeing the clues. Or asking how long they’re going to spend on a chess move in 3 turns time. They are possibly cagey because you are asking questions they betray the fact you are seeing this as a management problem rather than listening to what they’re telling you about their craft.

Or possibly your manner of communicating is attuned to more socially intuitive people. Try presenting what you need as a problem for them to solve with a clear start and end. That way you’re collaborating, and they know when their obligation to interact with you is “done”.

Instead of open questions like “can you tell me how X is currently working?” try specific problem setting questions like “I’d like to see if we can make X process be 10% faster, what would that look like?” or “what would you say are the top two things that affect the time process Y takes?”

They may not want to offend you, because many of the answers might be “obvious” and, also, if they’re honest workers, as many are, there may not be any clear way to improve certain things as they’re already trying their hardest, and your investigation feels more like an inquisition.

Again, it may be that you’re asking someone “how can I get you to get this crossword done faster?”. It’s sort of the wrong question. Unless you’re willing to listen to their bugbears which might be the actual things affecting how efficiently things run but might not be the kind of answers project management want to hear.