Dropbox Engineering Career Framework
dropbox.github.io
Dropbox Engineering Career Framework
1–10 of 136 posts
Re: Dropbox Engineering Career Framework
#2[dead]
Re: Dropbox Engineering Career Framework
#3Just skimmed through it, but it seems extremely similar to what is done at other big tech companies.
Re: Dropbox Engineering Career Framework
#4I don't know what to read or interpret from this. This is very very generic and almost same in any Big Tech companies
Re: Dropbox Engineering Career Framework
#5I don't know what to read or interpret from this. This is very very generic and almost same in any Big Tech companies
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
Re: Dropbox Engineering Career Framework
#6Just skimmed through it, but it seems extremely similar to what is done at other big tech companies.
Have they all reached the same conclusion independently or are they just copying each other's homework?
Re: Dropbox Engineering Career Framework
#7At 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.
Re: Dropbox Engineering Career Framework
#8While 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.
Re: Dropbox Engineering Career Framework
#9At 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.
Re: Dropbox Engineering Career Framework
#10In 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.