I’m a business analyst, and a big part of my job involves working with engineers and product managers to gather detailed, in-depth information. For reasons I don’t fully understand (though I have my theories), I often find that engineers, in particular, seem oddly reluctant to share the information I need. This makes the process more challenging than I’d like. Does anyone have tips or tricks for building trust with engineers to encourage them to share information more willingly and quickly?
EDIT: Here’s a summary with more details for those who requested more info: I’m working on optimizing processes related to our in-house file ingestion system, which we’ve been piecing together over time to handle tasks it wasn’t originally designed for. The system works well enough now, but it’s still very much a MacGyver setup—duct tape and dental floss holding things together. We got through crunch time with it, but now the goal is to refine and smooth everything out into a process that’s efficient, clear, and easy for everyone to follow.
Part of this involves getting all the disparate systems and communication silos talking to each other in a unified way—JIRA is going to be the hub for that. My job is to make sure that the entire pipeline—from ticket creation, to file ingestion, to processing and output—is documented thoroughly (but not pedantically) and that all teams involved understand what’s required of them and why.
Where I’m running into challenges is in gathering the nitty-gritty technical details from engineers. I need to understand how their processes work today, how they’ve solved past issues, and what they think would make things better in an ideal world. But I think there’s some hesitation because they’re worried about “incriminating” themselves or having mistakes come back to haunt them.
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.
If anyone has strategies for improving communication with engineers—especially around getting them to open up about technical details without fear—I am all ears.
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.
Probably they’d rather drink a dogshit milkshake every single morning than use fucking JIRA, and they’re hoping you die of natural causes before you get a chance to force it on them.
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.
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.
As a dev, this definitely triggered me a little.
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.
I am the wife of a mechanical engineer, who’s brothers are mechanical and electrical engineers, who’s parents are electrical engineers, who’s best friends are aerospace engineers.
Basically I married into a family of robots, and I agree with this commenter here.
This is the crux of why senior engineers struggle to talk about work I think, and I find the best way for me to get them talking, is to try to learn something small about their work, enough that I can ask intelligent questions, and then listen carefully to the replies.
After a while they open up and I get to listen to the best rants about “special metals” or “systems architecture” or “braking systems in the railway”. It’s awesome.
It’s how I connect with my husband.
The other wives stand in a circle and roll their eyes about them talking about work because they don’t understand anything. “Oh there they go, talking about work again.”
I decided I didn’t want that to be me, and told myself I would listen when they were talking, listen when my husband was working from home. Learn to ask intelligent questions about his work, and eventually, I knew what he was talking about.
Enough that I now freelance in condition monitoring, giving me yet another way to connect with him.
Ask intelligent questions, get excited about the replies, encourage them so they know you won’t be insulted when they assume you don’t know about <speciality subject> and you will have them opening up in no time.
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.
I’m a developer too and sometimes I say “I don’t know” knowing full well the shitstorm it’ll bring. I’m a few years in and I just don’t give a fuck if that pisses off the person on the other end.
I just don’t have time for games — a few times I tried to give a better answer but didn’t have all the information I needed and every time it came back to bite me in the ass.
I love being a developer with all my heart, I don’t come into the office and I love my job. But I won’t play politics, kiss ass or put lipstick on a pig. Why would I? In my experience doing so is a lot worse than admitting I don’t know something; if someone wants to throw a tantrum that’s fine but they can do it on their time. If we could just get off this time suck call I can find the information I need pretty quick and get you an answer ASAP.
Oh man, there’s been a few times over my career where they asked me what seemed like an easy enough question to them, but it’s in some terrible legacy code that were never given any time to fix, that fixing itself would be a huge ordeal and I respond with something like, it’ll take a day or two to get a confident answer to that.
They usually say no thanks after that, but they have sent me down that rabbit hole before.
Reminds me of my previous job that I stupidly took on because they wanted to go from the developer’s custom fork of Rails 3.2 up to Rails 6 (just released at the time).
The entire thing was spaghetti code and it was so out of date that I couldn’t really do incremental version updates due to libraries just straight up missing or being unmaintained.
My other mistake was thinking that because I had years of Rails experience I could take this on. As expected bugs occurred and everyone pointed their finger at me. I could barely make out what was going on and wasn’t familiar with unit specs at the time (ouch) so it was a poor experience on my end.
(My favorite was them doing currency conversions but storing the results as floats in the database. During a monthly scheduled job thousands of transactions were 1¢ off due to poor rounding. I felt ashamed because before working there I always knew to never do this, but apparently I didn’t do an adequate job of confirming how it worked in this app.)
thousands of transactions were 1¢ off due to poor rounding
Maybe the code was so poorly done on purpose so that developer could steal those pennies. You took his place, and now he’s off in the tropics living the dream!
