this post was submitted on 11 Jan 2025
67 points (95.9% liked)

Ask Lemmy

27414 readers
2127 users here now

A Fediverse community for open-ended, thought provoking questions


Rules: (interactive)


1) Be nice and; have funDoxxing, trolling, sealioning, racism, and toxicity are not welcomed in AskLemmy. Remember what your mother said: if you can't say something nice, don't say anything at all. In addition, the site-wide Lemmy.world terms of service also apply here. Please familiarize yourself with them


2) All posts must end with a '?'This is sort of like Jeopardy. Please phrase all post titles in the form of a proper question ending with ?


3) No spamPlease do not flood the community with nonsense. Actual suspected spammers will be banned on site. No astroturfing.


4) NSFW is okay, within reasonJust remember to tag posts with either a content warning or a [NSFW] tag. Overtly sexual posts are not allowed, please direct them to either !asklemmyafterdark@lemmy.world or !asklemmynsfw@lemmynsfw.com. NSFW comments should be restricted to posts tagged [NSFW].


5) This is not a support community.
It is not a place for 'how do I?', type questions. If you have any questions regarding the site itself or would like to report a community, please direct them to Lemmy.world Support or email info@lemmy.world. For other questions check our partnered communities list, or use the search function.


6) No US Politics.
Please don't post about current US Politics. If you need to do this, try !politicaldiscussion@lemmy.world or !askusa@discuss.online


Reminder: The terms of service apply here too.

Partnered Communities:

Tech Support

No Stupid Questions

You Should Know

Reddit

Jokes

Ask Ouija


Logo design credit goes to: tubbadu


founded 2 years ago
MODERATORS
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] empireOfLove2@lemmy.dbzer0.com 21 points 13 hours ago

Real life mechE here. I'll tell you how my brain works.
99% of the time when I get an odd request from outside of the department, it goes one of many ways:

  • the request is literally not in my scope of work and I let them sit for a day or two and then politely deny with a CC to my manager.
  • the request is so vaguely worded that I could give a 2 sentence answer or a 20 page pdf answer or a PowerPoint full of flowcharts, and all would be "right", leaving me in a state of decision paralysis and needing clarification.
  • the request is something I can help with but I don't know your technical capability levels, so I try to keep it very generic and high level as to not simply knock you over with a technical dictionary.
  • the request is in my scope of work and very doable, but I do not want to inadvertently share information that I may not be allowed to divulge freely to other parts of the company.
    And of course, there's a lot of CYA reluctance too depending on what's being asked.

If you're asking first or second level engineers things like "how does your technical work flow do it's thing?" you are starting at the wrong level for a documentation project of this massive scope. Engineers have managers whose job is to translate requests into technical terms and figure out who is the best at doing what. That's what mine does: he takes a super weirdly worded ECR (engineering change request) and translates them into technical steps and clear direction for me. Then I can pick out the details needed to make it happen, confirm them, and document them.

You need to define clear needs out of your request: start with your end goal, the processes you need, the mechanical details of the processes you need to write, how much detail you are comfortable with, and the format in which you want it . and take all of that to the senior or director level of whatever department manages those systems. They may or may not know the exact information you need, but it should be their job to delegate and translate the request such that their reports can collate what you need in the form that you need it. And because it's the director delegating, the engineers have inherent CYA and will be a lot more comfortable giving you what you need.