Hacker News Reader

Comment by Xcelerate | Hacker News Reader

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?

View on HN

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.

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.

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.

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.

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.

Reply on news.ycombinator.com