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.
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.
-
My husband is an engineer. Screaming, “what the fuck are talking about?” is probably not the way.
Maybe they see your job as pointless waste of their time. The engineers put it together with the limitted timeframe and budget they were given, and dont need someone to tell thwm how to suck eggs. They know whats broken and how to fix it and they know how to do it.
To make it worse, you will do none of the work but will take the majority of recognition as c suite will associate the change with consultation and not the more time or money allocated to rhe team.
The best time for analysis is at the start of the project as it reduces the learning and consultation. Now, its an uphill battle, and frankly, not needed.
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.
I relate to this style more than the other comments in this thread, this seems more typical of a large company.
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.
Unfortunately this adds to the bureaucracy, but it really is the most effictive way of translating business needs to engineering needs. It’s not a straightforward process, and accurately defining the steps that need to happen for a job to get done, takes someone with a lot of experience and training.
If you’re in a startup or smaller company, then I think the other comments that prioritize asking and listing to what the engineers recommend, is the best approach.
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.
Fair enough. But I actually do want to know that stuff, and it’s not over my head.
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.
Maybe they just don’t like Jira and hope you will go away if they don’t engage with your process.
I work in a fairly toxic work environment.
The reasons I do what the engineers are doing are,
-
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).
-
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.
-
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
-
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
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.
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.
Hire people who can speak, read And write English to a very high proficiency. Prioritise it.
Keep your promises and tell the truth. If you don’t keep your promises, be the first to acknowledge the failure.
I was an engineer for a long time and among my peers the problem we had with management was often that they had a slippery relationship with the truth.
Also, demonstrate forgiveness within the organization for technical mistakes. If your engineers don’t want to share the bad decisions they’ve made, look for aspects of your company culture that punish people who admit mistakes.
One example would be times when someone spoke about a mistake they made and then was relieved of responsibility because of it. That’s an example of punishing the admission of a technical mistake.
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.
