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.

  • ristoril_zip@lemmy.zip
    link
    fedilink
    English
    arrow-up
    7
    ·
    6 days ago

    first, you’re talking about software “engineers” which means you aren’t talking about engineers in general.

    and there’s a good chance none of them have ever had an engineering course in their life. they’re hackers who are good at making code.

    the reason they probably seem reluctant to share is that what they’ve cobbled together with bubble gum and bailing wire is difficult to explain quickly and thoroughly AND they’d be taking time away from their assigned tasks to do so without having any change to their deadlines.

    stop blaming them and start blaming their management for not giving them the time and permission they need to help you. go to the management and say you need so-and-so to be assigned 40 or 80 hours specifically to help you understand these widgets.

    and in the future you need to push for clean up, documentation, lessons learned, and training to be part of every project estimate.

  • shastaxc@lemm.ee
    link
    fedilink
    arrow-up
    10
    arrow-down
    1
    ·
    7 days ago

    A lot of great answers here, but there’s another possibility I haven’t seen mentioned yet. When you are gathering information like this it says to the engineer that you want to change things, and they don’t know if that change is going to make things easier or harder for them. Usually things only ever get harder as a project lives longer. So they’ll be less incentivised to help you unless you give them an idea of what you intend to do and specify what problems you intend to solve to make life easier for them personally.

    Also, as an engineer, things like this I generally see as less important than making sure the product works and that development is processing on pace. Having to explain everything about my job to someone coming in with 0 prior knowledge is a huge waste of time.

    One tip I saw mentioned works well in this situation: get them to start complaining about things they hate about the current processes. Everyone likes to complain because it is cathartic.

    It will help if you can educate yourself before talking to them. Present the info you have and ask them to fill in the blanks or make corrections. Must engineers like to solve problems, so present this as one for them to solve like a puzzle. Engineers are generally not novelists. Don’t ask them to just start spitting out history of The Process to you.

  • Treczoks@lemmy.world
    link
    fedilink
    arrow-up
    6
    arrow-down
    1
    ·
    6 days ago

    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.

    I’d wager that the engineers have experienced such promises in the past and got burned. Engineers, by nature, are very analytical. Re-gaining trust that was once burned will take a lot of work. And managers like you are exactly the kind of people that burn engineers.

  • lurklurk@lemmy.world
    link
    fedilink
    arrow-up
    5
    ·
    edit-2
    6 days ago

    It sounds like your job might be needlessly hard.

    Coming up with a design for a new process that will fix all issues at once is very hard; you’re very likely to miss something important. Making such a process change in one go is also hard, even if you somehow happened to end up with a improbably good spec. Doing it by interviewing people sounds kinda doomed.

    An easier path might be to take whatever holistic understanding you have right now and start in some corner of the problem where there are clear issues. Bring engineers and people who use the system together. Have the people who use the system walk through their common workflow together with the engineers, noting what parts are usually hard or slow them down. Keep people focused on improving things rather than arguing about how you got here.

    Together come up with small achievable process or software fixes you can implement and evaluate quickly (like in a week or two). If it works out, you have now made a real improvement. If it didn’t work out, you understand the limitations a bit better and can try again, as it was pretty quick.

    Helping to deliver real improvements in a way that’s visible both to the involved engineers and the people using the system will buy you a lot of credibility for the next step.

  • Curious Canid@lemmy.ca
    link
    fedilink
    English
    arrow-up
    3
    ·
    6 days ago

    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.

    • DominusOfMegadeus@sh.itjust.worksOP
      link
      fedilink
      arrow-up
      2
      ·
      5 days ago

      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.

  • dream_weasel@sh.itjust.works
    link
    fedilink
    arrow-up
    4
    ·
    7 days ago

    Good luck to you. Sounds like you’re working at the intersection of management meets reality, and nobody has extra love for a scrum master.

    I can recommend honestly and incremental adoption. It will be difficult to eat this whole sandwich at once.

    • DominusOfMegadeus@sh.itjust.worksOP
      link
      fedilink
      arrow-up
      1
      ·
      6 days ago

      I don’t actually want to change what they do; they have the thing working great. I just want to make sure they are getting the necessary tickets with the correct information they need, in the way that works best for them. Understanding their process is just ancillary to this effort, because I like to understand all the moving parts. I do also need to make sure the information is getting to the necessary teams in the next steps after their part of the process, with the correct infor