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.
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.
Have you asked them why they are reluctant to turn over the deets?
I’ve certainly withheld info because explaining DMARC is a lot more time consuming then just saying it’s a special type of spam filter.
Actually, no. Not in so many words. It seems so simple. My theory was that they are afraid of admitting mistakes because they think I’m going to “report” them or something, and make them look bad. And I have opened at least 3 times with how I am not remotely interested in anything like that, and I am looking to document process, and get their ideas for what an ideal process would look like for them. I feel like they don’t believe me.
Again, verbal assurances mean nothing, especially if they know the issue has internal political implications as this one obviously does. And even if they believe you, that doesn’t mean they trust your boss, so anything they say could still burn them later. Words alone can’t resolve this dilemma.
Also, has anyone tried what you’re trying before? If so, maybe you’re struggling because of past failure, not your fault but still your problem now.
This is an area my company has historically sucked at. Hard. I aim to fix that, and in fact that is the reason my team was created.
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”.
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).
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.
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.
As a dev, this definitely triggered me a little.
Hire people who can speak, read And write English to a very high proficiency. Prioritise it.
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.
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.
Good point. I’ve saved all my vitriol for our incompetent Product Team though 😜
Had a similar experience at a job. One source of resistance I found was engineers knowing upper management had absolutely no stomach for the type of change that the company desperately needed. This would lead to them likely not implementing anything meaningful. So rather than waste their time helping me and getting on board with the changes, they just kept churning out the same trash and questioned why I hadn’t made all their lives better.
Everyone wants change so long as they don’t have to be the ones to change.
You’re spot on. Fortunately the board has seen the light, and made some big changes today, which sound like they are going to flow downhill.
I’m a software developer, and I sometimes if I’m asked how something works, I can find it difficult to explain things in a way that would make sense to the listener, whether they are a PM or the client.
Other times, depending on the question, I simply don’t know the answer, and it could take hours for me to gain enough understanding of the project to even respond intelligently.
I’m a developer too and sometimes I say “I don’t know” knowing full well the shitstorm it’ll bring. I’m a few years in and I just don’t give a fuck if that pisses off the person on the other end.
I just don’t have time for games — a few times I tried to give a better answer but didn’t have all the information I needed and every time it came back to bite me in the ass.
I love being a developer with all my heart, I don’t come into the office and I love my job. But I won’t play politics, kiss ass or put lipstick on a pig. Why would I? In my experience doing so is a lot worse than admitting I don’t know something; if someone wants to throw a tantrum that’s fine but they can do it on their time. If we could just get off this time suck call I can find the information I need pretty quick and get you an answer ASAP.
Oh man, there’s been a few times over my career where they asked me what seemed like an easy enough question to them, but it’s in some terrible legacy code that were never given any time to fix, that fixing itself would be a huge ordeal and I respond with something like, it’ll take a day or two to get a confident answer to that.
They usually say no thanks after that, but they have sent me down that rabbit hole before.
Reminds me of my previous job that I stupidly took on because they wanted to go from the developer’s custom fork of Rails 3.2 up to Rails 6 (just released at the time).
The entire thing was spaghetti code and it was so out of date that I couldn’t really do incremental version updates due to libraries just straight up missing or being unmaintained.
My other mistake was thinking that because I had years of Rails experience I could take this on. As expected bugs occurred and everyone pointed their finger at me. I could barely make out what was going on and wasn’t familiar with unit specs at the time (ouch) so it was a poor experience on my end.
(My favorite was them doing currency conversions but storing the results as floats in the database. During a monthly scheduled job thousands of transactions were 1¢ off due to poor rounding. I felt ashamed because before working there I always knew to never do this, but apparently I didn’t do an adequate job of confirming how it worked in this app.)
thousands of transactions were 1¢ off due to poor rounding
Maybe the code was so poorly done on purpose so that developer could steal those pennies. You took his place, and now he’s off in the tropics living the dream!
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?
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.
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.
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).
Maybe they just don’t like Jira and hope you will go away if they don’t engage with your process.
deleted by creator
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.
This is why documentation of business process and methods is so important
absolutely not… if you think that random code from 10 years ago is difficult to figure out if it’s still needed, try that with documentation!
IT systems are living, dynamic beasts… they should be built in such a way that makes them comprehensible with relatively minimal effort, on their own, because the code is the only source of truth and everything else may as well be a lie
Lol. You’re highlighting ops problem exactly. Oversimplification of the issue and delegation of the documentation problem to the engineering department is the exact reason people there feel resentment. It’s simply not their job. As the other commenter posted - the system spans multiple disciplines and workflows, yet it seems only the engineer is tasked with understanding it all, in order to build the system. Consultants register this as a risk, and management assigns this to engineering because ‘only they understand the code’ - is exactly the problem op is facing.
The system is the property of the company. The company’s language should be used to capture it’s design, function and intent (what it does) versus how it is done (it’s expression in code). There’s a reason they call it ‘living documentation’ - it,.and the company’s understanding, should evolve along with the code.
Edit: are you seriously letting ‘random’ segments into your code? I think I found your problem…
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.
Yes. Please deep-dive into it all and then schedule a long, slow sit-down, regarding the Morton mod, but also be prepared to justify why the Penske Project is behind the arbitrary and impossible schedule some DeVry grad has already set for you.
(I suspect OP will find a lot of “in what fucking time?!?” concerns when it comes to knowledge ‘synch’ or documenting, since neither of those are billable endeavours and no one wants a deadline for the next project crushed because of the prep and meetings justifying the time over-run for the last project)
This is…very interesting
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.
After reading your replies, I am on edge.
Please consider the following questions.
What is the power dynamic?
Are there good reasons to stonewall you?What happened to the first few teams you worked with? Did the engineers involved advance in their careers? Do they talk with you still? What about their prior interactions with your team and department? Do those engineers still work at the company?
If you are confident you are there to help then just speaking to them like people. Don’t bullshit them. Push them up in their careers when you can. Get them what resources you can. Support them in their goals. Do a good job and you won’t get them to shut up.
This is a very long story, from my previous role, but both of those engineers have been promoted, and we are good friends.
You’ve probably tried this, but did those engineers have any insight as to how you can communicate with other engineers? Were things easy with them from the start or did you need to “prove yourself”?
This had not even occurred to me. Now On my to do list for Monday.
I was going to say, if you’re good friends how do they not have advice for you?
Yeah, I hadn’t even mentioned it to them. Also they are in Bosnia, and almost all of us work remote, so it’s not like I get to see them around the office. They are not in any of the engineering teams I oversee, and I’m relatively new to this role. I’m very excited to get their take on this though; it’s a great idea.
Install linux/*bsd on your work device (that you take into meetings). Respect from engineers will immediately skyrocket : D
I mean, after the third series of a person fending off shark attacks, you should also respect them as well
How does one know that they fended off sharks? It’s extremely easy to know if someone is arch user.
Because 33% of successful open BSD installs end in shark attacks
oops
