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”.
These frameworks serve 3 purposes. The first purpose is to have something concrete to point at so your employees don't sue you over unfair practices - they create a paper trail for management to operate and build evidence that what they are doing follows a meritocratic process (whether that's true or not is irrelevant, it's purely a legal concern). The second purpose is to motivate employees who want progression by setting up a goal posts for them to shoot for so that they try harder and don't leave, but vague and subjective enough to deny you the promotion for a least a cycle or two. The third is that there's all these bloody HR and middle management people hanging around and they need something to do.
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'm also in the same boat as both of you, but I'm not sure I agree with the idea that I need to do a bunch of extra work to prove some nebulous concept like "impact at the next level" or whatever buzzwoo we want to say in place of that. If the manager wants to develop my talent, then they need to get off their over-priced rear ends and do so.
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.
> If the manager wants to develop my talent, then they need to get off their over-priced rear ends and do so.
You are responsible for your own career. When (hypothetical) you get ready to look for another job, do you really want to only be able to say that you were a ticket taker or do you want to be able to say you led initiatives?
Even if you don’t really care about getting ahead, you still have to be able to stand out from other applicants
One way to stand out is to be nice, funny, and make a genuine personal connection with whoever the decision makers are. It sounds cheesy but it’s worked for me back when I didn’t particularly stand out.
I was competent though, which is always a requirement; this won’t work for smooth talkers only.
Now when I interview you, I’m not going to ask you to reverse a btree on the whiteboard. I’m going to ask you questions to see if you can “handle ambiguity” and work at the scope I need you to work at.
I’ve spent the last decade mostly as one of the early technical hires for a major new initiative and then leading cloud consulting projects (3.5 years at Amazon and now at a third party company both full time). I need to know I can throw a vague set of business requirements at you and you can take the ball and run with it.
I actually did a thumbs down to a very smart guy who had been laid off from the AWS EC2 service team because when I asked him behavioral questions, I didn’t get a sense that he could handle the type of green field initiatives I was going to throw at him.
You don’t, actually. People love to be flattered, and the trick is to go find whoever is making the decisions and to flatter them.
You’re not immune to this either. No one is. Again, competence is a requirement, but flattery plus competence is a very powerful way to distinguish yourself.
I am very immune to flattery at 50 years old. While like I said I don’t do coding interviews, I am asking behavioral questions to assess whether you are “smart and gets things done”.
My main motivation for impactfulness is just making my job more pleasant: Nothing is more soul-sucking than fixing the same kinds of issues over and over because the powers that be are convinced they're doing it right, and you're the one stuck fixing the issues they create.
My main motivation is for my resume to look good for my n+1 job. I don’t always know when I’m going to be looking or whether it’s by force or by choice. But I always want to be prepared
I never said anything about not being responsible for my own career. There was a previous implication that we need to help the boss look good, which is BS. If I want to develop myself because I want to explore different options or expand my skill set, I am free to and generally opt to do so. If a manager wants to develop my skills, then that is their responsibility.
Again, let's not shift all the accountability to the guys lower on the ladder. It's a team effort.
Perhaps I just don't understand your mindset because I do not define myself by my career. Work is just how I exchange some of my time and effort for money so I can focus my life on the things I actually matter to me, so the "weight" of my career is perhaps different than yours. Which is fine, btw. I don't really have any issues if someone wants to make their career their life, but I'll never align with that, especially not at this late in my adult life.
I don’t define myself by my career. But I do make damn sure I stay competitive. I’ve had 10 jobs in 28 years and 8 since 2008. I stay prepared to look for another job at a moments notice.
The “team” doesn’t care about you being competitive when you are looking for your next job.
Mid-40's, and many lessons learned by paying attention to those who paved the way ahead of me. Don't get me wrong, I'm a hard worker with a reputation for keeping my promises in an industry that is infamous for the opposite (manufacturing, without getting too deep into my role in that sector for the sake of keeping this brief), so I can't really complain about my wages or the recognition I have gotten in the past. But it's still just a job. My real life is my family, my hobbies and my adventures. When strangers ask me what I "do," I generally like to reply with those things rather than talking about work.
As for the email, it was part of a now-dead idea that grew out of boredom one evening while chatting with some old computer friends, and definitely involved different sounding farts. Never really got past a few lines of code, but I have been thinking about using the domain for a cranky old git blog or something.
Unfortunately, getting more for less is the point. Oncw these business are in flight, 99% of the work is "menial" and managers win by driving salaries down. A good way to do that is only raise salaries do to external challenges. Internally, do everything for minimal maintenance.
Keep in mind, the Art of War can easily be seen as a dummy's guide to product management and is just a default minimum because age managers are often selected by the peter principle.
I've worked in companies with similar frameworks both as a dev and as manager, and it was great. Everything has issues, but the framework gave useful guidance.
I'm not saying it doesn't work. Especially for early careers people, it works absolutely fine because the requirements are reasonable and the scope is largely within the employees control. For later stage employees, it's usefulness tales off massively. When you get to senior levels your ability to fulfil the requirements gets further and further out of your hands and often if you want to pursue the promotional criteria you're actually going to have to deprioritize delivering value to the business to prioritize engineering situations where you can meet the criteria. A lot of the senior goals are basically politics.
There's nothing shallow about it. Companies don't make "levelling up" worthwhile unless you have your ego invested in your title in an unhealthy way. If you hang out at senior+/staff level you can just plug away until retirement.
Career frameworks at corporations should be mostly ignored. They are thinly veiled attempts to extract more work from the same employees. This is why "there's always room for improvement" is seemingly infinite. Your performance reviews can be stellar, BUT you surely must want to sacrifice more of your time and mental health to move to the next rung, right?
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.
I have never gotten a “promotion” in 28 years of working across 10 jobs.
I’ve always changed jobs. It’s a lot easier to get a “promotion” as part of an interview when you control the narrative than going through the promo process.
Besides because of salary compression and inversion, even if you do get an internal promotion, you will probably make less than someone coming in at your level.
And if that’s the case, you have to find another position.
But I’ll tell you the lack of a framework does not change anything. Then all you get is “in my judgment, you haven’t proven yourself to be senior yet.”
And the result is the same: the person leaves to a place that will appreciate them.
If as you are moving up in you career and you are doing “more” work and not “different” work, you’re doing it wrong.
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
I am in the same boat. Specially after delivering multiple high impact systems and still getting the talk - "This is great, but not enough for the next promotion". So after a while I just realized that these levels are artificial and meaningless to a large extent.
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.
> You seem to want to be recognized for your contribution with increased responsibility.
But you don’t need a “promotion” for that. Even when I was at BigTech, there was nothing stopping me from volunteering for a more impactful project. No one was going to tell me that I wasn’t allowed to do it because of my level.
I had a junior consultant/returning intern that I mentored as an intern and then when they came back over a smaller project that usually would not have gone to someone at their level. They had proven to the department that we could trust them to both do the work and be in front of the customer.
I was there as a backstop if needed. But when we flew fk the customers site, I intentionally stayed in the background and deferred to them.
Same for me. I enjoy what I do, but if I didn’t need the money, I sure as wouldn’t be doing it for someone else. I’d just be working on whatever projects I found interesting.
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.
Well, you could think about making more money for retirement. Not saying you need to get crazy about it, though.
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.
You're right. My post was mainly focusing on expenses and living standards. I'm already contributing above average to my pension and I'm hoping that any above inflation payrises I do get go towards retiring early.
> I am not sure how the hell we will be able to manage that (retirement) with the lifestyle we got today
Then don’t. I’m 50 and my wife (48) spent the last four years “decontenting” our lives. I started working remotely in 2020 and we sold our big house in the burbs (for twice what we had it built for in 2016) after our youngest graduated and downsized to a condo in state tax free Florida. We are now down to one car and our fixed expenses are a nothing burger.
She also “retired” at 44 and spends time on her passion projects. We travel a lot and have done the digital nomad thing for a year flying one way trips across the country. In other words, when I do retire, we will already have cleared most of our bucket list.
I’m kind of in the same boat, I did my first and hopefully only stint at BigTech between 46-49. During that time my youngest (step)son graduated and moved out on his own, we paid off some debt, downsized to a smaller condo , sold our big house in the burbs and started traveling a lot after I started working remotely.
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
I CAN'T tell you how much I felt your comment. This about drove me wild in my career - dealing with the "need to level up" and having different rotating Ems who each get differing pictures of what that should look like. I just wanted to be left alone (career/rank up wise) to do great work.
I'm a line manager and tech lead at a big company. I have both direct reports and mentees that don't report to me but I'm helping with their trajectory who have that attitude ("I'm fine where I am") and it's mostly fine with some caveats.
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.
As an entrepreneur, 25 year manager and now mid level IC employee of a big tech firm... Good for you. As a manager I always told people I would kill for a team of people mostly composed of folks happy with what they are doing. It is sooo hard to manage a team of people where most are striving for advancement, especially when that cannot come soon enough for them (and especially when they do not believe they are not there yet).
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.
Dropbox does have a terminal level which I think was IC4 when I was there.
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.
These tools and many other from the HR handbook are mainly meant as communication tools. For some employees it's easy to talk about their motivations and goals within your company. With other employees you'll have to pull an answer out of them and it'll be a "yes" or a "no", I mean, it's obviously not that bad but some employees are really bad at talking about these things. Some managers are also very bad at it. The tools help frame the context for 1-on-1's where you need to talk about what sort of path an employee wants to go on over the next year. Sometimes these tools are misused, for some people here on HN, that will probably even be the only way they have interacted with them.
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.
Because you're expected to get to the next level in good time, otherwise you're not good enough and will be fired. The level you can stay at is typically the level below Staff.
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.
Politics, nepotism, ass-kissing, or incompetence exist everywhere and at every level. Just the byproduct of not living in a utopia.
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.
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.
I do think it's a bad thing, but not for the reason you think.
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.
In the orgs that I have worked in, there were very few developers who could actually handle coding complex features and applications. The people navigating the office politics are important, but let's not pretend they are actually capable of pulling off the work. They can understand that "system A interacts with system B" at a high conceptual level, but are not capable of digging down at the detailed level necessary to make it happen.
My current org is the opposite. Loads of Very Smart Developers all building supposedly brilliant stuff in isolation for their fiefdom without any regard for how it fits into the bigger picture.
I'm not the one you responded to, but I definitely feel like it's not necessarily a "good" thing or a "bad" thing. Having a senior be more involved in writing some functionality should mean more maintainable code with more complex issues factored in to the solutions, which should mean better predictability when it comes to planning new work.
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.
Writing code is easy when you have a spec to work to. It more or less writes itself - see <30second submissions to Advent of Code last month (likely AI - but it doesn’t matter how it was written for this point; just that it was written and solved the spec).
Getting that spec is damned hard.
What do i mean by spec? Basically are you going to build the right thing. A hard problem - if you think it’s easy, it more than likely means you didn’t understand the problem.
The reason pinning down a spec is so hard is because at the macro level, there are very few actual solutions - mostly only trade-offs are available to work with.
Sorry, I think that's delusional and if anything maybe only applicable to the very narrow and simple problem space. Nobody writes out the "spec" for the next best inference engine or the next best distributed database.
The senior needs to figure out that the next best inference engine or the next best distributed database are what needs to be built in the first place (or beating about the bush as you said). That’s hard. Lots of conflict to be explored.
Once it’s been captured what needs to be done (spec) enabling the rest of the team (execute) is comparatively easy.
Fail to spec, and the team can’t execute. They don’t know what needs to be built.
> Writing code is easy when you have a spec to work to. It more or less writes itself - see <30second submissions to Advent of Code last month (likely AI - but it doesn’t matter how it was written for this point; just that it was written and solved the spec).
I'm sorry, but it's hard to take your comment seriously when your definition of "spec" is AoC puzzle.
The context of this conversation is the actions of a senior developer. If the senior developer allows someone else to write the plan in isolation (thus allowing a completely useless plan to be devised), then they’re by definition of the senior role, not a senior developer, right?
The more senior you become, the more you are responsible for building the right thing the right way. Necessarily this might involve what you call "navigate office politics and ass-kissing" but others might just call talking to your colleagues and planning.
Agree with the sentiment, but senior, staff, platform, architect, etc can also be granted on merit in orgs with engineering segregated. Playing the high school drama games does get you places though.
Yeah that's a problem -- Here's my law for honest leveling - If somebody of a given level is incapable of doing something of the level below them, then your leveling system is broken (and they should be in a separate track).
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.
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 think it's true. It's in the company's interest that people are evaluated fairly, especially if they are going to give big bonus or agressively fire low performers (like some of these tech companies do).
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.
Work that makes your boss (or your bosses boss) happy gets you job security and in some companies gets you promoted. If that aligns with “what is best for the company” or an even more distant metric “what is best for the customer“ then thats great, but its not a requirement.
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.
companies do not really have interests, individual people have interests. The founders, the board, investors, executives, managers, ICs, consultants, vendors, customers. Everyone is doing what their manager (customer) tells them to do while capturing enough value for themselves to make it worth it, recursively. This becomes especially clear when interests diverge, the executives screw the employees, the board screws the founders, the founders screw everyone, the managers accumulate unnecessary headcount so they are responsible for more cashflow, the ICs inflate the estimates, the PMs prioritize visible short term features only.
I also recommend Gervais principle as mandatory read for young managers who don’t yet see the game for what it is.
So you're defending the standard company evaluation metrics in theory, yet in your closing paragraph you state from your own personal experience that the outcome aligns with the above commentor's statement (which you disagree with).
I'm saying it's possible to evaluate employees based on some metrics and objective criteria, and it can be much better defined than "make manager happy" in some arbitrary way. That's my disagreement with above commentator.
My experience is that it can be hard to define criteria that align with company's goal (make shareholder happy).
If I remember correctly, Dropbox was one of the first big tech companies to publish its career framework openly, a lot of organizations (especially smaller ones) based their careers on the Dropbox’s one
It would be reductive to look at it as a multiplier, but really? You don't see synchronizing terabytes of data for millions of people to not be complex? When if you make mistakes you are losing people's photos of their children or their company's financial charts? With hooks in the filesystem to make this all work?
The SQLite development team doesn’t run and operate a scaled set of sqlite instances serving 100,000 enterprise customers and 200 million consumer accounts. They don’t have to run a billing and account management system at scale and provide support for a sales and customer service organization. They aren’t responsible for managing an exabyte or so of other people’s data.
The core storage/synching engine of DropBox is pretty simple, sure. Running DropBox is a lot more than just building that piece of software.
When your product is basically a wrapper around s3 (figuratively - I believe they migrated), you bet there’s a lot of politics in their engineering org
They’ve done many acquisitions to expand functionality, tons of integrations, APIs, search and they do a very good job when they integrate those acquisitions too.
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.
I think a lot of it stems from the fact that it's difficult if not impossible to measure programmer productivity. Once people realise this they start playing political games rather than focussing on their own output.
> 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
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.
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.
> instead should attend a lot of meetings, craft long-term visions, influence strategies, and probably cross-functionally synergize paradigms or something
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.
Usually the levels don't say "you cannot do X until you are level Y" but instead are "if you are level Y you must be doing X".
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.
It doesn’t matter how good you are as a developer, you can only have so much impact coding 40 hours a week. I wanted to move up both to increase my autonomy and my vision is much larger than the amount of work I can physically do with my own hands.
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 you're describing is actually not that different from my own conception of what a senior principal SWE is. Simply stated, I would define that level as a very experienced, knowledgeable, competent SWE whose main value to the org isn't in KLOCs they personally write but as a force multiplier who sees around corners (but also writes their fair share of KLOCs).
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.
When I am managing very large cloud projects, I still have to deal with the client’s different departments priorities, fiefdoms, dealing with the operations side wanting everything locked down and the developers wanting the freedom to do what they want. It’s part of dealing with any large organization.
I got an offer to be a “staff architect” at the company that I acquired the startup I worked for before going to AWS. I would have been responsible for strategy across all of their acquisitions.
While the technical requirements didn’t worry me. I had never seen how a large product company worked at that level and didn’t have confidence I could pull it off from an organizational level. Before going to AWS I worked at small companies.
I did know the expectations in consulting. But in all large organizations you have to deal with that. It’s the nature of the beast.
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.
Additionally, to build up on your example, even though one might be quite confortable with techonology XYZ, if it isn't part of those last 6 months assignments, you might even see lesser skilled people acquire additional levels on those stacks, while the unlucky dev will have its capabilities not acknowledged and thus lose the opportunities that might arise in that XYZ technology.
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.
Could be. My guess is that in doubt, just copy what the other guy is doing. We see that all the time. Leetcode interviewing, return-to-office mandate, layoffs...
At some level you need engineers to roughly accomplish the sane things.
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.
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”.