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.
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.
Thank you for the positive response, and for not automatically assuming I’m some corporate asshole drone 🤣 . I have leadership support from all teams involved.
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.
This is brilliant. I often suspected they did not want to “incriminate” themselves, and I have tried assuring them that that is in no way what I am about. I am looking to optimize processes, and I am very eager for their ideas on what would work better than what we’ve been doing.
Verbal assurances mean little to many. At least put it in an email. Otherwise CYA dominates.
And remember the docco kicks around forever. Indemnification until retirement is impossible to ensure.
And, as our RedHat TAM rediscovers, we can bring that shit out of the archive to prove a point … or to heckle about overblown systemd promises, but that’s PTSD for another venue.
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
A million times this.
That last paragraph hits home, but in a sad way for me. I spent most of the last year working on a new project to streamline one of the biggest time sinks we have, and as we’re coming up on having an MVP ready to start beta testing, my org just dumped the entire team other than 1 guy. So I lost the guy who was my peer/dba on the project, and the dude who knows how to run the driver software.
Going to try to see if we can salvage what we made since it’s still needed, but fuck that wrecks a ton of time and effort. And really sucks cuz my team had to pick up the slack while I was trying to get this working, and we don’t even have anything to show for it…
