The difference between expert and advanced/intermediate technical staff is that the advanced engineer has an understanding of complex solution and mistakenly tries to apply them everywhere, so the net effect is to increase complexity. The expert typically sees simple solutions and method of resolving complexity and has a net effect of reducing overall system complexity.
Believing that the value add of experienced technical staff is to only solve really hard problem is likely caused by having too many advanced/intermediate people playing the role of experienced technical leads. All of the great technical team member I worked with always make call solutions simpler and easier to implement by knowing exactly what doesn't need to be done and what is essential.
First, if the title is real, then the term Principal carries serious weight, and hews as closely as possible to the best definitions of Principal Investigator (yah, academia has been busy making a mess of that)
More often than not, a good PI knows that all problems don't need the most powerful solution, some just need to go away. If a claimed principal is always applying the most complex solution everywhere, then they're bad at their job.
A good 1/3rd of my benefit is not going 'zomg - a hard problem' to my co-workers, its the exact opposite. And even when it is a hard problem, at least half the time then it's 'Don't worry - here's what Djikstra/whomever did to solve it'
I love advanced algorithms, and relish the chance to actually go try and make ones - that said, my main value is not that, its that some horrible new problem erupts, my job is to say, 'no, calm down. That's an old problem in a new suit'
That said, switch isomorphic to homomorphic - I'll give the seniors credit, they usually tag the isomorphic cases . :-)
The beauty of the model, to me, is in the separation of skills. Being an expert programmer doesn’t make you an expert in mentoring, or leadership, or architecture sometimes, and if the place you work has any flexibility with its career setup, there’s plenty of opportunity to branch out once you think you’ve maxed out your current tech tree.
... or you quit and get paid more elsewhere/go consulting/whatever ...
End of the day, the size of your tribe or budget is a physical manifestation of your power in an organization. Power is how you get stuff done -- all of the right answers don't matter if you cannot realize the outcome. IMO, it's critical to grow as an engineer to be able to get others aligned to whatever task is at hand.
My career is very much in the applied space -- my perspective is someone delivering solutions, not inventing tech. It may be different for different disciplines/scopes.
The interesting thing is what happens in mid size to smaller companies, where organization structures are not as well defined. You still need people here, however, if you know the stack very well or are a proficient IC, you can make contributions that can have a significant impact on the org, and gain the trust and allegiance of many engineers, albeit informally.
I've seen this happen a lot. A senior engineer will either create or integrate a new tool or process which makes life easier for other teams. They are grateful to the person and are much more willing to hear the engineer out for future designs and projects.
All that to say... just having a title doesn't get you anywhere. You have to build trust by delivering value, however incrementally. Maybe this is really trivial stuff, IDK.
Took me a while to understand this is true. You can't have an org with the wrong ratio of "architects/leads" and coders. Or tech leads and engineers, whatever terms you prefer. An org with 2 teams doesn't need 5 people coordinating cross-team work. An org with 40 teams needs more than 40 engineers, and so on.
Once the technology works well enough, and the ongoing changes can be supported by mid-level engineers, and there is no big challenges ahead, it's time to move on.
No, this is not how you grow in power and importance for 15 years within the same company. If you want that, management is your path.
There's a lot of business value in certainty. The value of the senior IC is the certainty that your business critical project will get completed correctly and on time. Sort of like how you want a good electrician to work on your house even if the job isn't technically that "hard".
I guess if you have a lot of title inflation things might be different. I've definitely seen places where a senior developer is pretty much anyone 2-3 years out of school who does a decent job but still requires supervision and oversight.
The bullet point list of strategic work that she provides mostly overlaps with what engineering managers do. It's valid to point out that you don't need people reporting to you to do it. It's very cool that she's been at companies that made that possible. But I think it's a mistake to say, as I think many commenters here are saying, that that's the only valid approach.
Sorry if I'm being dim - what's an IC?
your company and your boss have to support you (eg by not micromanaging, so that you can actually effect soft leadership), but the way you put it, failure is a foregone conclusion.
Strike teams seem to the most effective thing for ICs to lead, and having that be an explicit part of eng culture and the work processes is a prerequisite for that.
I've talked with many of my now manager peers and they seem to not understand that simply walking into a room with "manager" or "director" in your title gives you almost immediate clout (or something similar). Whereas if you enter a room as a "senior IC" there's just not as much authority inherent in your presence.
It's unfortunate, it's not right, but it seems to be true.
In addition, a lot of of the main decisions are being made by management before engineers even get involved. Don’t know how to improve this but from what I have seen in other companies this seems fairly standard.
I guess you need to stay tune for her next blog post.
Well, that's the biggest BS there is. Not everybody is a good lead. It's a completely different job compared to engineering. It takes people skill, organizational skill and it requires you to approach engineering from a much higher abstract level.
Personally I was really unhappy being a lead and I decided to step down. I was doing more harm than good and no-one benefits from that. Not the company, not the team, and definitely not me.
FWIW, if you still have to work 50 more years before you can enjoy a retirement, you better learn what makes you happy and do what makes you happy.
"It is a significant exodus in a short time, and many former employees describe a corporate culture at the fashion company that is unwelcoming, stressful, and occasionally hostile."
It's not a manual for how to be the world's best boss or build the best culture.
It's an approachable, informative view of what to expect at each rung of the management career ladder. I'd argue it's good because it doesn't take an opinionated stance on the particulars of how to accomplish the outlined roles.
- Tackling technical challenges that span multiple technical and organizational systems.
- Researching and identifying the problems that could be worked on, a year or two from now
- Ramping up strike teams to help build a thing.
- Looking at the big picture including cultural, product and technical challenges, to help inform choices that would be best for the org, perhaps with a 2-5 year view.
- Forming strategies, writing proposals and pitching them across the company, for new architecture, systems or approaches.
- etc...
Except for developing prototypes, assuming the senior engineer is actually doing that, that entire list are just foundational management/leadership tasks.
Yes coding is fun but,
1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun.
2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.
3. Spending your weekends learning the latest JS framework because you don't want to be someone "who doesn't keep up", is not fun.
4. Being paid less than the lowest grade manager, is not fun .
5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.
There is no such thing as "IC track" for almost every one of us, please shake yourself out of your delusion.
I do spend my weekends doing technical work (mostly reviewing and testing other people's ext4 patch submissions, and/or reviewing papers because I'm on various program committees), but that's because I love to do those things.
> 4. Being paid less than the lowest grade manager, is not fun .
At least at Google, and at IBM, it's not unknown for IC's to be paid more than their manager.
> 5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.
It may be different for people doing other kinds of programming, but at least for Systems Engineering, there's an awful lot of value in knowing how the various abstraction layers fit together, and more importantly, understand the business imperatives which drives even the lowest level technical work. (Things like maximizing ROI on storage infrastructure by making sure you can efficiently use nearly all the IOPS which the HDD's in your data center can deliver, for example, is subtle work.)
Also, at senior levels, you need to know how to lead technical teams, and that's quite different from people management. And when I say lead, very often you may not have formal hierarchical power over the people that you need to influence; but instead of you have to pursuade them to share your vision and go along with your plan.
This is the worst part of the whole gig frankly. It's an awful place to be, all the responsibility and expectations but none of the muscle.
What's the way in? Hope you find yourself in a job where there are leadership positions open and the stars align and you're promoted into one?
And you're dead right, not every place is Google or whatever. Hell I don't think Google's Google, mostly, in terms of what they actually do, but they do pay developers very well regardless, so there's that. But outside a handful of huge pure-tech companies and Wall Street, you better be moving out of development by 40 or so (earlier if you can swing it, really—god I wish I'd started making moves this way years ago), or your career's (pay's) in for a brief flat trajectory followed by a sharp drop way before you'd have liked.
If I'm interviewing you for a job at $COMPANY, I'm going to be looking for signs that you can exhibit leadership, and that's going to be way more important than whatever title that you might have. If you have the title, but you can't demonstrate ways in which you were able to demonstrate technical leadership, the title isn't going to mean much.
In corporate jobs, this is rarely the way in. Most likely, you'll have to convince your current manager (and maybe theirs) that you're ready to be a manager and look for a manager opening elsewhere in the company. If you think you're ready and your current employer does not, you'll have to look outside.
Years of leadership seems like a purposefully vague credential. It's not about a title; if you don't think you've been a leader at work, you probably weren't (or maybe you were and your talent just wasn't managed properly ¯\_(ツ)_/¯ ).
I've been programming for 20 years and it is a struggle for me to find something "new" that isn't a mild variation of something I've used before..
There's only so many variations of an application that can bring something really new to the table that gives you that excitement of learning something new like the first time you "get" TDD or DDD, or that first time you successfully implement an efficient CQRS model, with eventually consistent events, or run a GraphQL API that swaps the challenges of REST for a new set of problems and so on. Switching industries doesn't help much either, as they are either just more of the same but with different vernacular, or so niche that you'll need to have really been there since day dot of your career anyway.
There's only so many new libraries/frameworks that I can get excited about, and the rapid state of change in many ecosystems means that quota is pretty much full 100% of the time. Languages, too. That's before we even tackle the problem of getting _hired_ for languages I've not had any professional experience with, and with the added bonus of 0 personal time to implement side-projects, and a lot of companies never needing to stray from their current stack.. it's just not going to happen.
So now the only thing left that tickles my fancy are the "abstract" problems.
Instead of now focusing on implementing code to fix a problem, I'm asking and researching the questions like "How can the platform (and not just application) be more performant?" or "What is that the team can improve on?" and "how can I improve the learning culture?" etc. and using my experience to, at first, recognise these problems that are invisible to a lot of people, but also gauge which ones are actual problems or mild inconveniences.
Another point is: In many/most actual organizations, it's the people managers making strategic technical decisions, not anyone on any other track.
Don't forget that there are more possible correct answers to strategy than there are people to do it. Should your company continue to update the current project, work on the big re-write to fix all the problems, or abandon current products for something complete new? All of these are valid answers for different situations, and some of the reasons to choose each are not technical and so you shouldn't influence them.
I have a dozen projects I'm thinking about at any given time. Some will never get more than thinking about. Some are in progress. Some I'm working to get into progress. Some are likely to be needed soon and are just waiting for the time of need so I can save the day with a plan (if the likely need turns to reality). Some are bad ideas that I need to prove are bad ideas so that we don't go down a bad route.
I'm 54 and I'm pleased to say that I've never worked anywhere where that was the general rule - I've always been on the "technical leadership" side of things (CTO/Head of Architecture) since my 20s and I pretty much see my job as ensuring that "strategic technical decisions" get made in the right way.
If this is the case, your company's technical leadership track has a broken pay structure. You shouldn't need to go into management to get paid better.
If you’re in your 40s or 50s and not in a role where you’re “influencing decisions outside your own team” you’ll soon be in for a shock next (or next next) job interview.
Once time I interviewed at a place with a few managers that were in their late 20s. Turns out they were the senior employees only having been there less than 2 years. Turnover was less than 6 months, I passed on the job and my schoolmate was there 5 months. The place had a bad reputation.
(But if you're bothered by having a manager younger than you, that's on you; I'm not sure what the inherent problem with it is. When I was a manager, I managed people older than me; now that I'm a senior IC, I have leadership younger than me. Both things are fine.)
It's not about JS frameworks, but if you don't keep up with technology _because it's fun_; and you also what to be promoted very high on the ladder (aren't happy with "just" an average job with average pay that lets you have a decent life outside work) by all means do yourself a favor and move to management.
> because you can't invert a binary tree in 20 secs in leetcode
It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20).
> 2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.
I've been managed by former students. Worked out quite fine for me. Why wouldn't it? Age does not equal competence.... I'd rather be managed by a competent young guy than an incompetent senior. (bad managers are no fun, that I agree; but bad managers are not necessarily young; and young managers are not necessarily bad)
> Being paid less than the lowest grade manager, is not fun.
Being paid less than what you're happy with is no fun. But it's not really required.
> do you really need 20 yrs of coding experience to write CRUD apps
So don't write CRUD apps if you're better than that.
> What exactly are you bringing to the table.
In general, knowing what NOT to do. Finding out & solving the right problem, not the one that was given to me.
> There is no such thing as "IC track" for almost every one of us,
If that were true, it all becomes a huge pyramidal scheme (you constantly need more young developers so that you can manage them as existing workforce ages).
I'll give you that: for most people, it's probably easier to advance on the management track than it is on the IC track. And the IC track in many companies is a joke (if you're not at the headquarters, advancing is an order of magnitude harder; also you advance easier by playing the advancement game than by being competent in what you do - but that may be true for management too). So yeah, it's not for everybody. But OTOH, middle management sucks... big time. For some people, it may be a good deal to sacrifice some cache upside than to turn into something they don't want to be. It all boils down to what you want to optimize. If you're happy with a good income, even if it's not the best that you could possibly achieve, IC track might be an option (still, change companies every now and then. It's much easier to promote this way).
ok. I was being facetious with that (particularly famous) example.
you are able to breeze through hard leetcodes in your 40's in a tech interview setting?
Why would you be faster at 60's vs 20's , not sure i follow the line of reasoning.
> So don't write CRUD apps if you're better than that.
Can you give me some examples of better things that actually require 20yrs of experience ?
> In general, knowing what NOT to do. Finding out & solving the right problem, not the one that was given to me.
So true.
I would add the ability to look farther ahead at potential problems. I have seen so many young people blocked by some issues that should have been spotted way earlier.
> It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20).
My main problem is that I look like an idiot while writing code. I pointy-clicky navigate too much for many's taste—doubly so when someone's watching because I start second-guessing every keystroke and so avoid keyboard navigation—and tend not to remember much about languages I haven't written a ton of within the last 48hrs, and even then if it's some feature or function I haven't used in a couple weeks I'll either look it up or poke and prod my way to the correct syntax ("it's either this way or that way... OK, red squigglies, must be that way" or "I think null can just be used as falsy but undefined is gonna throw in this language? Yep, there it is, cool, I'll guard it then" or I'll not be 100% sure about the order of arguments for a "map" function even if I used it ten times yesterday and I'll look at the IDE's hint to get it right, stuff like that). I'm much better at the "what" and "why" than the "how", without support from tools and the freedom to faff about a bit, unselfconsciously.
All that's even worse on a whiteboard, of course. If someone bet me $100 I couldn't write a solution to fizzbuzz on a whiteboard in any language of my choice, that'd compile if input verbatim, without looking up some stuff in the couple minutes before doing it, I would not take that bet. There's a decent chance I'd manage, but I quite literally would not bet on it.
I mean I've been (technically) designing & shipping software for pay for a long time and everyone's always told me I'm pretty friggin' good at it. I've often been the go-to guy for weird crap and "hard" problems. But I look like a total dipshit who doesn't know anything and probably wrote my first "hello world" last week, if you watch me do it in interview conditions. I pretty much only have a career in software at all because not every place does those.
>>1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun.
This is true. This doesn't bother me though. I don't need to find "this" job, I just need to find a job. You ask me to invert a binary tree, don't worry. I'll find a job someplace else, and you can find someone else that has less experience and knowledge than me.
>>2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.
Don't honestly care. If you're a manager and making decisions on your lifestyle and feel that everyone else should live like you...see previous answer.
>>3. Spending your weekends learning the latest JS framework because you don't want to be someone "who doesn't keep up", is not fun.
Honestly, I don't have to. The foundations are the foundations are the foundations. Do I know how to use the equivalent of Redux in Vue.js? Admittedly, no I don't. I can google that. I may spend sometime looking up new stuff on my own, because I find it fun, but this doesn't stress me out. I can figure it out. You don't hire me as a framework jockey. That's not what I do. You want me to go up against some younger person who spends his time learning React and can tell you the syntax off the top of his head. OK, fine. Call me when your database has scalability issues, or your web server is overloaded.
>>4. Being paid less than the lowest grade manager, is not fun.
Yes, we'd all like to make more money. Here's the thing. I make enough money to live the way I want to. To think that all senior developers can become managers is a joke. Management is an entirely different skill set, and news flash, it's hard. Like really hard. The best manager understands things like accounting and finance. You have to keep track of head counts, who gets what raises, why do they get them. If I give this person a raise and not as much to this other person, will someone leave? How does that affect my staff. Do you understand how to counsel people, because whether you like it or not, you're going to do that too. You are a people person, you get to hear all the things that go wrong, and sometimes you need to understand how to fix them and other times you need to just listen, and you have to know when to do both. Are you ready to put your job on the line when you find out that another manager, or someone above you is sexually/discriminating or harassing people? You get to do that too (blah blah, laws against that. They can do that. Get back to me in the unemployment line on that.). Have we talked about firing people? How many people have you fired before? Not a fun requirement. How many people have you laid off that are perfectly good at their job, because the company wants to hit their bottom line? Managers may make more money than me ... when they're working. Just think how many managers vs engineers there are in the workforce. Let that sync in. You're competing against a lot of people that are or want to be managers for maybe what a 10th of the spots. Competition is a lot stronger, and that's assuming the open positions aren't been filled by people from within.
>>5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.
What am I bringing to the table? That's easy, 20+ years of coding experience. I've seen enough to know you shouldn't do things a certain way, or a whole range of problems that people who just started out didn't even know existed. I know which log files to look in on a web server when there is a de-serialization issue. I know that a particular linker embeds a date stamp 60 bytes into the header of an assembly. I also know how to write and communicate technical problems to an audience in a simple way to allow them understand the const benefit analysis of a particular approach. You don't pay me to write code. You pay me to solve problems, especially ones you didn't even know you had. Some of them are coding problems, a lot of them are not.
EDIT: Formatting
Here is why - (for the sake of discussion, "principals" refers to principals and above)
- In an org, lets say as a director, I find I rely on my principal engineers to objectively tell me what the right thing to do is. They have less political motivation.
- Principal engineers almost unilaterally have a series of noteworthy accomplishments that create a catalyst for innovation for all engineers around. The depth they create inspires people to really understand tech.
- Discussions with them require managers to have more depth themselves. Rarely can managers win arguments without brushing up on tech.
- Regarding some comments about "CRUD apps" as universal easy things all engineers can solve I find perplexing. Problems in distributed systems are all trying to make CRUD possible and organizations are still figuring out how to do that at scale.
- Regarding arguments about ageism for principals, yes, I agree that ageism exists to a certain degree. However, I find most principal engineers are older as you go up the chain. Therefore, what you are really saying is ageism exists for engineers < principal level. Where you can have new hires know the same depth as them and pay less for. Can you imagine trying to hire folks that built S3, Python, Kafka, etc. be replaceable by younger folks?
'When I was on TV (Computer Chronicles) in early 1987 showing our product Trapeze the other presenter was Mike Slade who was product manager of Excel. At the time young me thought him some random marketing weenie (young people can be pretty stupid). Yet he started all these companies later including ESPN, worked for Apple in various leadership roles, was a good friend of Steve Jobs and started his own VC firm'
http://thecodist.com/article/my-biggest-regret-as-a-programm...
[emphasis mine]
i think she makes a really good point here: one that's often overlooked by the "improve"-everything-all-the-time culture that a lot of contemporary tech inveighs.
it's easy to advocate solipsistically for an alternate solution that you came up with. it's harder to objectively weigh the merits of extant design decision and admit that your predecessor made an optimal (or more-optimal-than-you-can-muster) choice and defend it. iconoclasts may occasionally create great things independently (perhaps if they're a Linus Torvalds or a Margaret Hamilton), but the meat and potatoes of building functional and robust software is building well on solid foundations, specifically by respecting those foundations when they're sound.
Some of the above decisions have a technical part, but none are entirely technical questions.
you're telling me there's a difference between a principal and a senior principal? this seems like title bloat (non-financial, meaningless compensation)
i think there are just way too many senior engineers and not enough work for them. this title thing feeds into my hypothesis: if you're getting to the principal level and then encouraged towards "senior principal" level, that's an illusion of career progress.
i think more senior engineers expect to carry the sort of intellectual freedom they had as high output juniors forever as they become "organizationally woke elite hackers". that's just not a good way to portray yourself, though: eager juniors like that person once was will do the job at 75% cost, and not try to occasionally wade into politics as this free roamer has empowered herself to (ref. bullet about cross-organizational lubricant type)
i would be extremely wary of portraying myself as an "elite hacker with enough confidence to meddle across teams" because that is about as vanilla as it could be in 2019. instead i would slot in with an enterprising managerial type and basically become his code peon, pumping out his prototypes, giving him the credit where due, and understanding that he's generating the ideas but not the code, so he can't ghost you very easily and (maybe) he'll keep you safe in the event of layoffs.
this keeps you learning new tech and always building, but makes you really valuable to someone with organizational power, so safer than some generic engineer on a larger team.
And I find more and more that using this as a lens solves lots of these sort of conundrums
What do we do with senior / principal engineers? can be translated to "what shall we do with these really good readers and writers we have hired"? The answer is not invent some parallel path in the company to have them walk around looking for solutions - they become leaders of the organisation ... or they go out.
And as for the C-suite. No CEO ever announced that "well I used to read and write but I don't have time for that anymore. I do enable my skip levels to do more reading and writing on their 20% projects however. Sometimes I dream of taking a week off in order to write something - maybe an email, like the good old days"
If the management of the organisation is spending less than half its time coding, the company does not have enough automation and will get its arse kicked by 2030
