I really wouldn’t mind keeping my current salary, adjust it for inflation and I’m good. I don’t care about my title, I don’t want to manage people, I don’t want to work harder than I need to.
I just want to pay off my mortgage, have some leftover money for vacations, have time for my family.
I really don’t care “what my impact could look like at the next level”.
So the only way this process is relevant to you is that your manager might want to look good to their manager by demonstrating that they're "developing" your "talent". It's a nice favour to your boss to let them pretend their job isn't totally meaningless in this respect, but I'm in the same boat as you, I couldn't care less about progression.
I feel like making everyone at the lower levels shoulder all of the accountability is the exact opposite of what we need to do when it comes to improving operations across the board.
Sorry you've worked for such terrible companies.
If you’re in a small enough company for your impact to matter, chances are your stock options are still chips, which you might never get to cash in.
If the company is post IPO then chances are your impact will never move the needle materially for yourself.
Income is really the only thing that matters. When you do the same job and aren’t getting inflationary bumps then there’s a serious issue.
I love this and am going to reuse it!
It takes effort to become better than you are at your current level. To get past junior, that should happen by osmosis. For some people, talent alone will take them to senior. For others, they will need to put in the time to learn how do work more efficiently.
Consider that it will take a senior developer 20 hours to do a job a junior might take 80 and the quality will be better for the senior. In turn, the senior may only code 20 hours a week and spend the other 20 in something that might take a staff engineer 5 hours.
The problem is that skill acquisition takes time.
It means you’re failing at some combination of knowing how to delegate, how to communicate trade offs between time, cost and requirements and how to prioritize
The OP said they don’t care about promotion to the next level they just want to keep getting paid to do the same job.
You seem to want to be recognized for your contribution with increased responsibility.
Those aren’t the same thing, even if the way both of you are reacting is with a similar kind of cynical dismissal of the idea that a ‘career framework’ can help you with your needs.
Which is weird because it honestly sounds like both of you are looking for a clear career framework. Either one in OP’s case where it’s clear what ‘coasting’ looks like - meeting expectations for a level year after year and not striving for promotion; or one in your case where it’s very clear to you what you need to do to reach the next level.
You can object to the implementation of the promotion policy under a framework, but your problem is not with the concept of a career framework - if there were no guidance for job levels you would be in an even worse position when it comes to complaining about your promotion prospects.
Career goals? Keep things as they are.
Work is only something I have to do to have a decent life the rest of the time.
Unfortunately it feels very difficult to say that in earshot of one’s employer without being branded some sort of burnout slacker, even though I do work hard and to a high standard.
If I found a job at a higher level that I thought I'd really enjoy and that I'd be good at, I'll be interested, but otherwise I'm content.
I am not sure how the hell we will be able to manage that (retirement) with the lifestyle we got today. Not that I am rich, far from it, but I am not sure I want to ask my kids for help... and that seems more and more the direction we're moving in.
Yes I am a “staff” engineer at a smaller company now - equivalent in pay to around what I was making as an l5 (mid level) at BigTech. But with a lot less stress. I have no need to make more money except for inflation adjustments
One: you may actually be doing really well and deserve a promotion (or it would be relatively easy to get) but your imposter syndrome is blocking you from realizing this.
Two: you may not even be doing that well at your current level- promotion is out of reach, but we actually need to make sure you don't get out on a PIP or something. Not everyone is good at recognizing this in themselves. (Similar problem of metacognition, I suspect to point one).
Three: there is usually not enough L+1 work to go around on any given team, especially one in big companies that have been slowing down hiring juniors (if all the level 1 get promoted to 2 and not replaced, eventually the system will be too heavy). So this is mostly good, but if you don't communicate active interest in promotion to your manager, you're likely to get the least interesting (for some value of interesting, let's say at a minimum least promotable) work.
You may be fine with this, and as a manager I'm okay with it- someone has to do it and if I have some reports who aren't striving but are still solid, I can give them stuff to do and worry about the promotability of the reports who are likely to leave if they feel their trajectory is slowing down.
EDIT: the fourth caveat is, I'm just a line manager at some place. I don't speak for leadership (they may want to lay off all the non strivers, who knows) or even other managers.
I am trying to be this way, as I do personally love the work, but I would like one and maybe two promotions for the improved earnings and additional autonomy it would provide.
It depends on the company. A few companies have a terminal level that is approximately equivalent to Dropbox's IC3/IC4. This level does not involve managing people, but it does require owning projects that can span across several teams.
I'm in a similar boat but I haven't seen any place keep up with inflation without some kind of promotion or bonuses.
On the other hand they have recently done a layoff round every 1-2 years and if you are not a growing employee with a higher salary you could be at risk.
If an employer offers this they are up there in employee retention for sure.
As far as your personal motivation goes. There is nothing wrong with wanting to be an engineer. That doesn't mean you have to be stagnant though. A career path could be there to make sure you don't get bored, and then revisited to keep up. That is if it's done right. I'm not sure this dropbox engineering career framework is really very good. I glossed over the SWE part and it's so ridicilously vague that it will likely depend completely on the manager applying it. So in some cases it'll probably be a good communications tool and in others it'll be used as for employee metrics. A good manager would allow you to do what you want to do, while keeping you on course with what the company wants. If that means leaving you to do whatever you do for a while, then that is fine. Bad managers will not do this, but at least managers tend to change often enough that you can mostly just tell them what they want to hear and then wait for them to be replaced.
I personally wouldn't pick a company like Dropbox to "just do" engineering though. Too many hot-shots, too much bullshit, it's much easier to get some real work done in boring industries like banking or energy.
But beyond that there's way more to building than writing code or laying bricks. These aren't the career defining challenges you think they are. Solving problems is, and most problems in any non-trivial activity are not solved with code or more precise brick placement.
So while you should be able to code and lay bricks enough to be comfortable in any conversation in the team, you'll get away with not being the best at that if you have skills useful for the bigger picture.
When someone conceived the whole thing and considered all the implications properly from the start, when they "politicked" their way into smoothing the path for the builder to walk and build on, when they "ass-kissed" to get the resources they need, then they're certainly a few steps ahead of any junior or middle even before writing a line of code.
writing code != building things.
In my org, seniors spend a lot less time building things: writing components, etc. They do spend a lot of time navigating office politics. But they are engineering specific office politics: how does system A interact with system B? What are the architectural implications? Ownership of long term data and technical and business strategies?
The "art" of negotiation can be ass-kissing but quite often genuinely with the goal to advance the projects they own and the enablement of the "people who actually build things", which at some point also involves the seniors. You need to build raport and relationships to negotiate seriously.
Promotion is an inherently political process. "Impact" is really short for "impact on the business leaders' opinion of me".
I think it's a bad thing when a promotion process that is political, pretends to not be political by dressing itself up with flowery language. What it leads to is engineers burning themselves out trying to deliver real value, then getting passed up because they didn't make the right appeals to the shadow council.
If we all know the process is political then we should at least work toward transparency, so that people know that it's not enough to work hard and deliver results, you also have to advertise and network yourself.
At the same time, having seniors involved in more abstract discussions before implementation should also lead to better end results. That being said, having my engineers be involved in "ass-kissing" as you put it is honestly not a good use of their time. Leave office politics to engineering managers and project managers, in my opinion.
In order to bring thousands of engineers to bear on a business’s problems you need people figuring out what everyone should be building.
Basically if your leveling system says "A company of all Staff+ would write no code and go out of business" then your leveling system is bs.
Don't know about Dropbox in particular, but I know other tech companies who take evaluation very seriously. The manager doesn't have the final word and there's a calibration committee that ranks employee based on various data.
It's not easy to measure performance, but not impossible if you put the resource to do so.
I think what is difficult is to align employees incentives with the company's goals. For instance, focus on impact and metrics can back fire.
For instance, in my team, I have an ambitious and hard working colleague who is playing the company's game (basically, checking all the boxes needed go get promoted, playing the evaluation's game). I'm convinced it's not in the company's interest. It builds technical debt, we now have several half-baked time consuming projects that the team can't reasonable handle, dubious metrics, experiments, and systems to produce them that require maintenance etc etc... I'm not blaming him though, that's what the company is optimizing for.
If your boss cares about the customer, then you caring about the customer helps, but often it doesn’t matter much as everyone makes it out to be. On top of that there are way more direct avenues that have a bigger impact on your job development than whatever a user thinks.
I also recommend Gervais principle as mandatory read for young managers who don’t yet see the game for what it is.
I can't see Dropbox having a product/sales that is ~30 times as complex. However, I can easily see an organization that has become overly political.
Dropbox should be run as a small company and not run it as "big tech".
What are all these people doing besides political games?
The docs are frequently developed by the HR function with only incidental input from the actual professionals who are on these career ladders. The input is usually given only by senior executives who have not actually performed the roles that represent 80% of the company by headcount in a decade.
You may notice that the descriptions of responsibilities are both extremely vague and quite expansive. This is by design. The purpose of these frameworks are as follows:
1. To provide maximum flexibility in termination of an employee: Since the framework is essentially impossible to comply with in its entirety, if the manager or management chain of an employee wants to fire them, they can readily develop a plausible sounding justification. 0% of the employees of the company always do all the things listed on in the career framework, so there's always a justification to fire someone. This takes the form of something like "Your performance did not meet XYZ Inc's high standards. You did not complete framework section 6, bullet 3 when you were running project ABC. You aren't meeting the expectations for your job and level, so you are terminated effective immediately."
2. To provide flexibility for justifying promotions or lack thereof: Despite ostensibly having a rigorous process with checks and balances and extensive discussion, the promotion process at large tech companies is largely a subjective discussion that may or may not take into account the contribution impact of the employee. The discussions fall prey to anchoring, herding, and perhaps most importantly lack of blinding (e.g. I can see who is making what arguments, so I can tailor my position to them). Having a broad and vague role description lets the final decision maker justify a positive promotion outcome ("well, X did ABC and that's right here in the L5 description") in almost all cases. At the same time, it lets managers who fail to get their reports promoted say "feedback was that you didn't do Y, which is clearly listed in the L5 role profile."
Stuff like this only shows that it's not worth making too much of an effort since it's not really recognized anyway. The only time effort and monetary benefits go hand in hand is when you are the owner of the company you make your efforts for.
Which large tech companies have “failed” since 2010?
Facebook, Apple, Amazon, Google and Microsoft were the “large” companies then and are still the large companies now.
For example, although they say it isn't a promotion checklist, is it treated like one?
What percentage of people are focused more on career advancement than on actual (not paper) positive impact for the company?
How does misalignment rate vary by career track?
How effective and efficient are the orgs that they've built under this culture?
When I see that "code fluency" expectation tops out at L3, "design" at L5, and "architecture" at L6, I'm taken aback. So in Dropbox, L7s and L3s have equivalent code fluency?? Heresy! Nonsense! Dysfunction!
But I try to see this from the perspective of the (I assume) execs who maintain this document. Is the value of an L7 that they write better Python or React or Rust code than the other Ls? Or is it that they are expected to navigate the bureaucratic maze that Dropbox has become, making things happen and getting things shipped instead of throwing up their hands and blaming corporate dysfunction? I imagine myself as a Director in this same environment, bucking for a promotion which could easily have a seven-figure impact on my comp; who do I want implementing the projects that I am going to put into my promotion packet? Probably I want whoever will make things happen, I doubt I care very much about how finely crafted the code is or how many CPU cycles that hot new feature is going to consume in prod. In fact the document is explicit that all roles are measured on impact, which is only vaguely related to technical excellence.
This kind of thing used to upset me, as I've spent decades refining my craft as a SWE, I consider myself to be very good at it, and here's a Dropbox document telling me that they value my skills at about an L3-L5 level which would typically be 20-somethings on a traditional SWE career path. If I want to work at Dropbox with a title that matches my own self-assessed level (L7, naturally!), I will apparently be expected to do very little of the craft that I love and have honed over decades, and instead should attend a lot of meetings, craft long-term visions, influence strategies, and probably cross-functionally synergize paradigms or something.
But thinking more deeply about this, setting aside emotion, it makes a certain kind of sense. After all, at this point in the lifecycle of Dropbox or any other BigTech, what would have a bigger impact: another hot-shot software engineer shipping code day and night, or a smart technically-minded operator navigating the corporate hierarchy and political minefield to get the right things done in spite of the dysfunctional structures that seemingly every big org evolves into order time? The answer is obvious from my framing, the only confusing thing about this is that they use the title "SWE" for both of those things.
I would be interested in a Dropbox L7 SWE level of compensation, and I've already self-assessed myself as L7, yet my impression from reading this document is that I would be miserable as an L7 in Dropbox. Perhaps not coincidentally, I've spent almost the entirety of my career in startups without rigid career ladders, or vesting-in-place at the big companies that acquired those startups, or most recently founding my own software startup. That this career framework has convinced me that Dropbox isn't the right place for me is probably a good thing, as it saves me and Dropbox interviewers quite a bit of wasted time and effort.
I never understand how this is supposed to happen. As an employee of a company, no matter the level, don't I need to do the tasks that are assigned to me by the higher level? Be they "write code" or "attend meetings" or "write an architecture document" or whatever? If I am at L4 and whish to grow, can I just skip my coding tasks and instead join meetings uninvited, high-level ones? How can I "influence other teams" if I am not already empowered to influence other teams? As a team member, would I do what some external "influencer" says, or what my team leader / manager says?
It sounds to me like for most advancement, the actual requirement that can be read between the lines is "know how to navigate the rules and people to do what you want instead of what you are told to do". I would guess you would find plenty of people with this skill at NASA right before the Challenger disaster. People who knew how to "make things happen" despite lowly engineers telling them there are problems. Acknowledging problems isn't anywhere in the career ladder document.
This means that if you want to be promoted you go to your boss and say "hey, I want to work towards the next level." They then find opportunities for you to attempt the various things required for the next level and if you succeed you can be promoted.
No, but ‘no matter the level’. Case in point, the IC6 and 7 levels in the Dropbox framework SWE track here both say:
> I transcend organizational boundaries and proactively identify the best way to leverage myself
At a certain level you are senior leadership and it becomes your job to figure out what the most useful thing to be working on is.
As a 50 year old who has been doing this for awhile, I can and have:
- spent time on zoom calls and flown out to customer’s sites to gather requirements and help close a sale (cloud consulting).
- developed and managed implementation plans
- been both a dev lead and a lead for cloud architecture projects
- can be your standard, experienced enterprise developer
- I know almost every type of database out there and best practices for each
- can set up a “Well Architected” AWS account from an empty account including pipelines to deploy to EC2, Lambda or Kubernetes (EKS).
But I can only do one at a time. My “impact” comes from companies knowing that I can credibly speak to all of the individuals involved and they can fly me out to a customer’s site without me embarrassing them
What turns me off about the version of an L7 SWE as described in the OP's link is the extent to which it doesn't sound like that at all. Maybe it's my bias against BigTech career ladders, but reading between the lines it sounds to me like it's more about navigating organization, political, and bureaucratic obstacles and attending a lot of meetings and generally being seen to be doing these things.
The point of my comment is that perhaps it is rational for an org like Dropbox to value the ability to do that more highly, but I've been in those roles and I found them personally to be soul-crushing.
Why? Well, one side is often constrained by the red tape. i.e. "Oh for this promotion you have to define and deliver technical roadmaps of larger projects, we don't see you having done that in the last 6 months.", meanwhile the person is assigned to a team where their lead specifically does these things and will not be provided a chance to do it, or they have another person on the team vying for the same position which will jump on the task.
This leads to people being stuck in the same level for a while, until they decide to jump ship because there is less energy required to jump to/into that level in another company than it is to untangle the red tape at their current place.
The other group gamifies the system as much as possible. While one could say that is a good thing (no project to lead? create one!), it often ends up with folks doing fluff work just to show it off on their promotion review, coming up with project that will be left to die as soon as they get that jump or overestimating the value of their current work and impact, i.e.:
"now see, that event notification _notification_ delivery service topology I was working on the last 3 months was super important because there is a percentage of cases where they were not delivered on time, which is terrible, right? but our event notification delivery microservice doesn't deal with that, so now that we have an established topology we can architecture a backing service to pre-notify us of misdelivered messages and be sure it will work." (Jim, developer in a series A startup with 200 users)
While there is excellence hidden here sometimes (great operators will do whatever the hell they think needs to be done, red tape or not), often times it is just political grifting, trying to one-up the system to get into a position of more power/money/influence. These folks usually end up creating more red tape to constraint others from doing the same, or burn the bridges while they cross them, causing impact to the company (wasted time, wasted money, wasted code) for their own gain.
For non-experienced people, recognizing these is often hard, while even for the experienced ones fighting them is quite hard too, as they are playing the system and will use it to their defense.
I looked at the definition at Principal which is where I siy now at another firm.. and I've held at other firms... and it lines up. that's what I expect to do.
Work with director+ managers, show the way by being the way, etc. Very standard. I'd expect a bit higher tech bar... But bot hugely, it helps to convince people when you are stronger technically, it also helps with technical vision. You have to understand the details and own 'em. One small detail can turn your architecture upside down.... (Making push/pull choices is a classic issue, often with no good answer... but a bad one is possible, depending on constraints.)
.... I find it nice to see "Yup, that's what I'd sign up for." basically.
