The Seniority Roller Coaster and Down-Leveling in Tech
blog.pragmaticengineer.com
blog.pragmaticengineer.com
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.
I've been in a similar situation in the past and finding a different job solved the problem
This is the norm in my company, and I suspect many others.
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.
So just quit after the vacation.
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.
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.
This is obviously not the case for an early startup.
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.
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.
Is that really what it's signaling? "Need" and "salary" seem only loosely related.
source: late 90s bay area california
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.
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.)
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 :)
Did you skill up? Switch jobs asap. Get yourself a 20% raise.
There are entire weeks where I could have achieved absolutely nothing and I am not sure if it would have been noticed.
And that is probably not conducive to promotion as nobody who has power has any idea what I do.
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 will be sure to inquire about this in interviews then. Thank you. I very much had the impression that management was often distant.
(Taken to extremes, this can be as sociopathic as it may sound. So don't and avoid those who do.)
Sad that the incentives are set up this way.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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!
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.
As far as they are concerned, we are replaceable commodity cogs. So we should act like commodity sellers.
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)
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.
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.
(I'm Staff myself, but would not have got here without management responsibilities.)
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.
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.”
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
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.
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.
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.
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!
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.
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.
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.
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.
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.
FB may be different.
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.
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.
If the product was failing when you arrived, you're already in a poorly managed group anyway. No point in sticking around.
- 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.
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.
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.
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.
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.
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.
It's a little cheeky and at times a little hyperbolic, but I stand by it.
Reminds me of American Psycho, where everybody is a damn Vice President (reflective of the time)
Reflective of the industry, really. It’s still that way in banking.
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.
This isn't true for tech companies (except maybe the antiquated ones). At my current firm, everyone got a corp card on request.
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.
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.
Quote from TFA "For those in an underrepresented group, titles make a world of difference in establishing credibility."
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.
And this is coming from someone very cynical of big tech otherwise
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.
I hope to someday be one of those people.
https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN20039-ADP_6-...
Jocko also has a very popular podcast where he further dispenses leadership principles.
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 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.
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.
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.
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.
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.
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.
I could see why some at smaller companies would believe that, or rather prefer to believe that.
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.
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.
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).
Send this to the employer. If they balk you know know they were just telling you what you wanted to hear. Be wary.
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.
So, in this scenario:
* 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?
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
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.
Manager: I got this PagerDuty alert about the RefactoredRubeGoldberg System, can you look into it?
Report: Sure, how will this help me get promoted?
Manager: If you don't do this, then you won't get promoted.
You should periodically bring this up to your manager in the 1:1 meetings when you go over your projects that you are working on.
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.
"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.
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.
Titles do matter, but only when in the proper context.
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.
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.
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.
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.)
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.
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.
In tech, a VP is a big deal. In finance, everyone is a VP.
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 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.
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)
What's more common I think is people working for failed startups, or worse, getting screwed out of their equity.
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.
Overall, not a pleasant situation to be in.
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.
That said, seniority has an advantage: interviewers are less likely to ask you leetcode questions as a gating function to a new job.
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.
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.
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.
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.