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.

  • ricecake@sh.itjust.works
    link
    fedilink
    arrow-up
    53
    ·
    2 months ago

    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.

    • DominusOfMegadeus@sh.itjust.worksOP
      link
      fedilink
      arrow-up
      13
      arrow-down
      1
      ·
      2 months ago

      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.

  • JeeBaiChow@lemmy.world
    link
    fedilink
    arrow-up
    24
    ·
    2 months ago

    Frankly, it’s tiresome trying to describe technical details with business analysts who glaze over something you’re passionate about, treating it like nerdsprak. If the engineer has spent any amount of time producing a solution, you can bet he’s passionate and invested. Give credit where credit is due and don’t sound like an obnoxious condescending douchbag when doing so. People can tell when a disinterested person is giving fake praise. It’s quite different when a crowd of peers is giving recognition of a job well done. And no, you’re probably not as smart as they are in their field of expertise.

    Also, listen to their input. They don’t want a product with their name going live with a feature the bean counters want, but the engineers know make the product worse. It’s like a mom watching your daughter to go to prom with a cheap haircut because dad as too cheap to fork out for a perm. You know what I mean.

  • Hugin@lemmy.world
    link
    fedilink
    arrow-up
    23
    ·
    2 months ago

    As an engineer you learn to be very careful about what you say to non engineers.

    A trivial example.

    What if we make change x?

    It’ll make some things harder and some things easier.

    One week later.

    Why are you having problems? You said doing x would make things easier.

    More complicated example.

    Can this be used for real time control?

    Define real time.

    Just answer the question.

    I can’t it’s a bad question. I need to know what you are trying to control.

  • seven_phone@lemmy.world
    link
    fedilink
    arrow-up
    21
    arrow-down
    1
    ·
    2 months ago

    If you are saying things like ‘I’m not interested in punishing anyone for past decisions or mistakes’, I think I can see the problem.

  • sunbrrnslapper@lemmy.world
    link
    fedilink
    arrow-up
    16
    ·
    2 months ago

    My experience is you get the best response if they understand why you need the information and at what level of detail. They seem to respond well to clarity, organization and logic (who doesn’t!), so prepare your communications to include the background they need (how does your request help them in the long run), what it is you need from them (and in what format), and when you need it by. Trust is built by demonstrating your value to them. Think about ways you can help them get the info to you (start the work for them, book time on their calendars to focus on the request, sit with them and help them produce the info).

    Side note: engineers sometimes offer information that is not executive ready - you will either need to translate or tell the engineer who the audience is for the information.

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

      You have perfectly put into words what I have been attempting, and not really succeeding at. I should present my needs in a clear and logical, documented manner. Brilliant!

          • sunbrrnslapper@lemmy.world
            link
            fedilink
            arrow-up
            2
            ·
            2 months ago

            ❤️

            it occurred to me, if you have the ability to communicate with the engineers in person or on a video call, you could (maybe) avoid the pitfalls of text only. Anywho, don’t hesitate to reach out if you would like more detailed support. 😃

  • givesomefucks@lemmy.world
    link
    fedilink
    English
    arrow-up
    15
    ·
    2 months ago

    Talk less, listen more.

    They’re probably (no offense) nerds, so let them nerd out and listen to them.

    Then actually act on what they say, and soon they’re be telling you more shit than you want to know.

  • JordanZ@lemmy.world
    link
    fedilink
    arrow-up
    13
    arrow-down
    1
    ·
    2 months ago

    As a software developer that’s worked on a ton of legacy, home-grown, years old software systems, they may not be dodging the nitty gritty…they frankly don’t know it.

    Some of the systems I’ve had to work on were over a decade old and being maintained or patched by anybody that had a free minute(as in over 150 individual contributors over its life, 75% of which are no longer employed). So while I know what the main goal of the system is there are a bunch of little side responsibilities that nobody knows about. Like we need this thing but nobody will stick it on a roadmap or prioritize it so I’ll just stick it in here as a bug fix. Now multiply that over however long that spaghetti bowl of code has been around for. So that means that code isn’t documented, and likely doesn’t have a ticket in Jira(because you mentioned it) explaining why it exists at all. So that leaves a lot of questions. Chances are your devs have come across some code like this and know they don’t know what it does and expect to find more if they look. Tracking down why all that junk exists and if its still required can take a staggering amount of time. Trying to juggle that with your day to day is…not practical. So unless some time gets blocked out to actually answer those questions I find it unlikely that you’ll get what you need.

    • JeeBaiChow@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      2 months ago

      This is why documentation of business process and methods is so important. A lot of time, the engineer solves seemingly small problems without oversight, so imagine a decades old collection of many innocuous solutions leading to the whole ‘dunno what this does’. If it’s important enough to commit to a mission critical system, it’s important enough to document.

      Also, it’s incredibly frustrating for an engineer to be given a one line brief, work his ass off producing the solution, then have the business analyst take credit for the work, and not bother to even learn how the system works, even at a high level. It sows distrust and disdain.

  • kopasz7@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    11
    ·
    edit-2
    2 months ago

    Anecdote from my first job (software engineering): New manager wants to know what our team does and how our process and software works. Like, he really really wants to know it!

    Okay, I book a timeslot and prepare some slides and an example; we have a meeting. I go over the high level stuff, getting more and more specific. (Each person on our team was responsible for end-to-end developing bootloaders for embedded HW.) When I got to the SW update process and what bit patterns the memory needs to have and how the packets of data are transmitted, he called off the meeting and I’ve never seen him since.

    I guess, he didn’t want to know THAT much after all.

  • Tehhund@lemmy.world
    link
    fedilink
    English
    arrow-up
    10
    ·
    2 months ago

    This post is a little too vague to give real advice. You don’t tell us what industry you’re in. You don’t tell us if the engineers are the end users of the software or processes you’re working on, or if they will implement the software or processes you’re working on.

    If they’re the end users, they might be concerned that the changes you’re designing are going to make their jobs harder. A lot of changes in the past couple decades aimed at “efficiency” have involved making people take on more work for no additional pay, then firing the administrative staff or other engineers who used to do that work. Even if that isn’t the sort of project you’re working on they are reasonably wary based on past experience. Or maybe it’s not clear to you how this will make their life harder but management will find a way.

    If the engineers are writing the software that you are helping design, how are you helping to make their jobs easier and more fulfilling? It’s an unfortunate fact that software engineers are sometimes treated like misbehaving vending machines that will produce software if you force them to. If they are writing the code, there’s a very good chance that they know more about this process than anyone else in the room, but are they treated like they know more than anyone else in the room? Is their expertise valued or are they treated like roadblocks when they give their expert opinions?

    • DominusOfMegadeus@sh.itjust.worksOP
      link
      fedilink
      arrow-up
      3
      ·
      2 months ago

      This is extremely insightful. Thank you. To keep it somewhat vague, I am trying to optimize processes surrounding file ingestion. And I am trying to eliminate all the roadblocks caused by siloing of information. We have an in house file ingestion “engine” if you will, and we have really been rebuilding it from the ground up because its original function was not what we are using it for. So there are problems. To date, we have be MacGyvering the fuck out of everything with a pen knife and some dental floss, but we got through crunch time, and now we need it to be smooth, and by the numbers. Easy and clear for everyone.

      • AliasVortex@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        2 months ago

        Well that might explain some things.

        Not to throw shade at your company but that process is so backwards that it’s no wonder the engineers are sparse on the details. I saw another comment likening software development to a crossword puzzle, which is a pretty good analogy. To further it, changing software once it’s done is like trying to swap out a clue/ word once the rest of the puzzle is built. It’s theoretically possible, but depending on how the puzzle is designed, it can range from an absurd amount of work to nearly impossible. Given the way you’ve described the state of things, your engineers are probably low on goodwill to boot.

        I’ve worked on cobbled-together crunch-time hell-projects and the last thing I’d want after getting free would be a random BA coming to me about details that more than likely packed with the project PTSD and would very much like to forget. Doubly so if it’s issues that I bought up early in the design/ development process (when they would have been comparatively easy to fix) and was dismissed by the powers that be. I can only speak for myself, but I can only take so much “that’s not a priority”, “we don’t have time for that”/ “we’ll see if that becomes a problem in the future and deal with it then” before I throw in the towel, stop keeping track of everything that’s wrong, and just bin the entire project as dumper fire run by people who would rather check boxes than make things better.

    • AliasVortex@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      2 months ago

      Was trying to compose a similar statement on that lack of details. Like, my background is scrum/ agile software development and if a random BA called me up out of the blue for project details, my first response is going to be “I’m busy, talk to my scrum master and/or manager” and failing that it’s likely going to be the minimum amount of information required to get said BA to leave me alone so that I can get back to work. Plus, unless I know that my audience has the technical capacity for low level details, I tend to leave them out (I don’t mind answering questions, but I also don’t have time in my life to spout information that’s going to go in one ear and out the other).

  • ramsgrl909@lemmy.world
    link
    fedilink
    arrow-up
    9
    arrow-down
    1
    ·
    edit-2
    2 months ago

    I work in a fairly toxic work environment.

    The reasons I do what the engineers are doing are,

    1. A lot of times people will ask me questions and I give them answers. Then something will go wrong and it will somehow be my fault that I didn’t mention it to them (they didn’t ask, and I don’t know the specifics of what they are doing).

    2. I have my own goals and projects for the year. Why should I give you a significant amount of my time when my salary/bonus will not reflect helping you in anyway.

    3. Job security.

    These might sound bad, but that is how it works in corporate America

    Edit: It sounds like you need management on board with you before you can fully continue

  • Today@lemmy.world
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    2 months ago

    My husband is an engineer. Screaming, “what the fuck are talking about?” is probably not the way.

  • TheBananaKing@lemmy.world
    link
    fedilink
    arrow-up
    8
    arrow-down
    1
    ·
    2 months ago

    Probably they’d rather drink a dogshit milkshake every single morning than use fucking JIRA, and they’re hoping you die of natural causes before you get a chance to force it on them.

  • jubilationtcornpone@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    7
    ·
    2 months ago

    There are a few things you can do that will help make everyone’s life easier.

    First thing, ask engineering what can be done to reduce technical debt and then fight for it aggressively. This is often a hard sell to the product owners at first because it can increase the time it takes to produce new features, at least initially. In the long term, it will pay huge dividends to everyone involved.

    When tech debt gets ignored on a new project, the timeline usually goes something like this:

    • Project is barreling toward MVP at lightening speed. The Product owner said “move fast, break things” and engineering is delivering based on that mindset and everything seems to be going great.

    • MVP is almost ready but uh oh! Now a new feature has been requested.

    • “Move fast, break things” doesn’t allow time for code that is easily understandable or extendable to fit new use case scenarios so a huge chunk of the codebase has to be rewritten to accommodate the new feature.

    • Wash, rinse, repeat.

    Without a major change in design philosophy, the cycle tends to get worse over time with small features requiring more and more extensive refactoring and the number of regression bugs skyrocketing. Not to mention the code base is now a disorganized, smoldering pile of spaghetti that every dev loathes having to work on. Stakeholders are unhappy. Customers are unhappy. Engineers are unhappy. Everyone is unhappy.

    Second thing, talk to some actual users, people who are NOT involved in the project, to get their feedback. As an engineer, I like working on projects that add value to someone’s life, or at least make their work day easier. I want the user experience to be positive. I want the features I’m working on to enhance that experience. I don’t want to waste my time working on features that are completely useless and will be rejected by the users as such just because some VP who doesn’t understand what the users want has a bright idea. I’ve experienced this a lot throughout my career and to some degree it’s curbed my interest in software engineering, simply because I feel like a lot of my time and effort were wasted on projects or features that were DOA.

  • JoeKrogan@lemmy.world
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    2 months ago

    As an engineer, I hate having to repeat the same thing again and again so take notes and make sure you understand them.

    Secondly know the product or project intimately relative to your level. For example if I work on the project and I know it from the code and infrastructure and everything else in addition to how it works for the end user then the least I expect is that the person asking the questions has used the software with a demo account on UAT or something so that my answers will not go over their heads. Knowing the product will also allow you to talk to clients better and you will know what it can and can’t do.

    I’m ok with someone if I see they are willing to make the effort regardless of their level, if someone is coming to me to do their work for them , then I lose my patience fast and will very soon be less helpful and prioritize my actual work over their bs.

    Finally as I said we are often overworked and not looking to have more things to do. We are the ones that have to stay late to fix someone’s mess or get called to patch an emergency zero day in some software used by the company on a weekend. In addition we support everyone else as without us there is no product and no jobs for the rest of you. We are at the bottom of the pyramid holding the rest up with the CEO being the prick at the top.

    Finally dont just engage when you need something, get to know them and see if you can help them with something. Maybe a heads up about a project or client to avoid or some thing.

    It is good that you want to bridge the gap and I wish more in your position would do so.

  • irotsoma@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    2 months ago

    Be interested when they talk about things and ask questions. Engineers stereotypically have been told too many times that they need to dumb things down. And there’s a large percentage of neurodivergent people in software engineering who like to info-dump, but have been told their whole lives that they were boring or they overshare. But often when they are given the opportunity to share openly or even better, people show interest in learning, they usually will open up. It might take time, and it might take you getting a basic understanding of some technical topics so they don’t have to explain those basics to you to even start explaining their work.

    I have worked as an analyst, product manager, project manager, engineer, and architect. So I tend to be really good at bringing business and technical people together by interjecting a few details that an engineer might skim over because it’s basic to them as well as interjecting business scenarios that a business person might consider obvious, but an engineer might get frustrates because it was never explained to them and they like to know “why”.

    • AliasVortex@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      ·
      2 months ago

      This is excellent advice! I want to underscore that Engineers are very often much driven by the how’s and the why’s of things. I’ll admit to judging people based on how they answer those sorts of questions. From a project perspective, I’m far less interested in doing something if the why of it can’t be adequately explained to me. Similarly, I’m far more willing to take a “you know, I’m not actually sure”, than a “we do it this way, because that’s the way we’ve always done it” (the latter is probably the fastest way to tank any respect I might have had).

    • DominusOfMegadeus@sh.itjust.worksOP
      link
      fedilink
      arrow-up
      4
      arrow-down
      2
      ·
      2 months ago

      I think you and I might have some things in common. I am also captain of team Neurodivergent, and we are my favorite kinds of people.