Ask Lemmy

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?

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.

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.

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 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.

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.

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.

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.

hesitation because they’re worried about “incriminating” themselves

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.

technical details

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.

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.

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".

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?

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.

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.

please give an example interaction that was difficult?

https://media.tenor.com/rGSj2L2GVecAAAAM/on-the.gif