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.
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?
Was trying to compose a similar statement on that lack of details. Like, my background is scrum/ agile software development and if a random BA called me up out of the blue for project details, my first response is going to be "I'm busy, talk to my scrum master and/or manager" and failing that it's likely going to be the minimum amount of information required to get said BA to leave me alone so that I can get back to work. Plus, unless I know that my audience has the technical capacity for low level details, I tend to leave them out (I don't mind answering questions, but I also don't have time in my life to spout information that's going to go in one ear and out the other).
This is extremely insightful. Thank you. To keep it somewhat vague, I am trying to optimize processes surrounding file ingestion. And I am trying to eliminate all the roadblocks caused by siloing of information. We have an in house file ingestion "engine" if you will, and we have really been rebuilding it from the ground up because its original function was not what we are using it for. So there are problems. To date, we have be MacGyvering the fuck out of everything with a pen knife and some dental floss, but we got through crunch time, and now we need it to be smooth, and by the numbers. Easy and clear for everyone.
Well that might explain some things.
Not to throw shade at your company but that process is so backwards that it's no wonder the engineers are sparse on the details. I saw another comment likening software development to a crossword puzzle, which is a pretty good analogy. To further it, changing software once it's done is like trying to swap out a clue/ word once the rest of the puzzle is built. It's theoretically possible, but depending on how the puzzle is designed, it can range from an absurd amount of work to nearly impossible. Given the way you've described the state of things, your engineers are probably low on goodwill to boot.
I've worked on cobbled-together crunch-time hell-projects and the last thing I'd want after getting free would be a random BA coming to me about details that more than likely packed with the project PTSD and would very much like to forget. Doubly so if it's issues that I bought up early in the design/ development process (when they would have been comparatively easy to fix) and was dismissed by the powers that be. I can only speak for myself, but I can only take so much "that's not a priority", "we don't have time for that"/ "we'll see if that becomes a problem in the future and deal with it then" before I throw in the towel, stop keeping track of everything that's wrong, and just bin the entire project as dumper fire run by people who would rather check boxes than make things better.