I just got my first job as a Senior Engineer, I am having a bit of an imposter syndrome 🥲 That’s probably because I have been always told that senior engineers should be gurus. What advice do you have for me?
Congrats on the promo, Ahmed. Yeah, imposter syndrome right after promo is very common. I almost felt like hiding it from everyone when it happened to me. But remember that there are atleast some people who believe in you and the promo is a reflection of that. I can't give much advice without knowing specifics, keep doing the great work, find mentors and building network within the org.
Need some clarification on point 4 soloist. Isn't now a days most of the JD for senior developers are mere Individual contributor and when the appraisal review came the senior manager does review based on how much tasks one have contributed individually.
So how to navigate here from becoming a better senior dev to a good engineering manager. And how to portray ourselves to look good in review phase.
The primary job of a senior engineer is still to deliver their assigned tasks, but it's not a one-dimensional role. One of the dimensions is "being a multiplier" meaning how you provide technical guidance to juniors and help them improve, how you provide them feedback on their work and also organizing your work in such a way that the individual tasks can be delegated to others. Also seeking feedback for your work.
If someone does all of that proactively, they'll be considered "highly successful" in their role.
I kept this story "simple" in order to serve that section in the article. The full story is that, this was being done by 2 engineers and all the progress and demos were based on the usability not on debugability. Later, we realized that this was an over-engineered solution that I should have not let the team pursue. But I remember at that time the 2 engineers were pretty adamant their solution was the only correct approach.
The archetypes are spot on. As with any classification there are also overlaps. A suggestion - For each archetypes, a strengths vs Blind spots would be very helpful as a tldr.
Thanks for the feedback. Yeah there's definitely overlap between them. Sometimes one behavior causes the other. And ofcourse, there are other archetypes. I wanted to share the four common ones I've had to deal with.
Great breakdown — and a great reminder: even the most experienced engineers have blind spots. Totally agree on coaching over micromanaging.
I just got my first job as a Senior Engineer, I am having a bit of an imposter syndrome 🥲 That’s probably because I have been always told that senior engineers should be gurus. What advice do you have for me?
Congrats on the promo, Ahmed. Yeah, imposter syndrome right after promo is very common. I almost felt like hiding it from everyone when it happened to me. But remember that there are atleast some people who believe in you and the promo is a reflection of that. I can't give much advice without knowing specifics, keep doing the great work, find mentors and building network within the org.
Thank you so much 🙏 I will keep on exploring mentors and reading blogs
Need some clarification on point 4 soloist. Isn't now a days most of the JD for senior developers are mere Individual contributor and when the appraisal review came the senior manager does review based on how much tasks one have contributed individually.
So how to navigate here from becoming a better senior dev to a good engineering manager. And how to portray ourselves to look good in review phase.
Great question.
The primary job of a senior engineer is still to deliver their assigned tasks, but it's not a one-dimensional role. One of the dimensions is "being a multiplier" meaning how you provide technical guidance to juniors and help them improve, how you provide them feedback on their work and also organizing your work in such a way that the individual tasks can be delegated to others. Also seeking feedback for your work.
If someone does all of that proactively, they'll be considered "highly successful" in their role.
Great article! Everything is spot on, except for the following -
"It took 3+ months to build a buggy version of that service and we didn’t have enough logging or visibility into why it broke later."
So, for 3+ months, no one reviewed the progress on that?
Thanks for the feedback.
I kept this story "simple" in order to serve that section in the article. The full story is that, this was being done by 2 engineers and all the progress and demos were based on the usability not on debugability. Later, we realized that this was an over-engineered solution that I should have not let the team pursue. But I remember at that time the 2 engineers were pretty adamant their solution was the only correct approach.
Enjoyed the read — great choice of these personas, valuable for any engineering leader.
I highly value ADRs. That’s how decision-making should be done, and not just for architectural decisions.
Thanks for the link to Inversion, Suresh!
Thanks for sharing your thoughts Michal!
The archetypes are spot on. As with any classification there are also overlaps. A suggestion - For each archetypes, a strengths vs Blind spots would be very helpful as a tldr.
Thanks for the feedback. Yeah there's definitely overlap between them. Sometimes one behavior causes the other. And ofcourse, there are other archetypes. I wanted to share the four common ones I've had to deal with.