Ask Lemmy

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.

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

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

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.