Speaking frankly, I have been through the different roles and levels and I don't see the point of it all.
There's really only 3 non-exec roles in a software company, only 2 of them cut code, and one is just a placeholder for the junior devs.
Want to know how to keep people? Give them a little pay rise every 6 months and let them own a part of the product instead of having a no-responsibility JIRA burn and churn roster.
Those techniques assume that everybody’s motivations are the same, and that’s not true. Some people don’t want ownership. Others are already satisfied by their pay.
My answer to that question would be three parts:
1. Make sure that you agree on what success looks like, at the micro and macro levels.
2. Discuss what that person needs to achieve success for both of you - mentoring, training, tooling, access, time, money, whatever.
3. Frequently make sure they actually have what they need.
When people are regularly missing out on what you call success, you’ll probably get rid of them. When they’re missing out on what they call success, they’ll get rid of you by leaving. Don’t assume you’ve understood what they think success looks like until you’ve really discussed it with them individually.
I’ve had exceptional coders who were able and willing to make valuable contributions to the codebase, but needed to spoonfed the requirements. Maybe success in your team is a sense of ownership, in which case that person may not be right for your team - and that’s ok. Just don’t try shoehorning them into something they don’t want to do and expect successful results.
Some people want to work just enough to make money to support their other hobbies. Earning 3 times the money for twice the amount of responsibility is not worth it for them.
It's what interviews should be for, instead of "you've got 10 minutes to implement the best possible solution for this bizarre programming problem without access to any other resources".
And once you've hired them, it's what 1 to 1s for, instead of "give me a status update on all your projects".
I believe you're suggesting their level of satisfaction might change over time? I agree, which is why this is an ongoing conversation, not just something you have briefly in an annual performance review.
It's true that nobody ever says "no thanks" to free money, but there's an opportunity cost to where you spend your budget. People may prefer you to spend it hiring someone new to help them, for example.
If people need to "beg" for a payrise, then you're doing it all wrong anyway.
Everyone gets the same raise as long as they aren't obviously failing? A lot of people who have a more competitive personality would be completely demotivated by something like that.
I feel people who need to be above others, in pay and output, can be verz detrimental to a work environment. Yes, as long as a person contributes to a company functioning, they should be part of its success. And that means getting a raise simply for keeping things running.
I feel the urge to constantly outdo oneself and everybody else tends to burn people out (it has burned out me), and innovation or change just to complete a checkmark on a CV can lead to unnecessary and abandoned projects. Like it happens a lot at Google for example.
The downside of seniority based pay is that people who show little to no motivation can end up the highest paid on a team if they simply avoid getting in trouble for 20 years.
I know someone who quit a job at Boeing years ago in part because he was at the bottom of the pay ladder doing tons of work while the highest paid non-manager in his department didn't do anything except keep the printers stocked with paper.
Throwing incentives on competitive people can be toxic, but the opposite problem is that when high performers don't get rewarded the organization will rot.
> I feel people who need to be above others, in pay and output, can be verz detrimental to a work environment.
I find this worldview to be very detrimental to teamwork. People are different, we have diverse motivations and personalities, and we have to find ways to use this diversity to our mutual advantage, instead of trying saying that some of those are right and some are wrong.
> I find this worldview to be very detrimental to teamwork.
I strongly disagree, constant competition and a desire to be the best/most payed in a team dissolves cooperation. Why should I contribute to a team if person A tries to "win teamwork". I'm not saying you do that, and I'm not saying I believe that, because:
> People are different, we have diverse motivations and personalities, and we have to find ways to use this diversity to our mutual advantage, instead of trying saying that some of those are right and some are wrong.
I absolute agree with that statement. Mutual advantage to me is exactly that, even if I know someone else is smarter than me and can produce more quality work than me, the fact that I still contribute to the team success should mean I also get regular raises. Even if I only do the menial work those go-getters deem not worth their time.
Getting regular raises for contributing to the everyday work of a company is appreciation, and I gladly continue to the company if I feel valued. But not at the expense of my physical or mental health. If have the feeling I constantly have to outsmart and outdo everyone else just to keep my job and stagnate, my appreciation for the company drops. It's worst when the company instills the feeling that I'm replaceable at a whim if I don't put it 110%.
Again, I'm not saying you think that way. I'm saying that cooperation and inter team competition are orthogonal, but in my experience competition can demotivate people who otherwise deliver regular, good work. Not exceptional, and exceptional isn't always needed. Constant good work is more valuable to me that irregular exceptional.
I look at the way you describe competitive people, and I understand why you think this way. But in my experience, people who have competitive personality have a lot more variation, and don't really fit the picture that you paint. There are certainly some people like that; but there's plenty of toxic and demotivating people with opposite personality traits, too.
I understand that you wouldn't be motivated by competition, and that's fine. I wouldn't want to work in a company that forces everybody to compete. That's actually my point: working in a company that builds it motivation structure that suits only one personality type is wrong, whatever personality type that is.
I am fairly competitive by nature, but I my work competitiveness is me against my best possible and our company against our competitors. When I do well, I expect to be paid well for it. I don’t care what you pay someone else (so long as you’re convinced the company is getting an overlay on that deal), but I care a lot of what you pay me.
What you pay me changes my family experience, so I care deeply about it. What you pay someone else doesn’t, so I don’t care about the latter.
Every few weeks?! You almost certainly don't want this person. Even if you provide that, engineers who are this comp-driven will inevitably switch jobs if they get an offer that's remotely better, so you're unlikely to retain them for very long in any case.
I've never worked at a big company and my immediate reaction is that I don't like this. It feels like most HN commentators share this kind of sentiment.
I'm genuinely wondering what people on the other side of this debate think about this. If you like having systems like this in your organization, what is it that you like about it?
I feel like in my case it would totally discourage me from actually trying to make the company do better and instead would make me focus too much on trying to please people who rate me on these criteria. But I guess maybe that happens in a large organization anyways. And I guess in that case it's nice to have at least some (albeit not perfect) set of rules. Is that kind of the idea for having these?
> I'm genuinely wondering what people on the other side of this debate think about this. If you like having systems like this in your organization, what is it that you like about it?
I like it. There are limitations and the frameworks can be misaligned with the ideal goals, but in general it provides the following benefits.
1. You aren't completely at the whim of your manager. Managers need to actually document what you did and why that aligns with whatever level on these frameworks. Other managers can provide oversight on this. The alternative is that career success is 100% opaque and based on the feelings of one person.
2. It helps me as a manager do performance evaluations. I'm glad to have a framework than to just go based on my feelings, because my feelings are often wrong.
3. It can help shift priorities for an organization that is working on the wrong stuff. This is hard and requires careful language and training, but in an ideal world these sorts of frameworks allow people to align their personal career goals with the goals of the company.
If you can make the company do better without pleasing the framework, then the framework may be wrong or perhaps your priorities are wrong. I've seen the latter plenty of times. Somebody insists that their work is just obviously impactful and therefore they don't need to measure anything but they are forced to measure it due to framework requirements and, surprise surprise, what they did wasn't that important after all.
> You aren't completely at the whim of your manager. Managers need to actually document what you did and why that aligns with whatever level on these frameworks. Other managers can provide oversight on this. The alternative is that career success is 100% opaque and based on the feelings of one person.
This is the biggest important part. When your compensation, access to good projects, and career growth depend entirely on your manager, and you are not in the "in group," it's worse than demotivating--it's a feeling of hopelessness. You can document everything you did as evidence and none of it matters because your manager just doesn't like you. If you're lucky, you're at a company that encourages moving around and you can hope to luck into a better manager, because that's your only way out of the prison.
EDIT:
Unlike most of the commenters here, I love these written ladders, and I sincerely wish more companies did them. I would seriously favor companies that had written ladders over companies where it's hidden mysticism. When you are a "ladder climber" work personality, it is imperative that you can actually comprehend the actual requirements for getting to the next level--otherwise, how do you do get there? Guessing? When promotion happens at your manager's whim, it seems to have less to do with your work output and more to do with how well you brown nosed and smooth talked.
Big companies have to put these kinds of frameworks in place to ensure they’re treating everyone equally. Otherwise you end up with the absurd situations of two different people being rewarded differently despite performing the same job equally well merely because they have a different manager.
The downside is everyone becomes a cog in the machine, with nobody being treated like an individual with their own strengths, weaknesses, needs, fears, and aspirations.
The language here is so imprecise that if someone had intentions to treat someone unequally, they’ll do that anyways whether they have a framework in place or not.
This is just a bunch of corporate malarkey, let’s be brutally nakedly honest here. The fact is that this is just a more SV version of corporate bullshit with emojis - same exact thing you find in an old corporation like GE or IBM, just dressed up differently.
Absolutely, bad managers can still be bad managers, even with a framework like this.
But it can help big companies in two ways:
1. You can assess bad managers against the framework, show how they are not delivering it, and remove an excuse that they “didn’t realise”.
2. Help good managers see what’s required in common situations.
For what it’s worth, I agree with you that this is often corporate malarkey. Typically, the company doesn’t live up to the framework - it’s merely wallpapering for their own biases, which still come through anyway. But I understand why they try, and it sometimes works better than others. Not doing anything would probably be even worse. And all other solutions have their own problems. At enterprise level, there is no universal solution.
> For what it’s worth, I agree with you that this is often corporate malarkey. Typically, the company doesn’t live up to the framework - it’s merely wallpapering for their own biases, which still come through anyway. But I understand why they try, and it sometimes works better than others. Not doing anything would probably be even worse. And all other solutions have their own problems. At enterprise level, there is no universal solution.
I laughed out loud, just like real life Dilbert. I can imagine how these meetings would go. I think we gotta take this bullshit lightly and not get too caught up in its utility (there is none, even though you’re trying and I can empathize). Just act like it’s all great, do work, go home. I presume most people know it’s bullshit but still roll with it. I pity those who don’t. Gotta love enterprise life and it’s depressing if we don’t take it lightly. Office Space reminded us in a hysterical way.
Even your most successful solutions will be inspiration for somebody else's "enterprises are screwed up" cartoons. Enterprises are just too complex, so that good solutions appear stupid to most people since they don't have all the information necessary to understand why that decision was made. But, of course, there are also a lot of stupid solutions because of bad reasons.
I have been part of such initiatives in other organizations. The language is deliberately imprecise to give managers room to maneuver. It is also set to unattainable standards to make it easy to justify why someone is not getting promoted.
Appraisals are always highly subjective and frameworks like these are simply ways for the company to build a narrative of meritocracy and fairness. It's arguable how well it works though, because people generally see through such charades. But for some reason it's taboo to admit the inherent subjectivity in this process.
I've been pulled into meetings with people trying to write these things, and I can honestly say that they always seem sincere about trying to make the company a better place. It's not an excuse for cynical "hah, this load of bullshit will fool everyone". What's more, they're smart enough to know exactly how many people will see it that way.
Doing this kind of thing can't be the only thing do as a company to improve culture, just like a coding style document won't magically improve a codebase.
But, as part of a wider attempt to make things better, it can be useful.
In a lot of organizations, the language in the descriptions doesn't matter. Over time it becomes a fact that a contributor at a certain job with a certain experience should be a given level. That's it.
> The downside is everyone becomes a cog in the machine, with nobody being treated like an individual with their own strengths, weaknesses, needs, fears, and aspirations.
Being treated as a fungible human resource is as much a corporate culture issue, as it is a management issue. The creation of explicit levels and expectations is immaterial here. I’d argue the lack of levels, removes rewards and further dehumanizes individuals by literally treating them all the same.
Everybody is not being treated the same, there are ~20 criteria listed for SWE and you can have any of them be strengths or weaknesses! Everybody is unique-ish and established criteria allow a good balance between uniqueness and fairness.
The alternative is to have a set of managers write prose about how good or not their people are, make vague proposal for raises, to have them approved or not depending on how liked they are by their own managers.
It more or less works, but getting a raise/bonus or not just feels like playing blind bingo most of the time. I once had a manager explain that regardless of the actual project results, because the product people felt stressed and unsure of delivery he wouldn’t give good ratings to the team members. Fighting it back we were just told that he was the one in charge of the criteria.
Career frameworks are vague and there’s still tons of politics in applying it, but at least you have a fighting chance to argue about what you were expected to do, what you did, and about how much you should receive accordingly (these levels are usually associated with salary/bonus scales)
PS: to address the obvious point, if one is constantly fighting, leaving for a better place is the best option, but in a large enough company you could instead change manager. Having a grid setting where you stand in the org also help these horizontal moves.
I have things I like and things I don't like about it.
I like it because I see it as a guide that helps people understand how to grow and also a framework for fair compensation.
Without guidance many people, especially early in their career, will not grow as fast as they want to grow. They will need to find other ways to get this guidance, such as a good mentor. Some people learn better with a mentor, some people learn better with a framework.
Without a compensation framework, it's hard to reason about whether people are fairly compensated across the board. So what happens is that people start to develop these anyways. If not done explicitly that means that everyone has to independently do the work of coming up with their own framework and then everyone ends up with different frameworks, resulting in things being less fair. A shared understanding and a shared language can be really helpful.
I don't like it because I feel like it will inevitably change from guidance to a checklist. And then it gets political and competitive. Just like you said, people definitely start focusing on the rating. A lot. I think there could be ways to combat this, but I think it's a difficult problem.
I think no matter what you implement, there's a tradeoff. For example, my current thought is that I want it to be more about guidance and less about compensation. So it's guidance on where to grow (if you aren't sure) and de-emphasize the compensation part. How do you do that? I think you basically need to make the guidance more general and then tailor it to a person. Therefore the guidance will be more hand wavy so you sacrifice some fairness. By de-emphasizing compensation, you'd probably also be making people who thrive on promotions and leveling up less happy.
I would honestly love to hear people's thoughts on this as I'm thinking about defining levels in the next few months.
I was at a unicorn that didn't have any career level/framework and was growing fast. _Many_ engineers and ICs were asking management to add such a framework. In other cases, other employees were complaining that "titles actually do matter", claiming that the lack of rank or title was hurting their future prospects (which wasn't wrong, for better or worse). A good amount of hires refused offers because their title didn't match their prior roles. And then when a title was made for them, the title became an informal career ladder within the org. And then comparisons were made and requests to be ranked similarly made.
So strangely, it was the employees that requested and pushed for this. Personally, back then I was not interested in the whole thing. Still not that into it, but I'd be more on the fence.
I work at a big'ish company with a system like this. They also started doing Scaled Agile for Enterprise (SaFe) after I started here, which is just straight up waterfall disguised in agile speak. I feel like a cog and I feel my soul draining away. I've given myself a deadline until August to quit.
You’re absolutely right. The most likely thing to happen is that a clueless middle manager will look at these criteria and ask their reports to justify, point by point how they’re achieving or not achieving the different things listed in these criteria and if they’re not how they can “improve”. It’s a supremely shitty way to chart out ones career growth. It’s going to lead to sooo many copycat “we do our career ladder like Dropbox so we must be just as good” clones.
On the other hand, I’m also somewhat glad that this shit is in published form and not some secondhand version pieced together by ex Dropboxers. I personally liked that it lays out what kind of a developer they expect at different levels.
I guess what I’m saying is that I like this as a guide rather than as a rule.
The people on the other side of the debate are the ones creating these sort of frameworks.
I can understand this is a reasonable response when you're given the task of evaluating people and pay them accordingly.
Still, this is exactly the reason I hate being an employee. I don't think the employee model is really good, in general.
In the end the role title is meaningless and if a contributor doing good work threatens to leave, it's usually cheaper to bump his pay than to pay for a recruiter's fee, interviewing, onboarding and risk of bad hires.
This doesn't work with weird hiring rules in crazy places (Eg. Amazon's expectation of firing a certain number of people).
I’ve worked on building these systems for our company. I don’t think they’re perfect by any means, but once you have more than about 20 people their presence is better than their absence, especially at the first three levels in the hierarchy (where there is broad commonality in contributions and expectations at the first two levels, with individual variation of course).
When people (often terrible leaders) try to distill the framework into a checklist of activities, things tend to go quite badly.
Does anyone at Dropbox past or present want to weigh in on the usefulness of this framework and its application with more context? The original post falls a bit short knowing where and how this is being applied inside the org.
I'm a former Dropbox employee, current Amazon employee. I find these frameworks very useful, especially as I've gotten more senior and been involved in hiring, performance reviews, and promotion assessments. Without this kind of framework, it's really up to individual whims about whether someone is performing well. And yes, these frameworks aren't perfect, but the act of creating and maintaining them is healthy for the organization to understand what it values.
IC7 => I transcend organizational boundaries by taking a holistic view of the company’s goals and taking responsibility across EPD, not just within my immediate scope of ownership.
I laughed when I read this description. The religious undertone tells me everything that I need to know about the company. Almost cult like?
HN comments are reaching new levels of bad, there's literally nothing fishy about that professional goal and it's what you should be aiming for as a principal dev.
My personal experience of almost all such frameworks is that their very existence drives competition for promotions. In turn, that can lead to (unspoken) resentment of one’s peers.
But once such frameworks are introduced, they are difficult to get rid of.
Consequently, I see the introduction of these frameworks as a committal culture step which should not be taken lightly.
One thing that I think many are missing in their understanding, is that this gives Junior to Mid-level engineers a path forward and direction to improve. Often it's the case an engineer will ask their manager "How can I improve or get to the next level?" and having reference documentation for how to impact an organization at a larger level is extremely handy. It also helps engineers relate their efforts to the bigger picture and help them formulate a vision for why we have a competency hierarchy and how to view it in terms of career frame-working.
At my company we also have a very similar engineering career framework, but the goal isn't to push everyone into boxes, but rather to help engineers understand what it means to have a large impact on an organization. This usually translates to more cross-team responsibilities and deliverables over longer periods of time.
Meanwhile interns and junior developers apparently have to handle the bulk of hiring and job interview work. No wonder people complain about the quality of job interviews.
That seems so weird and makes sense at the same time. As in, why would they force juniors into that, and now I understand why some interviews make no freaking sense whatsoever, or the offer is way outside the scope of the position interviewed for.
This is getting a lot of hate here, but having a well defined career track is useful. So many people want to know what they need to do to advance in their career, yet for some reason think all they need to do is be good at closing tickets. Well, that’s not job at the upper levels. Yes, you do need an opportunity to demonstrate the skills, but it’s surprising how many people in my experience don’t understand that the job changes.
“Oh! But we have a flat organization”, you (cough Netflix cough) say. No you don’t. You have a shadow hierarchy. It’s there. The rubrics still exist. The “politics” and hurt feelings still exist. It’s just that the reasons are kept hidden, perhaps to make promotions more arbitrary and capricious. Does having an actual career make promotions and performance reviews objective? Of course not. Does it make promotions and performance reviews more aligned across the company? Yeah it does.
This is as much a tool for management, as it is for ICs.
At what point do we hit “peak emoji”? This document isn't describing summer jobs at the local park. It’s adults’ livelihoods. I can’t imagine referring to section trophy subsection rainbow in a serious discussion about my family’s source of income.
This is extremely close to the leveling rubric we use at the tech company I work at. The level names and language are slightly different, but it's the same matrices of scope and impact, and more or less the same qualifications.
I assume at this point there's so much cross-pollination going on between tech companies that many companies resemble one another operationally.
This must be a new local maxima that everybody is trending towards.
It is nothing new. It is similar since way back to MSFT times in the 90s and then google changed things a bit in the early 2000s.
Heck, I worked at a stogy financial company way back in 2003, (Fidelity), and had similar grades for engineering (4 grades), then Director, or VP for the highest level.
The Dropbox post would have been much more interesting if it had salary ranges attached to it. Otherwise it is just kinda fluff.
My own institution, a government lab, uses the same naming system (IC1 through IC6) with management also done similarly to what is shown here (M3-M6 at least, not sure about M7). And ICs are slotted into certain disciplines just as here (e.g., for us, Mechanical vs. Optical engineers).
And also with the same matrices. The framework is just the same, with the same griping about the language being slippery among those who use it ;-).
It was converted into the number/matrix setup from the earlier system with Senior, etc., some years ago.
Whilst I applaud this effort in transparency, I can't help feeling like there is a lot of weirdly specific prescriptive expectations and jargon in place here, with questionable practicality.
I wonder if a looser, more broadly-defined set of definitions might work better, recognising that people can add value in different ways.
"Values reported by employees over the past few years" is very different from "ranges used internally by employer today". In particular, levels.fyi can be very out of date.
Is there an alternative to heavy bureaucracy like this once a company reaches a certain size?
What other mechanisms exist for combatting nepotism, feeling too abstracted from the mission etc in a larger company?
Does a company like SpaceX with lots of people working towards big clear goals and where comp isn’t in the set of top reasons for choosing to work there use a levelling framework like this?
I work in a company of 10 where we all have strong drive towards the company goals. I’m worried that we will lose this as we grow but I can’t see any clear alternatives. I wonder whether you could build a company that operates like a loosely-coupled network of smaller teams with internal accounting so that teams are compensated based on some kind of internal team valuation (similar to how startup valuations are set by the ‘market’). Probably a terrible idea!
One alternative is an opaque hierarchy where it is difficult to find the goals or team missions documented anywhere.
It lets senior management avoid uncomfortable conversations about power relations while also creating a lack of clarity for individual contributors about what their subteam’s mission even is.
I literally had a interview with a company that insisted on ICs not having levels, while having levels for management. The director was wrapping up and said that the company took growth seriously and specifically mentioned promotions as a reward, to which I immediately pointed out that doesn’t exist for ICs. He then stammered some claptrap about ICs need to find warm fuzzies for themselves, and not worry about recognition.
The military--a completely flat structure of promotion based primarily on tenure and time-served, not necessarily ability or award/recognition. Before you blow it off as worthless there is some potential merit to it as it cuts out nepotism, cronyism, and other kinds of corruption that push unqualified people up the ranks.
> The military--a completely flat structure of promotion based primarily on tenure and time-served, not necessarily ability or award/recognition.
That's...not how the military works at all. I suppose it might appear approximately that way if you look only at the officer corps and, within that corps, only at survivors of the up-or-out policy. But, while their are minimum time bounds, subjective assessment of fitness (i.e., demonstrated ability) is the main key to selection for promotion.
The military is not that much different from the private sector. The first few ranks are as you say, but after that you can be fast tracked by nepotism, and cronyism.
It’s a hard problem. Honestly, I think it’s something you can just ask your team about and see what they say. The people that work with you now might help you discover what it is about the job that they love and is keeping them here and try to build on that.
There are a lot of comments being against frameworks like this, as a manager, after having a quick glance, it's a pretty decent one compared to other things I have seen. It's important to note a couple of things, before we even look at the framework itself.
Different people want different things. A lot of people want to code and to be left alone. A lot of other people don't. They want to feel they are progressing towards something. Good frameworks usually state: we consider you as a senior if you are doing X & Y consistently. This helps people aligning their actions/work with a level. The group of people that usually don't care about this things, might start doing so, when their title (e.g. "Software Engineer") lacks the "senior" keyword and they are applying for a senior role elsewhere. This might seem nitpicking, but you would be surprised how many people don't even pass the first screening because they don't have the "senior" prefix. In bigger companies monetary compensation is assigned according to the person's level. In smaller companies, not so much. Everyone has the same title, and people can have significantly different salaries. A good career framework makes it very clear to everyone that if you want to earn between X and Y you need to be at a particular level.
As for the framework itself, I am big fan of giving examples. Say for instance on IC3: "I’m able to navigate ambiguity and remain resilient through ups and downs". I would love if they assigned a somewhat real example: "I am able to complete tasks, even when the acceptance criteria is not 100% clear.". They did well with the separation of the different functions: QA, Software Eng, Security Eng & Reliability Eng. A lot of places bundle some of these together and leave people scratching their head.
It seems like IC1 = Intern, IC2 = Junior, IC3 = Developer, IC4 = Senior. No idea why they're not named closer to that.
Also, do people think that these role descriptions are actually helpful? I find them extremely vague and generally unhelpful in determining if I'm performing at a particular level.
I think they skip naming them because junior is a bit insulting and senior is pointless when you have three more seniority level above it. Also people are very fluent in this range. They develop in this range quickly. A very young person can reach seniority quite fast.
"Junior" is only insulting when the company doesn't promote from within. Which is most online companies, sure, but that's no reason not to buck the conventions.
Oh definitely. Being a junior rank also has privileges etc.
There are also other conventions we - as a society - try to break away from. So discussion and alternatives to conventions is something completely fine.
Levels aren't standardized in industry, but they are inside a company. They impact pay bands and other things.
IC1 sounds like it's for new grads. Junior doesn't seem to be a popular title in the bay area. One or two are probably Senior levels.
I find it useful for how they change. Work complexity grows, timelines go from some tasks to multi-year projects, and you are expected to work more outside your team and mentor engineers.
It doesn't really give you a path to get promoted though.
From that page, I'm seeing 7 SWE levels from the sidebar:
- IC1 Software Engineer
- IC2 Software Engineer
- IC3 Software Engineer
- IC4 Software Engineer
- IC5 Staff Software Engineer
- IC6 Principal Software Engineer
- IC7 Sr. Principal Software Engineer
(This is on a desktop browser. Maybe you're only seeing 4 levels because you're on a mobile browser and the rest is cut off. Or maybe you indeed saw 4 levels and the site has been updated since your post.)
IC3 or 4 looks like most senior engineers--i.e. you are now a force multiplier for your team. You are giving help, mentorship, advice, expertise, etc. more than you are needing it yourself. You're helping with important interview and hiring decisions.
It’s very common to have just numbers for the first few SWE levels. It is a bit unusual not to have “Senior” for 4, but then again it is pretty self-evident from the number.
>> This framework is not a promotion checklist for your role
I hope this is true. There were too many times where things started out as a general guideline but gradually turned into a rigid checklist where one must tick all the boxes to get a promotion/raise.
It's not intended to be read as instructions on how to be promoted. It is directed as much to managers and higher levels so they understand the boundaries and expectations.
One basic idea; a) recognition of level based on observed impact, as opposed to b) promotion to power as reward for effort/loyalty. With a), management is not a "final destination" of engineering careers. Old/sloppy organizations seem to devolve into b).
The instructions here seem to be written with this in mind, and directed to everyone in the org.
Lots of ways to do this, but one way is install poppler-utils so you get pdfunite, make sure your filenames for the pages lexicographically sort in the order you want the pages to end up[1], then do
pdfunite page*.pdf output.pdf
I have had decent results using pdftk as well to do pdf surgery so that's another option.
In this case, if you do a recursive wget I think it should "just work" because the files are named in a friendly way.
So, putting it all together:
wget -r 'https://dropbox.github.io/dbx-career-framework/overview.html'
cd dropbox.github.io/dbx-career-framework
ls ic*software*.html | sed 's/.html$//' | while read f ; do
pandoc --pdf-engine=wkhtmltopdf $f.html -o $f.pdf
done
pdfunite ic*.pdf output.pdf
[1] ie the ordering of the output of "ls" is the order you want the pages in the output pdf
A bit more manual, but I've been saving webpages I like in Obsidian.
First, click the reader view in Firefox, then select all, then paste it into a new Obsidian page. It's really good at keeping a nice formatting and importing pictures etc.
You can then export the result to PDF if so desired.
Not sure why you are downvoted, I save everything I want to refer to again as pdf because stuff on the web disappears. I can search all the pdf I have offline with Qiqqa or mendeley. Used to use google desktop for pdf search.
How does that work with the industry standard increasingly being that levels Senior and higher are really management in disguise (with all the responsibility, little of the authority)?
ICs have to produce technical work themselves even if they also have reports. Managers are presumed to spend so much time managing they no longer can/should do that.
Senior Engineer probably wouldn't have reports though - that just means you know enough to not make mistakes. Staff and up would run projects and have at least unofficial reports.
I also got the feeling there was some role justification going on here, with the level of detail employed (and what seems at first glance to be relatively arbitrary levels of skill differentiation). It reminded me a little of the SFIA Framework in that regard.
Normal doesn't mean sensible though. Having worked at a company that does this, there are high performing IC2s that I'd trade for IC4s (to use comparable "levels" here); so I'm not sure what this does other than declarative justification (across tech).
Well, it's just a pay band. The explanations are post-hoc, because you can't get promoted by following them or anything. You are supposed to live up to them at performance review time, and how that works is different at different companies.
This is kind of the main problem. You should't have employees at IC2 if they are IC4 worthy. They will just try to find another job, instead of waiting 5 years before reaching a level of someone who is performing same or worse.
There's really only 3 non-exec roles in a software company, only 2 of them cut code, and one is just a placeholder for the junior devs.
Want to know how to keep people? Give them a little pay rise every 6 months and let them own a part of the product instead of having a no-responsibility JIRA burn and churn roster.