Hacker News new | past | comments | ask | show | jobs | submit login
Square’s Growth Framework for Engineers and Engineering Managers (squareup.com)
486 points by girlwhocodes 22 days ago | hide | past | web | favorite | 239 comments



> Two Tracks / Becoming a manager is not a promotion

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".


I think a lot of responses to you are missing the point. Managers have more autonomy and more control.

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.


An IC can definitely have and maintain more control than managers, they just need to produce visible value to the company.

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.


Were those higher-level leaders managers? I mean I agree with your exact statement, but in my direct experience, the higher-level leaders tend to be less and less engineers.

Unless there is some power of the purse-strings, the two-tracks thing is always going to be biased in favor of the managers.


That's the beauty of working in a tech company compared to a non-tech company. Every single manager in my org is a former engineer. Every single manager above them is a former engineer. Heavy majority of directors in the org are former engineers.


That's not necessarily a good thing. Sometimes ex-engineer managers are the worst kind of manager due to their own misconceptions or arrogance.


I feel like that's really gonna depend on what part of the tech sector you're working in.

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.)


I agree with you in general. However, my specific experience with this comes from working at one of those massive tech companies. And there are definitely orgs within the company that fall under the "MBA-types-running-the-show" umbrella, but, I think, I just got very lucky with my org.


Yeah, the experience probably varies a ton across the industry and even within orgs. I'm sure most people around here who've been in tech for a while can tell stories about both types of company.


Same here. Not only are they immune to being fired, they can more or less switch teams whenever they want.


> they just need to produce visible value to the company

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


I think they tend to be anomalies. Mostly ICs don’t have as much power/authority/autonomy as people in managerial positions.


At my last company, I went through three managers in the 3 years I was there. The last guy in there, I was comfortable enough in my position to make a statement. At the time, I was getting into the office around 10 and leaving at 3 or 4, basically whenever I felt like it.

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.


Something about this comment really unsettles me. I can’t tell if it’s thinking that what was a “statement”, if it’s the underlying attempt at some lame kind of power play on a new member of your team or if it’s something else entirely.


What I'm reading in it is that the poster is a lot more comfortable in their position than the manager, knowing the manager is under a lot more stress and pressure than the poster themselves. After you've seen a few managers start and leave you kinda get the picture.


More or less. It wasn't intended to be malicious. I made it known I was there to support him in his Herculean task of moving the needle with his department with this wholly intransigent political environment. But I'd already spent some 2 1/2 years building up goodwill and clout in the company and there wasn't going to be any bowing and scraping.

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.


Until the company is bought.


The brutal reality is that a single individual contributor cannot, and should not, contribute as much value as a team of people.

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.


I think the difference is between organizations like square, and those that aren't.

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.


> people you passed on in the interview process suddenly appear next to you and you're required to mentor them,

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.


Yeah. These are all things that happened to me as an IC over the last 13 years. I'm jaded.

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.


> to start your own company or be the CTO of a company.

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.


> Managers have more autonomy and more control.

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.


I'm guessing that working as an engineer at one of these orgs would have been far worse. (Unless it's one of those rare cases where management's so tied up in its own bureaucracy that the tech team gets to run itself.)


I've seen it go both ways. Being able to change teams or projects without a lot of drama seems to help a lot.

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.


Show me how long an engineering manager can live within an organization that where their senior ICs don’t support them. It’s basically zero. Yeah you can fire the senior ICs who won’t take your word as gospel but that’s not exactly a great strategy. You as an EM need to rely on your senior ICs to do both of your jobs. It’s a team sport. And yeah if your EM kicks you to the curb for no reason, no doubt, they’re next.


OK, they can fire me. There are other coding jobs. They move up the chain and have to sit in meetings taking on greater responsibilities while I sit back and code for years, increasing in position and compensation without really having to be more accountable for the success or failure of the business. They probably make more than me, but I just shut down at the end of the day and run around with my kids.

There are far more ways to measure success in life than your paycheck or where you fall in an org chart.


I agree completely. If that's the choice you made in life and it makes you happy and fulfilled, I'm genuinely happy for you. But you can only make that choice if you walk into the situation with your eyes open. I don't like being bullshitted.


Upvoting this. Being a well-paid individual contributor who can work a ~40 hour week is amazing. I was a manager in another industry before I learned to code and I'm grateful I don't have to do it anymore. Having to put under-performers on a plan, being on the hook for work not done during a staffing shortage, trying to keep people happy when there aren't any raises or promotions to offer... if some other engineer wants to take that stuff on and get paid more for it, more power to them!


Your pay as an IC will plateau. It may plateau at a nice comfortable level but plateau it will. It’s a log curve not an exp curve. Younger professionals in the first 5-10 or so years of their careers are just seeing the extreme left of the log curve, where it’s steep, and conclude they’ll get 50% raises forever. Trust me, you won’t.

Management comp paths tend to be more linear.


they’ll get 50% raises forever

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.


> Now Google is looking to do the same sort of thing

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.


The maximum upside of the management track is definitely higher but the chances of achieving it are far lower. If your span of control is 8, that means only 1 in 8 of your managers will become a manager of managers and 1 in 8 of those will become a director and so on. Unless you're in a hypergrowth environment, the other 87.5% will struggle to move past the first management rung for a significant chunk of their career.


It also means less job security should one find oneself out of a job for whatever reason. A company needs about 1 manager per 8-10 ICs, and 1 second level manager per 8-10 team managers. Logically, that means there should be about 10% as many first level manager positions as IC positions, and about 1% as many second level positions as IC positions.


“Your pay as an IC will plateau.”

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.


“Force multiplication” is an intangible. If your salary depends on it, you’re depending on someone in management noticing that you’re “multiplying the force”, and that you’re willing to leave. It happens, but it’s rare, and usually occurs when people are great negotiators, or such an OG with the founding team that they’re like part of the corporate logo.

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.


“Force multiplication” is an intangible. If your salary depends on it, you’re depending on someone in management noticing that you’re “multiplying the force”, and that you’re willing to leave.

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.


>>> 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


The point to take away here was measurable influence.

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


Jeff Dean is also a manager at this point. There were historically two though, Jeff and Sanjay, and Jeff's former role is free.


The “former role is free”? Google is huge and has thousands of managers, so it’s only “free” in the sense that they’re hiring some managers. There’s still only one Jeff Dean.


I think you misunderstood.

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.


Ah, indeed. I took your comment to mean the opposite. Mea culpa.


Salaries plateau on both tracks until you get up to the very high levels. RSUs are really the only way to get compensation that keeps growing.


But in the management paths there is a lot more getting locked at a position.


Completely concur with this. After 10+ years in engineering management, rising through the ranks, I'm at a stage where I don't want to solve people problems anymore. I want to get back to coding or solve problems as an IC. Most companies will need only a handful of VPs, Directors and Managers but almost all companies will need software engineers. As a manager, one has to sacrifice becoming technical and competitive in the market or be the best in their field. Even if they are a really good manager, different companies have different expectations of their managers. Google might want pure people managers whereas LinkedIn might want managers that write code 60% of the code. It's just not worth it though some perks are really nice.


Yeah. My boss is a half-coder, half-manager. He can fire me. He gets paid more than me. On the other hand, I don't take my laptop with me on vacation. He feels that he has to. I never feel that.


Will Durant puts this very succinctly in "Lessons of History" [1]:

"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...


This being hacker news, the best way to capture your value is to go create something and sell it directly to the market.


Entering a market isn't for the faint-hearted. I got interested in buying turn-key online businesses last week. This way someone else gets to bear the risk of bringing a product to market and you can just focus on cashing checks and helping it grow.


The last time I had a supervisor that wielded actual responsibility and accountability was 1992. aka A Good Boss. Every one else just failed upwards or was cannon fodder for those who could (fail upwards).

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.


Career and compensation growth is a function of scaling your output.

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).


This 100%. Having been both engineer and manager, I have to say it is much harder for engineers get promoted beyond the senior level, so pay is going to be higher over time for managers.


At first I thought the solution is that it needs to be a step down: becoming a manager entails taking a cut in pay, a lower nominal role, an increased vulnerability if the team needs to be cut. Make people pay a cost in order to switch to this role.

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.


In most companies becoming an entry-level manager IS a step-down from staff engineer or equivalent in terms of compensation.


There might actually be 0 people who go from staff engineer to entry level manager in most companies. They go from engineer or maybe senior engineer.


> But a large part of me tells me this would just make things worse

Agreed. You'd end up with more of the folks who just want power for power's sake, instead of growth/validation.


I have no real ambition to management, but, at 5 years in, I’m considering it as a way to keep my salary growth going.


Managers have a lot less power in decisions like firing and compensation than you might think. Note that by "manager" I don't mean the entire management unit. Of course executives & directors have influence, but at a standard software company a staff+ engineer will 100% have more "power" than a regular manager (and will be paid a lot more as well).


I know my team manager can’t unilaterally fire me unless I fuck up in a truly egregious way. But, if I don’t keep him happy, word will get to the people who can start the ball rolling to fire me, and then I’m in deep shit.


An interesting situation is when you become known as so invaluable by higher levels of management that this dynamic gets inverted.

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.


Some organizations actually consider that arrangement an important part of their work culture:

https://en.wikipedia.org/wiki/Servant_leadership

https://planet-lean.com/spotify-agile-leadership-lean/


Is it possible you are conflating positional power with earning power? Your earning power is not limited by staying on the IC track in this setup. Positional power is always dependent on where you are in the organization and what your actual job in the organization happens to be.


That’s not true either. Who’s the highest compensated person at Square? Is he a manager or an IC?

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?


If a company claims to have “parallel and equal tracks” ask them how many VP equivalent individual contributors they have and how many manager VPs they have. Ask then what the CEO-equivalent individual contributor role entails.


This gets pretty tricky at some point, because there are a lot of hybrid people. The "standard" image of a VP is someone who has multiple directors reporting to them, and probably 50+ (really 100+) indirect reports. So what about a VP-equivalent with 5 direct reports who are all ICs? That person isn't an IC, but they're also not really a people manager, they're like a really high impact TLM. Do they count more as the first, or the second?


If you exclude the CEO at many SV companies there are most certainly ICs who make as much as people at that level all over the Bay. Certainly that’s true at Square.


More like CEO, all other Cs, SVPs and VPs, then yeah! Basically principal tops out at sr director MAYBE


That’s probably true, but there are a lot less highly paid ICs at the top than there are highly paid managers. So yes, you _can_ make the same, but your odds are a lot worse.


I don’t disagree with the imbalance or odds. Impact required to be that highly paid an IC usually boils down to “create the thing the company earns a large portion of its revenue selling” which is tough to do, especially more than once.


I’m not sure I understand what you’re saying. Okay exclude the CEO (why though?), are you saying the second highest compensated person at Square is an IC?


Yes. The second highest paid person at Square is likely an IC. There are a number of year zero ICs there still that aren’t reporting to Jack.

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.


> That’s not true either. Who’s the highest compensated person at Square? Is he a manager or an IC?

> 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.


That’s true, probably slightly less likely to be fired than a middle manager, though your salary is going to be a juicy target. But if you do it’s a lot less scary interviewing while middle aged for manager roles than it is for IC roles.

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.


This was a major motivator for me going into management. I don't necessarily like the role more, and overall there are fewer jobs for engineering managers than there are for engineers. Yet as I get older (and I'm not that old either) I feel I have much more long-term job security and stability in being a manager.


People like Vint Cerf are pretty old and been through lots of ups and downs.


I mean.. he’s largely at the executive level and co-invented tcp/ip. He is foundational in the development of the Internet so he sort of is an outlier.


Sort of? An internet god, really. We can't all be Vint Cerf's.


Just look at the top paid 10% of any of these engineering organizations and you will find far more managers/directors than individual contributors.


> 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 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.


Take a look at most companies, and compare the quantities of director/VP equivalent engineers to the number of engineering directors and VPs. In my experience, there are many many more of the latter, if only because orgs want to build out the org chart and so there's a natural place and need for those roles, and because there are basically default title bumps that come with the increased responsibility.


Sure. But that's not relevant to the argument being had. Growth beyond a certain point in management being easier, while perhaps true, isn't the same thing as claiming that swapping from IC to management is, alone, a promotion.


the original comment said "you'll watch them rise further and futher in the company hierarchy while you're enjoying your "parallel track"", and the comment i replied to disagreed.

the question was about "parallel track", and i don't see how you can conclude that they're parallel: it seems to me that the IC path is circuitous and takes a lot longer to get anywhere on.

put another way: imagine that you had no preference over the work, were equally good as both IC and manager, and wanted to optimize for career progression. you would _always_ prefer management. and in fact even if you'd make a better IC than a manager, to a large extent you'd still profit more in management.

i agree that it isn't necessarily a promotion to move from IC to manager. but it also _isn't_ a parallel track: by moving, you've moved to a track which is much more direct.


This is my experience as a staff dev in an org with this type of org chart. Staff devs are considered lead engineers with no reports and sit in most of the lead meetings.


Or even around decision making which is a large part of engineering.

If I ignore or undermine the choices made by manager I will be fired. But vice versa is not true.


Point taken. I haven't thought about managers that way, but you are absolutely correct - tracks can not be parallel by definition.

Next question is - is manager the only logical progression for a dev at some point?


Build a product, cover your salary. It's not easy, but it's doable. I've done it.


There is an option to go into consulting. Outside of the top of the IC ladders at the giant tech companies, they are the highest paid ICs around.

But that keep in mind you don’t have to keep progressing your career. There are risks to not doing so, but also rewards.


I always hear about these people but I never hear about the profile of the places that hire these people to do consulting.

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?


Some ICs at top tech companies get paid much, much more than $600k.


If you think you have a reasonable chance to become a Google Fellow or equivalent, then by all means ignore everything I’m saying here.


600k is staff level TC, not even close to fellow.


Oh really, I guess I was misinformed. Figured that was closer to 500-600. I hadn’t heard of anything well above $700k or so for positions like “Senior Staff”


Well the other piece is that after senior staff there's distinguished and principal, and then fellow.


There are somewhere around 3.5-4 million software engineers in the US. What percent would you say will make $600k TC or more this year?


I was responding directly to a comment referring to Staff Google engineers. So in response to your goalpost moving question, I guess the percent would be (total number of staff engineers or higher at Google) / (your random estimate of the total engineering population)


I’m sure we are all very impressed by your insider knowledge of the details of a tiny portion of the industry irrelevant to most engineers. For the rest of us Google Fellow or equivalent is a reasonable way to sum up the entire niche.


It's not equivalent, unless you think that getting a job at Google, Facebook, Microsoft, or any other reasonably large west-coast company is a "niche" that's completely out of reach for you. "Staff" is not some unattainable level that only a few people per company are lucky enough to break into.


There’s the patio11 way of doing things which he’s written plenty about.

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.


I wonder how many of these shops exist. And if they're mostly solo operations?


McKinsey and such, I expect.


In my last company it was indeed parallel. A Team Leader couldn't fire a Tech Leader (or have access to meetings that Tech Leaders didn't). They would work in pairs as leaders of a "Tribe". The company shared the average earnings per position, so we could see that the Tech Leaders used to earn more than Team Leaders too.


Many companies have team lead positions that have no formal management authority or responsibilities. Was that perhaps the case here?

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.


In theory the Team Leader could fire the other devs in the tribe (even senior ones, just not the Tech Leader). In practice it appears that the Tech Leader has a lot of influence in firing a dev. In case of disagreement, the last word, I assume, would be from someone higher up (the CTO).


If a C-level executive officer would be involved in a decision to fire a low-level developer, am I right in assuming the company was quite small? As companies get bigger, firing power and other forms of authority cannot stay concentrated only in the executive suite -- it's just not sustainable or scalable.


It had around 500 people, I believe around 90 developers. There was a Engineering Manager too, I believe that would be the final word actually.

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


I spent a lot of time in big4 consulting and it’s got a lot of high bill rate specialists in addition to normal partner people.

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.


My boss does an evaluation of my performance for the purposes of HR, but he doesn’t really manage me and I don’t think he makes more money than me. Our IC roles go all the way up to Director level without having any reports.


> My boss does an evaluation of my performance for the purposes of HR, but he doesn’t really manage me and I don’t think he makes more money than me. Our IC roles go all the way up to Director level without having any reports.

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.


That depends on how you define "manager". In our company, managers serve empowering function and don't have firing powers. They take full responsibility for growth and progress of the people they manage. They can report issues with people they manage to certain parts of the org, but can't solemnly pull the trigger.

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.


> That depends on how you define "manager". In our company, managers serve empowering function and don't have firing powers. They take full responsibility for growth and progress of the people they manage.

Who does have firing powers, and how does one get there without being in the management track?


I worked as a dev manager at a large org and definitely didn't have firing powers. It involved a process with HR, and following a pretty riggid pip-ing process, paperwork, etc, so that there's accountability at all levels.

I'd be curious the size and type of company the OP is talking about where managers get that much power?


I didn't mean to imply that managers can single-handedly fire whomever they want. But empirically good managers can get bad engineers fired, but good engineers can't get bad managers fired nearly as easily (if at all).


The managers werent the ones who flipped the switch with HR to start the firing process and provided the evidence to make the decision?


Not always. Managers sometimes like the people on their teams, and don't want to fire them. That's when someone else notices the team needs shaking up, or overhears conversations that are unsettling, etc. Also step-over meetings, too: that's when a manager's manager (or higher-up) will have a meeting with someone the manager is managing....good orgs have all these types of playbooks.


"Managers sometimes like the people on their teams, and don't want to fire them."

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).


I haven't heard of a modern tech company of any size that allows a team lead / direct manager of ICs to unilaterally fire a report without some decent amount of process and involvement from others.


Currently only the C executives, mostly because we are so small and this is a very solemnly an issues. We have not let go a person for more than 2.5 years. As we grow more, we will change it too, but will try to keep it very friction heavy so our employees are not worried about someone frivolously firing them.


Just wait until you get to 10000 employees. You must delegate at that point. A manager might not fire someone by themselves, but since the involvement of HR is generally limited to executing the decision it might as well be.


I'm aware that we will not be able to retain this policy forever, however not going to change it before it has to.

Also, I'm glad that you believe that we will get to 10k employees. Currently beyond the scope of my own ambition.


The way we implement this, you cannot report to a manager who is the same level as you. A sufficiently senior IC with an entry level manager gets transferred up the org chart upon promotion.


In my experience that leads to the organisation hiring more people at the upper ranks of the management track, and the end result is that management becomes the easier path to promotion and most of your senior staff are managers, not ICs.

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.


   the good ones will soon become managers of managers, and then managers of managers of managers.
Perhaps the most successful managers (sometimes) are the best at pushing their own agendas and making themselves look good, as your comments may imply. I’m sure the Peter principle comes into effect here when that is the case. The best managers in the most functional organizations must align more with your final comment.


Managers have a perverse incentive to use 100 engineers to do something that a team of 20 with adequate support and equipment could do just as well.


I agree with informational advantage and sort of self patting on the back thing but it’s also that average manager is a lot better at politics than average IC. Because it is literally their job. So a lot of power imbalance comes from that imo


It’s also much easier to get promoted as a manager M1 to M2 vs senior engineer to staff engineer. Managers automatically have a lot of impact across multiple teams, but it’s much harder for senior engineers to demonstrate that.


Having been a Senior IC and a Manager at a couple of big companies, I agree that that promotion is probably easier as a manager, but I worked with orgs/teams that had multiple senior staff/director-level ICs, but only 1 senior manager, director, etc. M1->M2 is possible managing a single team, but often M3 isn't. As long as the senior manager/director is there, you're not going to get promoted.

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).


Right. Companies - which means "managers" - operate on the weird assumption that "programmers are smart enough to model our arcane business processes, but not smart enough to figure out the implications of those processes for themselves".

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!


Can not agree more.

Anyone wonder why IC starts at level 3 but managers start at level 5? It's not because they're separate but equal.


My experience at most tech companies (Amazon, Google, etc), to become a manager you need to demonstrate that you have the technical ability to perform at senior(ish) level IC before you become a manager. i.e. You go from L5 IC to L5 Manager. Not L3/L4 IC to L5 manager.


What if I prefer working with the code (and fellow engineers)?


why wouldn't you be able to rise on the "parallel track" ?


In my 10 years of engineering, I’ve seen a whole bunch of such guides. Promotions are hard to make them fair. Promotions are also biased because it’s fuzzy and there are humans involved in it.

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.


This is so true, and often overlooked by a lot of people. There's no new incentive for companies to reward older employees (you're at the company already). But to get new employees to sign their offer, they're prepared to stretch their resources. Additionally the market has likely advanced and salary bands are probably higher. By staying at a company over a long period of time, you lose out on being compensated at the periphery / edges of the market. And you probably lose out on your read of the market too.


> There's no new incentive for companies to reward older employees

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.


A lot of what's in here reminds me of what we do at PlanGrid, and as someone who has been around to see our system evolve (and add my own feedback to it), I generally agree with the principles that it lays out.

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? :)


That’s unfortunate. As a small business owner, I can understand the business side of things — it can be hard to maintain profitability when someone gets promoted if they aren’t yet able to do all the skills of the job but get paid for it. I wonder if that was part of the strategy — not all the responsibility was added at once to transition?

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.


What's great about this is you're hedging your bets (prudent) while acknowledging the worker's needs as well. The problem without some kind of middle ground like this is that it reeeeeally feels like getting screwed when you're working above your pay grade for an extended period of time without explicit acknowledgement. I've had a lot of unhappy friends in roles like that where they were doing team lead / manager stuff and getting jerked around by HR and their boss for months or years. Now they're hypersensitive to anything that smells remotely like that experience. I like how you're making a public commitment but making sure to manage your risk. It's a great compromise.


I hope your friends have had better outcomes since. A good thing to protect yourself as a worker is to get a timeline or plan of action or growth as soon as new responsibilities creep in — if the company had the intention to promote, they will appreciate a clear path, of not, they will push back.


I like your method here - it is a good "carrot based" solution.


I honestly think this mindset creates what I call "The Reverse Peter Principle". I've seen this happen when very inexperienced leadership implements this system based on hype from other companies. You end up having a lot of engineers doing random stuff that's not part of their job description just to try and get noticed/promoted, and nobody is punished for shirking current duties as long as they aren't just completely slacking off or something. You stop getting rewarded for doing the drudge work and crushing your current role, because you start focusing on the future over the present.

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.


I worked at a startup that did this, but with one major difference. If you were interested in a promotion, you were given a set of new responsibilities explicitly that you could take on on a trial basis. If, after an evaluation period (typically 3 months) it turned out that you had executed on those responsibilities, you would receive a promotion retroactive for those 3 months, including the pay for those. If you weren't able to execute on those new responsibilities, you were left in your current position.

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).


My anecdotal evidence of the contrary: I was hired to replace a junior developer at my employer about 2 years ago. When my teammate left (team of two), I was basically handed over the entire mobile app. I even built and deployed an entirely new tv app by myself.

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.


> Promotions don’t unlock new responsibilities; the new responsibilities and increased scope come first and then we recognize it with a promotion.

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 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."

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.)


Agreed. This is especially problematic when pressure is put on managers to limit promotions. One friend works at a company where there's some sort of promotion quota. He put one deserving person up and was told other people deserved promotion more, so hopefully the promotion would happen in 6 months.

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.


This is pretty much every company. If everyone starts performing at the next level, you can't promote everyone, right? And plenty of things can squish your chances at promotion, like being somewhat unlikable in your group.

I think a better bet for spending your extra energy is often a side-hustle, like contracting.


Why can't you promote everybody who's performing at the next level? If they're delivering more value, they should be paid for that.


This is all based on the toxic and feudal idea that there should be a strict hierarchy of authority and pay that is narrow at the top and wide at the bottom. Each layer of employees should have a smaller layer of higher-paid overseers, going all the way up to the king (CEO).


The side effect of a promotion quota that managers who have the knack for hiring more talented people then other managers may hit the same limit as managers who hire a terrible team.


We have a very similar system here at http://www.synacor.com, and it works really well. The "Promotions don't unlock new responsibilities" thing actually has a big upside: you don't come in the day after your promotion and have the chance to fail at your new job, you were succeeding at it already.

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.


I agree with you 100%.

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.


> If someone has been operating at a level for 6 months, then why not retropay them for 6 months at their new salary? :)

Bonus and refreshed RSU's does the same, isn't it?


Absolutely!


I agree with this concern - one of the most common complaints I hear from my friends and coworkers is that they keep getting extra responsibility handed to them, but never actually see the promotion. There is an incredibly delicate balance between motivating people to take on new challenges and discouraging people by not giving them enough in return for it.

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.


The thing is, I'm often happy to get extra responsibility on its own; it makes the work feel more meaningful.

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.


Because it’s hard or often even impossible to demote someone. Compensation/title change has only one way (up) so it makes sense to give more responsibilities first to try it out and if it doesn’t work out (on either side) then the employee can go back to their previous position without any loss of face. Although I do think that 6 months is too long, a trial period of 30 days seems more fair to me.


One way to look at it is that you found a management need and filled it. Then you get the job. You created a new job! The trick here is being recognized for it eventually.

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.


you are (we all are?) confusing promotion as tournament with promotion as payment for services and promotion for span of control

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


This exemplifies why I quit my last job.

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.


Another way to say that is it's lame to give a someone a promotion to a role they are already doing, because it's the easiest way to communicate that they've been underpaid for way too long.


This is only true if the only way to get compensation increases is via a promotion. Granted at many companies this is true, but it probably isn't true at Square.

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.


Yes, this is the one part of the paper that stuck out to me. Too often I've been fed the "take on the responsibility and then we'll pay you" line. It feels dishonest to me; like they are extracting more work from you without giving you more money/responsibility/etc. If you want me to "take it to the next level" then you need to reward me at the next level.


Growth isn't strictly monetary and needs to be self-driven. I know there's not a snowball's chance in hell I'll ever get promoted at my current company, hell if they offer me a promotion I'll very probably turn them down. I work for a consulting firm, and the last thing I want my role to be is babysitting resources.

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."


This is a management failure. If your manager isn't living up to their promises, they are either incompetent at working the system for their people (and misjudging the situation/their own pull) or they've been lying to you the whole time.


Looks like it's easier to resign from Square and accept a salary bump and title bump elsewhere than navigate Square's "Growth Framework".

If we wanted this much structure, we would have worked for the government or military.


Exactly. When a company hires me, they understand that they're going to have to pay me while I get up to speed and master all the responsibilities of the job. Why should promotions be any different? Are they back-paying these people after they take on extra responsibilities for 6 months?

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!"


I understand your sentiment. However, put yourself in the shoes of a manager. Who does he look to promote? Those who are already doing the job. It is annoying, but at least Square is codifing this so that the expectation is explicit.


How is this different from, say, Google, except that Square is open and honest about it? After I got my offer from Google last year (that I rejected), my prospective manager told me that in order to get promoted (from L4 to L5 in this case) I would need to be operating at that next level for some period of time before my promo packet was even submitted, let alone the promotion come through.


As someone who worked at Square ~3 years ago and now works at Google, the rate-limiting and "promotion by apology" (their term, not mine) feel fairly similar - Google's is a bit more impersonal. However Google pays much, much better. Square (I felt) offered more opportunities to build a good engineering reputation and to gain actualization in other ways, and to make a significant impact.


> However Google pays much, much better.

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).


So my data may very well be out of date. Google's salaries are indeed somewhat low, but their total comp was way higher than what Square targeted at the time. Since Square is now public and doing so well I'm not surprised to hear they're paying better than they did.


To be clear, google is also open and honest about it. "We aim for promo to Avoid the Peter principle" is like in the official guidelines.


This is just true for tech overall. Job hopping will almost always lead to more money than staying at one place and navigating the ladder. What you gain with cash, you lose in clout.


It all comes down to your personal goals. If gaining 20-30% comp for the effort of building you resume and phonescreening and day long interview loops is worth it then it sounds like you shouldn’t stay somewhere for more than 2-4 years.

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.


In that case I'll take the cash.


This is basically a page to help with recruiting. A lot of companies do this, long detailed posts about career ladders. Then sometimes a short bullet point list about "good work-life balance", "competitive compensation", basically the things that really matter, but no real details.

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.


When recruiters mention unlimited vacation, I translate that in my head to ~3 weeks, which is less than what I currently get, so definitely not a selling point. I think we'll see unlimited disappear over time because everybody knows it's BS, and we'll see lawsuits from employees who were reprimanded for taking 10 weeks or whatever.


I don't know. I agree that everyone thinks, or ought to think, it's BS. But everyone thinks, or ought to think, that open offices are BS and companies are all going for those because it saves on costs. "Unlimited" vacation is the same: in practice, I think people are going to take less vacation because there are no clear rules about what's appropriate, and "unlimited" vacation isn't accrued so it's not a payable benefit like set vacation hours. That second one is a big one. If I get fired or quit or roll over more vacation hours than my policy allows, CA requires that those hours be paid out. There's no such cost associated with "unlimited" hours.


> If I [...] roll over more vacation hours than my policy allows, CA requires that those hours be paid out.

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.


It’s like unlimited* data! Aka not unlimited and has to be with VP approval for more than 2 weeks etc...


But isn’t CA eventually going to go after companies who are obviously just trying to circumvent payouts when it becomes clear that they block employees from taking off as much time as they want?

There are bound to be employees who want 3 months vacation and will get fired for taking it.


Maybe, but given that there’s no requirement that companies offer any vacation time, it seems unlikely to me (a non-lawyer) that a case like that would succeed. “Unlimited” is probably couched in “subject to your team and manager’s requirements” language in employment contracts.


My current job also offers unlimited time off, and this is a similar approach that I took when evaluating. I basically wrote it off as break-even with my last job's time offering, as it seemed reasonable to assume I shouldn't get less.

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.


Yeah, it's the best when you can't take a day off because you haven't accrued it yet. I love dictating my life around arbitrary days in some HR system's log books.


FWIW when I became a manager, my lead (who reports to Jack) told me that I needed to be a role model for my team and that I would need to take more vacation.


How much were you taking up to then?


Some of the more esoteric Leetcode medium/hard questions are ridiculous to ask someone who hasn't been specifically preparing for them, I agree, but I think it's fair to ask Leetcode easy's where the algorithm itself is not complicated but demonstrates the interviewee understands complexity analysis, data structures, etc.


Even with easy leetcode, there's still a lot of issues. If a company must do leetcode, it should be like this:

* 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.


Algorithm questions doesn't work well if you pull them from a public database, they need to be novel. If you get questions available on Leetcode then they are doing it wrong.

> 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.


> "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."

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.


Speaking from experience, it's much more enjoyable to interview a candidate who does well than one who does not.

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.


These interview questions are administrated by everyone at Google, so I just picked one used on me after assuring that it wasn't in any public database. The problem is apparently significantly harder than what interviewers typically get, I didn't know that when I picked it. However I don't think it is a bad question, seeing people struggle with hard problems gives a lot of strong signals as well. Also compared with other interviewers I tend to be on the nicer side of grading, so it is not like getting a hard problem hurts them.


Only if it's directly related to the problems the person will be solving. For example, asking data structure questions that aren't relevant to the position is a waste of time and biases your hiring to skills that aren't what you need.


Super agree with the no vacation == unlimited vacation.


SQ eng here. We check all your boxes, and of course we’re hiring. Shoot me a PM if you want to chat.

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.


> We promote engineers and managers when they have demonstrated that they are consistently performing at the next level.

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.


Whenever I explain this model to my friends outside the tech industry they think it sounds insane. The idea that you're not only allowed but expected and essentially required to do work outside your official duties seems arbitrary, almost like a trap.


The audience and purpose of this article is unclear.

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 level thing reads like some kind of horrible gaslighting, but to be fair it's mostly true across all companies. Being a senior engineer in a company that has QA and/or project managers is a very different role than in one that doesn't, for example, and this is a dimension orthogonal to "level".

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.


You're right this document neither terrible nor exciting, but I'd disagree that this document is "open".

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.


We built http://levels.fyi to help bring some transparency into hierarchies at companies (though mainly from a transitional and compensation perspective). It’s really cool to see companies opening up on their specific roles and responsibilities for candidates to see before they enter the track


> Promotions don’t unlock new responsibilities; the new responsibilities and increased scope come first and then we recognize it with a promotion.

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.


> You likely can’t accurately compare level numbers or titles directly between companies, even with tools that provide mappings between companies.

Companies may claim this but it can't really be true in practice, otherwise it would be impossible to level incoming candidates


You should level incoming candidates based on their performance during interviews, their prior projects and portfolios, not what level they were labelled as at a previous company. I don't care if you were a Level 38 at Foo Inc., I'm going to interview you and compare what I think you're capable of to the levels at my company and make a recommendation based on that.


Most interview processes I've been a part of had a target level for the candidate, with the possibility of leveling them up or down based on the outcome of that interview.

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.


Interviews should be pass or not pass. Leveling is a bet and a risky one based on a 45min interview. It is probably best to ask the candidate what they want and tell them where the options are to help that bet pay off.


As a self taught engineer, very unhappy to see the role of a 'relevant Bachelor’s degree' stated in every single level.

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.


It should say "or equivalent working experience" which is what the job descriptions on the careers page say. https://www.smartrecruiters.com/Square/743999692210768

I work for Square, we just hired a self-taught engineer on our team. There's no concrete degree requirement. :)


In general, I believe in this kind of system. I've long been a fan of public engineering ladders (see: Rent the Runway) and create a real career path for non-managers.

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.


Ooh boy, great to see this discussion. If anyone's interested, https://progression.fyi has a bunch more of these to compare and contrast (I'm adding Square's to it right now...)

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?


I definitely don't want some kind of career progression standard that is shared across companies.

Please work for the government if you crave this much structure.


Seems to coincide with the thread a few days back about engineers valuing "growth" when considering jobs:

https://news.ycombinator.com/item?id=20508465


I've been developing a growth framework at my org for the primary reason to ensure that we can have consistent conversations across teams and ultimately, provide a reference point for development teams as they work with their managers on growth.

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?


It’s influence all the way down. You want to keep things pretty abstract and let people come up with the solution on their own. 90% of the time it will be what you want, 5% they ask you for help and it’s what you expect and 5% maybe they amaze you..


I'm curious how the numbers work out at the higher levels. As I understand it, and I may be wrong so please correct me if you know better, at places such as Google there are separate manager and IC tracks however at top levels there's more managers then ICs. So it's essentially easier to become a top level manager than a top level IC.


It also doesn't help that they don't have definitions of what top ICs do. Managers are in charge of a definite budget and a definite number of employees.

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?


The question should be whether the ladder to help you climb, or just to let you climb at the company's pace?

Not sure who the quote is from, but something like "instead of climbing the corporate ladder, why not own the ladder?"


The problem with having to perform at the next job level to get a promotion is that you're still expected to perform at your current job level. So going from say staff where you're expected to spend 60% of your time coding and 40% on making a broader impact to principal where you're expected to spend 40% of your time coding and 60% of your time making a broader impact in essence means you're going to have to work 120%. That's great if you don't have a life outside work, otherwise, you're better off hiring into the level you want.


this seems directly copied from the model used at Amazon (even down to numbers assigned to levels)


I don't get how L5 EM and L5 IC are seen as the same level. Based on the number of responsibility items, L5 EM has like 16 items. L5 IC has 8 items.

L6 IC and L5 EM seem more comparable.


What is the point of sharing it? How is it different from any other company?

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


This is similiar to a framework my company utilizes for promotions. The key difference is that everyone at the same level makes the pay. This is great for transparency - everyone knows how someone should be performing and how they are being compensated (all the way up throughout the company).

For those interested, the company is Pariveda Solutions.


Cool to see this published. At GitLab we have a page that serves a similar purpose on https://about.gitlab.com/handbook/engineering/career-develop...


The devil is in the details--so much depends on how the levels and their descriptions are operationalized.

Would be interesting to hear more about calibration work, how they are defining output parity across the engineering disciplines/business units/products/teams.


I'm surprised there's no guidance for IC9. Are there just not any of those yet? At my last company (300-500 engineers) level guidance only went up to IC7, and there was a single IC8 who was sort of "pioneering" new level direction.


This is funny coming from Square, L5 and above is all politics there.


Does it matter who your manager is? Does this fit to all types of engineering work? Does the idea of responsibility unlocking promotions after the fact work for assigning levels to new hires? Do people who don’t self promote get promoted by their managers? Do managers benefit from promoting their engineers?

Someone else already asked, but who was this written for other than the people who wrote it?


You need permission to view the document! what!?


Somebody is working on fixing the permissions. Sorry.


You can do better. :D



The actual career ladder document linked from the post is in a private Google document so we can't read it.


Fixed.


Still locked down unfortunately.


We're looking ... Something about Gsuite permissions isn't working as expected :)


Works for me


google sheet is locked.


This is relatively O/T, but I've always been skeptical of the general concept of growing yourself in top tech companies. Seems like the overall idea is just to grow yourself professionally, do more and work harder for your customers, instead of growing yourself for yourself and your own personal happiness, being a better person, etc. On top of that, some companies expect you to give your all in that regard. "Practice your customer obsession" and that sort of thing so you can be a better worker. I hope in the future we'll still have very successful tech companies that don't do this -- ie. they have a more relaxed atmosphere and don't pride themselves on bending over backwards for every customer. Believe it or not, there is more to life than your career.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: