In all of "career frameworks" I've seen, people who actually build things are labelled as "juniors" and "middles" while those who navigate office politics and ass-kissing are "seniors" and above.
At the end of the day the decision is made on personal level. “I like you” or “I don’t like you”. Such frameworks are just the limits how a manager can show liking/disliking someone. The thing is, that measuring someone’s performance is very hard. It’s not standardized multiple choice written exam. And maybe the company does not need more than quick&dirty, but easy to explain solution.
I don't know what to read or interpret from this. This is very very generic and almost same in any Big Tech companies
There is not much insight to glean from these career framework docs. The high level takeaway is roughly that a junior engineer should own a feature, a mid-level should own a collection of features and a senior engineer should own a product or a significant chunk of a product and so on.
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."
Every senior role is always very arbitrary while the junior ones are very practical. I feel that this is why big companies fail because you can never actually tell if the senior employees fulfill their expectations because it comes down to personal preference.
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.
What's the boots on the ground feedback on how this (or, rather, the culture it reflects) is currently working out there?
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 reading BigTech career ladders like this one, I immediately fall into the trap of projecting myself onto the ladder, and getting upset when the level I've chosen for myself is described as something that sounds far removed from what I want to do. I must remind myself to frame this as how Dropbox describes the things that they value in each position. An L7 SWE is the most valuable SWE in Dropbox, as measured by the comp that they are will to offer to L7s.
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.
Within the framework, where to put the coders who write great codes?
While these are often useful for setting some internal guidelines for promotions, I've found such an approach to usually end up creating a giant inverse bell, where one side of the curve is constrained by the framework while the other side gamifies it. In the middle, there is a few folks that actually pass the bar organically, and those usually end up being the best hires.
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.
This is very well written IMHO, it highlights the possible responsibilities, but it's important to remember that these are not definite boundies as someone could be operating within 2 or 3 definitions while labeled as one.
According to a few LinkedIn posts I saw, didn’t Dropbox just have a layoff? Maybe it was small and isolated
Just skimmed through it, but it seems extremely similar to what is done at other big tech companies.
What are the salaries for these positions?
Whose quarterly goal is quarterly goals?
It could be that I’m getting old, became a parent and working remotely from the middle of nowhere, but do I need to get to the next level?
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”.