"When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path"
As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems. For one, organizational incompetence when people who were valuable contributors where they were are elevated up into roles where they no longer can apply those skills as effectively (i.e. technical team lead to management or architect) leaving a vacuum below. A form of the Peter Principle I guess, except the individual may have competence in their new role but not be happy, or make the team itself less successful.
And most importantly, as he touches on: being asked to 'level up' and told that this is your mission can lead to an unpleasurable career. Either when you do get that promo and then find that you don't enjoy the new responsibilities (but become trapped by the position / upgraded compensation etc.) or when you don't get the promo (or don't try) and find that your value in the eyes of yourself and others seems less.
And finally, I think this type of thing can really take hold in places with a highly academic background / focus / origin (like Google, etc.) as it mimics in many ways the grade / peer review achievement structure of academia. And that reward / grading structure may not at all correspond to either the monetary or cultural success of a corporation.
Smaller companies looking to grow/formalize should exercise caution when looking at the rating/performance/promo process @ FAANGs / MS as a model for their own.
(I'm at 20-25ish years in the industry, but really feel junior in so many ways when I read the words of veterans like this.)
First real job I had there was this guy who had one specialization. He was in charge of some software that drove tape drives.
Every outside new manager would come in and in some form or another look down on this guy in some form due to his age and generally not doing "a lot" of tasks and new products.
It took the local VP to come down and regularly high five him after his product git rave reviews from customers (regularly) and make the point every time some manager didn't get it.
That guy's code, documentation, everything was rock solid, and the number of support cases for everything he did was so low that the dude was without a doubt the most productive person as far as income goes. You could sell the product that he worked on and just rake in money with almost no costs after that. Almost everything else had a lot of support costs and etc.
Meanwhile the guys who were doing all the new stuff, sucked at trying to juggle 12 things because it looked good on a resume.
It's similar to the systems administrator dilemma.
Do your job well, it looks you are not doing very much, why are we paying you?
Everything is on fire, it looks you are not doing your job properly, why are we paying you?
I've worked with a few engineers over my career like the person you described and frankly they are worth their weight in gold, been able to bank on their output working reliably and consistently over time is hugely valuable, doubly so when what they do is the bedrock of many other things.
Of course the unhurried, thoughtful person looks like they are slacking and the hurried, frantically working person looks like they are a hard worker.
Fundamentally it's because impact is harder to measure than perception.
I once worked at a place where the development process for the Windows version of their product was GLACIAL because there was no way to run the CI scripts locally or even set up a dev environment that could build the product. People actually edited code in a text editor and then submitted it to github and waited an hour for the CI job to build a virtual Windows instance, run updates, install Visual Studio, Oracle, and all supporting software, run the compile and bail with a syntax error :((((((
So I made a Powershell script to install everything from scratch on a fresh Windows 10 or Windows Server system using Chocolatey. The script took about an hour to run, but once it was done you had a Windows box (or VM) that could build the project in 2 minutes at most, or just run the CI script directly before committing. Suddenly it didn't take weeks to fix bugs in the Windows client, and corrupted installs or DLL hell was one "wipe", "run script", "walk away while it churns for an hour" cycle to a perfect dev environment again.
I was fired 6 months later for "not stepping up enough".
I solved a bug at my company that was costing $10k per month. The whole thing was not acknowledged because the leaders were embarrassed and probably afraid of repercussions for not realizing they were pouring that much money down the drain. (this was at a small company). Then I was sidelined by the CEO (a marketing guy) because I wasn't "senior enough" to do the job, whatever that means. I wasn't good enough, but the system I built for them is apparently still running several years after I left and looks the same.
Management should clearly see impact and that your work multiplier is higher. Their loss for sure.
Typically, higher leveled engineers have higher workforce multipliers —- their output is measured not only on their own work but how they move the whole team, division, company, or industry forward.
If your test loop depends on waiting for what sounds like an end to end test, the core problem is that you’re missing lower level functional/unit tests. Nobody should have to regularly wait for a server to install visual studio and oracle crap just to get feedback on a code change.
Now this isn’t the sys admins fault at all. The sys admin definitely helped here but the devs still have a broken workflow.
This solution was designed to solve the whole package. The script is designed to run on BOTH a CI system and a standalone dev box (real or virtual), giving the same deterministic, stable environment so that everyone is always on the same page (Honestly I'm surprised this isn't done more often).
As a developer, you run the script once on your fresh Windows dev box, and then you can develop, run unit tests, or even run the CI script locally to have confidence that it will actually pass CI when you check your code in (and not overload the server with bad builds). In fact, I did all of my dev work in a VM because it's super easy to tear down and rebuild if I break the OS somehow or introduce an unexpected dependency ("it works on my machine" syndrome).
As an admin, you only have to include this one script onto a fresh Windows image, then run it and save the resulting VM image for the CI server to run (instead of installing everything on every run as part of the build script like they were doing).
The original issue was that everyone was using the CI server AS a dev environment because they couldn't get the project to build on a standalone box (it was tricky to set up, and undocumented, and the build scripts assumed a complicated CI environment). And management wasn't even raising a stink about this, despite the HUGE cost (in a large corporation I can understand this sort of thing falling through the cracks sometimes, but not in a small startup!). I'm actually not a sysadmin (I'm a developer), but I do hate inefficiencies like this enough to do something about it.
> Fundamentally it's because impact is harder to measure than perception.
Absolutely. Another nontrivial variable is the tendency for managers/team leads to get the "credit" for successful work, even if they aren't trying to.
I've had managers before that did nothing but impede a high performing team. Luckily we delivered despite this. But it never failed, the manager would get accolades (often very public) for successfully releases, customer feedback, etc, and would end up promoted up. Meanwhile the team kept doing our thing, getting barely-matches-inflation annual increases and more and more micromanagement from the scrum diehards. Didn't take too long for the team to move on to better things. I have a dream of someday reuniting the super team for a sweet startup idea. Not likely to happen but I can dream :-)
> Do your job well, it looks you are not doing very much, why are we paying you?
> Everything is on fire, it looks you are not doing your job properly, why are we paying you?
Option 3: Everything is on fire, be really quick to respond to your manager and then poke and prod at things in production until it kinda works, repeat daily. This guys a hard worker! I'll have to keep him in mind for a promotion.
On the other hand, lots of places have people who they _think_ are this guy, and who are actually just a bad dev who is good at building an impenetrable moat for job security...
I ask my junior sysadmins / new hires to write a daily log for their first year or so.
What did you do today?
What do you need help with?
What went well?
What was frustrating?
What should we change or fix?
When we get together to talk about their day or their week, these logs are extremely useful. Sometimes they generate tickets, sometimes book or course recommendations, people to talk to, sometimes just conversations.
As a sysadmin, I actually keep a log, but I'm under no illusions that anyone will ever see it but me.
I used to track my tasks in Jira with the thought that maybe my boss would look at it and see what I was doing. Of course he wasn't looking at it so I stopped doing it.
My log is mostly for me to provide a list of achievements to my boss whenever there's a review, or if I'm questioned about what I spend my time on.
It would, but these logs can also feel like oppressive and meaningless bureaucracy. A lot of sysadmins are not even good at typing...
It’s one of those things that would probably be naturally suited to voice-activated systems (“Hey Siri, today I updated system X to avoid Y, and I wrote a script to improve process Z on input A” - 5 seconds to say, log saved in the right place, keywords like “updated” and “system X” recognised and formalized into some record, etc), if only such systems actually worked on any word beyond the most trivial (good luck with context-less mentions of pythons, rubies, native-american tribes who somehow serve pages of webs, androids in phones, etc etc).
> Meanwhile the guys who were doing all the new stuff, sucked at trying to juggle 12 things because it looked good on a resume.
This isn't helped by the current trend of trying to hire mostly fullstack developers, also known as hiring one person to do the job of three people. It does almost nothing but incentivize packing resumes to hopefully make the cut and burn people out from switching modes.
Fullstack does not mean that you will burn out. Fullstack can mean 40 hours a week, never overtime. Also, for smaller apps, after you had at least few months of experience with all technologies, it is not difficult to switch modes.
People who specialize will be better at their specialization, but you will be good enough for majority of apps.
At the end of the day, some people like Javascrip and CSS. And "full stack" only means that they will work with those, SQL, and some backend language (that may be Javascript too). It doesn't imply anything on the workload, all it does imply is that the place is hiring a generalist instead of specialists.
The last job offer that made me smile was for an AI / fullstack developper.
Aka the platypus of software dev.
The problem is pretty simple.
Let's say you are cutting-edge in all the technologies that make you very adaptable at time T.
You get hired.
You decide a stack A/B/C/... for your next project.
You get stuck in that project for ... let's say 3 years.
(a reasonable time for a project to reach production and have a few real-life iterations).
If you are not an assh... who leaves after 2 years (leaving the production/maintenance to others, i.e never having lived the "hell" of maintaining things for real), then you are 3 years-behind in all the technologies that are not in the A/B/C/... stack.
Now, at time T+3, you are ... the obsolete man [for TTZ fans only :)]
Frontend has very few to do with HTML and CSS nowadays.
It all has to do with framework choice, the build toolchain, the unit-testing of the front, the server-side rendering vs the client-side, the architectural layers (or bricks) to use on the client-side, SEO, performance, CI/CD, browser compatibility, components lifecycle (yumm, library versions upgrade!).
That guy could perfectly be some tech lead, establishing his rock solid approaches on team of junior 4-10 engineers and delivering rock solid new products.
Another story may be because he may not be promotable to such position because of mentioned "prickly" behavior, which may or may be not just engineering honesty and straightforward approach in contrast to bs(sugarcoating, ass kissing, exaggregating, sweeping dirt under carpet, etc) culture established in many companies.
Expecting a talented software engineer to "upgrade" to become a manager of a development team makes exactly the same amount of sense as expecting a talented accountant to gain a bit more skill and suddenly become a lawyer.
There are other paths at Google than upgrading to mgmt, but all of them involve "cross-team collaboration" and other quasi-political (with a small-p) aspects.
Actually just writing code at Google is, from my experience, a small part of the job and not rewarded. The faster you get out of writing code and get into designing and delegating it, the better you're off. Sucks if you don't like it.
Coming up with a way to reward and improve nose to the grindstone technical contribution seems to me key to having an effective organization.
EDIT: also consider, doing management or team lead at a company like Google is so different from, say, a small company, that the trajectory may make no sense for somebody. Before I came to Google I felt myself on a career track that was team-lead/architect focused, mgmt interest, etc. Once I got there, that evaporated. I just couldn't imagine myself doing that kind of work in this large of a company.
Over the course of a number of years and a few jobs at IBM starting in the early 90s, I knew 2 people on their "technical track". Their jobs involved huge numbers of airline miles, continual meetings, and essentially no technical work.
That was one of the primary reasons I stayed a contractor most of my career.
Interesting that your contractor jobs haven't also filled with non-technical, biz type work? Lack of desire to deal with accounting, client meetings, all the organizational aspects of running a business have kept me away from contracting or consulting.
Might be time for me to revisit that, this being the year when I really think I need to start something new. I have no idea how to make that switch though.
Are you contracting through your own business, or someone else's?
Typically, no. I almost always worked as an employee of a technical contractor---I was an IRS W-2 employee; they withheld taxes and provided (sometimes decent) health benefits (although I decided it was better to buy my own rather than changing insurance when I moved). I had no more than the usual accounting and organizational challenges.
For me, getting into it was easy. I packed off a resume to several of the local contracting companies. They pass the resumes to the ultimate company, who will do an interview (usually very low stress because it's easy to get rid of you) and then the contracting company and the employer work out all the details. (It may have changed, but at the time of my last such deal about 2005, the contracting company absorbed about 15% of what the end company was paying for you.)
Do realize that you need to keep at least 6-9 months of your income in a readily accessible account (savings, money market, or (whoo, I'm old) CD). I never went for more than a week before I could another job, but I have known people who had more trouble.
I have since gone into federal government contracting, which is another whole bag of stinky fish heads.
I've moved into contracting after being a software engineer/developer/team lead.
Essentially since you are contracting, you are outside of the "bubble" where decisions regarding business get made. So while you may have important work on the project, you are not there when they are deciding on business aspects of it, you are usually not invited to any type of sales meetings or meetings with the clients. This is reserved for company people.
Another aspect you can do is that you can outright reject that type of work or slowly move away toward a client that is not requiring that type of work. When you are working in a company, you usually do not have power to do that. Your only option in a company is usually to quit and then hope next company doesn't pull you into that meatgrinder.
The down side is that you don't have any direct influence on those business decisions. (At one point, I wrote about three different login/single-sign-on clients for a web app infrastructure (including Kerberos/Active Directory) before they finally decided that SAML2 was politically/technically the right choice. Frustrating.) You do have indirect influence if you have a good relationship with your team lead, who will likely be a "real person", a real employee.
If it's anything like my experience hiring contractors, it's definitely that they get the most "fun" part of the work. Most companies use contractors (in engineering) precisely for a well-defined tech work. They don't have to manage people or sit in meetings that are not relevant. We pay them by the hour and we try to get them to work on the stuff they can contribute the most - dealing with politics is expensive.
In the 2000's I did contractor work by myself (and occasionally hired a friend or two to get a project done). It was a disaster. I spent >50% of my time on client, non-technical work. I then joined a ~20 person firm in San Francisco and worked there for a few years purely coding. It was a joy. They had great business people, designers, copy writers, and then about a dozen great engineers, and I could just focus on the code and get paid for that. My hours went down, pay went up, and got to do what I love.
If you are thinking of contracting/consulting, I'd highly recommend joining a diversified team in the 10-100 range so you can do the parts of the work you love and rely on your team for the rest.
Yeah, I no interest in running my own consulting business.
In my case, it was usually a contracting company with 10-100 contractors working for one or more client companies, but the contractor had 0 day-to-day influence on the work I did. (I did try to pick up my paycheck in person and chat with the office staff.)
Personally I "think" I want to just code forever, but I migrated from coder to more of an architecture role. However, for me, the growth is just not there. It is in the cross-collaboration, mentoring and industry influence is how you develop. In some companies time in grade is a factor in layoffs. Due to ageism companies might not be looking for someone at a certain age and experience to just grind out code full-time, but to work on a product holistically.
I've seen people from small companies playing the tech lead or manager roles, move into google as "Senior Software Engineer" or whatever equivalent - basically writing code again. And the reason is in your edit. In fact a lot of the "hot shots" at small startups that play nice with the boss and can wrangle Jira but were actually excellent coders - can't do the politics at the big companies.
Part of that is that the big companies typically hire suits to do management - which were basically the jocks in high school that always got the girl... that type - they run everything in the world now. Loud mouth tech bro asshole types.
I think a lot of technical leadership is a side-effect of ability. People with a lot of technical experience are able to view projects at a high level (and judge other programmers accurately) as a side effect of being good. You want them cross-collaborating because they have better eyes than someone without experience. Whether they know to iron their shirts doesn't matter.
In baseball, coaches and managers are all ex-players, but not necessarily good ex-players. (Well, anyone who plays in MLB is “good”, but relative to the rest of the league I mean.) Just like in other industries, the skills required for a good coach or manager don’t always correlate with being the best player.
> I can't think of any sport where players are expected to become coaches.
In amateur sports it's common. E.g. in rowing, cycling, fencing, cross country skiing, etc., people are generally expected to coach at some point. Albeit usually while they're doing the sport, and not necessarily as their primary careers.
To some extent, coaching something you practice is good for giving you another perspective on what it is you're practicing. In an ideal world, this will elevate your skill level.
This does, however, not necessarily mean that everyone is a good coach, nor does it mean that everyone should stop practicing what they're doing and focus solely on coaching.
Football/soccer? Of course there are more players than coaches so they can't all become coaches, but I would say star players are expected to become coaches, and lots of them do.
Football team coaching staff are almost like another team. Position coaches usually are ex players of that position but as you move up the chain it gets more into strategic management and thus by the HC level it's more of a manager role with architects underneath for offense and defense so less position technical knowledge more game knowledge.
Well, only 1/3 of them played Pro before going into coaching. The rest were college players (and two only played in High School) who switched to coaching, mostly because they didn't get drafted.
In my mind its not that far fetched, depending on the person. The transition from experienced dev, to mentor to leadership doesn't seem all that unnatural.
The only difference between a manager and the other on-the-ground engineers is that the manager works more closely with the stakeholders to understand their requirements in more detail than the other engineers have time to. With that additional knowledge in hand, the manager helps guide the other engineers to make the right tradeoffs. It is still engineering, just at a different level. A level not everyone enjoys working at, granted.
I guess if there is an accounting analogy, it would be selecting one accountant to work closely with the government to ensure that the tax law is fully understood and to watch the other accountants to ensure that they are following that tax law, reducing the inefficiencies of all the accountants in a firm needing to spend their days acquiring a perfect understanding of the tax law and not spending their days doing the practical accounting work.
That’s a really weird analogy... Writing software (in any reasonably challenging context) is not administrative grunt work with clear and easy definitions of right and wrong.
It’s an art and a science. So I much prefer the comparison with pro athletes who become coaches or actors who become directors.
Having been employed at Google for about nearly two years, your take doesn't seem accurate at all.
> And that reward / grading structure may not at all correspond to either the monetary or cultural success of a corporation.
The key feedback/suggestions I see for my own performance review is to define my impact on both the monetary and cultural success of my org. Exactly the opposite of what you are saying.
> being asked to 'level up' and told that this is your mission can lead to an unpleasurable career
I don't see this happening either. I commonly hear others say the opposite and make it known they are no longer trying to level up and that they are happy where they are.
> technical team lead to management or architect
This does not jive at all with the various career ladders I see. There is no ceiling that requires me to move to management in my tech ladder.
> find that you don't enjoy the new responsibilities
To some extent, the promo process levels up employees already working at that n+1. Sure, some may not want to maintain that, but that is ultimately up to the individual.
Disclaimer: I work at Google, opinions are my own.
> "to define my impact on both the monetary and cultural success of my org"
What you get out of that is people frantically chasing impact and visibility instead of focusing on the humdrum drudgery of keeping the lights on. The result is penny wise and pound foolish behavior that definitely does not correspond to the monetary or cultural success of the corporation. People who are good at gaming the system in this can create their "impact", collect the rewards, and make an internal transfer before the costs or superficiality of their "impact" catch up with them.
> As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs.
So I have to ask: do you or have you worked at a FAANG with these systems? I may be wrong but I suspect you haven't, particularly if you're equating them with more traditional hierarchies.
The whole point of a system like this (and I have direct experience at Google and Facebook) is so you can go pretty far as purely as an IC. You're not forced to become a manager.
So at Google for example, new hires start as a T3 (T4 for PhDs). There is an expectation for growth up to T5, meaning technically you are meant to progress over time. When I was there this wasn't strictly enforced (eg I knew people who had been T4 for 5+ years) but it may vary from PA to PA or manager to manager and it may well have become stricter.
IIRC the general guidance was 2-3 years T3 to T4 another 2-3 years for T4 to T5.
At that point you can sit at T5 forever if that's what you want to do. People's desire to get promoted leads them to becoming managers because it is demonstrably easier to promoted from M1 (T5 equivalent) to M2 as en EM than it is from T5 to T6 as an IC.
These higher levels are really an indication of your organizational and technical impact and for this you really have to influence others. This is not being a people manager however.
But the point is that there's no "up or out" (beyond T5) like you may find at IBM or KPMG.
Now there are definite issues with Google's approach here and that's really a whole other topic. I just don't think your observations here adequately describe the FAANG career paths (IMHO).
> So I have to ask: do you or have you worked at a FAANG with these systems?
Yes, 9 years at Google. But yes, not experience beyond the L4/L5 tier.
It is true that the IBM type structure isn't the same, and yes, Google is fine with you staying around L5 forever (well, L4 now). But the matrix of things to get beyond L4 really is, in the grand scheme of things, about moving beyond development and into delegation, or at least ownership. It's not management, but it is about leadership/cross-team collaboration and "demonstrating impact" to others. So, like I said elsewhere, small-p political.
At least that's my experience from seeing the L4 to L5 transition. But it may also be a product of my smaller office, where the number of projects is smaller, team size is smaller, and larger technical contributions of impact are harder to find.
EDIT: Also I've seen a lot of change in the 9 years, in terms of how the organization as a whole behaves, and it is becoming more and more like a traditional BigCorp. I just checked percent/ and within engineering 86.43473% full-time employees are newer than me. And a lot more if you count non-engineering. It is a way larger company than I started in.
EDIT2: I should underline, that the perf/promo process obviously works for a large, perhaps the majority, number of people. But it doesn't for all. It requires adapting to an organizational model that not everybody accords with. And I think that's in the spirit of the original topic: organizational structures / procedures that become your career goals may not make you happy, so find a company whose process matches what you want to get out of life. Or try.
The senior IC ladder saves you from being responsible for people, their job satisfaction, their career progression. But it is still a kind of management.
Facilitating meetings, reviewing documents, tracking schedules, reporting progress, convincing teams to prioritize the work, negotiating with those challenging the technical decisions, securing credit, deflecting blame, getting resources, etc. The model of an effective L6 or L7 IC is part secretary, part Frank Underwood.
You're right that you don't have to pursue L6/L7, but L5 is attainable in < 4 years. No 46 year old wants to be doing the same thing for the same pay as a 26 year old.
> No 46 year old wants to be doing the same thing for the same pay as a 26 year old.
Why not? Being a T5 SWE at Google is (or at least it can be) pretty chill. It's a sweet spot for low stress and relatively high compensation. Why exactly do you need to "advance" your career, particularly if you don't want to be actually or effectively managing other people?
The alternative is the "up or out" approach that drives engineers in other industries into being (usually bad) managers.
L5 / "Senior Software Engineer" expectations are such that you have to have "influence beyond yourself", own some area of work, set technical direction for some other engineers. You're either a team lead or an "exceptionally strong individual contributor".
It's not really that chill, and if you don't continue to do those things (lead or be exceptionally strong) that will show on your perf and therefore your compensation. Going from L4 to L5 means committing yourself to doing that on an ongoing basis. Remember at Google that "consistently meets expectations" is only a 2 out of 5 rating, just above "Needs improvement."
Coasting at L4 ("SWE III") could be fine. Large independent technical contributions, manage your own priorities, participate in design, etc. Solid individual contributor. Really equivalent to "senior developer" at most other jobs.
But now let's say you want to go transfer to a new project. The manager on the other team sees you've been at Google many years, but still at L4. Hm. Results may vary.
Not everyone makes a good team lead. Especially in a place like Google surrounded by PhDs and super achievers. But the expectation at Google up until very recently was basically that you should become that, or get out. Now in the last few years, it's been stated it's perfectly fine to plateau at L4. But I'm not convinced that that's the reality of the culture or expectations of managers.
So are you basically describing stack ranking here?
It's just impossible for everyone in a company to be a team lead, so not everyone can become that to become an L5.
Which leaves the other option, to become an L5, which is to be an "exceptionally strong individual contributor" and being that "on an ongoing basis". Not everyone in a company can be an "exceptionally" strong person, otherwise it wouldn't be exceptional any longer.
You're saying the expectation was to either become L5 or get out. So now we have all these PhDs and super achievers working at Google, but only some of them can be exceptional vs. the others.
You were exceptional vs. regular people and made it to L5. Now comes in a super achieving PhD that's a tad better than you and now he's exceptional. You are no longer exceptional. You're just an average super achiever. So get the eff off Google's lawn. Stack ranking completed.
Two years is a long time to stay in one job. Two years is an eternity for a team's headcount not to grow. It's virtually certain that you'll be a mentor to several new hires in that time. You'll also have a long head start on understanding the codebase and tools relative to many others who will be working with them. If you're not some kind of leader at that point, something's wrong.
Unless you found one of those rare teams that stays together for the long haul, but the experience with such a special phenomenon should make it more than worth your while.
If L4s are not getting opportunity to lead, they are on a sinking ship anyway and the smart ones are LeetCoding.
(Obviously this all reflects the crazy economic moment of the last 10 years in Silicon Valley, but so does the level system you're critiquing).
> Two years is an eternity for a team's headcount not to grow.
Teams do not expand until infinity. In fact, it is often better for teams to not expand.
If you are expected to be leader after two years, because the teams are expanding regardless of whether more people are needed and because everyone else is fresh new, then there is issue with managemet
Where do you think the crazy stock growth for the entire tech industry over the last 10 years is coming from? Having a massive backlog of productive opportunities, scaling up to execute on more and more of them in parallel.
I don’t expect that to last forever, but it’s the context that this system is built for.
Yes. The challenge is how to measure individual contributors. It’s easy in Sales, which is why salespeople can do very well without being managers. Harder with engineers, whose work is very interconnected.
For sure. And it's why frankly in my opinion it's very hard to scale software development effectively beyond 25-50 engineers. After that politics and faux-meritocracies take over as people lose personal touch with each other.
Team mates, usually know who is a good engineer, and who's not - much more accurately than management.
When I was in Google, Perf process was based on peers feedback, and it worked well.
I'm happy to lead as long as I also am allowed to work on the code itself from design to actually writing code. I have been doing this full time for 35 years and I would be miserable had I switch to a pure management role at any point including now. Meetings kill motivation for me.
> Smaller companies looking to grow/formalize should exercise caution when looking at the rating/performance/promo process @ FAANGs / MS as a model for their own.
Robert Townsend had a comment that stuck with me, you don't get to be GM by behaving like GM. Which is beware of cargo culting successful organizations as they exist now. I'll also suggest don't cargo cult hyper funded startups if you aren't one either.
I was 33 years in the industry, as a developer. Some times I considered going into management, and was asked about it, but fairly early on I realized I would hate it and it would hate me.
> I think this is a corrosive aspect of the perf/promo process at many FAANGs
Disagree on personal experience with two of the FAANG Cos I have worked for.
A person content in their position, performing/delivering as expected can (and many do) coast. There was little to no pressure from these firms to "move up or move out".
There is a corollary to this - having a career of sideways moves and simply not progressing even in ways that are positive and to your liking because each move effectively puts you back to zero and companies taking advantage of the 'flat structure' myth to avoid having to provide career progression.
I think of it as vertical vs horizontal career path. Vertical is becoming a manager of more and more people and/or projects. Horizontal is becoming an expert at more and more technologies/languages/etc.
At FAANG there's always an IC track and management track. Additionally, promotions are almost always lagging, meaning the individual needs to performs at that level for some time before being promoted.
"When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path"
As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems. For one, organizational incompetence when people who were valuable contributors where they were are elevated up into roles where they no longer can apply those skills as effectively (i.e. technical team lead to management or architect) leaving a vacuum below. A form of the Peter Principle I guess, except the individual may have competence in their new role but not be happy, or make the team itself less successful.
And most importantly, as he touches on: being asked to 'level up' and told that this is your mission can lead to an unpleasurable career. Either when you do get that promo and then find that you don't enjoy the new responsibilities (but become trapped by the position / upgraded compensation etc.) or when you don't get the promo (or don't try) and find that your value in the eyes of yourself and others seems less.
And finally, I think this type of thing can really take hold in places with a highly academic background / focus / origin (like Google, etc.) as it mimics in many ways the grade / peer review achievement structure of academia. And that reward / grading structure may not at all correspond to either the monetary or cultural success of a corporation.
Smaller companies looking to grow/formalize should exercise caution when looking at the rating/performance/promo process @ FAANGs / MS as a model for their own.
(I'm at 20-25ish years in the industry, but really feel junior in so many ways when I read the words of veterans like this.)