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.
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!
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
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
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.
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.
As an automation/software engineer that works with sysadmins I think there’s a natural resistance to top-down initiatives or others meddling with their processes (i.e. they’re the SMEs so just let them work). I could also see your line of questioning go into a decision to restructure and eliminate jobs.
In the first case (general change resistance) I think you’d need to come with numbers that show how expensive a dept is compared to industry standards or how inefficiency drives issues downstream.
In the second case the best way to show jobs as secure is to detail all the work that needs to be done, implying how foolish it would be to cut staff and miss even more deadlines.
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.
Hire people who can speak, read And write English to a very high proficiency. Prioritise it.
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.
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 😜
Maybe they just don’t like Jira and hope you will go away if they don’t engage with your process.
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).
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.
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.
I’ve worked very closely with engineers and I’m engineering adjacent myself. Most of the highly technical types I know in every field (myself included) struggle to talk to people about their job because they no longer know what normal people do or don’t know and they don’t want to come across as condecendong. Like for me the basic refrigeration cycle feels like something everyone should know but I logically know that actually isn’t the case and at the same time I don’t know where the laymans actual knowledge on the topic begins. Like do I need to start with explaining that boiling liquids remove heat? Do I need to start with what boiling even is? Do normal people even know that things boil at different temps at different pressures? If I start explaining any of this are they jist going to look at me like I’m an ass and say “Of course I know how thermodynamics works”? Eventually I just decide it’s better to not to talk to them.
At the same time though, if you do manage to break the ice with them then you are more likely to sucessfully get a passionate stream of consiousness rant from them because they’re passionate and now they know that you can be trusted not to see them as being condescending when they overexplain. Honestly the best way I’ve found to break the ice with technical types is to get them to start complaining about some part of their job. That also sounds like exactly what you’re looking for if you’re trying to make their jobs easier. But if they start seeing you as someone who it is safe to complain to then they will start seeing ypu as someone it is safe to talk to about other things.
Also as always there is a relevant XKCD.
I am the wife of a mechanical engineer, who’s brothers are mechanical and electrical engineers, who’s parents are electrical engineers, who’s best friends are aerospace engineers.
Basically I married into a family of robots, and I agree with this commenter here.
This is the crux of why senior engineers struggle to talk about work I think, and I find the best way for me to get them talking, is to try to learn something small about their work, enough that I can ask intelligent questions, and then listen carefully to the replies.
After a while they open up and I get to listen to the best rants about “special metals” or “systems architecture” or “braking systems in the railway”. It’s awesome.
It’s how I connect with my husband.
The other wives stand in a circle and roll their eyes about them talking about work because they don’t understand anything. “Oh there they go, talking about work again.”
I decided I didn’t want that to be me, and told myself I would listen when they were talking, listen when my husband was working from home. Learn to ask intelligent questions about his work, and eventually, I knew what he was talking about.
Enough that I now freelance in condition monitoring, giving me yet another way to connect with him.
Ask intelligent questions, get excited about the replies, encourage them so they know you won’t be insulted when they assume you don’t know about <speciality subject> and you will have them opening up in no time.
This is a really sweet comment that’s brightened my day while also being practical advice
You should always listen to your significant other. Of all the people in the world, they chose you to talk to
Of course I know how thermo dynamics works! But uh if you could just explain it for my friend here, gestures in general direction of dog, that would be perfect.
