I was a Sr Principal for about ~3 years, which taught me that the most valuable thing I could do was drive discussions to decisions, quickly and mostly painlessly.
Your job is to run good meetings to conclusions - any meeting which causes a follow-up meeting is a bad one.
However, that job get immensely harder if you can't understand complex technical things and tie-break decisions quickly. If your feet are not on the ground, you can't understand exactly why someone wants an API to be cut exactly at this level of abstraction.
If you have a bunch of motivated people working for you, this works in your advantage as they will grab you before the meeting to make sure you understand exactly what they are going to present & if both sides do it, then you will come into the meeting with more information than you could have gathered on your own.
And then the project will go ahead, things will break, whichever fork was taken. If you cannot jump in at that point to fix things or at least roll up your sleeves to get your hands dirty, then your opinion will slowly stop mattering to people.
So after quarterly planning has been done, you need to dig up some time to get into the thing that you think is the most risky thing that was decided upon, but work on it instead of asking for status reports.
About 6 hours of my weeks used to be 1:1s with people, mostly outside the office and on walk in a loop.
This happens because you are influential in the organization as a senior engineer - you get told the struggles, hopes and expectations of engineers, which allow you to run backchannels into the management tier whether it is about recognition, money or just personal stress factors.
All of this stops working when you aren't able to do the work that an IC can do, but your other 50% of time is made more valuable by the 50% of time you spend fixing things in the guts of the system. I'm only half kidding, mostly I could only do a day a week of coding at best, the rest is just eaten up like this.
Another aspect of this is only a few companies really afford to have serious IC tracks beyond a certain point (basically FB and Google). Many more companies would be looking for senior management roles than senior IC roles, even if the absolute number of positions is lower; plus senior ICs are usually hired in their core specialization (e.g. networking expert is not automatically hired for ML in the same level,) whereas managers are seen as useful in different domains, giving them practical mobility.
Not all people want to be in meaningless meetings, shuffling people around and dealing with their personal/career growth, dealing with project plannings and Gantt charts, preparing presentations for upper management, etc.
/rant :)
And this is exactly my problem with becoming a manager. You become fungible, easily replaceable, movable and fire-able.
In my current niche - cloud consulting - I can be over a project dealing with software development, cloud architecture, data analytics, migrations, cloud hosted call centers, etc.
Just like an engineering manager, I don’t have to be the best at each role. I just need to be comfortable working at that level of “scope”, “impact” and “ambiguity”.
Being a manager is "not a promotion" promotion.
In my experience (Sydney, Autralia) being a competent and productive IC in an organisation has limits. An alternative is to become a contractor and build up a reputation for delivering quality results on time and budget. You can easily out earn the managers and garner respect. However, the longer you stay with a client the more you get sucked into the meetings and politics.
The downside of contracting is that you need to continually evolve and technologically skate to where the puck will be. Doing so requires one to be clued into emerging fads as seen from the clients' perspective not your nerd's view.
I think for a long time, if you genuinely wanted to have a large organizational impact, eventually you needed to go into management. One person can only do so much.
Ignoring bureaucracy and organizational constraints (probably far fetched), a single individual might be accomplish to do 10x more in the near future. Especially since a individuals will always move significantly faster than all the coordination that comes with managing a team. Maybe middle management becomes less relevant as a result?
however, when it comes time to find a new place i find i’m overlooked because im older than most IC, don’t have the requisite experience for management (usually an ATS weed out), or my salary is above most “normal” IC bands. so now i regret not adding more management experience to my CV
In 2016, I was a senior engineer on two projects—one involving hiring contractors and another leading a legacy transformation with a small team. I preferred the latter.
Next, I joined a startup, gained hands-on AWS experience, led AWS initiatives across teams, and focused on POCs/MVPs, actively avoiding team lead roles.
Then, I landed at AWS Professional Services as a mid-level consultant, leading smaller projects or workstreams in larger ones.
After leaving, I had a choice: a strategy role overseeing acquisitions or a staff software architect position at a consulting firm. I chose the latter.
Now, I either work with customers to define requirements and project plans (acting as a solution architect) or lead multiple workstreams, coordinating architects, sales, customers, and project management.
Nowhere in the article does it mention how growth materializes. It seems like if you do this you'll just continue to be a senior engineer forever.
You have to find a way to get yourself into strategic leadership and step away from coding to move up to those higher levels.
In this world, there are doers and dinguses. If you're still doing, the dinguses who manage you don't want you to stop doing.
