Ask Lemmy

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.

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

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.

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.

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.

Engineers are, as a rule... well, you've seen what they're like. You gotta loosen them up with drugs first if you want a decent conversation.

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.

Hire people who can speak, read And write English to a very high proficiency. Prioritise it.

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.

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 an engineer for past 20 years ,and the moment I get a whiff of some biz person fluffing bullshit I check out. Not saying you’re like that but something to be mindful of

So be real, honest, straightforward, put in effort into understanding the technicals so youre not just a sales annoyance or engineers will write you off right away IMO

Also I don’t think some people realize how busy or hard engineering can be. I’ve been working my ass off on a ground up new product and a lot of stuff just falls to the wayside out of lack of time

There’s also !askelectronics@discuss.tchncs.de !engineering@sh.itjust.works among others

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.

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.

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.

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.

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.

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.

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.

My husband is an engineer. Screaming, "what the fuck are talking about?" is probably not the way.

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

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

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.