鴉PieFedAnyone have solid, tried and true strategies for improving communications with engineers?
submitted by
DominusOfMegadeus@sh.itjust.works
edited
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.
Sounds like a good old leadership trust issue. Unfortunately the only thing that solves that is time, beer (or other social activity), making yourself useful to them in other ways, and being honest with them.
If they're afraid of punishment you can always try an amnesty box. They put what they would say in the box, anonymously, and you discuss it without trying to figure out who submitted it. Even if it's obvious. Then they don't have to trust you so much as the process.
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 [email protected] [email protected] among others
A million times this.
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.....
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.
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...
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.
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
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).
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
there’s a few things here that trigger red flags for me:
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
oh you mean do worry - you want to know exactly how it works… sorry bud, no time, that’s a lot of energy
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
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
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.
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 author
Deleted by author
Deleted by author
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.
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.
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.
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.
https://xkcd.com/2501/
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
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.
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.
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...
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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!
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
They are probably unsure of your motives; are you analysing the business or analysing them? Software problems are extremely hard to estimate unless there is almost complete disclosure and discovery. It's like asking people how long a crossword is going to take without seeing the clues. Or asking how long they're going to spend on a chess move in 3 turn's time. They are possibly cagey because you are asking questions that betray the fact you are seeing this as a management problem rather than listening to what they're telling you about their craft.
Or possibly your manner of communicating is attuned to more socially intuitive people. Try presenting what you need as a problem for them to solve with a clear start and end. That way you're collaborating, and they know when their obligation to interact with you is "done".
Instead of open questions like "can you tell me how X is currently working?" try specific problem setting questions like "I'd like to see if we can make X process be 10% faster, what would that look like?" or "what would you say are the top two things that affect the time process Y takes?"
They may not want to offend you, because many of the answers might be "obvious" and, also, if they're honest workers, as many are, there may not be any clear way to improve certain things as they're already trying their hardest, and your investigation feels more like an inquisition.\
Again, it may be that you're asking someone "how can I get you to get this crossword done faster?". It's sort of the wrong question. Unless you're willing to listen to their bugbears which might be the actual things affecting how efficiently things run but might not be the kind of answers project management want to hear.
I'm at the stage of "I want to know how your process has worked up until now, and how you would like it to work, in a perfect world." Which did seem to garner a positive response.
To add onto this, sometimes it's about getting more specific with your questions to get the more specific answers.
For context of how I would suggest structuring these detail questions, here's how I think about code I write or debug: The functions and classes my code is made of are meant to get specific inputs to become specific outputs via a defined process; I think of this as inputs->how->outputs. Figuring out what inputs you need to execute the "how" part to get the outputs you want is the puzzle of each function or class I write. The "how" part can even be broken down further into smaller chunks of inputs->how->outputs.
I think asking your engineer friends to frame things in this context would both show your appreciation for the nitty-gritty details you are needing, as well as give you further context to ask more detailed drill-down questions (about deeper levels of inputs->how-> outputs) if needed. For example: "you said to get inputs A and B to result in output C, we need to run the fizzbuzz algorithm on A and B. What roles do those inputs have in that algo? Do we have to do any preprocessing on A or B before we fizzbuzz them, or any post processing of the fizzbuzz's direct output to get C?" "Oh, yeah, we have a wrapper that takes A and makes it column-major so that fizzbuzz executes faster, but we need output C to be row-major for when it goes into otherFunction(), so we do such-and-such to fizzbuzz's output to get the C we output." This gets you a level of detail deeper, and you could ask further questions about the transformations happening to A and the post-processing of fizzbuzz output to get C, as well as get more context for otherFunction to ask more about later.
You could also use this context to ask further questions about what they think the future implementation should look like. "Are there any assumptions we can make about A and B or how C is used that could simplify how we go from the former to the latter? Are there any requirements on the inputs and outputs that would better be either relaxed or made more stringent, and if so, in what way?"
I hope that helps! Best wishes for your work on this project--streamlining processes is hard, especially when working with other people's code, but your appreciation for the details to get things implemented well is admirable!
This is gold. Are you looking for a job?
I'm glad you found it helpful! And no, I love my current job, but I appreciate the sentiment!
Be interested when they talk about things and ask questions. Engineers stereotypically have been told too many times that they need to dumb things down. And there's a large percentage of neurodivergent people in software engineering who like to info-dump, but have been told their whole lives that they were boring or they overshare. But often when they are given the opportunity to share openly or even better, people show interest in learning, they usually will open up. It might take time, and it might take you getting a basic understanding of some technical topics so they don't have to explain those basics to you to even start explaining their work.
I have worked as an analyst, product manager, project manager, engineer, and architect. So I tend to be really good at bringing business and technical people together by interjecting a few details that an engineer might skim over because it's basic to them as well as interjecting business scenarios that a business person might consider obvious, but an engineer might get frustrates because it was never explained to them and they like to know "why".
This is excellent advice! I want to underscore that Engineers are very often much driven by the how's and the why's of things. I'll admit to judging people based on how they answer those sorts of questions. From a project perspective, I'm far less interested in doing something if the why of it can't be adequately explained to me. Similarly, I'm far more willing to take a "you know, I'm not actually sure", than a "we do it this way, because that's the way we've always done it" (the latter is probably the fastest way to tank any respect I might have had).
I think you and I might have some things in common. I am also captain of team Neurodivergent, and we are my favorite kinds of people.
The deeper I get into a subject involving engineering, the less I can relate what I know effectively. If I've done the thing many times, I can talk about it more freely.
It boils down to, "I don't know what I don't know." The only thing I can do is explain the long path of stuff I've figured out in order to get where I am at in my understanding. I don't have a clear overview scope. I'm aware I have likely made mistakes even within what I know.
If you are asking me for official statements that can come back to me, I'm going to be extremely cautious in what I tell you and only speak about things I am absolutely sure of and have triple checked. Most of what I'm sure of is going to be unhelpful surface level information. Professionally, telling you anything that could be wrong is career suicide. Reputation is the currency of an engineering career.
This is exactly the vibe I have been getting. And I have really been trying to reassure them that I am in no way looking to "punish" anyone for any mistakes. If anything, I want to hear about mistakes, and any solutions that were thought up, as a guide to how we can improve the process going forward, to make their jobs easier, as well as everyone's. It's all super positive, and none of this will ever "come back to bite them." But without finding out their challenges, it makes it very difficult to try an anticipate what issues we may run into as we build these processes, and further on down the line.
Try to also explain how you currently understand the systems and processes, and ask them to correct what believe need to be corrected, or why not ask them who else might know better
As an engineer, I hate having to repeat the same thing again and again so take notes and make sure you understand them.
Secondly know the product or project intimately relative to your level. For example if I work on the project and I know it from the code and infrastructure and everything else in addition to how it works for the end user then the least I expect is that the person asking the questions has used the software with a demo account on UAT or something so that my answers will not go over their heads. Knowing the product will also allow you to talk to clients better and you will know what it can and can't do.
I'm ok with someone if I see they are willing to make the effort regardless of their level, if someone is coming to me to do their work for them , then I lose my patience fast and will very soon be less helpful and prioritize my actual work over their bs.
Finally as I said we are often overworked and not looking to have more things to do. We are the ones that have to stay late to fix someone's mess or get called to patch an emergency zero day in some software used by the company on a weekend. In addition we support everyone else as without us there is no product and no jobs for the rest of you. We are at the bottom of the pyramid holding the rest up with the CEO being the prick at the top.
Finally dont just engage when you need something, get to know them and see if you can help them with something. Maybe a heads up about a project or client to avoid or some thing.
It is good that you want to bridge the gap and I wish more in your position would do so.
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.
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.
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.
The engineers have their own tasks and deadlines to deal with, why are you talking to them directly to get the information you want? You need to talk to their project manager to either give you access to the database in question, write a tool that generates the report you need or write a one time query to get this information. All of these things take time and need to be planned and resourced. I hope you're not just walking up to people and asking for random lists of customers that ordered more than once in the last year or whatever?
This is not at all what is happening here, but your sentiments are certainly valid. This is about process creation and improvement.
You should probably add some specifics, because your original post is super vague.
This is a hard one. Because this is not about engineers, but their nature as people.
An anecdote: A lawyer, once casually asked me - if I were to design a building (this was hypothetical, because I am not a civil engineer) and after construction, was to realise some mistake that would cost lives, would I go on to tell them about it - and his tone seemed like he considered it common sense that I won't report it.
So, at least in his mind, it is common sense that people hide their mistakes.
I am a kind of person that doesn't know that people find it difficult to understand concepts out of their domain (mostly because I understand most, well explained stuff, irrespective of domain) and if someone were to ask me about my work, I would easily wander into the details. After a few years of industry experience, realising that to not be the case, I tend to be more abstract.
If you want the engineers to tell you more in depth about the technical stuff, I'd suggest you to show them your aptitude to understand their stuff and you will see them going more into detail of it. I had a manager (kind of), who was also an engineer and used Linux on a regular basis. I found it easy to discuss more in depth regarding solutions (the product was using Linux too) due to his familiarity.
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?
Maybe they just don't like Jira and hope you will go away if they don't engage with your process.
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 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.
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.
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.
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
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.
Hire people who can speak, read And write English to a very high proficiency. Prioritise it.