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.

  • Pup Biru@aussie.zone
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    Ā·
    edit-2
    6 hours ago

    thereā€™s a few things here that trigger red flags for me:

    not worry about getting too detailed

    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

    because I need a very thorough understanding

    oh you mean do worry - you want to know exactly how it worksā€¦ sorry bud, no time, thatā€™s a lot of energy

    thoroughly documented

    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

    eliminating all the uselessly disparate systems that people are trying to stitch together currently

    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