Spent two years completely remaking the product I was tasked to work on, while the two other engineers on my team, both a level above me, cheered me on and didn’t do much.
I turned our product from a total waste about to be cancelled into a promising tech with some momentum, but I spent all my time coding instead of writing about coding, and I likely won’t get promoted again this cycle.
It’s been very strange to see the fruits of my labor benefit the org while feeling totally unrecognized outside of my team.
Now dealing with massive burn out for the first time in my career. Not sure what to do. I make sure to put out fires and do the bare minimum to keep up the product momentum, but I have no love for the org and just don’t think I’m cut out for the politics games.
Note that at Big Tech companies, almost all code is written by L3/L4 (the untitled "Software Engineers") and the few L5s ("Senior") that enjoy coding. L6-L8 ("Staff" through "Principal") are the political levels, where EQ is more important than IQ, your job is as much wrangling/convincing/selling/negotiating with other people as writing code. Most L6-L8 engineers are managers, but even those who are ICs spend the majority of their time politicking.
Being under the protection of a good L6+ is essential to actually getting anything done, launching, and getting promoted at a big company. Without it, you'll find that you won't get any cooperation from other teams, your projects will get canceled, and nothing you do will ever launch.
Staff+ engineers burn out at significantly higher rates than lower levels. I know a lot of Senior engineers that are quite content to just sit there and never get promoted, because the quality of life at that level is IMHO significantly better than at higher levels. Was talking with another recently-promoted Staff engineer (I'm Staff myself), and we were lamenting that Big Tech doesn't really do demotions, because the job expectations at higher levels get progressively higher, you have progressively lower control over outcomes, and the consequences for screwing up are significantly worse.
There do exist those rare creatures who manage to get promoted to, and beyond, L6 as ICs. I've been trying figure out how they do it, but can't say I've been making much progress.
(I'm Staff myself, but would not have got here without management responsibilities.)
Known of v high level example that is just incredibly disciplined about how they spend their time (e.g. "I did this, but was slowed significantly by poor code over that. Estimate about 30% time loss. I'm going to spend N weeks more in this area, so it's worth me spending 3.5 days fixing that code, but no more. I think I can fix it in about 2 days, so I will fix it. If I can't see the end of the fix by the time I'm 4 hours in, then I'm probably wrong about the expected time, so will abandon the fix").
The result is ridiculous productivity. They don't work long hours (strictly 9-5), but just very, very focused on making certain that there will be meaningful results from those hours.
So they exist, but absolutely it's not going to be common!
I don't know about other places, but volume of work does not matter for L5->L6 at Google. The kind of work you do is what matters. So doing 50% more doesn't get you there.
The L6 (and L7) ICs I know got there by implementing really tricky components way down the tech stack that are very difficult to update due to insane implicit dependencies and also enormously impactful in terms of savings across the entire company.
It's not rare at all in my experience. You just have to have a combination of skills that pays more than average on the open market (big data runtimes or distributed systems, say, or AI, in addition to other domain expertise perhaps), and you'll be L6 or L7 IC, no problem. No managerial duties whatsoever. L7 is more nebulous, but L6 is absolutely doable for anyone with a modicum of marketable skill.
You see, in spite of their internal promo treadmill and brainwashing, companies have to compete on comp regardless. Comp ranges, in turn, are tied to levels. If, say, someone who knows a distributed query plan from a hole in the ground costs $1M/yr, they'll get that and the "level" will be adjusted accordingly, as much as necessary, ignoring the elaborate formal descriptions of job responsibilities.
It's the proles in the trenches that take the levels seriously. People who actually run things understand that levels are merely a hamster wheel, put in place to give you something to look forward to, and to keep your comp expectations in check. Lack of "broad organizational impact" is _the_ most often used cudgel to deny promotions to the more senior level, unless your skill stack allows you to bypass this bullshit entirely.
That sounds entirely logical, but unfortunately having never worked in a FAANG or FAANG-like company[1] I can't tell whether this is the reality or not.
I would very much like other readers here with experience in FAANG or FAANG-like companies to comment on your comment.
[1] Most Corporates and enterprises are different - they resolutely refuse to match based on market-value of skills. There's also very little a developer (senior or not) can do to have a company-wide impact, because the fiefdoms that are in place will resist any attempt to "lose" their territory.
Largely false. Managers have pretty wide latitude to approve compensation matches for employees they want to keep without up-leveling them. So if you're a star L5 at Google and Facebook is giving you a $MM E7 package, you could end up with a $MM stock grant (which would normally be reserved for L7+) at Google. Compensation raises are tied to level, but that just means that you'll sit and vest your existing stock grant without further raises or refreshers until your formal level matches your comp package. This happened semi-frequently in the ~2010-2011 era when Facebook was recruiting heavily out of Google with pre-IPO stock.
The promo process is based on your value to your employer, and at least at Google is done by committee, which is drawn from a selection of high-level employees outside of your manager's department (so they have no incentive to keep you) and has a packet of information that does not include anything about your market value outside the company.
Stock ranges (as well as refresh grants) are also tied to levels you're hired at. "Largely false" my ass. All of this BS applies _only_ to people with weak skill stacks. Committee doesn't even know your "previous" level elsewhere. They know that you've e.g. built this very impressive distributed system here and now and hopefully it made $MM revenue difference (which you'd be smart to quantify and mention). So if you can do it, you'll get rewarded appropriately. If you can't, you won't. And sure, you can't go E5 to E7, there's just no way. But getting from E5 to E7 (or T5 to T7 at Google) is doable in two promo cycles for someone who's in the right place at the right time, and has the right skill stack. Or in fact in the immediate if they are willing to move to another FANG company.
Distributed system & big data knowledge is table stakes for Google engineers. At L4 you will be expected to deal with large distributed systems handling petabytes of data. You probably don't need it for L3 (which includes new grads who would never have had an opportunity to develop that skillset elsewhere), but by the time you're at L4 you should be dealing with that regularly.
This is one of the perks for moving from FAANG to non-FAANG; hiring managers elsewhere know that simply by being an engineer there you will have had exposure to distributed systems and big data, and so bring a transferrable skillset to their company.
I thought about whether your comment is true in the context of Speech & Image recognition and other AI technologies. The Speech leads do seem to have an awfully high number of Distinguished/Fellow engineers (this is the top of the eng ladder, where you can basically write your own ticket and your comp package is enough to retire on). However, there are still an awful lot of L4 engineers working on Speech, many training deep-learning models as part of their daily duties.
> Distributed system & big data knowledge is table stakes for Google engineers
True, but observe that knowledge is very different from _experience_. In anything sufficiently complicated there's tons of stuff you won't find in books, and even if you do, you won't pay sufficient attention to. E.g. you could sorta know how a database works (from a university course or something), but if you haven't implemented e.g. a state of the art query engine or a storage manager, you'll still be SOL in practice until you write one or more of those things and actually gain experience.
Knowledge by itself is darn near worthless, it only becomes valuable with experience, particularly if it's in 2 or more related fields.
I'm an L6 IC. Basically I had a track record of delivering projects that other engineers said couldn't be done yet were a high priority to upper management. That's actually on the (Google at least) ladder: "At this level...most Google-caliber generalist SWEs could not own and solve the problem this person is owning and solving."
Note that even though I'm a coding-heavy L6 (meaning I spend ~50% of my time coding vs. the 0% that most L6s do), the majority of my time is still spent interfacing, negotiating, and communicating with other teams. The ability to silo in a particular problem domain and just become a local technical expert ends at L5.
Can you give an example of a project like that? Or at least a hypothetical example if they are confidential.
I can’t think of a project like that that people said couldn't be done, its usually just people saying “we cant do it at this time unless we get more time or reprioritize something else.”
My current project is confidential, but one from 2013-2014:
We had a bunch of UXR that showed that people liked iPhones because of the fancy snappy animations, and our execs really wanted to bring that to Google's webapps. At the time, there was this big perception that mobile web sites were slow and clunky and you absolutely had to go native app to get smooth 60fps transitions. I did some profiling with the Chrome profiler and found that the bulk of time was spent in layout & reflow, and that one single reflow would blow your entire frame budget and then some for 60fps on mobile. So then I went to the Chrome GPU team and got a quick tutorial about exactly which operations were handled on the GPU (basically just transform and WebGL, at the time), and put together a visual language that basically involved rendering portions of the webpage to GPU textures and manipulating them only with 2D transforms, which could be GPU-accelerated. The work later formed the foundation for how Material Design was implemented in Search.
As a side note, I learned a lot about how browsers work under the hood with that project, and one of the things I learned is that the entire premise that React was sold with was false! At the time, the big selling point with React is that "DOM manipulation is slow, so we create a virtual DOM that's fast and then diff the changes to the virtual DOM so we make only the minimal set of DOM changes we need." Except that every major browser by 2013 used a dirty-bit system for DOM manipulation, so changes to the DOM are actually quite fast (roughly the speed of a couple pointer manipulations in C) as long as you don't trigger reflow. And you can trigger reflow with any one of about 2 dozen method calls, as well as automatically when you return from a Javascript script fragment, so basically every Angular and JQuery website was triggering multiple reflows per event. React was fast because it was declarative and didn't let you execute user code until it was done batching up all DOM manipulations, it wasn't fast because of the virtual DOM. And I believe there have been re-implementations of the React API that do away with the virtual DOM and they are equally fast (oftentimes even faster, since they're simpler and don't need the DOM diffing), but at this point React is popular because it's popular and everyone knows the API, not because of any purported performance benefits.
What about this project made it L6? Is it because it was a high priority for execs? Is it because you had to get a lot of buy-in from external team(s) in the Chrome org?
It's the combination of it being an exec priority + the industry consensus at the time being "It's impossible". If you deliver a high-priority project that any engineer can glance at and have an immediate idea how to solve, that's L4 work. (Say, you're shuffling data from protobuf to a bunch of Javascript on screen.) If you deliver a high-priority project that most engineers are declining to work on or saying "It can't be done", that's L6 work. If you deliver a high-priority project and then publish it externally and then the rest of the industry actually says "Woah, this is revolutionary and really valuable to us" and then Doug Cutting clones it over at Yahoo and releases it as open-source and spawns a whole sub-industry, that's L9 work.
This is all for IC engineering. I actually prefer to think of the ladder in organizational terms which also encompass management, but the sub-thread here is specifically interested in what it takes to be an L6+ IC.
Thanks this is really illuminating, how did you find projects like this? Where did u get the visibility to be able to find problems like this that were priorities for leadership?
It was quasi-assigned to me (I had the option not to work on it, but management would've been disappointed with that).
Management thought of me specifically because I'd built a reputation as someone who could tackle difficult projects, particularly those surrounding browser UI. I'd worked on the last 3 visual redesigns of Google Search (as the first engineer of the 2010 one, a consultant for the 2011 one, and the tech lead of the 2013 one), plus I started the Authorship project within Search, plus I'd done a bunch of little visual easter eggs like the [let it snow] holiday one (also a project that many people thought was impossible because it was started after the last binary push of the year). Management takes note of who delivers; it takes a while to get noticed, but once you are you get all the high-profile projects.
Not OP, but I image they are more projects that span multiple teams, disciplines, and stakeholders.
There's nothing (unless it hasn't been invented yet) that can't be implemented in software in a silo given infinite time, but the ability to deliver complex solutions to difficult business/process problems that require buy in and coordination from a lot of people are probably these kinds of projects, particularly if these projects are alterations or additions to other pieces of complex processes that already exist and are hardened but need improvement or overhaul.
Here's an example from my work. We use a legacy version control system alongside git. This causes tons of issues and the way forward would be to deprecate the legacy version control, but doing so without disrupting current engineering work and making tangible improvements going forward is a very complex task that spans a whole lot of teams and is risky and tricky to implement
I've seen this track described as a "Solver", a sort of internal mercenary who can join a project with a critical, difficult problem, research it to a very detailed level and drive a solution.
I spent the last 3 years completely redeveloping the foundation of our platform which will save the company millions of dollars a year. I didn't do it alone or anything. But I started the project, was the only one to work on it full time throughout the whole project, defined the underlying architecture, and implemented most of the lowest layers. I poured all my energy into the project.
We launched beginning of this month, I was so prod of what it represented technically. A week later I was told my performance was "acceptable", I got less than my target bonus, and got a 3% raise.
I tried to quit, but relented when I was convinced not to and am now putting my unlimited vacation to work. I'm 3 days into a month I'm taking off.
One thing I wish someone told me earlier in my career is that the skills and activities you need to perform to get promoted are totally different than the skills and activities you need to perform to get your job done, which by the way, are different than the skills and activities you need to perform in order to pass the interview and get hired. Not "related" or "complementary" to the job you are hired for--totally different.
Promotion is about marketing. Getting your name in a favorable light in front of the deciders, and projecting an image of "someone who is like other people who we promote." Different companies do this differently. At some of them, it's about directly brown-nosing the higher-ups. At others it's about getting in the right cool-kid clique. At others it's about playing golf with key influencers or talking about sportsball with them in the lunch room. At others, who pretend to be merit based, it's about writing docs and "evidence" of your good work, but don't be fooled, those docs are marketing material, not technical evidence. Getting promoted is a separate job skill you need to learn, just like debugging and DevOps. Except it's a skill that does not benefit the company's bottom line at all. You have to set aside time and stop doing the work that you were hired for, stop solving the technical problems, and switch gears to doing the unrelated "getting promoted" work.
Nobody in leadership or HR is going to explain it this way, of course. You kind of have to learn about it organically or listen to someone like me who had to learn it the hard way.
It's a signal from the market ("employer") that what you currently offer is not what they currently value. If you desire greater rewards/ recognition, you need to discover what they value and decide if you want to offer that.
Developers expect that work such as "refactoring", "platform architecture", "R&D", "investing into the future" has some intrinsic value to the business. At the company level, work such as "knowledge sharing", "upskilling the team", "fixing bugs for revenue-generating products", "reassuring management" can be more impactful given their current values and roadmap. You must choose whether to spend your energy working on your priorities or their priorities. Generally, you make more money if you help other people solve their problems rather than your problems.
Or find new partnerships where the two sets overlap, but the highest-earning consultants can fall in love with solving the problems they do have, not the problems they wish they had.
What they value and what they need often are not in alignment, and only briefly come into alignment when something fails. You can either shop for another team that has its priorities straight, move on, or play games.
Sometimes you have to develop a plan to fix something, and then not apply it until other people experience the pain themselves. Otherwise nobody knows how many land mines you’ve thrown yourself on. Games aside, it’s unfortunately part of delegation that they don’t fixate on what went well. They have other plates to keep spinning.
Sadly true..
From both a psychology & KPI perspective, an avoided unknown issue does not get the visibility of a quickly/competently resolved experienced issue. Sometimes one can be too proactive in this business.
I agree with this 100%. Also, perhaps the work you did was super valuable, but the company is simply not equipped to understand things like this. A much more realistic understanding of how the company "sees" and "feels" is through its managers. Unfortunately, they are often detached from what actually matters to the company, or discouraged from swimming outside of their lane. So, in the end, it is unfortunately very common for your "value" to the company to be what your manager values, and it is all too often the case that what they value is not totally in alignment with what actually matters to the company's bottom line (like from the perspective of the C-suite/shareholders).
This is obviously not the case for an early startup.
To me it's like having no problem paying $40,000 to the carpenters who assembled your house but cursing the world when you have to pay the architect $10,000 for designing it.
Shortsighted managers act like the 12 carpenters are doing all the "work" so they don't understand why 1 architect should get paid as much as 3 carpenters, never realizing the 12 carpenters wouldn't have a job without the architect.
This is true from anecdotal experience. However, what confuses things is that the "employer" simply doesn't know what it wants. The "employer" in this case is your immediate manager and, perhaps, a promotion committee that may include your peers. This set can have quite a bit of turnover in a company without good direction. The only constants that get recognized no matter the people (who may not have the ability or interest in evaluating technical contributions) are big talk, puffery, and unjustified confidence and optimism. Not to mention relentless positivity.
One of the relentlessly positive leads, the one who keeps calling me out for being pessimistic, has been swinging from his own petard for the ~year for rushing out changes we can’t really reason about a priori and getting smacked with obscure-to-us corner cases and regressions that are customer visible. I don’t think he’s absorbed yet how much political capital he’s burned through. Both his own and the team’s. People are frustrated. But of course he wouldn’t notice, he’s an optimist and they don’t think about things like that.
If you have a champion in mgmt things like "refactoring" or "platform architecture" can pay off. Please refactor this app off our oracle DB so we can say $10M - you will be fine and they may start slotting you into key business areas.
If you are toiling doing platform, refactoring on a product without a ton of love - then yeah - that may be pretty low visibility for most folks.
Yes, priorities and values are malleable. A strategic worker can help the company understand that they have a previously unknown problem, demonstrate that it's bigger than some other priorities, and show how they can take accountability for fixing this problem. This is what a champion does, and you can be the champion for your own work. Either you help change priorities by educating others or update your own understanding of relative priorities based on that education. Doing this requires a different skillset from actually solving the problem, and anyone who can do both consistently will be fast-tracked in any direction they want.
Be the change you want to see the world - in quite a few big organizations, if you really believe that a major refactoring of a major project is needed, the only way that's going to happen is if you switch over from development to management and become that champion, enabling other people to implement it, and without that you'll never see it happen.
> It's a signal from the market ("employer") that what you currently offer is not what they currently value. If you desire greater rewards/ recognition, you need to discover what they value and decide if you want to offer that.
Is that really what it's signaling? "Need" and "salary" seem only loosely related.
I don't believe it's healthy to look at a single employee-employer relationship through the prism of market capitalism. Maybe they just need to get better at defending their work and be clearer to their management about what they expect.
> I tried to quit, but relented when I was convinced not to
How did they convince you not to? Please tell me they have offered you something concrete and haven't just made empty promises or said nice things.
(I'm running on the assumption the unlimited holiday you mentioned is company policy rather than something they've done just for you, so by "something concrete" I very specifically mean compensation - salary, bonus, maybe stock.)
It sounds very much like he decided to take a month vacation instead of quitting. He could still quit at the end of the month. Better to get paid to unwind and/or search for another job.
Oh, for sure. And I'd definitely take the opportunity to look around for something else if there's nothing more concrete on the table (and perhaps even if there is). I mean he now knows their real opinion of his value either way.
I am currently learning that platform work in most places means nothing if you cannot point at an actual metric that management at appropriate level cares about, changing in a very tangible way; or unless your users are your peers, and you can be so good/promote yourself so well that your sheer reputation helps (and I'm not sure the latter even works in most places).
I've actually previously worked at a platform team for a ton of internal customers, and then at a B2B startup selling platforms - that's where you get promoted for platform development, cause platform is the product and reducing request latency or whatever is something VPs care about... in my current team I have a long list of impactful (on platform level) improvements I could make to infrastructure and libraries, engineering fundamentals, etc... that I'm not doing, cause I'm doing some boring work that will move some number, or sitting in meetings with 3 teams trying to get out a feature, that customers (or management) care about for some strange reason ;) E.g. perf work only matters when we want to save on server budget, and we have to decide to save on it beforehand, and it still doesn't matter as much as shipping some new widget or a metric change. Or e.g. I created a library for X that ended up being used by a bunch of people in a few teams (not the original goal). I am pretty sure nobody above IC level cares. All I get for that are occasional bug reports and a perception that I might be an expert at X... if the library doesn't contribute to my career via the latter, there's no other way it will :)
when big tech company A was preparing for being sold, they brought in "my boss' boss" .. a woman new to the company. She promptly refused to meet with any rank and file engineer, at all, despite an arms long list of them wanting to meet. Secondly, she stopped showing up to her assigned office on the same floor as the engineers, where her predecessor had a glass-wall office overlooking the same working area.. Later, we found out that she was in fact inviting herself to any and all meetings she could get into, regarding the coming sale of the company.. it was a strategic move on her part to absolutely distance herself in every way from those doing work, and meet and become important to, officers in the company who will be part of the company sale.
As a somewhat seasoned developer and former executive I can, sadly, state that raises and rewards are rarely tied to your output or how much it brings to the company. If your manager and executive leadership team are not actively marketing/hyping what your team is doing there is little to no hope of getting what you deserve. I get that this sounds "unfair" but there are some reasonable reasons for this. A company is huge there are many teams working on multiple projects, some of which have more executive hype visibility than others, where executives lust/focus money follows. If your project isn't one of those the best you can hope for is compensation the following year once the benefits are noticed, if they are noticed. Also note in any organization there is a never ending line of people who feel their contributions deserve more remuneration than others, so you have to make yourself standout from this bunch.
That being said the best way to get large raises in your company is to network and market yourself and your accomplishments LOUDLY and OFTEN. If this makes you uncomfortable then the absolute best way to get a raise overall is to leave for a new company; don't worry in two years you will be welcomed back at your current company if you want to return.
I am at the stage in my career now where I just want a solid funnel of work to rip through on technology that I enjoy working on and a competitive salary. I have a full life outside of work that brings me fulfillment and joy so I no longer need accolades and attention from work, honestly the less they notice me the happier I am! My job is for money and to keep my mind sharp, if I am unhappy I leave if I am happy I stay. I spent years climbing the ladder, learning to network and market myself and my team, sadly I learned that it was all a waste of time for me and I have more overall life enjoyment being a well thought of and compensated developer!
Also alignment with upper executives is pretty critical. Pay careful attention to what they say at All-Hands and which teams they're spending their time with, and try to get on those teams. Try to be in the room when major decisions are made; understand the thought process that went into these decisions. If you can simulate your VP's thought process and predict what they're going to value next, you're at a huge advantage over most of your peers in the department, and you can also leverage that to help your management look good.
Try to be ahead of that - figure out what project they will care about next and be the leader of that one. Sometimes you need to risk a couple years on an unknown project before it breaks out to get the attention. Just be careful, it is a risk: if it works you are aren't just on it, you are the leader of it, but if it fails you are the leader of a project they never cared about.
An even better way to figure out what project is going to be important, sabotage it on a way that you can pull an 80 hour week at the last minute to rescue it. (I strongly encourage leaders to NEVER reward someone on a project for pulling long hours at the last minute - an outsider who steps in fine, but someone who was on the project should have prevented it in the first place. I've never seen a leader pay attention to this)
Have a list of the projects you worked on with measurable benefits to the company.
Start by talking to your manager and then work your way up your reporting structure talking to the directors/cto/ceo's. If they don't know you you need to walk in an introduce yourself, don't drop all your accomplishments on them at once but something I have used many times in the past is just "Hi I am X I work/ed/ing in/on Y, loved helping get project Y over the line and am excited to see its impact on Z. What are your hopes/thoughts on where it will lead us"? Offer to take them out to lunch and get to know them better, you don't even have to talk about work with them, developing connections is personal not business!!
Outside of that when talking to stakeholders the key is to be invested in the business outcomes of what you are building and talk to leadership on their terms. They give zero sh*t's about your technology or methodologies, they care about impact on revenue and cost.
Everywhere I've worked, it's an order of magnitude easier to get a L+1 job at another company than it is to get promoted to L+1. Until and unless that's fixed, expect tenure to remain low. The fact that no company fixes this tells me this is employers' desired end state.
I transferred to a different position. Suddenly they discovered all the little things I did had value and wanted me back. (I didn't want to go back, but the reorg told me go back or find a new job...)
Working in big tech has been incredibly disappointing. I'm a mix of a Software Engineer and a Systems Engineer, so finding jobs (and not getting downleveled) is fairly easy. That said, after nearly a decade in tech, and staying at one firm for over three years I have never been promoted without leaving a company. It's not like I don't have major accomplishments either; but politics is a blood sport and either you or your manager must play it.
My two cents, it's not worth trying to get promoted. Enjoy what you do and once your RSUs have matured, start your exit by interviewing elsewhere.
> My two cents, it's not worth trying to get promoted. Enjoy what you do and once your RSUs have matured, start your exit by interviewing elsewhere.
This is the best advice I've seen so far.
I have refrained from playing the political game, have mostly stuck to helping people whenever they needed technical help (as it turns out, technical skills are critical when fixing things : p ) and that has lead to me being naturally included in interesting projects. If I start feeling like I'm not being asked to work on interesting things anymore, its a good sign to start looking elsewhere.
I guess I am somewhat fortunate/privileged that there are so many opportunities in tech that I don't have to play politics. Its pretty great though; its not like I can't recognize when others are playing political games, but I chose not to get involved in that world.
Some big companies are starting to figure out they need a plan to get people promoted before they leave. If so read that closely: it is your roadmap. Often what the map says isn't be a great coder, so put your time into the things on the map.
People have long said being a great programmer isn't important in business, but it really is. I don't want to work somewhere where being a great programmer is less important than being a politician. Being a politician in my view is a lot different than having soft skills. Unfortunately, most companies advertise they want great programmers and reward them, but that's mostly a lie.
Being great at programming is important only if/when they realize it is important. Politics is always important, but if you are not great at something else you may be found out.
> I turned our product from a total waste about to be cancelled into a promising tech with some momentum, but I spent all my time coding instead of writing about coding, and I likely won’t get promoted again this cycle.
As a FAANG SWE, what I am reading is "I spent two years cranking out code without doing any design work. My manager and TL never suggested I write a design doc, or didn't give me opportunities to do so."
At least at my employer - where, yes, you typically need to do design work to get promoted - that shouldn't happen. It's a failure of management if it did.
To get promoted in FAANG (and many large tech companies), yes, you need to document it.
Interestingly, whether it works or not is completely unrelated to whether it's documented or not. In fact, the types of useful documentation (descriptions of how decisions were reached, known tradeoffs, API contracts, etc) often are completely different than the types of documentation management asks for (box diagrams that no one but management looks at). And the timeline for generating it is often different as well (management oftentimes asks for documentation before implementation, where such documentation runs the risk of being an incorrect blueprint; what is useful is documenting along the way).
Valuing documentation can be done well, but pretty much every place I've seen it as an organizational requirement it has been a checkbox (and definitely running afoul of the agile manifesto, which makes it doubly frustrating, when an org also says "we're agile because we do scrum" or whatever).
At least at Google (where I work), a "design doc" is an iterative and interactive design proposal, including alternatives considered and rationale for design choices made, not (just) documentation of what the design is.
"Documentation" of the sort you describe is an almost entirely unrelated thing, again just speaking of Google.
> Interestingly, whether it works or not is completely unrelated to whether it's documented or not.
I disagree. Writing up your design gives others the opportunity to provide feedback and improve the design (and possibly catch major flaws) before you build it.
If you never write up your design there's a higher chance that you have built something that doesn't correctly fulfill the product requirements / won't scale / will fail under some race condition you didn't anticipate / is not compatible with the plans an adjacent team has to touch the same area in the next 6 months / etc.
I think you're assuming that documentation is the only way to collaborate. I'm a big fan of talking to people. The outcome of that talking may turn into documentation, but, per my post, it tends to turn into -useful- documentation if it does, which is very different than the company mandated types of documentation, at least in my experience.
A software specific formulation of Goodhart's Law applies here; if documentation is the metric, the organization will prioritize documentation, regardless of its effect on delivery. If working code is the metric, documentation may still happen if it helps to deliver working code.
There have been zero times that mandated documentation felt helpful to me, and was able to be used without massive modification after the fact by anyone else (I remember one project that had their architectural design document v1...and v2. v1 was the mandated "before you build", and v2 was the "we've now built something that works and it is so different that it's easier to start anew than modify v1"); there have been uncountable times that I have chosen to document something that seemed important to share or persist to inform later decisions.
> I'm a big fan of talking to people. The outcome of that talking may turn into documentation,
For any nontrivial design, it must. I expect that many people in this thread are coming from the Google (or Amazon?) perspective where a "design doc" is a formalization of a collaborative conversation. For small designs, it may be just a mild reformation of a set of meeting notes (you should take notes when you talk to people!). For larger projects, there's an iterative process where you start with a proposal that may be that, and get it reviewed and ensure you cover all the aspects that it will impact.
I've been on both he giving and receiving end of the "oh hey you may need to rethink this due to XYZ" at what was assumed to be late in the design process. THat's annoying, but much less annoying than spending 2 weeks or 2 months building a thing only to have to throw that effort away.
> if documentation is the metric, the organization will prioritize documentation, regardless of its effect on delivery. If working code is the metric, documentation may still happen if it helps to deliver working code.
IMO, good organizations should have both metrics. You should document your intent, and then you should be able to show that it worked out after the fact. "Working code" is a lagging metric with many dimensions (functional, secure, performant, etc.). If your only reason to believe you will get to working code on all those dimensions on a 6 month+ project is that the person who is building it thinks it's right, that's a big risk.
It seems like you're describing a particular kind of dysfunctional org where there's top-down mandates for forms of documentation that aren't valuable for sharing plans or informing later decisions. That hasn't been my experience of how design is done where I've worked, where writing designs is a collaborative process that starts with your team.
My conclusion after working in tech for a few years: If you don't want to play the politics game, just interview with new companies and get a new role and a significant pay bump every 1-2 years.
I meant sad in the sense that if folks were properly incentivized to stay at an organization longer-term (10-20% pay bumps per year), I think we'd see more big innovations in technology – think NASA, Bell Labs, etc. – as opposed to incremental improvements.
That's hard, I've been there too. I went into role where nothing was documented, and I built up a knowledge base to get all of the tribal knowledge out of people's heads. There were all sorts of manual scripts running "hot" on production to fix issues, very few of them documented. It made my ramp up time much harder than it should have been. And my efforts made it way easier (and safer) for the team and everyone who was hired after me. That year I got a lower performance rating.
The silver lining was that I gained skills that helped me land my next gig, along with a nice bump in pay. I responded to a cold call email from a recruiter and from that began a more fulfilling career trajectory where I was appreciated more.
I don't know anything about what you did or what your level is, but a few things to consider:
- While what you did sounds like good work and beneficial to the company / team, was it something that exceeded expectations or just a good job but expected?
- How many other engineers can do what you did? i.e. was what you did special / unique in some way?
- Did what you accomplished demonstrate abilities at the next level? A very good L5 that exceeds expectations may or may not be at the L6 level.
Especially at the more senior levels, a promotion isn't typically just about doing your current job well. The next level some times involves a slightly different skillset.
Again I know know anything about what you did or if you "deserve" a promotion, but some things to consider.
> One of the things I have noticed in both my full time jobs at this point is that my direct managers have had no idea what I do day to day.
FYI: This isn’t normal. It’s not even particularly common in the industry as a whole. It is, however, a hallmark of dysfunctional companies that are headed in the wrong direction.
If you find yourself consistently stuck under clueless managers or working in companies that reward all the wrong things, it might be worth reevaluating your choice of companies and shaking up your career a bit.
It’s not good to be stuck in dysfunctional companies for years. This is how people become disgruntled and cynical.
I am "reevaluating" my choice of companies for other reasons [0], but it is interesting to learn that this abnormal. That is an organizational thing, as my manager is part of the "leadership" team, so he often has wall to wall meetings.
I will be sure to inquire about this in interviews then. Thank you. I very much had the impression that management was often distant.
The unpleasant reality is that getting promotions requires a bit self-promotion. While good managers (which you apparently don't have) will clue you in on what's necessary and help out with it, the bulk of the burden is always on the employee to be able to explain their value to the company and to make sure their achievements are known and recognized.
(Taken to extremes, this can be as sociopathic as it may sound. So don't and avoid those who do.)
Don't get bitter or passive aggressive; that will only hurt your career and mental health long term. Find a new team internally, sell them on what you did and move on. Or move to a new company.
If the product was failing when you arrived, you're already in a poorly managed group anyway. No point in sticking around.
I’m in a similar spot, except I’m also the guy people come to for weird problems they don’t understand. The work I did day one is arguably one level above mine, and my first boss was on track to promote me but the little fucker quit a month before the annual review cycle and the next guy promoted way fewer people than he should have.
Now it’s been going on for so long that I’m not entirely sure how I will react if/when I do get promoted. I think we’ve gotten beyond, “about time” into some swear words. For starters they’d have to backdate the raise. I am about to start actively looking.
You often do need to leave to get a promotion. If you are not willing to leave they assume you are satisfied where you are, which is more money they don't have to pay you.
Sorry to hear this. Feeling validated and appreciated for your work is often overlooked in all career types in multiple jobs. Try to find peace with the small wins you’ve done for yourself. It sounds super impressive and something you definitely should be proud of.
I ran into the same situation at FAANG. I was explicitly told I had failed to lead a project because of my level by my direct manager. I was not named as a tech lead (which was not necessarily level dependent) of my area and had multiple coworkers ask me why.
The final product was shockingly close to my original documentation and implementation. Part of the reason for this was the core implementation was all done by me, but I actually set good enough direction that after I left the company, a year later the final product was closer to what I designed than when I left. This product is still being maintained and the core functionality is the same and has been expanded upon (that is no full rewrite). The implementation isn't ideal imo and could be improved in a variety of ways, but it works well enough for the users 2 years later.
This entire ordeal burnt me out hard enough that I took 5 months off and I'm still recovering, and I've basically given up on leveling up in a traditional tech company in anyway. People might tell me I didn't play the game right, and I didn't, but it did really drill that politics and appearance is more important than impact. Especially anything that can be made to look like indirect influence can be used to take credit. I made the mistake of trusting managers and senior engineers with my ideas and they didn't return the favor.
If you're not cut out for politics, you have two possible moves: Stay or quit. Don't threaten to quit -- but actually quit. Give them the least amount of warning possible to find a replacement before you walk out the door.
Frankly if they're not investing in you doing your job, then you shouldn't feel invested in staying.
That said, people have debts, and can't leave a job for whatever reason, so both moves are completely respectable decisions.
Building or adjusting stuff on your own is unlikely to lead to a promotion. Guiding a group while being the main and most important contributor increases your chances. Working with other teams on a critical cross-team use case, increases chances even further. The main differentiating factor here is scope and impact of work the related amount of dependencies.
For your work to be easily recognized by others, one usually requires their peers' or manager's support. This means, asking for advice from more senior peers within and outside of your team and talking in 1on1s about the solutions you developed, problems you resolved, and discussing the business impact that the changes will bring product-wise. If no one knows about the product/platform being broken or suffering from performance problems in the first place, then it will be hard for them to value that the product is now working as expected.
Eligibility for promotion highly depends on the product that you are building. If you impact a product responsible for a sizeable portion of the revenue, visibility and impact is orders of magnitude easier to get.
Further, the business impact, as defined by KPIs for the product, may need a few months to materialize and show a trend. Unless provided with sufficient observability and historical data, you may not even be able to show that the product is more reliable or stable due to changes in its architecture or performance improvements. Pouring more marketing money may lead to the same effects business wise on the top line (revenue).
Lastly, and most importantly, promotions depend on your manager. If managers are not incentivised for the development and growth of engineers they manage, but more as a function of the scope or size of the team they lead, the latter may be the easier path as team growth may occur naturally with less effort and friction on their end.
>...I spent all my time coding instead of writing about coding, and I likely won’t get promoted again this cycle.
Would your perception about the org, team and self really change if you would get promoted?
If that's the case, then you could try to promote yourself. Especially, now that you've got a concrete result. It's just to show openly to the org and team that the promotion is what you want.
Package it with some outlook about how your contribution in the new role would boost the team and how timely you feel this is in your professional growth.
I’m sorry to hear this. Please take care of your health, mentally and physically. Management usually promotes folks showing “visions” rather than those who keep their head down and make sure the plumbing works smoothly. It’s a sad state.
Have you looked around at other places while still working on this project? It sounds like they don't value you enough. That said, take care of yourself, burn out can be serious.
Save up money and work at a risky pre-Series A startup. They'd kill to have an ex-FAANG employee who can design things from the ground up, lease a project to completion, and enjoy the systems they are building.
Recently left a small startup for Google and was recently talking with someone who thought I was going for promotion. I asked if I should, they then looked at my profile and said "You've only been here X long so they won't give it to you even if you deserve it."
Completely different world. Completely different mentality.
I made a fairly popular reddit post recently on how I down-leveled my career in recent years. Each time I down-level, I get a raise in salary -- it's pretty great.
What that permitted me to learn about myself is that - at the end of the day - I just like solving interesting and challenging problems, working with colleagues as equals, and creating products and solutions that I'm proud of. I have utterly no interest any more in climbing any sorts of ladders, or "chasing" a role, position, or title because I think that'll somehow be the road to riches. Having autonomy, the flexibility to work when I'm productive and inspired (and to not work when not), and interesting/meaningful work is infinitely more important than role or salary. I also feel like I'm not the first person to come to this conclusion.
I mean at the end of the day the title is only to feed your own ego. At family gathering nobody's gonna ask you why you were Principal and now you're Staff. I find no difference between being called a "Director" or a "Manager", because the title alone tells me absolutely nothing
Reminds me of American Psycho, where everybody is a damn Vice President (reflective of the time)
It's more complex than that, though. If you're meeting with people outside your company, your title can influence how they see you. If you're meeting with a bunch of "Director" level people and you're a "Senior", they may treat you as a lesser member of the group. This can be impactful to your ability to accomplish your goals within that group at times.
That may be true, but definitely not in my experience. I have included my job historically on emails eg: Software Engineer but never my level. I don't even put that on internal emails because I see it as my business and no one else's. This includes when I worked side by side with sales folks from time to time at a start up. If you didn't feel like working with me if I was a SWE I but you feel like it with a Principal, why would I want to work with you?
People do care that someone will show up and answer all their questions in a thorough and non-elitist (read: talking over people's heads) way.
I think your experience is fairly characteristic of software developers. However, there's a lot of other segments out there where title comes into play a lot heavier; where it caries weight in the same way experience does.
It's probably also worth noting that title can impact pay when it comes to a job; a lot of companies have pay caps based on title.
Really, my point was that title is more than just self-gratification.
Vice President has legal meaning as a title. Only a vice president or above can make some loans. Since banks make those loans all the time they need a lot of vice presidents to do it. In a small town bank with at most 10 people it makes sense, but for a large banks with branches all over the country you end up with a ton of vice presidents just for that need, but they don't really get any other authority.
Interesting. I always wondered why Senior level engineers at banks got the VP title. It seemed odd for someone formerly an IC to suddenly step into a VP level role, but this makes sense now.
No, but there are people at that level in the company who need to sign those contracts (I don't think it's loans specifically), and it's easiest to use a consistent title for everyone at that level.
> Reminds me of American Psycho, where everybody is a damn Vice President (reflective of the time)
My understanding was that this still happens as a way to get around corporate card policies (either from the company or the credit company) that prevent anyone with a lower-than-leadership title from having signature power for purchasing. Want to give someone a corporate card so they can buy their own necessities? Give them a VP title.
idk to me salary determines the level. you can't really "down level" when you get paid more. titles doesn't matter. I know for a fact a lot of people with "manager" are paid significantly less than me with my bland title, but it lets everyone sleep at night so all is well.
All the things you mentioned important to you are indeed important stuff, and you are not wrong to prioritize them. But that doesn't mean you should completely ignore the title. Think of the title as giving you more freedom to choose. By completely ignoring, you are potentially missing the extra freedom you can have in choosing your problem and team. So, I would agree you don't want to chase a title, but as a secondary nice-to-have goal, it absolutely is worth considering.
Mostly agree, but how about a person (lets say like me) who would like to offer skills in exchange for a great salary and thats it? No need for challenging problems, just the autonomy and time - thats what I would care about the most (and € ofc).
Personal motto: work for living, not live to work. Therefore: screw those titles.
“For example, a senior title at Big Tech typically expects more from an engineer than a small developer agency, a non-tech-first company, or a recently founded start-up does”
This is simply not true. Seniors at FAANG type companies simply dont do that much. Typically have a narrow specialty and a good grasp on how it fits into the larger Org’s strategy etc.
Senior engineers at a small shop do EVERYTHING. Front end, back end, DBA work, training and upleveling juniors, PM work, sales calls and client support occasionally. Also more involved in product and strategy.
> This is simply not true. Seniors at FAANG type companies simply dont do that much.
I don’t know where this myth came from, but it’s not true. Aside from the isolated stories about mismanaged FAANG departments that don’t have many responsibilities, FAANG jobs tend to have high standards and high expectations.
FAANG companies don’t pay the highest salaries without expecting high output. The engineers may not be spread thin across many domains like in a startup, but they are expected to have both broad and deep knowledge within their speciality, and to deliver work that meets the highest standards.
Having worked at both I can say this with a high degree of certainty from my experience.
Even if you have a dedicated Sr at a BigTechCo it is just a much bigger boat to move. Also I have seen people promo at FAANG for projects that would be considered trivial/part of the job at a smaller shop. Command line utilities, improved CI pipeline etc.
The gap emerges because doing everything under is vastly different than doing strategic work across multiple organizations. It's the difference between captaining a small boat versus a super carrier.
I've met Principal Engineers at Amazon who never write a line of code and barely do any mentoring (I don't like those PEs).
But I've also worked with Senior and Principal Engineers who do incredible work, mentor, truly lead. They are force multipliers, making adjustments to the course of the organization in ways that have huge benefits and gains. And if you dropped these people into a new challenge with a totally different stack and business, they'd do the same thing there too.
Have you worked at a FAANG? I'm sure it depends on company/team, but it was pretty common for externally hired senior engineers to struggle (and sometimes flame out) due to consistently high and enforced expectations, different mode of work (extremely cross-org and cross-functional) and very high ambiguity (which can also come with low handholding in fast growing areas).
I worked at Google and Microsoft and left both of them and started my own company precisely because of how hard it is to get anything done at bigger companies, and comparatively speaking Google is one of the less "bureaucratic" companies to work for with much less friction compared to the other FAANG companies.
Working at a start up company allows you to be far more productive than at a bigger company. You are not shoehorned into any particular position and you need to be able to excel at multiple areas and be able to switch gears rapidly. One month I'm using React/TypeScript to implement new front-end web pages, and then the next month I'm working on improving the green-thread scheduler we use for our backend systems in C++, and then after that I jump into Kotlin to work on the mobile version of our app. All of the developers here are able to work across the different projects and pick what areas they want to, some choose to focus just on a particular area and that's fine, but others can jump across a variety of different technologies, and as I own the company I like to get involved in a little bit of everything.
At Google, I'd be lucky to be working on one narrow facet of one of those areas over the course of a year.
Startups are absolutely not for everyone and they can lead to burn out, as is evident from many posts to HN, but for people who really want to immerse themselves in tech and want to work on a variety of different technologies I just can't see working at a bigger company comparing to it. That said it's definitely true that if I didn't have Google/MS on my resume, no one would have taken my startup seriously, so it's worth getting some experience at FAANG for the credential, and then jumping ship after a couple of years if the opportunity arises. Also there were nice things about Google as an environment, like tech talks, and I absolutely miss Testing on the Toilet. You can recreate some of that at a smaller company but the scale at which Google is able to do it is very impressive and hard to replicate. That said you can always go back to FAANG and recruiters from both companies are just an email away.
I have worked at a FAANG company and my experience was very much like the poster's. Everyone around me seemed to really heavily weight the expectations placed on folks at each level going up, but nothing was like the actual responsibility levels people had in the orgs I'd worked in before.
This has been the opposite for me. Yes I wore a ton of hats at the startups I worked at but working at big tech I’ve been exposed to scale and quality standards beyond what I was used to before. Plus my coworkers are all higher quality so it’s like being in college again and hanging out with all these smart people I’m learning from just by interacting with them.
And this is coming from someone very cynical of big tech otherwise
Sometimes it is. In my experience I was expected to do less at a start-up but to do it well. Yes, I worked across the stack and often would find myself doing varied things but instead of stacking more on in a day, it was more like quickly shifting priorities each day.
Now at a larger company I’m expected to spin many plates so to speak. I’m measured on my ability to write code, pitch projects, design architecture, manage cross functional relationships, interview many candidates a week, have company outreach of some form, mentor junior members, deal with organizational politics (this is the big draining one), participate in project reviews, run projects for new employees to work on, provide feedback to all my peers, tons of personal development planning and self-reviews, manage third-party relationships, respond to incidents and be on-call for things not related to my team, learn new things every year aka personal development, and more.
And if I fail in one of the four areas in a performance review I can be put on a performance review plan. I’m making it sound more grim than it is, but for my experience there are just more things to do and there are no compromising them.
Maybe other individuals are better at this or work with a manager that has less expectations, but this is my experience. I think I was a better programmer at the startup, but I have more organizational impact at the bigger company.
> Seniors at FAANG type companies simply dont do that much.
I initially mis-interpreted this sentence to be talking about quantity rather than roles, it seems like others here got the same impression. It’s important to recognize the part you quoted was talking about quantity and not role, and what you’re talking about is role and not quantity. It’s also important to recognize that engineers with a lot of experience are biased toward working at stable companies and not startups. From experience, I would agree with the article that the common expectation in startups very much is that you have to make do with junior developers when hiring, and if you get high quality senior engineers with a lot of experience, you’re pretty lucky.
While there’s some truth to startup roles sometimes being more broad (less focused) and big-company roles being more deep (more focused), might it be best to stick to personal experience rather than claim what a broad group of other people’s experiences is without really knowing?
As a founder with a partner in an initially 2-person company, I did only front-end while my partner did only back-end. Our dev roles were more focused than by previous big-company jobs, but we both had to do non-dev work too, of course.
As a sr/principal in a FAANG-type company, I’m doing more mentoring of juniors, more sales and support calls, and also more math & research, than I was doing with my startup. I’m also involved in product coding, algorithms, and design prototyping.
So, speaking personally, I can’t exactly confirm your view that startups are broad and big-company roles are narrow. For me, the difference is that with a startup there were some tasks that I just don’t have at a big company, like doing taxes. The other main difference is that my own company was mine, and big-company work is structured around the organization. It’s not so much a difference in the amount or the type of work, but a difference in the ownership and motivations and what success and failure looks like at any given time.
Your mileage may definitely vary, especially based on what kind of team you're in.
Senior SWE at a small company was significantly less responsibility than Senior SWE at Google. As a Senior at Google, I was doing almost everything you say a "small company" Senior does, aside from DBA work and sales calls.
I suppose if you're just a cog in the machine of some huge org like Ads or Search you might be right, but a smaller product team might look a lot more like a small company than you might realize. There is a lot of extra overhead of various sorts, but I wouldn't say the responsibilities are significantly less.
> This is simply not true. Seniors at FAANG type companies simply dont do that much. Typically have a narrow specialty and a good grasp on how it fits into the larger Org’s strategy etc.
I don't think this is true. Big techs have surprisingly many moving parts even for minor engineering projects and that complexity is the main motivation of hiring smart people from the globe. Most SWEs in big techs are generalists, not specialists.
Do you want to launch something in Google? Then good luck dealing with all the facets from general engineering to other topics like security, privacy, latency, quality, measurement, logging, scalability, redundancy, monitoring, resource management, access control, data retention, documentation, testing, release, i18n and even inclusion nowadays. Upon all the technical debts accumulated over 20 years. Oh, did I mention organizational dynamics? Usually you need to deal with 5~10 teams for getting anything non-trivial done. And it is a very fun thing to find out the current owner of very specific dependency to avoid accidental breakages.
I would politely say that that just means it is harder to get things done so you accomplish less and by definition “get less things done” at a BigTechCo
Navigating a bureaucracy is a skill. And doing so can help get things done but in and of itself it is not actually getting anything done. Getting things done at a BigTechCo definitely takes more effort.
This isn’t the case but your statement is true all the same. Smaller shops engineers DO do everything which is valuable at a small shop but is not valued at all at a large shop because it doesn’t scale. Once you’re working at scale different values surface like being able to communicate and drive consensus, focus on one (high impact) thing, and do higher leverage work. When I went from small-co to big-co I also didn’t understand what others valued and I languished a little trying to do all the things. Now I’m in the groove and look back at how much easier it was to just do all the things.
That still seems to be expecting more in terms of skill.
I have only ever worked on small teams with smallish companies in my short career, so I have had to handle everything from test to database to frontend to cloud config.
I really don't think these kinds of roles let me master anything because I am so often switching modes.
If you get to focus, you probably become more skilled very quickly.
The title rollercoaster was a great opportunity to disassociate my worth from my title. My last three jobs went something like this: started as Senior Engineer -> left as a Director; started as Manager -> left as Senior Manager; started as Manager -> left as Manager.
As just about everyone I started off caring about titles. As I moved up company tiers, my compensation was significantly higher each time, despite lower title. Downlevel in title also doesn't always mean downlevel in responsibilities - the scope of my Director role at a lifestyle business was the same as the Manager scope at a fast-growing startup. The next "step down" was a true downlevel, but such is the price you pay with FAANG. It's an opportunity to perform with lower expectations at a higher compensation.
In other words, it's a multidimensional rollercoaster and it's not recommended to be always focused on a single dimension (title).
This. Before accepting any offer, put all promises into writing. Attach milestones, even if you just make them up, i.e. salary will increase when company receives next funding round.
Send this to the employer. If they balk you know know they were just telling you what you wanted to hear. Be wary.
I'm not trying to be insulting, but none of what you wrote is realistic.
There's no such thing as putting a promise of a quick-promotion into writing. No company would agree to that, nor should they (what if you suck once you start?). And I'm highly skeptical a company will agree to a milestones-rewards plan for an individual employee.
If someone wrote such a proposal and sent it to me, I'd immediately reject them in the hiring pipeline. And I consider myself to be a very employee-friendly hiring manager.
* hiring manager tells the candidate they’ll get a “quick promotion”, but only if they “don’t suck”.
* candidate responds with proposed clarifications of “speedy” and “suck”.
* hiring manager drops candidate from consideration.
Did I get this right?
> And I'm highly skeptical a company will agree to a milestones-rewards plan for an individual employee.
And yet hiring managers play fast and loose with employee expectations all the time, even if their company would never honor such promises as a matter of policy.
How would you propose a candidate determine whether the hiring manager is making promises in good faith?
The only answer is there's no guarantees, and Caveat Emptor.
One of the worst offenses is the one we're discussing in this thread: a HM or recruiter says "We're slotting you at level 4 instead of level 5, because we like to give employees room to grow." That's a BS line -- put me in at 5 and grow me to 6, then! If you hear this line, you just need to understand it's poppycock and make a decision from there.
But basically everything a hiring manager says about a position can turn out to be just wishful thinking on their part:
* The team is most likely not solving a big problem
* The company most likely does not work well together
* The position problem does not have huge room to grow
I've noticed that unless you live in a city where one can switch jobs in under a week, not have to re-locate, or take a big hit on the commute, companies know (knew? At least pre-COVID and rise of work from home) that they have the upper hand.
Even in countries with extremely strong labor laws, companies are not shy to pull every trick in the book to drag out promotions. I've seen examples where it took close to 12 months for someone to get their promotions finalized, and thus a new tittle/higher pay. It took that long time because the employer knew they were the highest paying in the area (albeit underpaying the employees in question, due to not having received promotions in years), and very much locked to their jobs.
When people get established with a mortgage, family, and what not, it's much harder to just drop everything and move away for some extra bucks. So my advice to young devs / engineers would be to do as much career climbing as you can, before you settle down. Once a company knows there's little chance of you leaving, they'll slow down things all over.
As you get older there is diminishing returns on getting better. There is a big difference between someone fresh out of school and been there for 1 year. Between 1 and 2 years it isn't as big, but still important. Between 10 and 20 years there is very little (at 20 years you should have forgotten something that is no longer useful). By 40 years your mind is probably in decline...
This. Anytime management asks you to do some work, ask them -
"How will this play into my promotion?"
If they can't come up with tangible points, don't do the work. You are not risking anything because at this point, the manager has already decided they want to string you along.
If I had a direct report who asked me this for all the work I ask them to do, I'll have to tell them:
"All the work you do, every bit of it, plays into your promotion. I ask you to do something because it's important to the company and to us all as a team, not because it's going to specifically help you get promoted. If you deliver strong results, I will be the first to champion your promotion. But if all you care about is promotion, maybe you should start looking elsewhere."
I mean, it's perfectly fine (and expected) that I should be discussing with my direct reports how their work helps them on path to promotion. But it's not acceptable for that discussion to be a blocking question for every work item.
> This probably isn't a good idea because you are going to annoy your manager. Annoying your manager is not a good strategy to getting promoted.
In a different world, I would agree with you 100%. But our industry is filled with managers who only look out for themselves.
For a manager who says "If you don't do this, then you won't get promoted", this is a bad faith power move. I have learned that when a manager says this and the IC acquiesces, the manager ends up with a proverbial upper hand. Often, this asymmetry is abused.
At that point, I highly recommend the IC to cut their losses and switch. Let the manager spend another 6-12 months staffing and ramping up someone else to do the work.
The thing that many folks don't understand is that it's not that "Titles don't matter", it's that "Titles don't matter when compared across companies". There's not a universal definition of say, "senior software engineer", so comparing titles across companies will always be an apples/oranges exercise.
Titles do matter, but only when in the proper context.
One area that was not discussed at length was the transition from a high tier to a medium tier. In that case the HR at the medium tier often put a lot of weight into the title. I have seen HR teams say thing like "That person was not a principal engineer in their previous job" so they need to come in at a lower level here. They (HR) often don't recognized tiers within the industry, and use titles as a proxy for skill. Many HR staff view a change in title as a direct indication of skill, and when they see someone go from 'Sr. Software Engineer' to 'Software Engineer' they assume a skill demotion. In one of my earlier companies we used the title 'member of technical staff' in a pretty broad context, and I later heard that it was problematic for some people in getting interviews in future jobs. It is stupid, of course, but also a reality.
At one of my previous employers I noticed that a few of my coworkers had created/inflated their job titles on their business cards, so I asked my manager (without naming names) if that was allowed, to which they said it was fine as long as you don't claim to be CEO.
I worked at a company that called everyone Member of the Technical Staff (were you at Cycorp too?), and I just put a more descriptive title on my LinkedIn, resume, etc. I never had a use for business cards so the issue never came up
Ah, no. This was a company called eFusion, which was an early VOIP telecom spinoff from Intel (which is where I started at). The Member of Technical Staff was a very east coast Bell labs like title, which didn't really translate well to other schemes.
When a big tech (or FAANG) company acquires a smaller company, it very often happens that the smaller company's employees' titles all get adjusted. SmallScrappyCo's CEO becomes the team's Senior Manager. SmallScrappyCo's VP of engineering becomes Regular Engineering Manager. I've worked directly with former Directors who suddenly became "third engineer from the left" after their company was acquired.
There ARE formal definitions of positions, title/rank, and requirements for experience and education, (as well as pay range) defined by the US Federal Government's Office of Personnel Management. These are used for determining staffing requirements in government contracting and hiring.
Most mature government contracting companies follow these standards.
In private industry, though - it's like Lord of the Flies. As far as I've seen.
Titles only matter to me when I need what they communicate.
Once, when working in a distributed team where I was going to be the lead, it was critical to me that I was "promoted" to a more senior title than the people I was working with. I didn't care what the title was, nor did I care for the money. (I didn't get a raise.)
All that mattered was that the title established who was in charge. It didn't matter what the title was.
> People who stay at the same company for a long time can get left behind compared to their peers, especially if the company does not move internal compensation bands to keep up with new offers
Right now, my office is being absolutely raided by recruiters from other companies because of this. With the switch to more remote jobs, the pay differences between geographies have gotten more level. What used to be great pay for Toronto is now good, but not great.
A lot of people who wanted promotions but weren't getting them are getting them- somewhere else, for more money.
I was downranked once when switching jobs. I had significantly more experience than the people who I was working with, including the leadership, and it showed. There were some red flags during the interviews, but because of life circumstances, I felt like I couldn't say no.
The situation didn't end well. It didn't have to, but I place that firmly on the managements' inexperience.
(Side lesson: I suspect that situations like what I encountered are why a lot of people "age out" of tech. Although many people state that "ageism is real," I think a lot of younger managers just have trouble letting go when they work with people more experienced than they are.)
If you’ve been in the tech industry long enough, you probably know that titles don’t mean much when comparing across different companies.
But titles are a constant discussion topic when I’ve mentored younger people. It’s a common tactic for smaller companies to try to lure juniors in by offering them more prestigious job titles. If you’re fresh out of college and half of your career advice comes from your parents’ outdated knowledge of how businesses work, it can be tempting to pick the job that offers the highest job title, ignoring other factors. Companies know this and use it to their advantage.
On the hiring side, titles on a resume don’t mean much unless it’s coming from a company with a well-known advancement structure. If you’re coming from a 50-person startup I’ve never heard of before, I don’t care if you’re a “software engineer” or “principal software architect”. I’m going to be asking you what you did, what you shipped, what your role was in decision making, and other questions to figure out how you fit into our advancement hierarchy.
When so many companies focus on hiring senior engineers, we shouldn't be surprised that junior engineers are optimizing for the title. I did the same, negotiating a senior title with like three years of experience. It's silly, thinking back, but this was before the hiring boom (closer to the dotcom crash in fact), and felt very rational at the time.
I'm 100% onboard with not worrying about titles (and posted about my experience elsewhere in this thread), but certain market realities make for a different calculus for juniors vs seniors IMO.
I went from Director / Principal Eng at a 100-person company to Senior SWE at Google, with a significant pay bump. Now I'm a Staff SWE. I agree this seems pretty common.
When I see "senior" in front of any job title, I generally ignore it as essentially meaningless (and I've been a "senior" for about 20 years now). Unless a job title and description comes with actual managerial responsibilities (so director, VP, etc.), it doesn't seem to correlate in any way with pay, respect, job security or any real say in priorities.
At big or established tech companies, yes. At "startups" / passion projects with between 1 and a small handful of people it's almost always a made up inflated title. The amount of resumes I've seen with "CTO / VP of Eng" at some hoaky parking app made in a weekend in enough to raise red flags anytime I see the title.
I was one of those people, about 8 years ago - my title was VP, but nobody reported to me (there were only five of us) and I spent all my time programming. I'm uncomfortable even listing it on my resume, but I was there for three years, and if I change my title on the resume to better reflect what I was actually doing then, I'd actually be lying.
They're not. VP Eng is a management role whereas CTO has an expectation of technical leadership or strategy. VP Eng has a focus on operations, the processes and mechanics of the engineering organization, whereas the CTO has a focus on the future technical path of the org.
Don't really agree. In a startup, CTO is often the most technical co-founder and may be a manager, may manage VP Eng, but the role is not well defined; it's whatever the technical co-founder feels most adept at.
Later on, the situation may be inverted, i.e. CTO might report to VP Eng. Usually, VP Eng reports to CEO. The point is that operational management of engineering usually flows from VP Eng, and not very often from the CTO. If the CTO does manage, it's a small shrub on the larger org tree.
I hate titles and I have worked in larger corporations and smaller ones and I very much prefer small businesses every time.
I would recommend Joshua Flukes videos on Odysee / Youtube. I think they're usually very spot on in pointing out some corporate BS and a lot of people can draw valuable lessons from that instead of having to burn themselves like a lot of us has done.
I have downleveled once in both salary and title because I got promised work that was good for society. Turns out it wasn't and it was all empty promises.
My only advice is to always go for stuff they cannot change like salary, other benefits like remote work (but that should be in the contract) and so on. Because with time, stuff will undoubtably change. People will quit, focus will be shifted etc but no one can take away your salary.
I passed up a down-leveling opportunity with a "sure thing" FAANG several years before it went public, because I was insulted at the reduction in my team size/scope (and I knew a bunch of people getting hired in as Directors). That ego cost me... $20 million, maybe more?
There's a lesson there somewhere.
(of course, be in Silicon Valley long enough and everyone accumulates tons of stories like this, so in a way it's not a big deal)
I was CTO of a small company and managed 20+ devs. Got down leveled to Engineering Manager even though the job I applied for was Senior Engineering Manager. They switched the title at the offer stage. I reluctantly accepted but now regret it. One, I think of them as crooks for this and I have disengaged from the work. Second, titles especially in management have a HUGE effect on future jobs. Before this job, I would at least be considered for Director of Engineering positions. Now, zero response.
Also, as others have mentioned, the current work is easy as I have done much more complex tasks. But at the end of the day, I won't be reaping most of the benefits.
I can attest to this; though I've worked almost exclusively at small companies with only a fleeting amount of time spent at a handful of megacorps.
I've gone from intern, to junior, to mid-level, to lead, to senior, to "engineer" to senior, where I stayed for some time, to self-assigned title "grand poobah of slinging bits at switches."
As can be guessed, I've come to the conclusion that at small companies titles simply don't matter much.
As an aside, at one of the megacorps it looked as though my title ceiling would likely be "Architect" as very few programmers appeared to make the lateral switch into management, even with skills upgrading training on their own time.
I'm a shitty business person, but a pretty good developer. I'd not do well in a position that had a business emphasis, like a management position. (And, unlike other incompetents, am not narcissistic enough to groom my image at others' expense, so my optics would be terrible.) So I'm not inclined to climb the corporate ladder and my ego suffers less of a blow from taking a downlevel in title. Just pay me and pay me well.
That said, seniority has an advantage: interviewers are less likely to ask you leetcode questions as a gating function to a new job.
I have a friend who has worked at a few companies at what I thought were pretty average jobs. I asked him how he liked the jobs ... his response "the money is green". His priorities were bank 1st everything else second. He had no qualms about it ... I admire him for that.
I intentionally took a down-level, going from director of a 40+ team to an 8 person team. It was an opportunity to work on a product that I was excited about, and I didn't believe my ego was wrapped up in team size. It seemed like less responsibility for more money was a great deal.
I still maintain that's true. However, in hindsight what I learned was that no matter the org, it's frustrating as a manager to not have the level of influence you're accustomed to...especially when you see organizational problems. I had more experience than my boss did in their role, and they were drowning. I realized within two weeks that I had made a mistake and could only watch. Six months later that entire org got dissolved and reorganized. That leader was laid off.
The only way I'd recommend a down-level to anyone is if you really believe you can accept people operating above your level being bad at their roles.
In the UK, I have only been "down levelled" once, and that was when my company got bought out by a FAANG. I went from head of infra(with a growing team), to almost a ticket monkey, but not quite. Apparently I'm bottom rung senior, but given that I'm not managing people, infra or projects, its really not.
This is of course natural, as FAANGs are stuffed with over achievers and people willing to sacrifice _everything_ for for fake company points. I am happy enough collecting my kings ransom for handling 1/20th of the responsibility I had in the previous company.
I am lucky that when I have been looking for a new job I haven't had pressure to take anything that was on hand. This meant that I could avoid the bullshit jobs and push for something I wanted to do. At each stage I've had more responsibility, or more control over my area.
At some point I realized I'm quite bad at engineering skills as well as politics skills required to be promoted at big companies, resulting in significant slower promotions than most people in the company.
After some years, I realized I'm better at the game of pretending to care, and put less effort and hours while still being paid 100% of compensation. Even more so thanks to remote work with covid. Now I find gratification in projects outside of work with this time.
Note that both strategies (getting promoted vs just working less time) increase your pay/hour, so just do whatever you're best at.
hired as a senior manager, reshuffling happens and job title becomes "senior analyst".
now I feel dir+ folks do not have the same respect as before and overall treat me like crap.
I have 10+ years of experience in my line of work. I'm afraid I'll need to update my linkedin job title at some point and I won't be able to interview for a manager role anymore.
Another kind of down-leveling is switching from IC to Manager and back. This doesn’t necessarily mean a pay decrease but I’ve gone back and forth multiple times in my career and so have several of my peers. E.g One of the senior engineers at my company was a VP Engineering at a previous job
The key is to get away from engineering titles, LinkedIn, resumes and all this other “levels” stuff. Use an anonymous coding interview platform to hire, and problems of age bias go away. And other kinds of bias...
I recently jumped careers and got a down level. The only reason I accepted it was because of a massive compensation upgrade (almost twice).
The thing is, there is a reputation that titles are always inflated in smaller companies. And regardless of whether that is true or not, you'll always be held at that standard. So when you move to a bigger company, in the short term you get the down level, but you can easily kill it with your skills and demand a raise, or you can jump to another big company where you can get back your leveling.
Is Netflix the only big tech that doesn’t have promotion circuses to a higher title? I know they only have Senior SWE and Director of SWE. I honestly don’t think they have Staff or PE. Though, I bet there should be hugely disproportionate pay rate between 2 SWE sitting next to each other with the same title.
Spent two years completely remaking the product I was tasked to work on, while the two other engineers on my team, both a level above me, cheered me on and didn’t do much.
I turned our product from a total waste about to be cancelled into a promising tech with some momentum, but I spent all my time coding instead of writing about coding, and I likely won’t get promoted again this cycle.
It’s been very strange to see the fruits of my labor benefit the org while feeling totally unrecognized outside of my team.
Now dealing with massive burn out for the first time in my career. Not sure what to do. I make sure to put out fires and do the bare minimum to keep up the product momentum, but I have no love for the org and just don’t think I’m cut out for the politics games.