Managers control the purse strings. ICs don't. There will never be equal status, and it starts with other ICs that won't lift a finger unless it pleases someone with a fat purse. You can leverage IC star power a little, but it won't get you too far without a purse.
The problem with growth as an IC is that one person only has so many hours in a day. The only real way to multiply your impact is to transition from using your own hours to produce work towards directing the hours others use to produce work. Simple math shows that your own productivity scales only up to 24 hrs/day while you can easily direct a team of 4 towards 32 hours a day of productivity and actually get some sleep.
I don't know if that requires being a people manager, specifically. You can also scale your work by being able to work alongside other people to help them maximize their impact - you don't necessarily need to work above them, choose their work, direct their performance reviews, etc.
If you do it right, this also scales well. If you can help a hundred people do their work 10% more productively, that is also more effective than helping four people do their work 50% more productively. Most tech companies that have separate engineering-IC and engineering-management ladders try to keep roughly similar expectations at each level about scope/breadth of impact, it's just that for engineering management, it's "how many people do you transitively manage," and for the IC ladder, it's not as obvious.
I think this article does address that by pointing out that the design management career track generally expects you to manage both increasing numbers of people and increasing amounts of work, and those don't need to be the same thing:
> Overlapping responsibilities between IC and managers is the most prominent issue I’ve observed, but it’s an easy one to resolve by looking at where the line is drawn between people and product on the team.
(This sort of reminds me of a similar problem in academia: there are three separate skillsets, doing research, leading researchers/scaling a research lab, and instructing students, that tend to be conflated into one ladder. They don't need to be.)
This just isn't true. A friend of mine is an IC and regularly ends up making original tools that solve his problems that everyone else at his company ends up adopting. The company recognizes this and awards him in kind. He makes around 1 million in regular salary.
He has way more impact than any individual manager. If you want to have a huge impact at your company as an IC, solve the higher level problems that both you and your fellow developers are having.
It is simpler to manage a company without arrangements like this. It makes ICs and Level 1 managers more interchangeable. If you moved the 1M employee over to another group it would blow up that manager's budget. The more interchangeable employees are the better for some people in upper management who don't actually care about maximizing cost efficiency and productivity. They are maximizing other metrics.
That 1M employee is generally not “moved” to another group, in my experience. They are often already at a seniority level that is above the group. Also, like most VP’s, their compensation is not typically accounted for in a group/division/etc budget in the same way as their reports.
A big one is that managers are de facto judged by the size of their team (and, for more senior ones, the size of the tree underneath them, too). It seems to be really, really hard to have middle management in an organisation without "maximise headcount" becoming an unofficial goal.
Edit: Employee happiness is an interesting one here. It's quite believable to me that being seen to cut down a few tall poppies might have a positive impact on (mean) employee happiness in some cases.
I was not expecting such a Machiavelic answer, but yes, your explanation looks quite possible. Indeed, it is possible that the expertise ceiling that goes on a lot of companies is due to misaligned incentives (plus some dishonesty) for management. That seems worth taking a better look.
> It's quite believable to me that being seen to cut down a few tall poppies might have a positive impact on (mean) employee happiness in some cases.
This again... I dread to imagine going through the day around people that think like this. But people that think like this exist, and I imagine they concentrate somewhere. If some place makes them happy (and everybody else unhappy as a consequence), you'll probably find them there. This is really believable.
I'm a manager and I have a member of my team that does exactly this. They have built tools and process that has allowed everyone else to be more efficient. Anyone on my team can, but they gravitate towards it. It's up to a manager to make sure they are paid appropriately and make sure that they are given space to actually do this type of work.
I definitely think tools can have a lot of leverage, and an experienced IC could easily develop a tool that would save time for the whole team. And I've seen it happen.
But IME this is the exception rather than the rule. The experienced engineer usually gets the credit for building the system with the tool (for which it was essential), but not building the tool itself. The tool is considered useless until someone has proved it on a important, shipping project.
This often doesn't mean much because when there are tons of highly capable engineers, anyone could write that library and it's only a question who had a chance to do it.
No IC is going around making a million dollars for creating internal tools. If he's making a million it's for something else - he's a founder, he was acquihired, he is related to the founder, etc.
In a world where various technology curves are going through exponential improvement, this seems like a false mental model. Scaling yourself out as a manager may offer some kind of linear multiplier over raw output, but hard to say without context. (For example, if you are a strong contributor managing weak contributors, the net effect may in fact be negative in terms of raw productive hours.)
However, that linear multiplier doesn't mean jack in a world where technology can create exponential leverage. I'm pretty sure on a given day, the potential for a single or small set of individuals (without any centralized management) to produce products and systems that change the world is higher than any day previous.
Depends on your industry. In the investments industry, there are many ICs who do well both impact-wise and financially. That is because the input of scale is AUM (dollars being invested.) You work the same but pump more $ into your algo.
That is why you see tiny hedge funds doing well, both for finance, quant, and tech workers.
I find the whole concept strange. Why are technically skilled folks boxed into being “individual” contributors? There are many ways (hats) in which technical skill can be leveraged to help other people or teams: the person who can troubleshoot surprises with relentless digging (beaver), the person who provides technical feedback to colleague (reviewer), the person who has a broad understanding and can quickly get someone up to speed in a new area or suggest exactly what to look for (consultant), the person who understands the system well enough to onboard a new member quickly (teacher), finding new directions for the org (researcher), etc. All of those are multipliers on the performance of people and teams, and don't befit the “individual” moniker.
Working on complex problems requires collaborative effort, which can be immensely gratifying not just intellectually but also emotionally (humans are social beings). It is strange to see a warped restriction of the concept of collaboration down to each “individual contributor” doing what they’re assigned, and ignoring the other “hats”. That formulation never allows/imagines a chance for the whole to be better than the sum of its parts.
because thats the meaning that we've assigned to the phrase "individual contributor", its as simple as that. If you don't have people reporting to you for you to direct in accomplishing the goals of the organization you're an individual contributor, if you do have them you're a manager.
I'd argue the best individual contributors don't have the skills to be the best mentors or managers. These skills can be learned only by sacrificing IC value, maybe just temporarily.
It seems this industry is getting better at realizing IC skills may be prerequisite for any successful mentoring or managing. The breadth of knowledge is only getting bigger, so if you aren't an expert in some area, what have you been doing, and if you are, why aren't you sharing it.
I've seen the IC/manager dichotomy diffuse into my mental model as I've moved through the tech industry. I agree that it seems to be a model that undermines healthy organizations. The attraction to it, in my view, is that it confers the sense that there will be no 'blocking' on decision making: the manager calls the shots. But in a healthy organization, that's not how it works: not only should managers not be calling the shots, but their job should be pushing decisions onto the people they manage. Additionally, the decisions made should be a mixture of consensus and deference to experts within the group on that particular domain. If you fail to get consensus, or you force people to defer to people who are known to be unable to make good judgement calls on a particular area, you're doomed.
So, once it all plays out, in a healthy organization, the IC/manager dichotomy seems somewhat counterproductive. I can't say I have a better alternative for larger organizations, but for small teams and startups, I highly advise disbanding it and staying small for as long as possible to avoid it from being forced upon them due to the surrounding culture.
I agree with the sentiment that a dynamic, role based method for delegating responsibility seems incredibly attractive. If you haven't seen it before, Turtleocracy is really interesting (not just directly, but at a meta level as a way to design social systems for these problems) https://www.notion.so/Turtleocracy-47a6df7692bf4e95a39504a73...
Value is all about impact and companies are incentivized to reward and promote impact. It’s valuable to a company to have a really great IC, it’s even more valuable to have a manager that can grow their team into really great ICs - presumably like the manager was at one point.
If you are an amazing IC, but can’t/won’t help others grow to that level, you are only so valuable to the company - hence the IC ceiling.
ICs reach a local maximum at some point. Most companies aren't solving problems that are hard enough to warrant executive-level equivalent engineering roles (except organizational ie. management of said engineers).
There’s nobody making you choose to stop being an IC. If you want (and you stay up-to-date with the latest trends) you can continue doing it indefinitely. You just can’t do that and also demand that you be paid the salary of someone who is leading a team.
You are paid to produce value. If you continue to focus on producing value as an individual, you have to reasonably expect that your compensation will eventually reach a limit.
Microsoft pays employees based on level. My manager does make more than I do, but that’s because they’re a higher level, not because they’re a manager.
Facebook is the same. Transition to management, make the same pay per level. It's less about moving for money and more about moving to what skillset you prefer to use, which I really like.
Ish. There is a ceiling to an ic. Sr dr ic level(distinguished) is probably it, while an em can go up to svp level.
Let's not kid ourselves, the ladders are never equal, and a senior ic level doesnt translate well to another company. After l7 and above, the skillset is only mostly recognized within the company.
Yes, at perhaps five of the world’s most elite software companies, they have pay tiers that theoretically scale with experience.
Setting aside the fact that most companies don’t have this, here’s a protip: count the number of engineers at each tier. People don’t get automatically promoted to l7 just because they spent years grunting at l6. It scales with impact, and opportunities for impact as an IC are fewer and farther between than for managers.
ICs are architects and as such create rules about what is to be done and maybe more importantly what must not be done. While it is often said product follows organization there is also something to be said about organization following products - once the initial architecture is established in a new undertaking the team structure is usually aligned.
Some ICs are not really architects but work on tiny scale on critical bits. There is often some fractal quality to their work and the tiny structures are reflected back into the organization.
Some ICs have come up with patents - the foundation for building businesses with a profitable moat around them.
Last but not least are ICs role models and can have a large impact on the development of other individuals.
It is often not easy to find a way to impact the organization on a larger scale but it is possible. I think the I in IC is not helpful.
> There’s nobody making you choose to stop being an IC
There kind of is, though. If you’re lucky, once you hit mid-40, you’re with a company that will be able to keep you on/stay in business for the next 20 years until you retire, because job hunting as a middle-aged “IC”/non-managerial is… unpleasant. I’ve been involved in several hiring committees where (managerial) types would look at a resume and say, “this guy’s been doing this for twenty years and he’s still ‘just a programmer’? Ugh, next”.
Most companies have no use for very senior ICs. They don’t have much difficult work and a lot of managers want to involve themselves in technical decisions so once you have reached a certain level there is no room to grow. Either go into management or stagnate.
It will build morale in the team of developers on that project but from my experience management/product people will just give you a blank stare. Like so you spent a month doing... nothing?
So they need to "see" it. They need to see business metrics of cleanup work. Show them e.g. AWS usage cost savings report/powerpoint in their language and you will gain a respect.
Technical debt is like real debt. You do it because you want to grow the business, and you can delay it as long as you can. Paying the debt down doesnt make the business grow.
You try to pay down debt after growth to prepare for the next round. And in many ways tech debt is worse because while real debt just constrains you, you can maneuver just as fine within the constraints with or without it, while tech debt can gum up even your slightest movements.
I'd say tech debt is more like a special VAT applied to your current actions, whereas regular debt is proportional only to your past actions.
Paying technical debt down takes away from other areas you can grow on.
Unfortunately the economics doesnt play out like this. Whether you have technical debt or not, the stack will get a rewrite every now and then because thats how senior ics will like it or will get promoted because of it. I have seen lots of infra churn that went over budget, didnt result in the impact it claimed, and so on.
Even when technical debt is deliberately taken on in the interest of growth, it still can come around to bite you, as you triple and quintuple the size of the team yet see only 20% increase in velocity, and face further dilution to maintain growth momentum.
(Yes, technical debt is often overrated, by young engineers unused to maintaining hairy code. But when it builds up over several years, it can add up to a real problem.)
Sure, but you will find out that eng has more desire to rewrite than gradually increase quality.
Meaning... When you choose your debt reduction strategy, you cannot go 0% debt. There will be investments you can do, like increasing deployment velocity, adding monitoring and so on, but refactoring that ugly god object may not be the greatest idea.
There's little point rewriting code which isn't modified often. And actually it's code which is modified often which accumulates design debt; structure tends to "dissolve" in the face of repeated local modifications by engineers on a time budget who don't understand the whole and don't know where to make the right changes.
Ugly code which is locked away in a module isn't a big deal unless it's a performance problem or bug magnet. I wouldn't really consider that stuff debt, though; if it's not impeding velocity, you're not paying interest on it. Technical debt which has a noticeable interest payment, that's worth reducing.
Sometimes the interest cost isn't obvious. E.g. the UI might be written using some framework which is 5 years old; it might be reasonably clean internally, but the payment comes from developer churn and lack of appeal to devs (whether current or pending hire) wanting to keep their CVs up to date. That cost is real, yet it's imposed exogenously, not because of any deficiencies in the actual technology.
This is part of my point. The eng could have spent 6 more months on making that UI even better, only to have another eng rewrite it in 5 years because... why not.
I'm very lucky where at my job technical decisions are actually deemed meaningful gasp and so are made consistently for the entire company.
Most places I gather the non-technical people in charge assume they don't matter so they're basically left as fodder to appease dev leads and make them feel important/creative.
Most of it comes down to short-term and long term view of people in charge.
Unfortunately, companies do promote short term gains. Promo cycles are 1-1.5 years long for most companies, as a result people tend to optimize for launching. For managers, in FAANG, that seem to go around # of people that report to you, so they optimize for that.
For a business, there's less incentive to do that investment. You need _some_ investment to keep it long term, but you don't need to put your 100% to make it work. It also comes down to VP of Engineering or equivalent in an org.
Not overdoing technical debt is key. It's a means to an end, the end goal is still $$.
After owning a house, I feel like technical debt is much more closely related to building homes and doing remodels.
You can always cheap out and get it done slightly faster and slightly cheaper. And you might not have to suffer the consequences. But someone down the line likely will.
E.g. we recently had to install a cleanout for the sewer mainline in our house. Apparently when they built the house, they did everything but install the final above-ground cleanout - instead they just capped it off below ground. The other work, except for the above ground part, all had to be done for testing purposes anyways. But by not installing the above ground part they managed to save something like $10 for each house they built. But now, instead, I had to pay a company $1,200 in labor (they spent all day digging) to install a $20 part when our sewer backed up.
I work in a codebase full of bad, willful technical debt like this. "Let's just do it the easy way" - despite the "hard" way not being harder, just more different than they were used to at the time. Or hard coding things despite being able to derive it from other information - "we can do it later" - good luck, differences creep in and you will spend weeks or even months figuring out all these minor differences and whether they are on accident or on purpose.
6 months down the line, that easy way is completely fucking us up. Certain changes that would have taken an hour take days. And it was completely predictable at the time.
This is true, but i doubt it was just 10$ piece - they did many of these shortcuts that probably didn't matter. They probably didn't use the _best_ material on your kitchen countertop, because the marginal value over good enough is not there.
In a similar analogy to yours, most of these systems tend to cause outage somewhere, which are then usually patched on the fly. Depending on a project, shipping fast is usually more valuable than not shipping it for a year. From my pov, i used to be in advertising, and not releasing a billion dollar feature for a year would, by definition, cost a billion dollars a year. If it explodes after releasing, you are still better of by a huge marging because outage would cost much less. Once you have the business going, you can spend money and manpower on the problem, too.
I think this is key: "Hard way not being harder". This depends. Engineers like to overengineer, and without proper supervision they tend to favor technical excellence over business usecase - it needs to be a balance.
On the house example, i bet the value of your house still increased, and the 1500$ you paid is irrelevant in the grand scheme of things. Just like business & rewrite.
Overall, don't get me wrong, I like to use my best skills and put a shiny design out, but i don't do it because I favor doing "good enough".
That pretty much describes my career trajectory. I'm too "old" to be hired for a lot of jobs, but it turns out that there are niches involving cleaning up the messes that youngsters make. :-)
I've seriously considered becoming a "Code Janitor" consultant.
I can clean up any mess better than most, and I actually enjoy it.
To me refactoring is the design process of modern development. First you write the working code, and then yo design it. Except most people don't bother with the design part, and get dragged down by their atrophied systems.
The best work I've done has sort of iterated between design and coding, with minor and major swings between. They say that complex systems that work invariably evolve from simple systems that work, and I believe it.
If one wants more responsibility, one has to move to leadership. This is true in almost every company and work type, not just in software development.
There is a flip side to this, as some (many? most?) excellent ICs either become poor managers, or hate the job of dealing with humans, or (frequently) both. This is well known and many companies actually want and support top ICs who want to stay ICs with significant freedom to choose projects, generous (time, travel and $$) conference budgets and other perks.
Thus at least some ICs do not go anywhere after they peak (hopefully plateau), which can be a good place to be. But sooner or later they will likely be working under one of their team members whom they did not think much about (who may just be better with people than with technology). This is not a reason to lose any sleep; just something to keep in mind. My 2c.
Responsibility vs. accountability. If one wants more accountability, then you must move to management. Responsibility can and should scale with IC levels.
What’s the difference? Think about when a project fails. “Bad things” happen for the person accountable, whereas the person responsible can move on to the next project. The buck stops at the accountable individual not the responsible one.
In practice, every project has a manager that’s accountable and a lead that’s responsible. As ICs move up the ladder, they’re able to lead larger and larger projects and offer expertise and guidance across multiple projects. Think: providing feedback, from hard-fought past experience, on a design doc that’ll save a team 3 months worth of effort; architecture review, etc. Essentially ensuring and instilling engineering excellence across the organization.
One thing to note, moving up into a senior engineering role may mean you’ll be coding or designing less. And that’s to be expected. Senior engineers understand that coding/designing is one portion of a larger picture that includes communication, eliciting buyin, documentation, architecture, software quality attributes, and many more responsibilities.
In theory, this provides equal management and IC tracks that are fulfilling to all. In practice, very few companies work this way, but there are some out there. And when you find them, you won’t want to leave because it’s such a pleasant experience.
I'm sure it's a pleasant experience for the high level IC, but from the rest of the organization's perspective it you're describing architecture astronauts.
* They descend on random design docs to demand changes, based on vague pattern matching to a problem they faced 5 years ago.
* They don't have to do any of the work to implement those changes, of course. My team has to, and we have to defer to their opinion that changes are needed.
* If the changes they demand end up being really dumb, and hurt or kill my project, they can't be held accountable. Not even when it's a recurring pattern, since every corporate metric will show that the project team are the ones who messed up.
Maybe our disagreement is less severe than I'm thinking, since I also wouldn't agree the IC model at e.g. Google works like you're describing. But separating accountability and responsibility is in my experience an unmitigated disaster.
You describe a bad implementation of top level IC. They same way, it can be someone from the top management who has no clue about individual teams, makes dump decisions that hurt your team.
Top ICs work together with ICs that represent their teams, so that they can make informed decisions. They are up to date with technologies (this must be an obligatory requirement), code regularly, so they are much better then managers to make efficient company wide technical decisions, own the architecture of the whole system or large parts, organise and overlook large and expensive engineering initiatives, drive prototypes and research projects. They must me accountable for being up to date, understanding the consequences of their decisions, getting feedback from managers and engineers - not turn into “astronauts” in some years.
I think ICs should go in parallel with engineering management in the reporting chain: the top IC reports to CTO, next level reports to directors, etc. This ensures that IC’s scope of responsibilities is expanding and they have better visibility and power.
> I think ICs should go in parallel with engineering management in the reporting chain: the top IC reports to CTO, next level reports to directors, etc. This ensures that IC’s scope of responsibilities is expanding and they have better visibility and power.
That’s how it works at IBM. I’m the “responsible” party and technical leader for a couple of teams working on related projects. I report to a program director who reports to a VP. My peers are line managers and other senior tech leaders. Part of what’s great about the team that I’m in is that we ha e clear talent pipelines that show how you can matriculate upward in design, engineering, or management, and that a “band 10” of engineering is equivalent in scope, comp, influence, and autonomy to his or her manager equivalent or design equivalent. That extends into the executive ranks as well though it’s more common to find people who hold dual roles of VP and Fellow or Director and Distinguished Engineer or Distinguished Designer.
Exactly, it is similar to my position at some previous company: as a tech lead I reported to a Director of Engineering who also managed a few engineering managers. The top IC tech guy - “Chief Architect” reported to CTO.
This anti-pattern is alive and well throughout the industry. I'm automatically suspicious of any department that dubs itself as "architecture" because the motivations are usually broken in that success looks like forcing outside engineering teams to adopt a pattern conceived in abstraction.
My experience says that ICs are best embedded in the team to deliver working code with patterns that are conceived from exposure to the real problem being solved.
I agree, architecture departments are anti-patterns, but very soon, IC cannot grow in the value they can bring to a company by being scoped within a team and shipping code - as IC you scale by: writing some code that benefits many teams, by mentoring, helping with planning and executing challenging work, prototyping, organizing and overlooking large engineering initiatives: CI/CD, ops, migrations on a large scale, and more and more.
Yeah, you are right. Where I've seen it work is when an embedded IC is given free reign to spend time helping other teams organically. The real root cause for architecture in abstraction is a management issue where some VP is kingdom building by collecting engineers to be disconnected oversight architects to other engineering groups.
I feel like one of the worst things that can be done to engineers is disconnecting them from the problems being solved.
I’m afraid you constructed a strawman to argue against that doesn’t occur in my comment at all.
I’d like to hear more on your thoughts about Google’s IC track and implementation, especially if you’ve worked there. Care to provide a compare and contrast?
At some companies I'm familiar with, the highest level ICs have nearly unlimited freedom to "move on to the next project" as you put it. Some slot themselves into purely advisory roles, so they can dedicate their time to accountability-free control without ever having to risk assuming responsibility. Others constantly flip through greenfield development projects, leaving maintenance teams behind like mouse droppings once the projects are too mature for their tastes.
At Google, high level ICs seemed accountable by most standards. They couldn't just abandon projects when they became boring, they got in trouble when their projects didn't work well, and the weird committees (which admittedly did exist) generally felt like guideposts more than obstacles.
I have no beef with your definitions, those are nice and consistent, but in practical terms I have trouble imagining anyone who, by your definition, wants more accountability. This seems to be asking for a harness and a whip.
On moving up the ladder while staying an individual contributor -- IME as one becomes the tech lead of larger and larger projects, the "tech" part shrinks and "lead" grows and the setup has a constant forcing function into a "manager in all but a name" setup. One might resist, but this is frequently a pretty hard push.
People that want to control P&L necessarily want accountability. I’m not sure why it’s difficult to imagine someone who’d want that? Every founder of a company, by definition, is seeking and taking accountability.
Your second point is spot on. A natural tension arises as ICs move up the ladder, and if one values being an IC, then one must maintain their boundaries.
> Responsibility vs. accountability. If one wants more accountability, then you must move to management.
Depends on the org and company, to be completely honest. Sometimes, management and leadership have little true accountability and that ends up falling on ICs. Projects fail and senior ICs are blamed instead of management because they were "responsible for the implementation". Accountability without responsibility or vice versa often ends up in failure.
At some point, I simply cut and pasted the paragraphs of my performance self-reviews and actions for growth from one year to the next and told my manager: “WYSIWYG, you know what you can expect from me, you know I’ll learn anything that’s needed for the job, and more. What more needs to be said?”
And that was the end of self reviews and we all lived happily ever after.
You seem to assume someone has to "love" what they do to be effective. I'm a senior engineer, and I don't hate what I do, but I wouldn't be doing it at all if I were financially independent. I'd be doing something I love instead.
There are many ways to be an IC. You could just write code all day with minimal interaction with the rest of the team. But you can also mentor your teammates or be a technical lead for a component or entire project, even without becoming a manager with direct reports.
In general I don’t think there is anything wrong with “peaking” at a point in your career where you feel fulfilled without feeling pressured to always take on more responsibility and stress. If you want to lead projects or manage people, go ahead. If you just want to write code, that’s fine too. Of course depending on the company your compensation might top out after a certain point, which you may or may not be happy with. But at least in the bigger FAANG-type companies, you can go pretty far as a “tech lead” style of IC, without directly managing people.
> In general I don’t think there is anything wrong with “peaking” at a point in your career where you feel fulfilled without feeling pressured to always take on more responsibility and stress.
So true. Especially after having a kid, I'm dreading any further promotions above the usual Senior. I'm happy at the level I am for the last 5 years and don't see why I would suddenly want to spend more hours in meetings and be held responsible for more things?
In places that allow senior non-manager ICs, those ICs are determining what to do. The managers are figuring out who and when to do it, the ICs are going to figure out the details, tech ordering, research, etc.
Usually the way it works is I'll identify a large scale problem, work to quantify it, cost it out, work to find the manager who is most appropriate for it. Work with that management chain to further quantify cost and benefit of fixing the problem. We'll get high level resourcing and prioritization for the work. I'll get going on deeper research, role needs, design docs and v0 implementation. Manager will get going on hiring. At some point I'll swap from driving everything to doing, and just lob prioritized tasks to the managers. Essentially I'm working as a Product Manager and IC coder at this point, eg I'm saying what we should be doing (PM) and doing the work. However at this point the manager is actually setting sprint task level priorities for me. So weirdly the work goes PM (me) -> SDM (mgr) -> IC (Me). At this point the SDM will usually have hired some other devs or a PM and we just fit them into the flow. At a certain point I'm really just a Lead on the team while we groom up a permanent lead. Or if it's a longer project I'll stay in the Lead role for a year. The manager, PM and I are all working together. I don't have to manage anyone but I do a ton of mentoring and product work and communication.
They asked me a while back if I wanted to manage people (manager came from where everyone here seems to be coming from). But when we discussed it they didn't want to lose 30% of my time to management duties.
A highly effective manager will be able to delegate large parts of their perceived responsibility to others, which is how they get to 100% productivity. Same can happen for managers.
Since I do the same process described here (at a FAANG), I’d like to elaborate on one more thing: responsibility. Upper management trusts me to do a good job along the entire pipeline, particularly at the hand-off to the maintenance/independent-development phase.
Not every company actually defines a role like this (mine doesn’t), but it is a role every healthy large-scale company needs.
Very good call-out. Trust is inherent here. Amazon would call it earns trust and ownership. The role there is Principal Engineer (or really senior sde3).
This reflects my experience too. I’d also like to add one more thing though. In many tech orgs (and some non-tech orgs like mine), top IC’s are actually the equivalent of VP’s. Their compensation, responsibility, accountability, and impact are often at the same level or sometimes even higher.
Like everything I did the research and presented facts. I've managed before. There are projects that would be better if I had directs, and things where it's better if I'm a wandering problem/solution finder. I preferred not to in this case and didn't. It didn't come down to it anyway as there were other options.
I find when you're working well with your management then things just happen and there isn't much fretting or arguing. In fact I have to often call out distinctly "are we all clear were making a decision here." And then we just move forward.
I think this phenomenon is evidence of the value ceiling of IC work. What is the point of diminishing returns on paying an IC more money to do what they already do well vs hiring an additional younger and less expensive person to do the same thing, though not as well? Of course, an experienced IC can transition to mentorship, and different companies value this differently, but that may have a value ceiling as well.
Personally, I don't think it's necessarily a bad thing when IC's who max out their value writing code transition to other things. I agree not everyone makes the transition successfully, but it's a great opportunity for personal growth, and the potential for upside is high, since an organization can gain a leader with very nuanced and deep insights into product + market.
This is not my experience. It might depend on the field. Unless there is a "peak IC" doing stuff development stagnate and no matter how much time or resources is put into something the great results never comes. Things turn out good, yes, but not great.
It might be that I see this from an engineering perspective and that "the market" and stockholders wont notice in the short term until the brand gets a quality reputation in 10-20 years from user hearsay.
Managers on the other hand seems to mostly have the duty of fighting fires and putting out fires - with the most important quality of not litting fires themselves. There is no way a great engineer working as a manager have time to deal with deep proactive technical issues where I have worked.
That's a great question, and of course depends on the handicap. If it's hearing/speaking, probably a lot of jobs can be done via "chat", with little or no phone or in-person hearing required. For limited sight, we fortunately live in an era of huge monitors. Certainly being blind would suck, of course, perhaps even more than 20 years ago given the "advances" in UI.
"Then, a few years into the [manager] job, they realize that they don't have the natural talent to develop other people. Not only is this a waste of their time, but chances are, they could have increased their contribution even more if they had stayed in the [developer] role - a role in which they naturally excelled. Yet if we want additional income, status or responsibility, most organizational hierarchies force us into a very different role - instead of allowing for an entire career of progression within a specific role that fits our talents."
I am a senior IC transitions to management. I think these articles leave out a very significant part of the equation and that is compensation and career mobility. Generally the management track at higher levels has more openings. If you stay in the IC track, there are going to be much fewer openings at that level with appropriate compensation. This is particularly true the more specialized your knowledge is. Moving to management track provides more opportunity at the same/similar or greater compensation. The exception to this are the FAANG companies but in my experience it’s way easier to get in through the leadership ladder than through the senior IC ladder. At least that was my experience in the 2 I’ve worked for. In one of the FAANG I worked for, I joined as a senior IC but was given a very non-senior manager and was effectively treated as a junior engineer during the 1st year.
More openings at higher levels? That's just at odd with how organizational structure works. For engineers, at least, you need about 1 manager per 8 ICs. Going up the ladder, you probably need about the same number per level, so: 8 managers of managers per first level manager, and so on. If you have team managers, directors, and VPs, you should need:
Because every year there's some turnover, so your senior IC has a shot at getting some reports. Meanwhile, the incentive for upper management to promote a senior IC to super-senior IC or fellow or whatever is slight.
There are more openings for managers at higher levels with the same or higher compensation than for high ICs simply because there are fewer problems that have the scope for such a senior engineer. A FAANG I worked at might have a need in an org for a few director level ICs. These ICs in my experience are few and far between. ICs at this level make same money as management track. In my experience not many teams within an org have scope for an IC at that level Making it more difficult to transfer within the organization. Yet at the same time there are many director level managers because there are many teams and lower level managers to manage within those orgs. Additionally, a director level manager is considered somewhat generic and has an easier time moving around in the company with things that are tangential to their domain. My current company is not a FAANG but I can tell you that I see the same thing there.
GP means more openings in management track than in similar level IC-expert track.
Which makes sense seeing
1) in those 8 person teams you mention there may not always be a place for an expert IC
2) companies often reserve the IC-expert budget slots for internal IC promotions while relying on management slots on external recruitment to a higher degree
I think often what you'll see on the IC side is above the Senior level (Principal, Distinguished, Fellow, etc.) there are fewer available roles. I've been in organizations where the highest level you could go is Distinguished Engineer and each VP would have one Distinguished Engineer and several Directors. Using your example breakdown, there are 8 possible director positions under a VP while there is 1 possible DE position under the VP.
Additionally, it can be easier to transition to an equivalent or higher role from one company to another on the management side. Most companies are open to hiring a VP from outside but often the highest levels of IC roles are only filled by those with significant experience within the company.
Yes, this. Same background, similar story (I went into tech strategy consulting instead).
The knowledge and ability to do tech work is great, but many jobs require that AND some other skill set (sales, research, communication, people management, etc). Those jobs also tend to be very well paid.
The original article's title is: "Where do IC designers go once they peak?" (not sure why it was changed on HN), and it focuses mainly on the career path for design.
For engineers, at least in larger tech companies, there's often a tech career ladder that runs parallel to the management ladder where you can have salary and responsibility growth as an IC without managing people. These ladders usually top out at a "distinguished engineer" or "fellow" level that's roughly equivalent to being a VP.
Based on my experience, it doesn't seem that many companies outside of the FAANG companies have those kind of tracks. At a small company that builds a single product, what would a "fellow" actually do that is different than a senior engineer?
You're right, the company needs to be of a certain size before this makes sense. But it's not just FAANG -- for example, IBM, Microsoft, Twitter, Lyft and many others have similar tracks.
People are so stuck on the acronym that think of MS as less of a tech company than Netflix? Microsoft is much larger than Netflix no matter how you measure it.
Probably because there's a substantial minority of hardware engineers here for whom IC designer is a very specific job title.
I have worked at and worth several companies which purport to have this parallel track. In practice there seems to be much less need for senior engineering and much more need for senior management. There may exist a parallel track but there aren't many positions on that track.
E - Teaching? A few of my absolute best adjunct professors were retired from industry and took jobs in education because they loved the field and wanted to give back.
Be careful that you are at a company or, even better, in an industry that isn't rife with ageism and where there is a clear and well defined path for more senior ICs to continue to develop an age appropriate resume (increasingly strategic contributions while remaining current with latest industry tools and practices) that will serve them well if/when they are looking for work at 55.
In software this is very often not the case. A 55 year old still fluent in hot tech and a lot of strategic work as an architect, interventionist, mentor to younger devs, etc and who can demonstrate all that in their resume will probably do ok. A 55 year old who is "just" a coder will often have a rough time (vs 28 year olds getting actively recruited 5x/week).
In other industries, like EE where I also worked for several years, this is much much less true. Very senior ICs are highly valued and it is common for teams to be a blend of engineers from fresh grads upto near-retirees.
Not an easy problem to solve. And this is why, given the odds, a career in tech is probably a bad decision.
To avoid ageism while being an IC you need to find a job in a niche where the domain is CS and/or ENG based (as in embedded, aerospace, or even relational database engines) and these jobs are far and in between.
Beware: jobs like Facebook seem to be CS based but they aren´t (that´s why their programmer average age is 27). The CS problems they have are due to arbitrary complexity and they are short term. Companies like these are media companies.
What’s wrong with as the parent poster said “develop[ing] an age appropriate resume (increasingly strategic contributions while remaining current with latest industry tools and practices)”?
I’m 45, still an IC mostly but my next role whenever I decide to leave my current job, will probably be working for a consulting company. Currently, I am “more equal than others” and have more influence based solely on my “relationship and expert” power.
the problem with an age appropriate resume is that it signals your age, and most companies aren't interested in any 'relationship and expert' power that candidates can bring since they have already filled those positions.
I’m not seeing that. What I’m seeing is that a lot of companies are hiring cheap (relatively speaking) junior or outsourced developers and a few “architects”.
In the cloud consulting space or the generic “digital transformation” space, you have a few customer facing consultants and lots of low paid people doing the grunt work.
I am not seeing any shortage of openings for either “principal software engineers”, or architects. Of course, I’m staying away from the west coast. The major cloud providers and their partners are hiring in most major cities as long as you’re close to a major airport. I happen to live near the world’s busiest airport.
None of your conclusions follow from your premise.
I could just as easily claim that coders who refuse to develop new skills and keep up with a changing environment will eventually find themselves sidelined, due to their inability to adapt to changing needs. Since most of those middle aged people started programming 30 years ago now, they then move into environments where the technologies also haven't evolved in 20-30 years: embedded, aerospace, and dated DB work.
This doesn't preclude people who can evolve from keeping up as mostly-just-coders in a changing world. Calling the complexity inherent in something like facebook "arbitrary" as opposed to the complexity in embedded work as innate just implies that you don't understand the "CS" problems that Facebook (or similar) deal with, and I can imagine that a company like Facebook might not want to hire someone who, for whatever reason, is unable to accurately analyze the complexity of their problem space, especially at a more senior level.
> I find the wording of your last paragraph a little insulting.
And calling modern app development's probelms " due to arbitrary complexity and they are short term" isn't?
I do think that much of the aerospace technology industry uses dated methods. Same with much of the embedded field. There are certainly places that, for example apply modern best practices to embedded work, but most of those places are the exact same things that you're writing off: Google, Facebook, etc. Have embedded projects that follow best practices.
Focusing on aerospace specifically, I know of plenty of people who work in aerospace and don't use version control. That's plainly unacceptable. And I'd argue that the problems encountered there are much more self-imposed than at a Facebook.
Db engines again depend. There's a number of really cool modern relational database work, but the places where it happens (postgres, Google, cockroach labs) aren't places where someone who isn't interested in self growth are going to succeed.
The tl;dr here is that the impression I get from your comment is that you're describing a developer who let their skills stagnate because they learning things one way and don't want to keep up with changing processes. The fields you mentioned are fields that have such a stigma attached to them, and not unjustly. It doesn't apply to every person or project in those fields, but the people it doesn't apply to would succeed anywhere anyway.
I'm sure such ageism exists, but you also need to consider the nature of software development. Just over the past decade, we transitioned from one model of deploying software to a totally different one, evolved into a somewhat widely accepted orchestration platform etc. The nature of software developments seems to required that one be capable of learning new technology and be comfortable with understanding new frameworks and such.
I've encountered engineers older than me who are just as excited by new technology as I am and are willing to learn about it and offer their perspective and wisdom as to how its different from what they were used to before, conversations which I find fascinating.
There are also those who I will call less-enthusiastic about the changes; and quickly get overwhelmed by change and either move into management positions or into roles or companies with less change.
I don't think there is anything fundamentally better about one kind of engineer v/s the other. The problem is only when you place an engineer who enjoys the change in a role that doesn't involve much of it, or vice versa.
Couldn't agree more and there is an age dimension to those personality types. Generally 24 yr olds have a very "I know nothing, tell me what to do, I'm excited" attitude while people with a mountain of experience have opinions of their own and, human nature, frequently are resentful or stubborn about being told to do things that feel like reinventing the wheel or a step backward by people more jr than them who did decide to go into management. But following fads in an ever-improving upward spiral (I'm not one of these people who thinks the industry is going in circles) of productivity and expressiveness is just part of the industry reality. Maybe 28 year olds really are more suited, on average, to that reality? They key thing is, even if that is sometimes true, to judge people individually since of course there are older devs who are totally amazing, creative, and flexible and there are 28 year olds that are completely stubborn, unhappy pains in the ass.
To some extent the reality doesn't matter. If the market perceives me as washed up just because I'm 55 then I'd be foolish not to have an alternative lined up. No matter how enthusiastic or flexible you are you will always be trying to push past recruiters perceptions.
My experience is that energy companies, especially the international oil majors, are very good at doing this. Employees rotate in and out of management and IC positions throughout their careers as either part of climbing the ladder or just leveraging their skills in a new way.
I have been an IC for 17 years now (MS/Amzn/Snap) - let's hope I haven't peaked yet :)
But over time I have seen my role change in many ways though: I started as the stereotypical IC, slinging code and did that for a long time. Almost at every level though, sooner or later I ended up with almost full ownership of whatever I was working on. That meant I kept growing in levels and I am where I am right now (Uber tech lead for all data analytics infrastructure at snap).
My current role essentially takes up 10-15% time for company level arch/design reviews, 10% time on interviews, 40% time on preset meetings (scrums/team design reviews/planning/post mortems), 20% time on operations and about 15% time for coding. So pretty much all coding I do is in that tiny sliver or outside office.
I am pretty much a part of all meetings my manager peers are a part of - except for their people commitments. The main differentiation I see between the IC role and managerial is that I don't have people reporting to me. I also don't have to be in ALL the status reporting meetings / managing up etc.
There are definitely times I want to put my head down and get some problems solved, but it usually comes at a cost. So I find some or other engineer to task it on and watch it done most of the times. Rest of the times I don't sleep :)
It is breadth heavy because snap is still a small company in terms of # of engineers. My equivalent role in AWS was a lot more on the building side (50-75% went into building stuff and rest for ops/interviews etc.) because it was a depth position. I did choose this after 13 years of depth roles, it has been quite interesting so far! The biggest advantage I bring is that I can pretty much fix anything in the system and make changes in any component, assuming the dev is not available. I also keep the full stack in my head, so serve as the initial litmus test for new proposals.
I see a bit of misconceptions about pay (I do get paid in the same band as my level to next level give or take bonuses/stocks etc), ownership (My ass is very much on the line for our data quality), responsibility (my managers share the responsibility in a different way - they will get a team member on things that need done and refocus. I will jump in myself if that doesn't work) etc.
I like the freedom. I do like the fact that I can be socially aloof (I am usually friendly, but my friends are outside work) and still get things done. I prefer not to worry about others personal lives (from what I see, this becomes inevitable for managers). I definitely like not having to deliver reviews (I am still a part of the process).
Hear hear! There's still so much to learn - I've been coding for nearly 30 years, and there are entire domains I've hardly scratched the surface of. And now I'm actually getting a chance to apply AI techniques to my day-to-day work!
It sounds like career path for designers has some similarities with software engineers. I think software engineering can potentially offer a much wider and deeper set of opportunities.
Still, in practice, these growth opportunities can seem far less common than yet another senior full-stack dev position. If you want to work with scale, there's Google, Amazon, etc., but most companies don't really need to engineer for scalability and high availability. They just need to ship some CRUD features yesterday.
At some point, it's worth considering whether it's worth the costs to keep pushing up in career for more interesting work, more money, more status, whatever.
It is unfortunate that the industry seems to stick to only “coder or manager” framework. There are technical topics and decision spanning across a few teams or the whole organization: CI/CD, data pipelines, languages / frameworks, consistency, reusable components, best practices, mentoring, integrations.
Can coders who are limited to a single team, without exposure to a big picture, not experienced in business communications, specialists not generalists do it?
Can a director of engineering, who is busy with people management, meetings, plannings, work allocations, who can barely keep up with latest technologies, forgot when they coded last time do it properly? Do you want VP to decide what language or platform to use across the organization?
It is just my opinion and some experience, but I think there is a proper set of responsibilities in many tech companies for such leadership roles without people management, like tech leads on steroids, they can be called architects, principal engineers.
Roughly, 20-30 percent coding, the rest on communications, coordination, designing, mentoring, researching, solving tricky problems, with career progression in the scope: single team -> department, area -> whole organization.
And then there's me, desperate to get into management. Has hussled for 10 years to make it happen, with no luck. I'm currently sending out hundreds of CVs trying to get a business analyst role. No interest. Do you know how many engineers I've seen promoted in 15 years in the industry? 0. None. Had I done a business degree I'd be well away. I'm so old now that even doing an MBA wouldn't help me. I'm currently considering getting a super market job because the thought of going back to programming makes me feel physically ill.
Devil’s Advocate Question: What’s wrong with peaking? I’m 45. I spent 10 years in “Expert Beginner” mode and then spent 7 years moving between 3 companies and for the last 3 or 4 going back and forth between a dev lead, back to an IC to get some hand on experience in some areas I was weak at and now back to an “architect” or a Single Responsible Individual with maybe a team of dotted line reports.
I make “enough” now to meet my short and long term goals and have a great work life balance. Why shouldn’t I just focus on keeping my network current, my resume up to date with in demand technologies, and within the next two or three years when I reach my ceiling, be happy with cost of living raises?
I’m looking at the next level. Management doesn’t interest me. I’m really not interested in the travel requirements of consulting and we are good. I could easily see myself doing the same thing I’m doing now using whatever technologies are trending then at my current company or an equivalent.
But, on the other hand. I might get bored out of my mind and move to consulting just for new challenges and the extra money would be nice but not necessary. A regular old Enterprise Developer in Atlanta can live a good life - especially with dual incomes
Why do we feel the need to "progress" anywhere? I mean, why not enjoy the mastery of the field, knowing your job so well you can do it blindfolded. Somehow a welder or a plumber doesn't need to "progress" to "welding architect" or "distinguished plumber". Yet most of us in tech willingly participate in a stupid rat race that eventually causes a lot of us to burn out. You can't make all the money in the world. On my deathbed I'm pretty sure I won't be thinking of how much more money I could have made. In fact I won't be thinking about work at all.
What a dumb article, the whole thing is the title.
Here's my measure for "meaning density" in article. "How many sentences did it have" divided by "How many distinct points did it make"
this is one of these "lightning rod" articles, where nobody upvotes it because the article itself is good, but rather because it talks about something they are angry about and agree with and want to debate.
138 comments
[ 3.0 ms ] story [ 249 ms ] threadIf you do it right, this also scales well. If you can help a hundred people do their work 10% more productively, that is also more effective than helping four people do their work 50% more productively. Most tech companies that have separate engineering-IC and engineering-management ladders try to keep roughly similar expectations at each level about scope/breadth of impact, it's just that for engineering management, it's "how many people do you transitively manage," and for the IC ladder, it's not as obvious.
I think this article does address that by pointing out that the design management career track generally expects you to manage both increasing numbers of people and increasing amounts of work, and those don't need to be the same thing:
> Overlapping responsibilities between IC and managers is the most prominent issue I’ve observed, but it’s an easy one to resolve by looking at where the line is drawn between people and product on the team.
(This sort of reminds me of a similar problem in academia: there are three separate skillsets, doing research, leading researchers/scaling a research lab, and instructing students, that tend to be conflated into one ladder. They don't need to be.)
No better way to spread your skills to the whole team.
He has way more impact than any individual manager. If you want to have a huge impact at your company as an IC, solve the higher level problems that both you and your fellow developers are having.
Can not be customer satisfaction (by quality) or employee happiness or retention.
I wonder what those other metrics are.
A big one is that managers are de facto judged by the size of their team (and, for more senior ones, the size of the tree underneath them, too). It seems to be really, really hard to have middle management in an organisation without "maximise headcount" becoming an unofficial goal.
Edit: Employee happiness is an interesting one here. It's quite believable to me that being seen to cut down a few tall poppies might have a positive impact on (mean) employee happiness in some cases.
> It's quite believable to me that being seen to cut down a few tall poppies might have a positive impact on (mean) employee happiness in some cases.
This again... I dread to imagine going through the day around people that think like this. But people that think like this exist, and I imagine they concentrate somewhere. If some place makes them happy (and everybody else unhappy as a consequence), you'll probably find them there. This is really believable.
I'm a manager and I have a member of my team that does exactly this. They have built tools and process that has allowed everyone else to be more efficient. Anyone on my team can, but they gravitate towards it. It's up to a manager to make sure they are paid appropriately and make sure that they are given space to actually do this type of work.
I definitely think tools can have a lot of leverage, and an experienced IC could easily develop a tool that would save time for the whole team. And I've seen it happen.
But IME this is the exception rather than the rule. The experienced engineer usually gets the credit for building the system with the tool (for which it was essential), but not building the tool itself. The tool is considered useless until someone has proved it on a important, shipping project.
However, that linear multiplier doesn't mean jack in a world where technology can create exponential leverage. I'm pretty sure on a given day, the potential for a single or small set of individuals (without any centralized management) to produce products and systems that change the world is higher than any day previous.
That is why you see tiny hedge funds doing well, both for finance, quant, and tech workers.
Working on complex problems requires collaborative effort, which can be immensely gratifying not just intellectually but also emotionally (humans are social beings). It is strange to see a warped restriction of the concept of collaboration down to each “individual contributor” doing what they’re assigned, and ignoring the other “hats”. That formulation never allows/imagines a chance for the whole to be better than the sum of its parts.
So, once it all plays out, in a healthy organization, the IC/manager dichotomy seems somewhat counterproductive. I can't say I have a better alternative for larger organizations, but for small teams and startups, I highly advise disbanding it and staying small for as long as possible to avoid it from being forced upon them due to the surrounding culture.
I agree with the sentiment that a dynamic, role based method for delegating responsibility seems incredibly attractive. If you haven't seen it before, Turtleocracy is really interesting (not just directly, but at a meta level as a way to design social systems for these problems) https://www.notion.so/Turtleocracy-47a6df7692bf4e95a39504a73...
If you are an amazing IC, but can’t/won’t help others grow to that level, you are only so valuable to the company - hence the IC ceiling.
You are paid to produce value. If you continue to focus on producing value as an individual, you have to reasonably expect that your compensation will eventually reach a limit.
Let's not kid ourselves, the ladders are never equal, and a senior ic level doesnt translate well to another company. After l7 and above, the skillset is only mostly recognized within the company.
Setting aside the fact that most companies don’t have this, here’s a protip: count the number of engineers at each tier. People don’t get automatically promoted to l7 just because they spent years grunting at l6. It scales with impact, and opportunities for impact as an IC are fewer and farther between than for managers.
Some ICs are not really architects but work on tiny scale on critical bits. There is often some fractal quality to their work and the tiny structures are reflected back into the organization.
Some ICs have come up with patents - the foundation for building businesses with a profitable moat around them.
Last but not least are ICs role models and can have a large impact on the development of other individuals.
It is often not easy to find a way to impact the organization on a larger scale but it is possible. I think the I in IC is not helpful.
There kind of is, though. If you’re lucky, once you hit mid-40, you’re with a company that will be able to keep you on/stay in business for the next 20 years until you retire, because job hunting as a middle-aged “IC”/non-managerial is… unpleasant. I’ve been involved in several hiring committees where (managerial) types would look at a resume and say, “this guy’s been doing this for twenty years and he’s still ‘just a programmer’? Ugh, next”.
They usually have enormous technical debt that elite engineers could disentangle.
Doing so will not be recognised nor appreciated by management.
That one month project could probably be split in to 5 smaller but still meaningful ones.
Agreed. It should be part of the normal workflow and not much talked about.
Heck, even other devs don’t see technical debt as problem. It’s more of a political problem, less technical.
I mean this as a message of hope, not a quibble!
I'd say tech debt is more like a special VAT applied to your current actions, whereas regular debt is proportional only to your past actions.
Unfortunately the economics doesnt play out like this. Whether you have technical debt or not, the stack will get a rewrite every now and then because thats how senior ics will like it or will get promoted because of it. I have seen lots of infra churn that went over budget, didnt result in the impact it claimed, and so on.
Technical debt is overrated.
(Yes, technical debt is often overrated, by young engineers unused to maintaining hairy code. But when it builds up over several years, it can add up to a real problem.)
Meaning... When you choose your debt reduction strategy, you cannot go 0% debt. There will be investments you can do, like increasing deployment velocity, adding monitoring and so on, but refactoring that ugly god object may not be the greatest idea.
Ugly code which is locked away in a module isn't a big deal unless it's a performance problem or bug magnet. I wouldn't really consider that stuff debt, though; if it's not impeding velocity, you're not paying interest on it. Technical debt which has a noticeable interest payment, that's worth reducing.
Sometimes the interest cost isn't obvious. E.g. the UI might be written using some framework which is 5 years old; it might be reasonably clean internally, but the payment comes from developer churn and lack of appeal to devs (whether current or pending hire) wanting to keep their CVs up to date. That cost is real, yet it's imposed exogenously, not because of any deficiencies in the actual technology.
This is part of my point. The eng could have spent 6 more months on making that UI even better, only to have another eng rewrite it in 5 years because... why not.
Most places I gather the non-technical people in charge assume they don't matter so they're basically left as fodder to appease dev leads and make them feel important/creative.
Unfortunately, companies do promote short term gains. Promo cycles are 1-1.5 years long for most companies, as a result people tend to optimize for launching. For managers, in FAANG, that seem to go around # of people that report to you, so they optimize for that.
For a business, there's less incentive to do that investment. You need _some_ investment to keep it long term, but you don't need to put your 100% to make it work. It also comes down to VP of Engineering or equivalent in an org.
Not overdoing technical debt is key. It's a means to an end, the end goal is still $$.
You can always cheap out and get it done slightly faster and slightly cheaper. And you might not have to suffer the consequences. But someone down the line likely will.
E.g. we recently had to install a cleanout for the sewer mainline in our house. Apparently when they built the house, they did everything but install the final above-ground cleanout - instead they just capped it off below ground. The other work, except for the above ground part, all had to be done for testing purposes anyways. But by not installing the above ground part they managed to save something like $10 for each house they built. But now, instead, I had to pay a company $1,200 in labor (they spent all day digging) to install a $20 part when our sewer backed up.
I work in a codebase full of bad, willful technical debt like this. "Let's just do it the easy way" - despite the "hard" way not being harder, just more different than they were used to at the time. Or hard coding things despite being able to derive it from other information - "we can do it later" - good luck, differences creep in and you will spend weeks or even months figuring out all these minor differences and whether they are on accident or on purpose.
6 months down the line, that easy way is completely fucking us up. Certain changes that would have taken an hour take days. And it was completely predictable at the time.
In a similar analogy to yours, most of these systems tend to cause outage somewhere, which are then usually patched on the fly. Depending on a project, shipping fast is usually more valuable than not shipping it for a year. From my pov, i used to be in advertising, and not releasing a billion dollar feature for a year would, by definition, cost a billion dollars a year. If it explodes after releasing, you are still better of by a huge marging because outage would cost much less. Once you have the business going, you can spend money and manpower on the problem, too.
I think this is key: "Hard way not being harder". This depends. Engineers like to overengineer, and without proper supervision they tend to favor technical excellence over business usecase - it needs to be a balance.
On the house example, i bet the value of your house still increased, and the 1500$ you paid is irrelevant in the grand scheme of things. Just like business & rewrite.
Overall, don't get me wrong, I like to use my best skills and put a shiny design out, but i don't do it because I favor doing "good enough".
I can clean up any mess better than most, and I actually enjoy it.
To me refactoring is the design process of modern development. First you write the working code, and then yo design it. Except most people don't bother with the design part, and get dragged down by their atrophied systems.
There is a flip side to this, as some (many? most?) excellent ICs either become poor managers, or hate the job of dealing with humans, or (frequently) both. This is well known and many companies actually want and support top ICs who want to stay ICs with significant freedom to choose projects, generous (time, travel and $$) conference budgets and other perks.
Thus at least some ICs do not go anywhere after they peak (hopefully plateau), which can be a good place to be. But sooner or later they will likely be working under one of their team members whom they did not think much about (who may just be better with people than with technology). This is not a reason to lose any sleep; just something to keep in mind. My 2c.
What’s the difference? Think about when a project fails. “Bad things” happen for the person accountable, whereas the person responsible can move on to the next project. The buck stops at the accountable individual not the responsible one.
In practice, every project has a manager that’s accountable and a lead that’s responsible. As ICs move up the ladder, they’re able to lead larger and larger projects and offer expertise and guidance across multiple projects. Think: providing feedback, from hard-fought past experience, on a design doc that’ll save a team 3 months worth of effort; architecture review, etc. Essentially ensuring and instilling engineering excellence across the organization.
One thing to note, moving up into a senior engineering role may mean you’ll be coding or designing less. And that’s to be expected. Senior engineers understand that coding/designing is one portion of a larger picture that includes communication, eliciting buyin, documentation, architecture, software quality attributes, and many more responsibilities.
In theory, this provides equal management and IC tracks that are fulfilling to all. In practice, very few companies work this way, but there are some out there. And when you find them, you won’t want to leave because it’s such a pleasant experience.
* They descend on random design docs to demand changes, based on vague pattern matching to a problem they faced 5 years ago.
* They don't have to do any of the work to implement those changes, of course. My team has to, and we have to defer to their opinion that changes are needed.
* If the changes they demand end up being really dumb, and hurt or kill my project, they can't be held accountable. Not even when it's a recurring pattern, since every corporate metric will show that the project team are the ones who messed up.
Maybe our disagreement is less severe than I'm thinking, since I also wouldn't agree the IC model at e.g. Google works like you're describing. But separating accountability and responsibility is in my experience an unmitigated disaster.
Top ICs work together with ICs that represent their teams, so that they can make informed decisions. They are up to date with technologies (this must be an obligatory requirement), code regularly, so they are much better then managers to make efficient company wide technical decisions, own the architecture of the whole system or large parts, organise and overlook large and expensive engineering initiatives, drive prototypes and research projects. They must me accountable for being up to date, understanding the consequences of their decisions, getting feedback from managers and engineers - not turn into “astronauts” in some years.
I think ICs should go in parallel with engineering management in the reporting chain: the top IC reports to CTO, next level reports to directors, etc. This ensures that IC’s scope of responsibilities is expanding and they have better visibility and power.
That’s how it works at IBM. I’m the “responsible” party and technical leader for a couple of teams working on related projects. I report to a program director who reports to a VP. My peers are line managers and other senior tech leaders. Part of what’s great about the team that I’m in is that we ha e clear talent pipelines that show how you can matriculate upward in design, engineering, or management, and that a “band 10” of engineering is equivalent in scope, comp, influence, and autonomy to his or her manager equivalent or design equivalent. That extends into the executive ranks as well though it’s more common to find people who hold dual roles of VP and Fellow or Director and Distinguished Engineer or Distinguished Designer.
My experience says that ICs are best embedded in the team to deliver working code with patterns that are conceived from exposure to the real problem being solved.
I feel like one of the worst things that can be done to engineers is disconnecting them from the problems being solved.
Then, by definition, they wouldn’t be an “embedded” engineer, no? In fact, what you’ve described is not at odds with what I’ve described.
I’d like to hear more on your thoughts about Google’s IC track and implementation, especially if you’ve worked there. Care to provide a compare and contrast?
At Google, high level ICs seemed accountable by most standards. They couldn't just abandon projects when they became boring, they got in trouble when their projects didn't work well, and the weird committees (which admittedly did exist) generally felt like guideposts more than obstacles.
On moving up the ladder while staying an individual contributor -- IME as one becomes the tech lead of larger and larger projects, the "tech" part shrinks and "lead" grows and the setup has a constant forcing function into a "manager in all but a name" setup. One might resist, but this is frequently a pretty hard push.
Your second point is spot on. A natural tension arises as ICs move up the ladder, and if one values being an IC, then one must maintain their boundaries.
Depends on the org and company, to be completely honest. Sometimes, management and leadership have little true accountability and that ends up falling on ICs. Projects fail and senior ICs are blamed instead of management because they were "responsible for the implementation". Accountability without responsibility or vice versa often ends up in failure.
At some point, I simply cut and pasted the paragraphs of my performance self-reviews and actions for growth from one year to the next and told my manager: “WYSIWYG, you know what you can expect from me, you know I’ll learn anything that’s needed for the job, and more. What more needs to be said?”
And that was the end of self reviews and we all lived happily ever after.
In general I don’t think there is anything wrong with “peaking” at a point in your career where you feel fulfilled without feeling pressured to always take on more responsibility and stress. If you want to lead projects or manage people, go ahead. If you just want to write code, that’s fine too. Of course depending on the company your compensation might top out after a certain point, which you may or may not be happy with. But at least in the bigger FAANG-type companies, you can go pretty far as a “tech lead” style of IC, without directly managing people.
So true. Especially after having a kid, I'm dreading any further promotions above the usual Senior. I'm happy at the level I am for the last 5 years and don't see why I would suddenly want to spend more hours in meetings and be held responsible for more things?
In places that allow senior non-manager ICs, those ICs are determining what to do. The managers are figuring out who and when to do it, the ICs are going to figure out the details, tech ordering, research, etc.
Usually the way it works is I'll identify a large scale problem, work to quantify it, cost it out, work to find the manager who is most appropriate for it. Work with that management chain to further quantify cost and benefit of fixing the problem. We'll get high level resourcing and prioritization for the work. I'll get going on deeper research, role needs, design docs and v0 implementation. Manager will get going on hiring. At some point I'll swap from driving everything to doing, and just lob prioritized tasks to the managers. Essentially I'm working as a Product Manager and IC coder at this point, eg I'm saying what we should be doing (PM) and doing the work. However at this point the manager is actually setting sprint task level priorities for me. So weirdly the work goes PM (me) -> SDM (mgr) -> IC (Me). At this point the SDM will usually have hired some other devs or a PM and we just fit them into the flow. At a certain point I'm really just a Lead on the team while we groom up a permanent lead. Or if it's a longer project I'll stay in the Lead role for a year. The manager, PM and I are all working together. I don't have to manage anyone but I do a ton of mentoring and product work and communication.
They asked me a while back if I wanted to manage people (manager came from where everyone here seems to be coming from). But when we discussed it they didn't want to lose 30% of my time to management duties.
A highly effective manager will be able to delegate large parts of their perceived responsibility to others, which is how they get to 100% productivity. Same can happen for managers.
Some call it managing up.
Not every company actually defines a role like this (mine doesn’t), but it is a role every healthy large-scale company needs.
And what were your feelings on the matter? You make it sound like "they" decided you would not go into management, regardless of what you wanted.
I find when you're working well with your management then things just happen and there isn't much fretting or arguing. In fact I have to often call out distinctly "are we all clear were making a decision here." And then we just move forward.
Personally, I don't think it's necessarily a bad thing when IC's who max out their value writing code transition to other things. I agree not everyone makes the transition successfully, but it's a great opportunity for personal growth, and the potential for upside is high, since an organization can gain a leader with very nuanced and deep insights into product + market.
It might be that I see this from an engineering perspective and that "the market" and stockholders wont notice in the short term until the brand gets a quality reputation in 10-20 years from user hearsay.
Managers on the other hand seems to mostly have the duty of fighting fires and putting out fires - with the most important quality of not litting fires themselves. There is no way a great engineer working as a manager have time to deal with deep proactive technical issues where I have worked.
StrengthsFinder 2.0 from Gallup
1 VP per
8 directors per
64 team managers.
So, how are there more openings at higher levels?
1) in those 8 person teams you mention there may not always be a place for an expert IC
2) companies often reserve the IC-expert budget slots for internal IC promotions while relying on management slots on external recruitment to a higher degree
Additionally, it can be easier to transition to an equivalent or higher role from one company to another on the management side. Most companies are open to hiring a VP from outside but often the highest levels of IC roles are only filled by those with significant experience within the company.
The knowledge and ability to do tech work is great, but many jobs require that AND some other skill set (sales, research, communication, people management, etc). Those jobs also tend to be very well paid.
For engineers, at least in larger tech companies, there's often a tech career ladder that runs parallel to the management ladder where you can have salary and responsibility growth as an IC without managing people. These ladders usually top out at a "distinguished engineer" or "fellow" level that's roughly equivalent to being a VP.
EDIT: added clarification about company size
Ok. That's great. How about the small product companies that have like 20 or 200 engineers as opposed to 2,000 or 20,000?
I have worked at and worth several companies which purport to have this parallel track. In practice there seems to be much less need for senior engineering and much more need for senior management. There may exist a parallel track but there aren't many positions on that track.
A-Management.
B-Consulting.
C-Stagnation.
D-Endure a string of jobs where they are mobbed because they are seen as a threat until they retire from the industry.
E-Continue working as an IC, satisfying their intellectual and financial needs.
In software this is very often not the case. A 55 year old still fluent in hot tech and a lot of strategic work as an architect, interventionist, mentor to younger devs, etc and who can demonstrate all that in their resume will probably do ok. A 55 year old who is "just" a coder will often have a rough time (vs 28 year olds getting actively recruited 5x/week).
In other industries, like EE where I also worked for several years, this is much much less true. Very senior ICs are highly valued and it is common for teams to be a blend of engineers from fresh grads upto near-retirees.
To avoid ageism while being an IC you need to find a job in a niche where the domain is CS and/or ENG based (as in embedded, aerospace, or even relational database engines) and these jobs are far and in between.
Beware: jobs like Facebook seem to be CS based but they aren´t (that´s why their programmer average age is 27). The CS problems they have are due to arbitrary complexity and they are short term. Companies like these are media companies.
I’m 45, still an IC mostly but my next role whenever I decide to leave my current job, will probably be working for a consulting company. Currently, I am “more equal than others” and have more influence based solely on my “relationship and expert” power.
In the cloud consulting space or the generic “digital transformation” space, you have a few customer facing consultants and lots of low paid people doing the grunt work.
I am not seeing any shortage of openings for either “principal software engineers”, or architects. Of course, I’m staying away from the west coast. The major cloud providers and their partners are hiring in most major cities as long as you’re close to a major airport. I happen to live near the world’s busiest airport.
I could just as easily claim that coders who refuse to develop new skills and keep up with a changing environment will eventually find themselves sidelined, due to their inability to adapt to changing needs. Since most of those middle aged people started programming 30 years ago now, they then move into environments where the technologies also haven't evolved in 20-30 years: embedded, aerospace, and dated DB work.
This doesn't preclude people who can evolve from keeping up as mostly-just-coders in a changing world. Calling the complexity inherent in something like facebook "arbitrary" as opposed to the complexity in embedded work as innate just implies that you don't understand the "CS" problems that Facebook (or similar) deal with, and I can imagine that a company like Facebook might not want to hire someone who, for whatever reason, is unable to accurately analyze the complexity of their problem space, especially at a more senior level.
Please answer: do you think aerospace, embedded and relational DB engines is dated work that has not evolved?
And calling modern app development's probelms " due to arbitrary complexity and they are short term" isn't?
I do think that much of the aerospace technology industry uses dated methods. Same with much of the embedded field. There are certainly places that, for example apply modern best practices to embedded work, but most of those places are the exact same things that you're writing off: Google, Facebook, etc. Have embedded projects that follow best practices.
Focusing on aerospace specifically, I know of plenty of people who work in aerospace and don't use version control. That's plainly unacceptable. And I'd argue that the problems encountered there are much more self-imposed than at a Facebook.
Db engines again depend. There's a number of really cool modern relational database work, but the places where it happens (postgres, Google, cockroach labs) aren't places where someone who isn't interested in self growth are going to succeed.
The tl;dr here is that the impression I get from your comment is that you're describing a developer who let their skills stagnate because they learning things one way and don't want to keep up with changing processes. The fields you mentioned are fields that have such a stigma attached to them, and not unjustly. It doesn't apply to every person or project in those fields, but the people it doesn't apply to would succeed anywhere anyway.
I've encountered engineers older than me who are just as excited by new technology as I am and are willing to learn about it and offer their perspective and wisdom as to how its different from what they were used to before, conversations which I find fascinating.
There are also those who I will call less-enthusiastic about the changes; and quickly get overwhelmed by change and either move into management positions or into roles or companies with less change.
I don't think there is anything fundamentally better about one kind of engineer v/s the other. The problem is only when you place an engineer who enjoys the change in a role that doesn't involve much of it, or vice versa.
But over time I have seen my role change in many ways though: I started as the stereotypical IC, slinging code and did that for a long time. Almost at every level though, sooner or later I ended up with almost full ownership of whatever I was working on. That meant I kept growing in levels and I am where I am right now (Uber tech lead for all data analytics infrastructure at snap).
My current role essentially takes up 10-15% time for company level arch/design reviews, 10% time on interviews, 40% time on preset meetings (scrums/team design reviews/planning/post mortems), 20% time on operations and about 15% time for coding. So pretty much all coding I do is in that tiny sliver or outside office.
I am pretty much a part of all meetings my manager peers are a part of - except for their people commitments. The main differentiation I see between the IC role and managerial is that I don't have people reporting to me. I also don't have to be in ALL the status reporting meetings / managing up etc.
There are definitely times I want to put my head down and get some problems solved, but it usually comes at a cost. So I find some or other engineer to task it on and watch it done most of the times. Rest of the times I don't sleep :)
It is breadth heavy because snap is still a small company in terms of # of engineers. My equivalent role in AWS was a lot more on the building side (50-75% went into building stuff and rest for ops/interviews etc.) because it was a depth position. I did choose this after 13 years of depth roles, it has been quite interesting so far! The biggest advantage I bring is that I can pretty much fix anything in the system and make changes in any component, assuming the dev is not available. I also keep the full stack in my head, so serve as the initial litmus test for new proposals.
I see a bit of misconceptions about pay (I do get paid in the same band as my level to next level give or take bonuses/stocks etc), ownership (My ass is very much on the line for our data quality), responsibility (my managers share the responsibility in a different way - they will get a team member on things that need done and refocus. I will jump in myself if that doesn't work) etc.
I like the freedom. I do like the fact that I can be socially aloof (I am usually friendly, but my friends are outside work) and still get things done. I prefer not to worry about others personal lives (from what I see, this becomes inevitable for managers). I definitely like not having to deliver reviews (I am still a part of the process).
Feel free to ask me any questions.
Hear hear! There's still so much to learn - I've been coding for nearly 30 years, and there are entire domains I've hardly scratched the surface of. And now I'm actually getting a chance to apply AI techniques to my day-to-day work!
Still, in practice, these growth opportunities can seem far less common than yet another senior full-stack dev position. If you want to work with scale, there's Google, Amazon, etc., but most companies don't really need to engineer for scalability and high availability. They just need to ship some CRUD features yesterday.
At some point, it's worth considering whether it's worth the costs to keep pushing up in career for more interesting work, more money, more status, whatever.
Can coders who are limited to a single team, without exposure to a big picture, not experienced in business communications, specialists not generalists do it?
Can a director of engineering, who is busy with people management, meetings, plannings, work allocations, who can barely keep up with latest technologies, forgot when they coded last time do it properly? Do you want VP to decide what language or platform to use across the organization?
It is just my opinion and some experience, but I think there is a proper set of responsibilities in many tech companies for such leadership roles without people management, like tech leads on steroids, they can be called architects, principal engineers.
Roughly, 20-30 percent coding, the rest on communications, coordination, designing, mentoring, researching, solving tricky problems, with career progression in the scope: single team -> department, area -> whole organization.
I make “enough” now to meet my short and long term goals and have a great work life balance. Why shouldn’t I just focus on keeping my network current, my resume up to date with in demand technologies, and within the next two or three years when I reach my ceiling, be happy with cost of living raises?
I’m looking at the next level. Management doesn’t interest me. I’m really not interested in the travel requirements of consulting and we are good. I could easily see myself doing the same thing I’m doing now using whatever technologies are trending then at my current company or an equivalent.
But, on the other hand. I might get bored out of my mind and move to consulting just for new challenges and the extra money would be nice but not necessary. A regular old Enterprise Developer in Atlanta can live a good life - especially with dual incomes
Here's my measure for "meaning density" in article. "How many sentences did it have" divided by "How many distinct points did it make"
this is one of these "lightning rod" articles, where nobody upvotes it because the article itself is good, but rather because it talks about something they are angry about and agree with and want to debate.