I think people have already done a god job of covering the likely concerns. Here are the things I would emphasize.

Bear in mind that a lot of developers just hate doing documentation. :-}

Make sure that their management has made working with you a part of the engineers’ work load and goals. No one is going to provide good information when every minute they spend is putting them behind on things that directly affect their careers.

Provide them with a context for what you are trying to accomplish. Tell them the why and how, not just the what. That information can be very general or it can be at the level of providing specific examples of how you intend to present the information you gather. Find out what they would like to know, particularly since it’s likely to vary from person to person.

Keep in mind how different people can be. There are reasons for the stereotypes about developers, but their are pointy ends on every bell curve. You are likely to find a few people who communicate very well and can help you get the information you need from those who do not.

You sound like you have good intentions and the skill set for doing this kind of work. Don’t let negative responses discourage you. Work with the people you have, treat them with respect, and make sure they get credit for the work they do with you. Let them see what you’re doing and ask for feedback. There are going to be things you can’t control in the process, but if you work openly and in good faith people will usually respond in kind.

first, you’re talking about software “engineers” which means you aren’t talking about engineers in general.

and there’s a good chance none of them have ever had an engineering course in their life. they’re hackers who are good at making code.

the reason they probably seem reluctant to share is that what they’ve cobbled together with bubble gum and bailing wire is difficult to explain quickly and thoroughly AND they’d be taking time away from their assigned tasks to do so without having any change to their deadlines.

stop blaming them and start blaming their management for not giving them the time and permission they need to help you. go to the management and say you need so-and-so to be assigned 40 or 80 hours specifically to help you understand these widgets.

and in the future you need to push for clean up, documentation, lessons learned, and training to be part of every project estimate.

I’ve tried to make it clear that I’m not interested in punishing anyone for past decisions or mistakes—on the contrary, I want to learn from them to create a better process moving forward. My goal is to collaborate and make their jobs easier, not harder, but I think building trust and comfort will take more time.

I’d wager that the engineers have experienced such promises in the past and got burned. Engineers, by nature, are very analytical. Re-gaining trust that was once burned will take a lot of work. And managers like you are exactly the kind of people that burn engineers.

I work in a fairly toxic work environment.

The reasons I do what the engineers are doing are,

1. A lot of times people will ask me questions and I give them answers. Then something will go wrong and it will somehow be my fault that I didn’t mention it to them (they didn’t ask, and I don’t know the specifics of what they are doing).

2. I have my own goals and projects for the year. Why should I give you a significant amount of my time when my salary/bonus will not reflect helping you in anyway.

3. Job security.

These might sound bad, but that is how it works in corporate America

Edit: It sounds like you need management on board with you before you can fully continue

Keep your promises and tell the truth. If you don’t keep your promises, be the first to acknowledge the failure.

I was an engineer for a long time and among my peers the problem we had with management was often that they had a slippery relationship with the truth.

Also, demonstrate forgiveness within the organization for technical mistakes. If your engineers don’t want to share the bad decisions they’ve made, look for aspects of your company culture that punish people who admit mistakes.

One example would be times when someone spoke about a mistake they made and then was relieved of responsibility because of it. That’s an example of punishing the admission of a technical mistake.

A lot of great answers here, but there’s another possibility I haven’t seen mentioned yet. When you are gathering information like this it says to the engineer that you want to change things, and they don’t know if that change is going to make things easier or harder for them. Usually things only ever get harder as a project lives longer. So they’ll be less incentivised to help you unless you give them an idea of what you intend to do and specify what problems you intend to solve to make life easier for them personally.

Also, as an engineer, things like this I generally see as less important than making sure the product works and that development is processing on pace. Having to explain everything about my job to someone coming in with 0 prior knowledge is a huge waste of time.

One tip I saw mentioned works well in this situation: get them to start complaining about things they hate about the current processes. Everyone likes to complain because it is cathartic.

It will help if you can educate yourself before talking to them. Present the info you have and ask them to fill in the blanks or make corrections. Must engineers like to solve problems, so present this as one for them to solve like a puzzle. Engineers are generally not novelists. Don’t ask them to just start spitting out history of The Process to you.

As an engineer you learn to be very careful about what you say to non engineers.

A trivial example.

What if we make change x?

It’ll make some things harder and some things easier.

One week later.

Why are you having problems? You said doing x would make things easier.

More complicated example.

Can this be used for real time control?

Define real time.

Just answer the question.

I can’t it’s a bad question. I need to know what you are trying to control.

I’ve worked very closely with engineers and I’m engineering adjacent myself. Most of the highly technical types I know in every field (myself included) struggle to talk to people about their job because they no longer know what normal people do or don’t know and they don’t want to come across as condecendong. Like for me the basic refrigeration cycle feels like something everyone should know but I logically know that actually isn’t the case and at the same time I don’t know where the laymans actual knowledge on the topic begins. Like do I need to start with explaining that boiling liquids remove heat? Do I need to start with what boiling even is? Do normal people even know that things boil at different temps at different pressures? If I start explaining any of this are they jist going to look at me like I’m an ass and say “Of course I know how thermodynamics works”? Eventually I just decide it’s better to not to talk to them.

At the same time though, if you do manage to break the ice with them then you are more likely to sucessfully get a passionate stream of consiousness rant from them because they’re passionate and now they know that you can be trusted not to see them as being condescending when they overexplain. Honestly the best way I’ve found to break the ice with technical types is to get them to start complaining about some part of their job. That also sounds like exactly what you’re looking for if you’re trying to make their jobs easier. But if they start seeing you as someone who it is safe to complain to then they will start seeing ypu as someone it is safe to talk to about other things.

Also as always there is a relevant XKCD.

https://xkcd.com/2501/

I’m an engineer for past 20 years ,and the moment I get a whiff of some biz person fluffing bullshit I check out. Not saying you’re like that but something to be mindful of

So be real, honest, straightforward, put in effort into understanding the technicals so youre not just a sales annoyance or engineers will write you off right away IMO

Also I don’t think some people realize how busy or hard engineering can be. I’ve been working my ass off on a ground up new product and a lot of stuff just falls to the wayside out of lack of time

There’s also !askelectronics@discuss.tchncs.de !engineering@sh.itjust.works among others

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.

Frankly, it’s tiresome trying to describe technical details with business analysts who glaze over something you’re passionate about, treating it like nerdsprak. If the engineer has spent any amount of time producing a solution, you can bet he’s passionate and invested. Give credit where credit is due and don’t sound like an obnoxious condescending douchbag when doing so. People can tell when a disinterested person is giving fake praise. It’s quite different when a crowd of peers is giving recognition of a job well done. And no, you’re probably not as smart as they are in their field of expertise.

Also, listen to their input. They don’t want a product with their name going live with a feature the bean counters want, but the engineers know make the product worse. It’s like a mom watching your daughter to go to prom with a cheap haircut because dad as too cheap to fork out for a perm. You know what I mean.

If you are saying things like ‘I’m not interested in punishing anyone for past decisions or mistakes’, I think I can see the problem.

Install linux/*bsd on your work device (that you take into meetings). Respect from engineers will immediately skyrocket : D

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.

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?