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.
Thank you!!! In fact I have been emphasizing that I need to know the technicals, and that they should not worry about getting too detailed, because I need a very thorough understanding so I can best come up with a process for how they do file ingestion (which mostly is up to them) but then also how the information gets to them, and how they output the data, in the best, most thoroughly documented (without being uselessly pedantic) way possible. Which is pretty much going to be getting everything into JIRA, and eliminating all the uselessly disparate systems that people are trying to stitch together currently. I need to make sure all the teams along the road of this process are communicating with each other, and at are at least having a basic understanding of the whys behind what is required of the process. And of course that it is efficient and fast and definitely not cumbersome.
there’s a few things here that trigger red flags for me:
oh good! because it’s probably ill-defined and nobody really knows and figuring that out involves a lot of reading other people’s shit code and we have work to do
oh you mean do worry - you want to know exactly how it works… sorry bud, no time, that’s a lot of energy
ugghghh documentation is for people that don’t understand that documentation is out of date the second you write it: don’t drag me into your futile attempt to make a static artifact that i’ll need to maintain in the future when i update a living system
okay but that’s really dismissive… this is work that people have put in - even if it’s shit and everyone knows it’s shit, it’s disheartening to have things thrown out… and what they do now they know how it works, they know the caveats… you’re talking about coming in, getting a cursory understanding (what you think you can understand everyone’s problem when the people that built the thing don’t have the full picture?) and then planning out and telling them what to do
if you want help from engineers, ask them for help to build a new thing: don’t ask them for help to explain something so you can tell them what to build. we’re creative, and we love solving problems and we hate robotically implementing someone else’s vision
In addition to what other people have said, “the technicals” and “getting too detailed” is ridiculously vague. There is always a too detailed. Software engineering is a giant world and engineers specialize, and even other engineers with a slightly different specialty don’t really want to know all your “technicals”.
Be specific about what details you’re interested in and why if you want to build trust. Demonstrate tangible investment in figuring out what your gaps are and ask specific questions, and be clear about what kind of answers you want. “Thorough understanding” is not helpful.
100%. I regularly have to tell DB or App people that I only need the high level answer because the details are immaterial to the discussion at hand. I might be personally interested, but I got shit to do…
Have you stopped to consider that the current solution might be better than an all JIRA one? I can definitely see a lot of “file ingestion” pipelines that would be much better handled by a bunch of different systems intertwined than JIRA, especially for automated file ingestion (which I guess is what you’re doing? Hard to know but hard for it to be something else).
I don’t know what’s the situation there, but if I was an engineer on one such project I would explain to the person why it’s not feasible, but it could be that that got interpreted as not explaining stuff. An easy to understand example would be someone asking what’s the best way to replace a car (that has been cobbled to pieces from separate cars) with a shoe, and then you try to explain to the person that that just doesn’t make sense they say that you’re being uncooperative and not explaining how the car works so you can make the shoe do the same.
Look, I’m not saying this is your case, but it feels like you’re approaching this the wrong way, you have a new solution without even understanding the current one. A better approach would be to gather the engineers and ask them what are THEIR problems with the system, and how would THEY like to fix them. If the Jira thing comes from higher ups tell them that this is a new requirement, but let THEM solve the technical issues, you are unlikely to be able to even if they explain them to you in detail.
Ok, so I AM asking the engineers that. But we need to be angle to track the implementations for each client, and that is why we are using JIRA. I’m very open to alternative ideas, but one of the problems is that teams involved are using salesforce, JIRA, and
AtlassianAzure, and this is causing a serious dearth of communication, as well as there being no way for anyone to get a bird’s eye view of where implementations currently stand. Frankly I have a lot more autonomy and control over this thing than anyone in this thread seems to be used to, so if people have better process ideas, I am all ears.Since one makes the other, it’s like saying “Rav4 and Toyota”. I’m assuming you mean Confluence (aka Flatulence; or Confluenza for the stress-based sickness from watching the spinning please-wait-web-loading symbol too much).
Quit it.
No one uses those tools; they get used by the tools. They’re slow, cloud-based, usually under-budgeted for the great gobby java blob-wrangling clown shows they are.
If you’re asking deadline-driven engineers to use a slow cloud app like that, with their caffeine levels, and invite real feedback without fear of penalty, you’re going to get some interesting opinions. Please, try to find something more usable for the non-deadline-helping work-tangents like documentation; which are important, but not on-fire-important like every other bloody thing on the list.
Sorry, meant Azure
Ok, so it seems that you’re only talking about managerial stuff, whether to use Jira or Atlassian, engineers don’t usually care about that, and there’s usually no technical reason to use one or the other, so it could be that you’re asking them to explain how a car works to try to figure out the best shoe to wear.
Also no one that’s not involved in the project will have better process ideas because we don’t know the process, and apparently neither do you from what you’re saying, it’s the thing the engineers “refuse” to explain to you. I think at the end of the day you need to sit down and explain what the higher ups want and listen to their ideas on how to get there.
absolutely this… engineers want to help you design solutions… if you come to me and ask me to explain something so that you can design a solution that i’m then told to build you’re removing all the fun out of it and i ain’t gonna help with that