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.
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.
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 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.
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 😜
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.
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
My experience is you get the best response if they understand why you need the information and at what level of detail. They seem to respond well to clarity, organization and logic (who doesn’t!), so prepare your communications to include the background they need (how does your request help them in the long run), what it is you need from them (and in what format), and when you need it by. Trust is built by demonstrating your value to them. Think about ways you can help them get the info to you (start the work for them, book time on their calendars to focus on the request, sit with them and help them produce the info).
Side note: engineers sometimes offer information that is not executive ready - you will either need to translate or tell the engineer who the audience is for the information.
You have perfectly put into words what I have been attempting, and not really succeeding at. I should present my needs in a clear and logical, documented manner. Brilliant!
I can’t tell if you are being facetious, but if not feel free to message me for more specific ideas.
Yeah, text communications are constantly problematic for these reasons. I was being 100% serious.
❤️
it occurred to me, if you have the ability to communicate with the engineers in person or on a video call, you could (maybe) avoid the pitfalls of text only. Anywho, don’t hesitate to reach out if you would like more detailed support. 😃
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.
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.
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.
As a software developer that’s worked on a ton of legacy, home-grown, years old software systems, they may not be dodging the nitty gritty…they frankly don’t know it.
Some of the systems I’ve had to work on were over a decade old and being maintained or patched by anybody that had a free minute(as in over 150 individual contributors over its life, 75% of which are no longer employed). So while I know what the main goal of the system is there are a bunch of little side responsibilities that nobody knows about. Like we need this thing but nobody will stick it on a roadmap or prioritize it so I’ll just stick it in here as a bug fix. Now multiply that over however long that spaghetti bowl of code has been around for. So that means that code isn’t documented, and likely doesn’t have a ticket in Jira(because you mentioned it) explaining why it exists at all. So that leaves a lot of questions. Chances are your devs have come across some code like this and know they don’t know what it does and expect to find more if they look. 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. So unless some time gets blocked out to actually answer those questions I find it unlikely that you’ll get what you need.
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
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.
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?
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).
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.
My husband is an engineer. Screaming, “what the fuck are talking about?” is probably not the way.
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.
