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 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.
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.
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.
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 😜
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.
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.
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.
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.
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.
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.
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.
Verbal assurances mean little to many. At least put it in an email. Otherwise CYA dominates.
And remember the docco kicks around forever. Indemnification until retirement is impossible to ensure.
And, as our RedHat TAM rediscovers, we can bring that shit out of the archive to prove a point … or to heckle about overblown systemd promises, but that’s PTSD for another venue.
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
-
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.
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.
I’m an engineer for past 20 years ,and the moment I get a whiff of some biz person fluffing bullshit I check out. Not saying you’re like that but something to be mindful of
So be real, honest, straightforward, put in effort into understanding the technicals so youre not just a sales annoyance or engineers will write you off right away IMO
Also I don’t think some people realize how busy or hard engineering can be. I’ve been working my ass off on a ground up new product and a lot of stuff just falls to the wayside out of lack of time
There’s also !askelectronics@discuss.tchncs.de !engineering@sh.itjust.works among others
That last paragraph hits home, but in a sad way for me. I spent most of the last year working on a new project to streamline one of the biggest time sinks we have, and as we’re coming up on having an MVP ready to start beta testing, my org just dumped the entire team other than 1 guy. So I lost the guy who was my peer/dba on the project, and the dude who knows how to run the driver software.
Going to try to see if we can salvage what we made since it’s still needed, but fuck that wrecks a ton of time and effort. And really sucks cuz my team had to pick up the slack while I was trying to get this working, and we don’t even have anything to show for it…
A million times this.
Thank you!!! In fact I have been emphasizing that I need to know the technicals, and that they should not worry about getting too detailed, because I need a very thorough understanding so I can best come up with a process for how they do file ingestion (which mostly is up to them) but then also how the information gets to them, and how they output the data, in the best, most thoroughly documented (without being uselessly pedantic) way possible. Which is pretty much going to be getting everything into JIRA, and eliminating all the uselessly disparate systems that people are trying to stitch together currently. I need to make sure all the teams along the road of this process are communicating with each other, and at are at least having a basic understanding of the whys behind what is required of the process. And of course that it is efficient and fast and definitely not cumbersome.
In addition to what other people have said, “the technicals” and “getting too detailed” is ridiculously vague. There is always a too detailed. Software engineering is a giant world and engineers specialize, and even other engineers with a slightly different specialty don’t really want to know all your “technicals”.
Be specific about what details you’re interested in and why if you want to build trust. Demonstrate tangible investment in figuring out what your gaps are and ask specific questions, and be clear about what kind of answers you want. “Thorough understanding” is not helpful.
There is always a too detailed. Software engineering is a giant world and engineers specialize, and even other engineers with a slightly different specialty don’t really want to know all your “technicals”.
100%. I regularly have to tell DB or App people that I only need the high level answer because the details are immaterial to the discussion at hand. I might be personally interested, but I got shit to do…
there’s a few things here that trigger red flags for me:
not worry about getting too detailed
oh good! because it’s probably ill-defined and nobody really knows and figuring that out involves a lot of reading other people’s shit code and we have work to do
because I need a very thorough understanding
oh you mean do worry - you want to know exactly how it works… sorry bud, no time, that’s a lot of energy
thoroughly documented
ugghghh documentation is for people that don’t understand that documentation is out of date the second you write it: don’t drag me into your futile attempt to make a static artifact that i’ll need to maintain in the future when i update a living system
eliminating all the uselessly disparate systems that people are trying to stitch together currently
okay but that’s really dismissive… this is work that people have put in - even if it’s shit and everyone knows it’s shit, it’s disheartening to have things thrown out… and what they do now they know how it works, they know the caveats… you’re talking about coming in, getting a cursory understanding (what you think you can understand everyone’s problem when the people that built the thing don’t have the full picture?) and then planning out and telling them what to do
if you want help from engineers, ask them for help to build a new thing: don’t ask them for help to explain something so you can tell them what to build. we’re creative, and we love solving problems and we hate robotically implementing someone else’s vision
Have you stopped to consider that the current solution might be better than an all JIRA one? I can definitely see a lot of “file ingestion” pipelines that would be much better handled by a bunch of different systems intertwined than JIRA, especially for automated file ingestion (which I guess is what you’re doing? Hard to know but hard for it to be something else).
I don’t know what’s the situation there, but if I was an engineer on one such project I would explain to the person why it’s not feasible, but it could be that that got interpreted as not explaining stuff. An easy to understand example would be someone asking what’s the best way to replace a car (that has been cobbled to pieces from separate cars) with a shoe, and then you try to explain to the person that that just doesn’t make sense they say that you’re being uncooperative and not explaining how the car works so you can make the shoe do the same.
Look, I’m not saying this is your case, but it feels like you’re approaching this the wrong way, you have a new solution without even understanding the current one. A better approach would be to gather the engineers and ask them what are THEIR problems with the system, and how would THEY like to fix them. If the Jira thing comes from higher ups tell them that this is a new requirement, but let THEM solve the technical issues, you are unlikely to be able to even if they explain them to you in detail.
Ok, so I AM asking the engineers that. But we need to be angle to track the implementations for each client, and that is why we are using JIRA. I’m very open to alternative ideas, but one of the problems is that teams involved are using salesforce, JIRA, and Azure, and this is causing a serious dearth of communication, as well as there being no way for anyone to get a bird’s eye view of where implementations currently stand. Frankly I have a lot more autonomy and control over this thing than anyone in this thread seems to be used to, so if people have better process ideas, I am all ears.
Ok, so it seems that you’re only talking about managerial stuff, whether to use Jira or Atlassian, engineers don’t usually care about that, and there’s usually no technical reason to use one or the other, so it could be that you’re asking them to explain how a car works to try to figure out the best shoe to wear.
Also no one that’s not involved in the project will have better process ideas because we don’t know the process, and apparently neither do you from what you’re saying, it’s the thing the engineers “refuse” to explain to you. I think at the end of the day you need to sit down and explain what the higher ups want and listen to their ideas on how to get there.
explain what the higher ups want and listen to their ideas on how to get there
absolutely this… engineers want to help you design solutions… if you come to me and ask me to explain something so that you can design a solution that i’m then told to build you’re removing all the fun out of it and i ain’t gonna help with that
JIRA, and Atlassian
Since one makes the other, it’s like saying “Rav4 and Toyota”. I’m assuming you mean Confluence (aka Flatulence; or Confluenza for the stress-based sickness from watching the spinning please-wait-web-loading symbol too much).
using salesforce, JIRA, and [Confluence]
Quit it.
No one uses those tools; they get used by the tools. They’re slow, cloud-based, usually under-budgeted for the great gobby java blob-wrangling clown shows they are.
If you’re asking deadline-driven engineers to use a slow cloud app like that, with their caffeine levels, and invite real feedback without fear of penalty, you’re going to get some interesting opinions. Please, try to find something more usable for the non-deadline-helping work-tangents like documentation; which are important, but not on-fire-important like every other bloody thing on the list.
Sorry, meant Azure
Maybe they just don’t like Jira and hope you will go away if they don’t engage with your process.
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.
I’m not interested in punishing anyone for past decisions or mistakes
right so you think our decisions were mistakes rather than at best suboptimal but reasonable given the information at the time? how arrogant
deleted by creator
deleted by creator
deleted by creator
