How Senior Engineers Lose Trust

I work with a staff level engineer that I think internalized the article's advice in the worst possible way.

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.

If bad management is punishing good engineering then it's time to find the door.

commentary from first time staff engineers should be taken with a grain of salt because they can be silly trying to prove themselves. same as first time people managers with an engineering background. if they're not a few iterations through the engineering manager pendulum, they're still getting their bearings.

if you're at a company where leadership doesn't understand this, do your mental health a favor and leave.

Friendly advice: get out as soon as you can.

I have a lot to say on this topic, but need some time to get my thoughts together before they’re coherent enough to share.

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.

Also, your role and the situation.

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.

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.

From your comment, the resulting impression is that staff engineers aren't needed. They're a luxury that is diminishing in value every single day with AI filling the gap.

If anyone is going to spot that the easy fix turns out to actually have more implications its the senior engineer. To some extent it comes with a battle hardened wince to "this is a 30 minute fix" knowing full well it sometimes isn't and to look for the foot guns.

I think the author didn't account for different types of engineering orgs at different points in their lifecycle. "just fix it" at an enterprise massive company as a junior is fine but a senior would know "if you fix it, you own it" and it could cause downstream issues with what your team does or owns at the company. whereas at a startup, if you're relying on junior devs to "just fix it"... good luck with that

Aaaaaactually, those are principal engineers. With them, there are flips back!

At a previous job my manager complained. They weren't mad about the extra work itself but rather that I didn't go through the entire change process. That meant writing a user story, creating a ticket, bringing it to refinement, agreeing with colleagues that it's something we should do, planning for it in a sprint, etc, etc. For large tickets/tasks/projects that makes sense.

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.

Short statement. Short statement.

Dramatic conclussion.