10 ms·
Dropbox Engineering Career Framework
- bru3s 2y ago[dead]
- nitinreddy88 2y agoI don't know what to read or interpret from this. This is very very generic and almost same in any Big Tech companies
- arnvald 2y agoIf 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
- silvestrov 2y agoDropbox has 2,693 employees. 37signals has ~80. 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?
- nextworddev 2y agoWhen 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
- saagarjha 2y agoIt 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?
- silvestrov 2y agoSynchronizing is software that scales well. You need a handful of very good developers, not an evergrowing number. Look at how few developers that SQLite has. That isn't simpler than the dropbox software.
- jameshart 2y agoThe 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.
- brightball 2y agoThis sums up the original HN post where several people made fun of Dropbox. https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224 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.
- silvestrov 2y agoThe first post says "this shouldn't be a product at all". I'm not saying that. I'm saying that it should be a small focused company like FastMail or 37signals.
- brightball 2y agoThat’s how they started but it turns out that good syncing storage has a lot of potential integration points to create a more complete product.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- kyawzazaw 2y agoyou are comparing the most unique company with Dropbox. bad start
- elnygren 2y agoThere is likely some reason why they all look the same and also happen to be some of the best performing companies there are.
- hshshshshsh 2y agoThere was also likely a reason why everyone used to believe Earth was center of Universe. What exactly is your point?
- yodsanklai 2y agoJust skimmed through it, but it seems extremely similar to what is done at other big tech companies.
- Hamuko 2y agoHave they all reached the same conclusion independently or are they just copying each other's homework?
- rgblambda 2y agoHired the same management consultants to write their career framework is my guess.
- yodsanklai 2y agoCould 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...
- ilc 2y agoAt 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.
- dewey 2y agoMakes sense to be somewhat comparable as people switch between these companies a lot.
- thecupisblue 2y agoWhile 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.
- pjmlp 2y agoAdditionally, 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.
- lnsru 2y agoAt 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.
- yodsanklai 2y agoI 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.
- mentalgear 2y agoSo 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).
- yodsanklai 2y agoI'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).
- zerr 2y agoIn 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.
- bboygravity 2y agoSomething something work smart not hard.
- throw_pm23 2y agoThe Gervais principle is one deep rabbithole on this topic: https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/ https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
- niklasrde 2y agoDo you think that's a bad thing? 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.
- cupofjoakim 2y agoI'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.
- ecmascript 2y agoEvery 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.
- tonyedgecombe 2y agoI 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.
- scarface_74 2y ago> 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.
- neilv 2y agoWhat'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?
- serial_dev 2y agoIt 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”.
- SirHound 2y agoThat’s because “impact” is generally code for making other people rich. 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.
- zooweemama 2y ago> “impact” is generally code for making other people rich I love this and am going to reuse it!
- sabellito 2y agoI don't understand the shallow cynicism. Isn't everything we do at a company in order to make the owner and shareholders richer?
- jerrygenser 2y agoIn capitalism, that's how it's designed, yes. Everything else is "religion" to distract from this fact.
- bdndndndbve 2y agoThere'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.
- october8140 2y agoWhat are the salaries for these positions?
- 8organicbits 2y agoI'm not sure how accurate: https://www.levels.fyi/companies/dropbox/salaries/software-engineer?country=254 https://www.levels.fyi/companies/dropbox/salaries/software-e...
- deleted 2y ago[deleted]
- anelson 2y agoWhen 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.
- stevej1999 2y agoWithin the framework, where to put the coders who write great codes?
- herval 2y agoIC4 or above?
- Bilal_io 2y agoThis 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.
- stogot 2y agoAccording to a few LinkedIn posts I saw, didn’t Dropbox just have a layoff? Maybe it was small and isolated
- meltyness 2y agoWhose quarterly goal is quarterly goals?
- deleted 2y ago[deleted]
- semioticthrowa 2y agoThere 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."