How Senior Engineers Lose Trust(tahahussain.substack.com)
tahahussain.substack.com
How Senior Engineers Lose Trust
https://tahahussain.substack.com/p/how-senior-engineers-lose-trust
54 comments
Exactly. Asking questions is a strength not a weakness.
Content of the question does matter ofc.
Content of the question does matter ofc.
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.
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.
In what context are they doing this?
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.
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.
The context is when this person joins an existing team/project to help out and do some work. So there will be, for example, a meeting where 4 people are up to speed, with this person present.
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.
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.
Came to say this. As a senior you can help foster an environment of “no stupid questions.”
On the other hand, seniors who think they know it all are dangerous. Bad decisions come with bigger impact at that level.
On the other hand, seniors who think they know it all are dangerous. Bad decisions come with bigger impact at that level.
> 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.
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.
Damn right, as an introvert all my career I have been afraid of looking dumb but talking to other fellow developers and reading things like the following made me aware of it.
https://grugbrain.dev/#grug-on-fold
https://grugbrain.dev/#grug-on-fold
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.
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.
It depends on the context. If it is a mentoring session, of course, fire away.
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.
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.
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.
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.
What kind of meeting calls in 10 or more people? It's either a workshop (where questions should be welcome) or a complete joke (where I'd zone out, no questions needed)
That's great unless you're in an organization with insecure higher rank (ex-engineer management, staff engineers, etc) who take that as an excuse to dismiss anything else you say, treat all your concerns as XY questions, etc etc.
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.
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 feel like I could very easily write this list in the opposite direction.
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.
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.
I like this a lot :)
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.
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.
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.
Exactly. Or as the juniors say, “This!”
>1. “I’ll Just Fix It”. As a senior: it’s reckless.
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).
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).
This one's just wrong, unless the author is using a novel definition of senior.
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.
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.
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.
This - and how to deploy that “easy fix” in a way that watches for unexpected consequences, and with a plan in hand to mitigate them or revert the change without undue disruption if necessary.
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.
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.
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
Even at an enterprise its absolutely possible. I work for one after all. My team owns the product anyway though and my "just fix it" tasks are 99% of the time annoyances that I encounter in my day-to-day work.
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.
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.
Aaaaaactually, those are principal engineers. With them, there are flips back!
It’s funny that you get (or got) pushback for basically doing extra work. If you were to just take a break and do nothing at all, people would just assume you were hard at work on the main issue.
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.
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.
I was trying to read this article but could not get to the end. Suddenly, I realized.
Same mannerisms. Same style.
Was it written with AI?
Same mannerisms. Same style.
Was it written with AI?
Blame the game not the player. "LinkedIn cringe style" predates generative AI (though it was arguably willed into existence in part by the evolutionary process operating on a engagement-based feed-ranking AI)
I think it was just written by someone used to making tweet threads rather than coherent articles.
Short statement. Short statement.
Dramatic conclussion.
Dramatic conclussion.
Yes.
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.
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.
Yes it’s not X it’s Y. I dont mind AI as such, but I’m tired of that specific style of writing.
It does seem like it - with the addition of "one sentence per paragraph", which - outside of its LinkedIn format - feels like yelling. This format doesn't incite trust in the person advising (let alone the tone).
This is more an explanation for why our industry sucks in big second tier companies.
They do a lot of stuff for the wrong reasons. And they don’t even care. Seen it countless times.
They do a lot of stuff for the wrong reasons. And they don’t even care. Seen it countless times.
It should have been separatd into "new hire" and "long time employee", regardless of technical experience.
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.
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.
Senior engineering and junior engineering are called different things for a reason? You don't hope the senior engineer can get things done, you know it. It's the opposite for a junior. If you cannot deliver the goods, you are sending a message that you are not senior.
If anything the real flip is recognising their are no absolutes and no hard rule that things have to go one way or the other but rather accepting the need to find the right fit at the time. Each of these options the reverse might be true and it really just depends.
Reading the whole thing I find myself jumping between agreement and disagreement. Yeah sure the way an experienced engineer contributes impact is different to how a young junior would go. But its neither black/white or specifically isolated to being experienced. Often the environment or the persons this third you will expect a certain mode of engagement regardless of seniority. This is not two dimensional.
There is a very distinct moment in your career when you realize that staying late is not a sign of enthusiasm/energy, it's a sign that you're struggling. Going home early is a power move. It means you're on top of your shit. It means you have a life outside of work. It signals efficiency.
Pretty spot-on. Describes several people I know quite well.
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.
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.
This is what happens when you promote people to "senior" based on time served rather than experience and career growth.
The article, you mean?
> Follow me on LinkedIn for daily insights shared with 80,000+ incredible minds
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?
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?
tbh none of this sounds like "senior engineer" qualities, and leans more toward "working at larger companies/in larger teams." From my perspective at startups/SMBs:
> “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.
> “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.
Half of this is nonsense, to me, and I am pretty senior. This indicates that probably this guy has a different technical culture than I do, but he’s talking as if his culture is the only kind.
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.
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.
> I work nights and weekends and anyone who thinks that’s weird is an idiot or a child
Or possibly they've read those studies that show that overtime reduces work quality and massively increases mistakes made
Or possibly they've read those studies that show that overtime reduces work quality and massively increases mistakes made
"I have abstracted something extremely complex in this convenient list of 5. Pay me and I will tell you more!"
Meh.
Meh.
more AI slop in the style of navel-gazing LinkedIn garbage. so nauseating. is there no escape from this? also, since when is asking clarifying questions a problem? this article is absurd.
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.