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.
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’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
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’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
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.
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.
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.
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.
-
I’m not an engineer, but I work in IT and work with engineers, analysts, and management. I have no idea what your knowledge or background is, but the engineers may be reluctant to get too technical in fear of talking over your head. I would make clear to them that you need specific, technical details and not to worry about to much jargon. If they’re reluctant for other reasons, it may be an issue for your management to address.
This is definitely part of it, and I am starting to make headway assuring at least this first team, that I am very eager for the nitty gritty technical details. This stuff all makes sense to me conceptually, I just never wanted to learn to code (and I am actively rethinking that decision), so there’s very little of it I will not be able to grasp.
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.
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.
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 with almost thirty years of experience, I don’t want to be on the hook for telling someone the wrong thing. Also, if you want an estimate there are lots of engineers who won’t want to give an estimate of 2 months when you’re expecting 2 days. Then we have to explain that the entire app is a fucking unmaintainable shit show because we’ve been doing two months worth of work in two days by cutting corners and writing shit code and we know it.
Also they could just be shy introverts. But it’s probably a reluctance to commit themselves.
I say all this like a universal truth, but just by reading all the responses here you can tell it varies from person to person. You have to assess your team and figure out each individual. My experience is it’s a trust/comfort thing, but that may not be your case.
I think a lot of it is trust/comfort, and I am definitely making progress in that regard, and the advice here has been fantastic. Which I suspected it would be. My strategy is that we need to work together to solve issues, like if they were to “tell me the wrong thing.” It could certainly gum up the works if I am basing a part of a new process on bad info, but honestly I have no desire to gotcha anyone, and I think that would be completely unproductive at this stage of the game. They have this file ingestion “engine” running pretty darn well, and now we need to tweak, and improve, and gameplan for the upcoming year.
please give an example interaction that was difficult?
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 😜
Good luck to you. Sounds like you’re working at the intersection of management meets reality, and nobody has extra love for a scrum master.
I can recommend honestly and incremental adoption. It will be difficult to eat this whole sandwich at once.
I don’t actually want to change what they do; they have the thing working great. I just want to make sure they are getting the necessary tickets with the correct information they need, in the way that works best for them. Understanding their process is just ancillary to this effort, because I like to understand all the moving parts. I do also need to make sure the information is getting to the necessary teams in the next steps after their part of the process, with the correct information, and if there are any hiccups.
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.
