How Senior Engineers Lose Trust
Posted3 months agoActive2 months ago
tahahussain.substack.comTechstory
calmmixed
Debate
40/100
Software EngineeringLeadershipTeam Management
Key topics
Software Engineering
Leadership
Team Management
The article 'How Senior Engineers Lose Trust' discusses common pitfalls that senior engineers may encounter, leading to erosion of trust, and the HN discussion revolves around the validity and relatability of these points.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
23m
Peak period
49
0-6h
Avg / period
13.3
Comment distribution53 data points
Loading chart...
Based on 53 loaded comments
Key moments
- 01Story posted
Oct 19, 2025 at 11:49 AM EDT
3 months ago
Step 01 - 02First comment
Oct 19, 2025 at 12:12 PM EDT
23m after posting
Step 02 - 03Peak activity
49 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 22, 2025 at 2:00 PM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45635077Type: storyLast synced: 11/20/2025, 5:39:21 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Same mannerisms. Same style.
Was it written with AI?
Dramatic conclussion.
What is it is with one sentence paragraphs?
This drives me nuts.
It also feels like hubris that the writer believes each sentence is so important that it deserves its own paragraph.
At the same time it makes me question the writer's confidence that they may be doing this to trick the reader.
Whatever it is...
It drives me nuts.
Annoys me.
Gets on my nerves.
But alas...
That's the internet for you, and in the end...
There are bigger things to stress about.
I guess.
It still get to me.
For the sake of my own sanity and enjoyment of my work, I have realised that I sometimes have to do this. I'm not talking about massive 2 week tasks but rather something done in 30mins - 1h. I call them pallet cleansers and when there is a particularly hard task that has me stumped I'll do one of them to give my brain some time to passively process the more difficult one.
I have also told my manager point blank that they can get on board or start looking for a new engineer because I would leave otherwise. Thankfully, they're a good manager and are completely fine with it as long as my main work gets done on time and I somehow communicate it (standup, slack, jira, etc).
Senior engineers are exactly who I trust to "just fix it" when they notice a problem, even one outside their immediate domain. Sure the bar is higher, but that's still their job. If this was about staff or architects, then it would make sense.
For example, we run a Jenkins instance for our platform that has bi-weekly production releases. We write announcements in slack when there was a release with a list of PRs and links to the tickets in Jira. That used to be manual work. At one point I was annoyed by it and took 30 minutes to write a 15 line script to automatically take the merged PRs, create a Jira link and announce it in our slack channel.
As I go through this thread, one word keeps coming to mind: discernment. The more senior you become as a SWE, the more you’re expected to know what to address, when, and how to address it. The actual addressing of the problem is table stakes, and as you move from senior to staff you’ll find yourself directing more and implementing less.
However, I outright refuse to go through this process for a minor annoyance that needs 2-3 lines of code and 30 minutes until its in production.
Since then I steer clear of companies and teams that have an incredibly strict sprint schedule were no unplanned work, even if its tiny, is allowed. I hate that way of working and refuse to do it.
In the years since we worked together I've adopted his "there's no such thing as a stupid question" philosophy and it's served me really well.
if you're at a company where leadership doesn't understand this, do your mental health a favor and leave.
If it is a meeting with 10 or more people, asking a basic question can be interpreted negatively a) you are trying to embarrass the organizer of the meeting implying they are clueless b) you are trying to disrupt the meeting.
I’ve been in meetings as a Sr. Staff SWE where the expectation was that I could provide guidance and direction for projects using tools, architectures, or stacks that I’ve not used extensively… or at all. In those cases, I try to make it clear where I’m not confident in my knowledge and ask questions designed to uncover what I need to know to do my job.
I’ve learned to do that even in areas where I’m almost completely inexperienced. For example - I’ve never worked with Java and Spring Boot, but I’ve worked with the JVM and many application frameworks in other contexts, so I’d ask questions to help me understand the strengths and weaknesses of those tools, with a focus on areas where I’ve found friction in other projects with similar architectures.
I’m also always worried that I’m “taking over the meeting”, and every couple of rounds of questions I pause and explicitly ask if I should continue to investigate or take it offline and come back with findings.
On the other hand, seniors who think they know it all are dangerous. Bad decisions come with bigger impact at that level.
What’s working well for me is to open conversations by being explicit that I’m trying to make sure my knowledge is accurate, and that I’m phrasing things as statements of fact not because I know them to be true but because they are the premises that the weight of my position depend on. I want you to speak up if I’m wrong because I want us to succeed and I want to be right the next time it comes up!
I’ve also found that this bleeds over into other conversations, even where I’m not involved. If my team is used to working in an environment where premises should be challenged, they tend to do the same thing in other contexts. As long as the organization as a whole is accepting of this - and I can’t overstate how important that part is - the whole thing establishes and constantly reinforces a culture of collaborative skepticism.
I want to work somewhere that bringing an idea or a project plan to a group isn’t saying “this is what we’re going to do”, it’s saying “this is what I think we should do; if you disagree please try to convince me otherwise - because I want what’s best for us and I want to expand my own abilities”
I’m blessed to have a place like that today. I’ve had three in my career thus far, and I’ve stayed at each of those until I was forced to leave in order to grow as an engineer.
I interview with this in mind, and it’s very hard to tell from the outside. It seems that about 1/3 of the companies I’ve thought were suitable for me turned out to be.
Content of the question does matter ofc.
Rather that asking questions, or reading code, when confronted with something new they will state "I don't understand X" or "I don't know what a Y is."
And then expect someone to jump in and fill in the gaps.
It's incredibly obnoxious and grating on a personal level and makes me not want to work with this person despite their other, genuinely valuable skills.
I can see myself saying exactly that in a meeting where we’re trying to explore a problem space to plan or make decisions - in which case I’d want to make it clear that I’m coming at that part of it blind, and am seeking enough information to identify tradeoffs.
What I’m not doing is expecting someone else to do the work of learning so I don’t have to. It’s limited to the topic at hand, and if it’s something that I expect I’ll encounter again I’ll spend time afterward diving in and learning enough to answer those questions for others in the future.
I’m perceiving your comment as you considering their actions to be laziness or disinterest. Is that accurate? If so, then yeah, that’s a huge red flag that could mean that this person isn’t suited for their role and expectations. If not, then it might be fruitful to sit down with this person to understand why they’re asking those questions and what they’re trying to accomplish. It could be that they’re simply not communicating their intentions.
It's not expected that they know everything up front, of course. Onboarding to a new project takes learning.
A big part of the irritation to me is the fact that they decline to phrase their question as a question. Always a statement. They won't ask "what is X?", it's "I don't know what X is." Leaving the onus on others to reinterpret as a question for them.
https://grugbrain.dev/#grug-on-fold
For context: I’m in my early 40s, have been in a technical role for ~20y, and have had a “SWE-equivalent” title for about 15y. My current role is Sr. Staff SWE.
Your comment resonated, though:
> as an introvert all my career I have been afraid of looking dumb
I remember feeling this way very early in my career. I wasn’t so much afraid of looking dumb, but of exposing to my colleagues that I lacked some critical knowledge, likely as a result of my not having a traditional CS education (or a degree at all).
A few years into my career I began to see that people were interested in what I had to say not because of who I was, but because of the way I presented the concepts. If I came at a problem openly, was clear about what I was and was not confident in, and spoke in terms of tradeoffs and balance, others would mirror this behavior and jump in to fill my gaps.
In moving into the staff engineer role, I focused on why some orgs I’d worked for were more effective than others. I came to the conclusion that it was cultural, and therefore also concluded that the way I could make the biggest impact was through building and guiding that culture.
I make it a point to ask “dumb questions”. Often I already know the answer, but have identified that if I were wrong there it would have an outsized impact - so I explicitly challenge those preconceptions and ask for argument.
I’m constantly telling people at all level (but especially those more junior who seem to speak up less) that asking those questions is important. I reach out to them early and directly, and offer to always be willing to ask questions that they’re afraid to ask on their behalf, and without attribution. If it ends up making a positive impact, I immediately and publicly give them credit. If it’s not well-received, I own it. There have been a couple of times that I’ve refused to tell leadership who a question like that originated from because they were looking for a scapegoat. I actually lost a job by doing that before I reached “staff” level (or perhaps before staff engineers were a commonly-understood concept?), and don’t regret it.
These days I work for a company whose culture doesn’t look like a good fit for me at all. I’m in a very red state, steeped in that culture (though not the politics - long and irrelevant story), and expected quite a bit of friction. What I found was that I could lean in to the “blameless/egoless” paradigm and make it work for me, and in the process make it a more effective organization as a whole. Now I find my self saying things like “I know you’ve hear this before, but I mean it: you can treat this as a safe space. I want to help our org succeed, and I want to help you succeed. I’ll do everything I can to protect you from the politics, help you grow as an engineer and as a professional, and be happy. If that means tapping my network to find places fro you to interview because you’re not happy here, I’ll do it.” - and I’m saying it as a big bearded dude with a deep Southern accent and absolutely no shame.
To put it another way - I’ve reached the point in my personal and professional life where I know exactly who I am. I’m not threatened by what others think of me, and am confident in my abilities to the point that I want to be aware of and clearly communicate my shortcomings so I’m as effective as I can be.
We all have moments where we don’t know (or can’t remember) something we should know. I’ve gone from being ashamed of that as a junior to seeing it as an opportunity to demonstrate that it’s normal and an accepted part of our company’s culture at the staff level.
The more senior an engineer is, the more important demonstrating difficult but necessary actions becomes. It makes you more effective as an individual and is essential for building effective teams.
1. I'll just fix it – as a junior you can get away with not working on something unless you're told to. As a senior you're expected to take ownership. Cut through organisational malaise. See a thorny bug not being solved because it sits slightly across team boundaries? Fix it.
2. Working nights and weekends – as a junior you can expect to just turn up during your work hours and nobody will bat an eyelid. As a senior sometimes you'll have to make sacrifices. Stay on late to deal with that incident. Monitor a vendor migration over the weekend.
3. Asking a lot of questions – as a junior you can get away with being shy and avoidant. As a senior you're going to need to push through the discomfort and ask the important questions, challenge people, and have gotten over your fear of looking stupid to ensure you always have the right information.
4. Being "Extra" Helpful – as a junior you can very much just focus on your project work. As a senior you're expected to find impact beyond what is given to you in JIRA tickets. You need to review other PRs, manage other projects, unblock team members questions. Your job is beyond just closing tickets now.
5. Loud enthusiasm – as a junior you are not likely to have the political capital to get your org to take a risk on a new framework, language, tool. As a senior you are expected to have the experience to be able to take those risks when they are appropriate for the situation.
It's true though that you need be thoughtful about whether your behaviour is what is valued in your job. Regardless of seniority, different managers, different companies can value traits that other companies punish, and visa versa. You can really suffer if you're not aware of what it is your managers actually want from you.
A senior engineer has knowledge and experience. A staff engineer has discernment.
In an ideal world, people should be promoted to staff and above when they demonstrate that discernment. We should always be unafraid to share our perspectives, but staff engineering is about knowing when to get involved, when to watch, when to ignore, and when to actively look away.
As “Sr. Staff”, I see my job as knowing when to exercise authority far more than merely exercising it.
I work nights and weekends and anyone who thinks that’s weird is an idiot or a child, OR they have a different technical culture from me, WHICH IS OKAY. I don’t impose my culture on everybody else, except people who work for me.
Or possibly they've read those studies that show that overtime reduces work quality and massively increases mistakes made
I do think these are the symptoms, but TFA doesn't completely call out the cause. They do say it a couple times though, to their credit.
The core issue is that at senior, and especially at staff+, you need to have more impact (as the article states) and you will be fundamentally unable to do so if you spend all your time doing the symptoms you see in the article. It's all "low-impact" work and in some cases is simply distracting (constantly gushing about, or potentially even churning integration, of new techs/frameworks etc).
I had an EM who helped me grow a lot. They told me, racecar drivers have to look 100'+ ahead, because if they look right in front of them, they will crash. You have to tape over the bottom half of the windshield to help yourself look far enough ahead.
And that's really what it comes down to. E.g. for #1, jumping into random problems yourself means no triage/priorities and you're probably depriving a teammate of an opportunity to grow and learn more of the stuff your team owns (much higher-impact outcomes for your team). Plus the opportunity cost of what you could've been doing instead (pointing a mid-level eng at a problem with some sage pointers is a lot less time-consuming than DIYing it. higher-leverage).
I do want to remark on "asking lots of questions". I know then attenuate this by saying it's perhaps not "less" questions but "more surgical". I think really though, I would describe it not as surgical, but as guiding. Your questions will change from being mostly informative for you and move to being more informative to the person you're asking the question of. Similar to the socratic method. It's all about internalizing what the person you're helping currently knows, and then give them questions that, if answered, will move them forward. I find often the other person will be both capable of answering, and delight in answering, such questions. They just didn't know to ask it in the firstplace.
They do a lot of stuff for the wrong reasons. And they don’t even care. Seen it countless times.
Nothing screams Senior Engineers more than this! (/s... or not?)
But anyway if the expectations of seniors are exactly the same as that of juniors, than what's the point of hiring seniors?
> “I’ll Just Fix It”
Yes please. Diving into unfamiliar areas of code and being able to fix problems outside of your wheelhouse is critically important. This doesn't mean stepping on people's toes or subverting processes e.g. design/code review, but just being willing to take ownership and not just shrug and say "not my problem".
> You’re expected to build fences.
Again, this is a big business thing and not a senior engineer thing. As a senior engineer in a team of 250 there are more barriers, but a senior engineer in a team of 20? You shouldn't be building very many fences.
> Working Nights and Weekends
This is a cultural thing that comes from the top. Goes beyond the scope of just senior engineers but I'll say that in my experience, if you're at a startup nobody is going to complain about you working nights and weekends. Again, this is a "large company" thing where slow and steady is more important than fast results.
> Asking a Lot of Questions
Dumb. I mean yes, if you're a senior engineer and asking questions like "what's a for loop" you'll raise eyebrows, but all of the best engineers (and managers for that matter) I worked with at Amazon etc all asked questions. In fact asking questions--extremely pointed and insightful questions--was basically all Jassy did in AWS meetings when I was there.
Anyway this article is mainly crap, IMO.
Meh.
You should expect new hires (of any seniority level) to jump in and try to fix things. It shows they're invested, willing to embrace opportunities.
You should expect new hires (of any seniority level) to ask lots of questions. They need to learn this new environment, quickly. That's the best way to do it.
You should expect new hires (of any seniority level) to try to be extra helpful. They still don't know exactly where they can help the most, mapping the ground is a good sign.
You should expect new hires (of any seniority level) to be enthusiastic. It shows they value being there, and are on board with trying new approaches. In other words, it shows they believe themselves to be useful in that new environment.
It has absolutely nothing to do with being a senior, but being in a new environment. Of course, to juniors, every environment is new and they should do that all the time. Seniors should do that when they change environments, or when the environment changes for them.