[2C64]

My least favorite version of this is when non-technical leadership skips a level or two and talks to junior technical staff rather than the senior or leadership technical staff who have enough experience to know to ask clarifying questions, establish a timeline, expected outputs, etc. It's something I've seen often at various campaign and political tech organizations.

[wildrhythms]

I frequently see these attempts to bypass hierarchy like this, and it never works well. The junior technical staff understand the chain of command, so when higherups break that (either intentionally or unintentionally) it creates confusion and chaos.

[clnq]

No one is saying it, but a part of the reason is that a long power distance makes it difficult for a junior to object or negotiate a request. It’s usually a plain “yes, I’ll do it”, no matter the consequences.

[closeparen]

On the other hand, the game of telephone up and down the hierarchy frequently confuses important details.

[s1gnp0st]

In that case, CC the engineering boss while discussing with the IC; otherwise what's really going on is the nontechnical is trying to hide their impact on the IC's workload from their boss.

This leaves aside for the moment that I don't think nontechnical leadership belongs in a technology company.

[Cthulhu_]

Or it's a relief because the request will get watered down and / or expanded upon the more management layers it goes through. Are those layers of management even needed? I've read some anecdotes from people working at google and co where it seems a massive management party and nothing of value is done.

[kortilla]

No, Junior technical staff are terrible at scope estimation and will commit to ridiculous things on impossible timelines without realizing it.

[phanimahesh]

I have an extreme instance where the ceo bypassed everyone to directly drive a group of sde1s. When pushed for same day deliveries and the sde1s pushed through, and everyone else were publicly humiliated for taking much longer to deliver. It resulted in weekend marathons and all nighters being a regular occurence for the group he directly took charge of, and the demands escalated to timelines needed in hours instead of days, and a mess of code. The already popular copy paste driven write once development pattern became the only means of survival to many. (code so bad that it's only written once, nobody had the confidence to modify. New, similar request? Copy paste, modify, and manually test.)

I am so glad to have escaped that, for many more reasons. Still working off that near burnout and putting off getting back to work since a few months. (burnout not due to overwork, I escaped that madness, but other dysfunctional things in the organisation.)

[MajimasEyepatch]

Almost by definition, junior engineers are incapable of distinguishing "this is the literal request from the stakeholder" and "this is what the stakeholder is actually trying to accomplish."

[Xcelerate]

I’m not leadership, but if I was, I feel like I would probably be guilty of this. The junior engineers are often the ones doing the actual, physical work and are best suited to answering certain types of questions that those with a higher-level view would not be able to answer as well. Why play a game of telephone when you don’t have to?

[sarchertech]

Junior engineers might be doing some of the actual work, but by the nature of being junior tend to lack any context around how their work fits into or impacts the overall system. Mix that with being too green to feel confident pushing back at all, and you get someone who will say yes to nearly any question you ask them.

“Hey junior front end engineer, how long will it take you to change that passcode from 4 digits to 6?”

The junior responds with “There’s nothing to it. A day tops.”

But the junior doesn’t realize that the devices that are integrated with the system are statically allocating memory to hold that passcode and can’t change the length without shipping new firmware.

Of course that kind of thing can happen when asking a more senior person as well but it’s much, much less likely.

[2C64]

Exactly this. Context is king - and as someone else stated below knowing how to get to the actual ask vs. how the ask is being phrased is something that comes with experience.

That said, it should also be the role of the more senior technical leadership to involve junior technical staff in the process so they have the opportunity to grow. For example, CEO asks CTO how long it would take to add X feature so CTO loops a junior engineer into the conversation and demonstrates how to get to what the CEO is actually asking (which may or may not be X) vs. just providing a time estimate for X feature. Hopefully the CEO learns something here too but ymmv.

[wefarrell]

Because there’s always additional context that the junior and higher ups need that they aren’t aware of, the most obvious being time/capacity.

I used to manage an engineer who was responsible for a critical part of our system and he would frequently get hounded by higher ups who went around me and it ate up all of his time to the point where my manager thought this engineer was just unproductive. I wasn’t able to stop those requests entirely but I was able to establish a paper trail and show my boss that this engineer was actually being overworked.

[mdgrech23]

I think this is a good argument but also an example why it should probably be technical people defining the product and requirements rather than this made up role we've created of product owners.

[codingdave]

If you feel the need to drill down, skipping levels to ask what the people in the weeds are doing, you are probably micro-managing and should start working at a higher level.

[Exoristos]

"It's something I've seen often at various campaign and political tech organizations." If you're already in hell, what's a few more degrees here and there going to matter to you?

[2C64]

The stories I could tell if it wouldn't out me!

[creer]

"experience to know to ask clarifying questions" I have seen this happening in sales also: An inexperienced vendor "project coordinator", plus a vendor technical person who is used to the coordinator doing the job, plus a client who is new to the circus and you have a potential mess on your hands.