Square’s Growth Framework for Engineers and Engineering Managers
developer.squareup.com
developer.squareup.com
To any young engineers who may be reading this, this is social fiction. If someone can fire you but you can't fire them, you better believe you're not on parallel tracks.
EDIT: it's not just firing. Managers know your compensation, but you don't know theirs. They'll all work to split their team into multiple teams so they can say they ran a group; the good ones will soon become managers of managers, and then managers of managers of managers. They'll sit in on senior meetings, work on strategic decisions, and you'll watch them rise further and futher in the company hierarchy while you're enjoying your "parallel track".
If I ignore or undermine the choices made by manager I will be fired. But vice versa is not true.
We are also significantly smaller than Square though, with 40+ employees. We want to keep it this way up until sustainable, then figure out something else. We don't want managers to ever be able to single handedly fire people.
Who does have firing powers, and how does one get there without being in the management track?
I'd be curious the size and type of company the OP is talking about where managers get that much power?
I remember early in my career meeting a very senior and experienced manager from another company on the same project who said he intentionally didn't become too friendly with people in case he had to sack them - which I thought must be a miserable way to live. NB I have sacked people for poor performance and laid off people I considered friends (and who are still friends).
Also, I'm glad that you believe that we will get to 10k employees. Currently beyond the scope of my own ambition.
The root poster is absolutely correct. The responses that say you can have a great life without climbing to the top of the highest ladder are also correct, but they aren’t refuting what the root post says.
Also, while things look pretty rosy for senior ICs right now, I wonder how many people lauding that path are in their forties or older. It’s one thing to be a respected principal engineer in a strong economy but what about if we hit another recession and your third wave tech company gets bought out by IBM?
> The root poster is absolutely correct. The responses that say you can have a great life without climbing to the top of the highest ladder are also correct, but they aren’t refuting what the root post says.
> Also, while things look pretty rosy for senior ICs right now, I wonder how many people lauding that path are in their forties or older. It’s one thing to be a respected principal engineer in a strong economy but what about if we hit another recession and your third wave tech company gets bought out by IBM?
I was with you until the very last part of the very last sentence. In my experience, often times where there is management duplication they will trim management (we don't need _all_ of these engineering managers do we?) but keep performing ICs.
Age discrimination in this industry is very real (notwithstanding the tired excuses we see in every thread on the subject.)
People that are in their late 20s or early 30s need to start thinking about this. Right now you’re the age that the industry loves for “senior” ICs but mid 30s come on fast.
Exclude the CEO because it’s a singular position. Only one person can be CEO. There’s no IC equivalent to it because it’s a unique position.
I think it will be hard to find another job at director level without any reports. I have witnessed the struggle of my friends with this exact setup.
If you have a team of engineers rangining from L3-L7 (on Square's scale), and you want to hire a new engineer you'll interview, and then decide on a level based on the person's skills & experience. Probably you knew up front that you were targeting a 4/5 or a 6/7, but generally, you don't go looking for a L7 IC, you look for an experienced engineer and then put them at the level that is appropriate.
But if that same team needs a manager then your policy is that they need to be a L8 or above (otherwise you'll need to do a big reshuffle to move all the L7 ICs out). So now you interview looking for a L8+ EM, and you hire the best person you can find, and you make them a L8. Maybe they're at the lower end of the L8 scale, and you know this role will be a stretch for them, but that's OK because it's good to stretch people into new roles and you think they'll step up.
But, you would have made a different decision when deciding what level to give an IC. My experience has been that for ICs, companies (rightly) err on the side of caution and if they think that the new hire is on the lower end of the scale they'll bring them in at the lower level, and let them prove themselves.
So if you're asking Is this engineer a N or (N+1)? you'll be more likely to bring them in at N. But for a manager, there are incentives to bring them in at N+1 so that they can maange the members of the team who are N.
And now your standards for an (N+1) IC are higher than your standards for (N+1) EM. And when it comes to promotion time, the new hires form part of the benchmark. And your existing Level-N EMs are performing just as well as your new N+1 EMs, so they're good candidates for promotion. But your existing Level-N ICs are really only performing at the same level as your new Level-N ICs, so things seem to be balanced.
I don't think there are any easy solutions to this problem. If you have a policy of ICs reporting to higher-leveled EMs then you create a system that makes it easier to be promoted on the management track. But if you have ICs reporting to a same-(or lower)-leveled manager, then you have a perception (and possibly an reality) that being a manager gives you more organisational power than the same level IC.
There are far more ways to measure success in life than your paycheck or where you fall in an org chart.
Management comp paths tend to be more linear.
This depends on your org. Also there are individual contributors literally and individual contributors who function like a force multiplier and, although not managing, provide a lot of value beyond just their commits. I’ve seen this with wizard architects and sysadmins who just a percentage of their time is great on a project.
For most people, salary correlates with measurable influence, and there’s nothing more measurable than head count. So maybe you’re right about certain orgs, but I wouldn’t advise any young turks to bet on it.
Basically, every nerd thinks they’re gonna be Jeff Dean...but there’s only one Jeff Dean, and his job is taken.
absolutely this
Just as in how sales people can be on commission but no one puts fifty developers on commission the ability to measure is as important as the metric itself
Most managers don't set their own salary, and are dependent on someone else noticing and respecting their "contribution" (like "headcount" metrics) for their compensation consideration. It is entirely possible to be sidelined as a manager, just as it is anywhere else.
Everyone should have clear, communicated, consistent, meaningful, deliverable, pragmatic metrics that they are subject to in their evaluations.
Jeff was an IC. He no longer is. Under the naive assumptions that many people in this thread are making, that means the IC position he was in should be available.
It's not. I leave why as an exercise to the reader.
50% raises are a sign of company growth and a competitive market. Once a business is well established, growing slowly, and there are enough developers to go around compensation will settle down.
We're in the first few decades of Internet technology companies. This is the industrial revolution all over again. If you look at the first factory workers in the early-1800s, and the first steam engine engineers, and the first factory production foremen, they were quite well paid relative to other jobs. Later, when rural folk saw what was happening and moved to the cities and mill towns for work, and the supply of workers boomed, the wages stopped growing (and actually fell). The factory owners made hundreds of millions in today's money. They built towns for their workers to live in (Bournville, Rowntree, Port Sunlight here in the UK). Now Google is looking to do the same sort of thing. Its all playing out in a very similar way.
Give it another 20-30 years and things will look very different in tech.
I wish. Where in middle American or whatever you call the equivalent in Britain is Google or any other tech company building towns for their workers?
Nope, Google and the other FAANGs are all still focused on 4-5 large urban areas, almost all of them on the West Coast.
If there actually is a parallel track, this doesn't happen. Directors sit on meetings with sr. staff engs and principles - directors think about the resource allocation, principles think about the technology direction. The technical track is just management of and responsibility for larger and larger technical areas.
You may get paid the same while working as an individual contributor, at least for a while, but over time your power in the org suffers a slow decay.
For example, you may not be able to direct your work towards that which generates the most revenue, people you passed on in the interview process suddenly appear next to you and you're required to mentor them, projects that seem dumb get assigned to you from on high without your input, compute resources appear or disappear from under your control, etc.
It's like death by a thousand cuts. And in my experience, the only way to actually get paid on this track over the long term is to create something so valuable that you are the single point of failure.
At least for programming, the only real 'Individual Contributor' career track that makes any sense to consider is one where you're a lead developer, that is you still code, but you manage a team of other people as well.
I've seen multiple ICs with more power than their direct manager. They are basically immune to being fired because higher-level leaders understand their value and respect their track record.
Unless there is some power of the purse-strings, the two-tracks thing is always going to be biased in favor of the managers.
In the world of early and middle stage startups, you're probably right. However, in massive tech companies or more legacy-type tech companies, it seems like you're a lot more likely to find managers who are trained as managers and not engineers (MBAs, etc.)
Many specialists don't get this opportunity and require certain character traits to go out of their way to make it known. If they maintain a key product but don't need to interface with group of people often, then they get ignored for "employee of the month" and other accolades that would translate into more clout
The first few days, I stayed until a couple minutes after he left, to let him know I supported him. Then one day, I walked out with him. He looked at me and said, "but you got in at 10." I looked right back at him and said, "I know. I stayed late the last few days in case you needed me." Then it was back to old habits.
He was going to need all the help he could get to manage the political situation. In the end he couldn't cut the knot, he left not long after I did.
Any ideas he had were welcomed but at the end of the day, they were going to throw it all out anyway. I was hoping they'd let me build the new platform, but they picked a consulting company to build them a Magento solution. To recognize my efforts, I got like a year and a half of half-salary to get on the phone if they ever needed me.
My next role paid 33% more.
Sometimes. I've seen orgs where middle management was not allowed to delegate enough, either by culture or by tools. The net effect was a schedule full of catch-ups and backlogs full sign-offs without much actual input into what they spent their days doing or thinking about.
Good engineers are always hard to hire, bring up to speed, and retain. Especially ones who want to deal holistically with the existing team and system instead of narrowing in on certain approaches.
It almost like you telling incident happen in my team last month where a guy was hired exactly in similar fashion. Now I am supposed to mentor him.
The best thing you can do, if you find yourself replacing whole teams of people due to your experience , is to start your own company or be the CTO of a company.
That sucks though, it's high risk, low reward. The safer bet is to just be a manager.
In which case you’d be a manager. There’s no getting around the value multiplier of making other people more valuable. Even traders and movie stars have a ceiling as compared to the people that run hedge funds and movie studios.
I work at an organization like square. My manager could probably fire me. Not today, but should he desire he could manage me out, at least of his team. I have the autonomy to move elsewhere.
But I am working with ICs right now who have more organizational I influence than my manager. Certainly he decides the priorities for his direct reports, but these ICs influence the priorities for our organizing as a whole, much more strongly than my manager does. And he certainly can't fire them.
So sure, my manager is senior to me, but that's because he's senior to me. There are equally, and more, senior ICs in our org who he has to defer to in practice.
I strongly believe in technical tracks and I've seen them work. Every place I've worked had technical positions that are peers to managers, at every level. They worked alongside managers, and did not report to them.
Progression on both managerial and technical tracks requires skills in leadership. Whether that is people leadership or effective technical leadership, the principal's are the same. You need effective communication, clear articulation of ideas and an ability to influence and lead.
If you focus solely on your technical skill and implementation ability, then it is going to get harder and harder to progress. At a certain point an exceedingly skilled individual starts adding less value to the team they are in, unless they can demonstrate real leadership.
Next question is - is manager the only logical progression for a dev at some point?
But that keep in mind you don’t have to keep progressing your career. There are risks to not doing so, but also rewards.
Since you mention "Outside of the top of the IC ladders at the giant tech companies" which is about $600k or thereabouts, I am guessing this means they are billing for about $500/hr-$600/hr? So a week's rate is roughly $20k+. What kind of place is paying software engineer contractors that much?
But there’s also the more classic knows-where-to-put-the-screw consultant. Something is broken and bleeding money and after being jerked around by underlings for a few weeks some director is desperate to fix it.
There’s are many many companies out there that can be losing tens of thousands of dollars a day or more because something isn’t working.
The bottom line is some folks in the company do have firing authority -- or at least have broad say in initiating the process to have someone fired. Rarely are these folks not on the management track or its equivalent.
But see that I am talking about "last word"; if a Team Leader and a Tech Leader disagree in a decision to fire someone. If both of them agrees, it doesn't scale up
But a large part of me tells me this would just make things worse. The only people who would opt to transfer to the manager track would be those who are really career politicians, who can take credit for every success but blame every failure convincingly on someone else. Ideally with management thinking all the time that this guy is a loyal contributor and not a politician. This is what seems to happen in practice.
So what can you do? Hire only people who are strong engineers and who don't have any ambitions to management? Hire excellent engineers and mediocre management? This last seems to be the approach of many tech companies. Frustrating though it is for the engineers, this explains one reason companies may go for this approach.
Agreed. You'd end up with more of the folks who just want power for power's sake, instead of growth/validation.
Anyone wonder why IC starts at level 3 but managers start at level 5? It's not because they're separate but equal.
The more senior you get and the higher your compensation gets, the greater the expectation is that you accelerate the work of others around you.
Historically, this has been easiest to do through management. If I make a team of 10 each 10% more effective, then I've effectively doubled my (individual) output.
Software engineering is different than most traditional roles. It offers other ways to accelerate the velocity of others; ways that don't require being a manager.
This is why compensation can be decoupled from management in these roles and why parallel tracks can truly exist in this role.
But the tracks remain parallel only as long as you're continually scaling your output. This takes effort and discipline. It happens more automatically through management promotion (though not for managers that never get promoted to lead larger teams).
"History reports that the men who can manage men manage the men who can manage only things, and the men who can manage money manage all."
In my experience, a management role has typically come with 10-20% more compensation versus a comparable individual contributor role, but 100% more responsibility and accountability. I wouldn't worry too much about parity between the two tracks, focus on what you truly enjoy doing. Besides, the money guys can fire us all ;-)
[1] https://www.amazon.com/Lessons-History-Will-Durant/dp/143914...
As a Junior Power Ranger, I had three terrific jobs. Work hard, do well, get rewarded. Good experiences that completely screwed me for the shark infested waters of corporate america.
I wish I had read The Prince earlier.
It’s not true that manager know your salary, nor that they can fire you. Managers there controlled projects and investments but almost no one knew salary unless you were HR. Raises and bonuses were always in percentages and only your local mega partner who didn’t actually manage you knew real numbers.
Profitability was based on averages and bands to discourage minmaxing profitability on projects as that was detrimental to delivery and to clients. Markup and overhead was so high it was pretty difficult to be unprofitable.
So maybe in some orgs there’s strict boss type ladders. But there are many orgs where parallel is real.
Maybe it just feels good but there's something that feels right about your manager working for you, getting you the resources, answers, and commitments from others that you need. And in return they get to boast all the cool shit you make to their boss.
On the other hand, I've worked hard to get IC's on my teams promoted up and out of my team because good directors rely on their Sr. Staff/Prinicpal engineers so there's room for them to grow (even if it's difficult).
the good ones will soon become managers of managers, and then managers of managers of managers.
If you are at level N in a company and (capable of) operating at level N+1, then your choices are to wait and hope that is recognised by your completely fair, impartial managers and you get promoted, or interview elsewhere and take your career path into your own hands. The second option is more reliable and likely to result in higher comp too!
The only true way to get to know your worth is to test the market. It’s a supply and demand game. Most raises I’ve got is by switching companies. Most companies usually overpay their newer hires and underpay their older hires. Why should they pay more if they’re not asking for it ?
Managers will always get paid more as you move up. They make bigger decisions and have bigger impact. Their impact is their management tree’s summation.
As an IC you plateau out. You either start your own thing or work in more lucrative industries.
Promotions never land on your feet, you gotta fight for them.
Is this just plainly not true. But the reason you may be led to believe that is simply a matter of inefficiencies. If a company loses a senior team member, they’ll need to replace them with one of equivalent competency. Putting aside the fact that recruiting and on boarding costs quite a lot of money, there’s a few basic economic reasons why they may have lost that team member to begin with.
1. They hadn’t adequately assessed the competency of that team member, and that person was able to find a better paying job elsewhere.
2. The company might not hire people for that position very often. If they don’t know how much money it takes to secure a candidate of that caliber, then they might not know they’re not paying them adequately.
Both of those scenarios involve employers not understanding the market properly, and if that results in them losing skilled staff, then that is very costly for them. So there’s a very clear incentive for companies to invest in retaining staff. However the truth is that the world is full of poorly run companies, this is a problem that’s actually quite hard to get right, and there’s a very slow feedback loop when it comes to measuring how good you’re doing at it. For those reasons, that’s why it’s often better for people to seek new opportunities rather than seeking raises or promotions, because that’s the best way to make sure you’re getting a fair market rate, and will allow you to bypass any inefficiencies in the way your current employer may be doing things.
There’s also another possibility, where the people on the payroll are simply developing their skills faster than the company can provider more advanced opportunities for them. In this case the employer doesn’t need to replace you with somebody of equal competency, they just need to find a replacement for a role that you outgrew.
There is one thing that bothers me here though.
> Promotions don’t unlock new responsibilities; the new responsibilities and increased scope come first and then we recognize it with a promotion.
To some extent I agree with this. The part where I don't agree with this principle is that it's essentially saying "do the job of position XYZ, and after you prove to us that you can do it, we will recognize and pay you for it."
If people are taking on additional responsibility and having a bigger impact, pay them for it. Maybe Square does, but normally comp+promotion go together and so I'd be interested to hear evidence to the contrary. If someone has been operating at a level for 6 months, then why not retropay them for 6 months at their new salary? :)
But:
> If someone has been operating at a level for 6 months, then why not retropay them for 6 months at their new salary? :)
The answer is: because they can.
The best way to handle this situation (for the employee) is to just sidestep the problem and offer the increased salary and promotion upfront with the new responsibility. There is the additional benefit of internal visibility - if somebody is taking on extra responsibility, it is able to be communicated to the whole team, dodging the common issue that engineers face of not knowing who in their organization they should go to for help/mentorship.
In this context, I view responsibility as more of a level of operating rather than just "more work". For instance, I'd be very happy to mentor a more junior employee it's not something I'd expect a promotion for.
That's obviously very different than if my on call hours were doubled. Doing twice as much work at my current level is different than doing my work at a higher level (which I almost always want to do).
I'd much rather get called junior while doing senior level work than get called senior while doing junior level work.
Not only does this serve to underpay people ready for promotion, but it makes it harder for them to move elsewhere. If they're working at level X but have the title/pay of level X-1, then they'll have a much easier time finding a job at X-1, which effectively resets the promotion clock.
I think a better bet for spending your extra energy is often a side-hustle, like contracting.
We handle this a different way - when someone is promoted, they are given a chart of new responsibilities, expectation timeline and a small raise. Once they completely train into the role, which can be anywhere from 3 weeks to 3 months, we give a larger raise. Again this is because we cannot actually afford to pay for work not being done. It seems people like the acknowledgement, clear expectations and reward when they’ve made the cut.
Bonus and refreshed RSU's does the same, isn't it?
It has some interesting tradeoffs vs promote on a trial basis and then demote. Whether it's a good idea probably depends on how well the responsibilities and evaluation process are laid out (in that company's case, not so well).
An engineer who stays an engineer will want to increase in skills and experience and be recognised as such through increased pay
An engineer who wants to get the top jobs in management will want promotion because there are scarcer fewer positions as you go up the ladder - they are deferring their pay for a hope of massive tournament winning payouts.They would be well advised to avoid having direct responsibility for greater control (ie approving the change is ok, changing the feature flag yourself bad)
An engineer who wants to stop being an engineer and mentor others (and fight the idiosyncrasies of the organisation) will want promotion with the added responsibility
If your pay and promotion strategy is not aligned with these then problems will result
I think a big part of the problem is the difficult position managers are in when they consider promoting somebody. I've never seen anybody get demoted, even after failing to meet the expectations of a new role. They're either left in their role indefinitely, moved to a less important project, or fired. As a manager there's a lot riding on promoting somebody if my only corrective option is to give them up, especially since they're likely good in their current capacity if I'm considering promoting them. If I want to be absolutely sure, my least risky option is to have them do the work for a fraction of the pay to prove that they can do it. This also helps prove to their peers how capable they are so I'll face less backlash from people who would otherwise argue that they deserved the promotion.
If demotion was common practice it would guarantee indefinite accountability and increase managers' risk tolerance when considering whether or not they want to promote somebody. Realistically I think employees would leave in droves if a company started implementing this over night, but it does seem odd that such a potentially useful course of action isn't even on the table.
The downside is that it really relies on EMs to work hard to make sure that ICs have clear, measurable plans to advance. At Synacor, there's a standard format for how these plans work, and all plans get review from senior managers, so it works fairly well, but a vague plan or one filled with details that are easily overcome by market changes will usually fail and the individual will not be promoted. It can also be challenging because, at higher levels, the plans often include improvement in multiple areas -- say, improving development skills, but also taking on more mentoring. If the developer learns and applies new skills well, but is having a hard time with mentoring, that will delay the promotion, which can leave a frustrated dev whose promotion is delayed.
It does essentially eliminate the Peter Principle, however -- people who are about to get promoted beyond their abilities will discover that before their promotion, and they'll stay in a happy spot.
Google's system worked like that. What they don't mention is that there is a pay range for the various promotion levels, and if you're on your way towards a promotion, you're also on your way to the top of the pay for your current level.
So you are not really sacrificing a ton of pay to be "almost" ready to be promoted. (But the top range of the next level is always pretty incomprehensible to someone at their current level.)
I think it all mostly boils down to skilled versus unskilled managers and internal career planning. If a manager is promoting people who aren't able to execute on the new role more often than not, then they are bad at recognizing when people are ready for more responsibility, and they should work to improve that skill while also working to plan things better with their reports and set expectations. To me this doesn't say that there's a fundamental problem with the system that needs to be alleviated through process change.
And on the flip side a skilled manager would be better able to keep everyone on task in their current role even while they are planning/demonstrating for the next role, if you're doing the "no peters" thing.
Our dev lead, hired months after me, has been promoted to CTO and even our sole graphic designer, hired many months after me, went from "Graphic Designer" to "Lead Graphic Designer."
So the takeaway here is classic: As an employee you are seen as a cost, and your boss will gladly let you take on the responsibilities of "Lead XYZ" and pay you as "Junior XYZ" if you let them. I unfortunately let them, so I'll cut my losses and chalk it up to things I learned in my early 20s. Could be worse.
If you are backfilling a role though then it can be annoying to not be paid up front even in a probationary period. The crappy part is having to do two jobs but the trick is to start delegating your IC work. So the old saying is that a good QA engineer automated their work away. A good manager manages their work away. Debating works only so far though without authority so you have to develop authenticity and street cred.. or enlist a few interns.
But primarily,
"We promote engineers and managers when they have demonstrated that they are consistently performing at the next level. Promotions don’t unlock new responsibilities; the new responsibilities and increased scope come first and then we recognize it with a promotion."
Every discussion I had with my manager, my promotion was six months away, despite IC contributions exceeding the sum total of the rest of my team when measured per-project via our number one KPI: annualized cost savings (larger org was seen as a cost center).
Unfortunately these "principles" are becoming harder and harder to avoid.
If you get promoted to Senior level, the assumption is that you're getting paid what a senior should be. If then, you take on additional responsibility above and beyond what a Senior is doing, you get merit increases up to some higher point. That is, a Senior who is getting 5/5 performance ratings probably makes more than a Senior with a 3/5. Eventually, that 5/5 person might get promoted (I say might because an exceptional Senior might not make a great Staff engineer. Someone really good at implementing things quickly, but with terrible design sense won't make it to Senior in a lot of orgs, for example, even though they might be a very strongly performing Engineer) to the next level, at which point the process starts again.
But I'm sharp, and I focus on getting sharper every single day. I don't have 'pre-' conversations about what could potentially happen, I simply solve the problems the organization has. If the company recognizes it great, if not you'll look around one day a few months after I leave and lament, "man things were so much better when we had Vince around."
If we wanted this much structure, we would have worked for the government or military.
These seems like a somewhat immoral way to squeeze extra productivity out of your workers without paying more. "Just keep piling extra work onto your plate and in six months we'll talk about the possibility of a promotion! It's gonna be great!"
Eh, at least in my case the offer they extended me was shit (speaking from my privileged and fortunate position). Combined with that promotion process it was easy to reject (and a month later I got an offer elsewhere for one level and $75k/year more).
If doing the job above you for 6-10 months to maybe get 10-15% is more your speed, then find a company you wanna stick with for a while.
I’ve done both. Jumped until I reached a comp level I’m content with and now playing the promo game expecting minimal reward increase for my labor but enjoying the stability.
As a senior engineer with a good job who has been in this industry for a while, here's what really matters for me when I look at new jobs:
- Does your company allow WFH schedules to everyone? There's debate about full remote vs full onsite, I'm not talking about that. I'm just talking about working within driving distance, but having a 3-2 or 4-1 weekly schedule of onsite vs WFH. There's really no excuse to not offer this at this point in communication technology. Some excuse like "more collaboration" doesn't apply if everyone is still going to the office regularly. And this has to be allowed for everyone, not just special exceptions for a few. It must be a culture where everyone is WFH regularly.
- Will I have to write code on a whiteboard? If yes, then goodbye. Even a chromebook with a html page that has nothing but a <textarea> element is better than a whiteboard for writing code. Will I have to study leetcode for weeks to pass your interviews? Then also goodbye, I don't have time for that and it's a stupid way to do interviews. A fizz buzz type question to just see if someone can write any code, that's ok. Leetcode stuff is not ok. Take-home test? It better be really short or also goodbye.
- Compensation, it's actually ok if you're not at FANG level, few companies can be. The other things like offering regular WFH schedules are very valuable and this is how non-FANG companies should compete. But it needs to be still a reasonable amount of compensation. Guidelines are really difficult here due to so many factors such as cost of living. But I know a bad offer when I see one so don't try to trick me.
- Well defined on-call process that doesn't burn out engineers.
- Minimum of 4 weeks vacation. If it's less to start, you better have a schedule that increases that quickly (not some 1 week for every 5 years bullshit). And if you're doing no vacation (AKA "unlimited vacation"), you better have something really convincing that shows people do take long vacations in your office. Like an official policy to encourage this.
I don't care about free lunch, video game consoles in the office, all that silicon valley "perks". Tell me about the stuff that really matters.
Reflecting back though, I think much of this has to be determined by the manager who looks at these things. I've been fortunate to have good circumstances with a very understanding boss who seems to be content with whatever time off is needed as long as things are moving forward. I worry many others won't have the same luck.
Now I understand the real purpose of Raytheon's policy of letting people roll over all of their vacation time, but docking next year-s allocation if the total is more than 40 hours.
There are bound to be employees who want 3 months vacation and will get fired for taking it.
* Both candidate and interviewer enter the room.
* A small script randomly pulls a leetcode easy question from the website.
* They both spend the next hour together working on a solution.
I can already hear the objections from leetcode fanatics, things like I have to know the answer already so I can "calibrate" (basically see how fast they can regurgitate the rote memorized solution). A bullshit reason, so an engineer who solves something 1 minute faster than another is better? Or I need to always use the same question so I can compare candidates. Another bullshit reason, I thought it was about seeing how they reason about a problem, why do you need the same question for that? Whatever question you get, it should be clear if they're good at reasoning or not.
The truth is, it's just a hazing ritual by insecure engineers who want to be the one with the one true answer they can use to feel better than the candidate. That's all it is and that's why I ignore companies with this kind of process.
> The truth is, it's just a hazing ritual by insecure engineers who want to be the one with the one true answer they can use to feel better than the candidate.
It is not, I believe they are useful and have seen data showing that they are useful. The question I use was first used on me and I solved it completely in 20 minutes. I haven't had a single candidate solve it in 45 minutes, and I give them huge amounts of help.
I give hire recommendation to those who makes a good attempt and doesn't start bullshitting. Lots of people starts spouting bullshit when they get questions they can't answer for some reason, I guess this kind is what you get if you use publicly available questions.
Honestly it sounds like you're proving GP poster's point here: these interview questions are administered by engineers who want to feel better than the candidate.
An failed interview is awkward, and then I have to turn around and write clear and explicit feedback about exactly why someone shouldn't get hired. It's probably my least favorite job responsibility.
But at least with calibrated questions, I can be fair and impartial and know how much help the candidate needed. Throw me into a room with a question I don't know, and the same general complaints apply, but now I have to figure it out as we go too, so my focus isn't on feedback and helping, but on understanding the problem.
We don’t do referral bonuses, FYI. So I’m not chasing cash by reaching out. It’s just a legitimately good place to work.
This while very common has always seemed... a little off to me, and also seems to encourage people not sticking around if they feel like they could do well at the next level, but maybe have some inconsistencies or areas of learning to work on. This leads to an awkward situation especially as thinking starts to become more "meta" as you go to a higher level. At what point is it okay to start touching code less and doing more design and organization-level work, when your current level is more about individual production and output? It can make a top performer trying to get to the next level look like their output has gone down, because the measures to those outputs look differently at different levels.
Additionally, if someone's making that big impact, you're saying they have to wait a year. If they can prove that impact, they can go somewhere else and get that pay bump /now/. Don't make it easier for someone to leave than to stay, especially if they're on a promotion track.
Is this meant for engineers who don't work at Square, for the purpose of recruiting? Or for engineers who already work at Square, for the purpose of justification, i.e. an internal newsletter?
The headline matches the former, but the content seems bent towards the latter.
For one, the overly-long preamble reads like a page in a corporate handbook, laced with insecurity.
> Our levels don’t line up perfectly with those of other companies ... You likely can’t accurately compare level numbers or titles directly between companies, even with tools that provide mappings between companies.
Similarly, most of the "principles" presented are either common-place:
> Levels build on each other: Each level implicitly includes all criteria and responsibilities of prior levels.
Or deceptive:
> Promotions don’t unlock new responsibilities; the new responsibilities and increased scope come first and then we recognize it with a promotion.
Or are a lot of nice-sounding words, too incoherent to disagree with.
As someone who's had to suffer through career frameworks championed by company-lifers straight from college, I don't think this article won’t quite attract the best and brightest.
The bit on promotions is fairly commonplace and sound, about the only real solution I've seen to the Peter Principle.
This doesn't strike me as a particularly exciting document but it doesn't seem terrible either. I like that there are a variety of ways companies handle this sort of thing, and that companies are being more open about it. It really helps potential employees sort out where they want to be.
As others commented on the falsehood inherent to "Two Tracks / Becoming a manager is not a promotion", a blurred transparency tends to be more deceiving than an obvious opacity. Or rather, being bull-shitted can be worse than being told nothing at all.
Most companies follow this model now. You should already be performing at the level to deserve a promotion which sounds reasonable but not very much in practice. People will look for a job elsewhere if they get frustrated.
Companies may claim this but it can't really be true in practice, otherwise it would be impossible to level incoming candidates
There are other reasons why leveling can be important - the expectations of the candidate around title and comp, for instance.
This is why sites like levels.fyi exist. They are surely not perfect and I don't know much about how the data is collected or verified, but it's a question that people want answered.
If I have performed above expectations in an engineering role for 5 years, do not have a bachelor’s degree, and I am judged against it, it is not a company I would be working for.
Most companies acknowledge this and allow the substitution of a 'relevant Bachelor’s degree' by experience.
I work for Square, we just hired a self-taught engineer on our team. There's no concrete degree requirement. :)
But... I see a lot of companies hiring at the senior end of the management track (Directors, VPs, etc.) and not so much on the non-management side (usually tops out a senior engineer).
I think that if companies are serious about non-managerial tracks, they need to hire for such roles more seriously.
As you'll see, lots of companies reinvent the wheel with this stuff. It feels fundamentally misaligned to me while these rubrics are solely owned by each employer – personally, I care about my growth across a career, not just a single job.
If this was measurable and transferrable in the same way as – say – learning a language (e.g, I can take my Go experience somewhere else) it would be far more compelling to me as an employee.
The question is: how many companies are willing to 'share' levels and expectations to facilitate this?
Please work for the government if you crave this much structure.
I think they make a lot of sense.
One question .. has anyone planned out how Staff Developers work within most organizations? I feel the Venn diagram for them between an engineering manager has plenty of overlap, where the people aspect (all things HR, hiring, growth) are on the engineering/people manager.
Can a Staff Developer make decisions? Or are they more of an influencer?
I also find Title misleading, Ladder is not a framework - it is a way to retain talent. And I find it to be quite silly (as an eng who held highest level position at famous eng company) way. Working in a title-less org now and it is much better as we can concentrate on the mission and not the the freaking ladder
What does the IC have responsibility and authority over? Do they absolutely get to make certain technical choices? How? Which ones? What happens when the right technical decision has impact on how budget and employees are allocated?
Not sure who the quote is from, but something like "instead of climbing the corporate ladder, why not own the ladder?"
L6 IC and L5 EM seem more comparable.
For those interested, the company is Pariveda Solutions.
Would be interesting to hear more about calibration work, how they are defining output parity across the engineering disciplines/business units/products/teams.
Someone else already asked, but who was this written for other than the people who wrote it?