My experience is much the opposite:

the managers who want to write a lot of code usually are so focused on their contributions they fail their other responsibilities.

The ones who are trying to set product direction are usually harmful, too.

The managers I've had the best experience with are the ones who focus on helping their ICs navigate the larger organization, dealing with human issues, and helping the ICs understand organizational priorities, and evaluate risks.

what's an IC? a piece of corporate-speak i haven't come across before.

Others have answered what the words "IC" mean, but let me add that this is the usual name for the technical career track, i.e. the not-management track, meant for people who do not want to manage teams of people.

Strictly speaking, the roles of Engineer Manager and IC are incompatible; you cannot want to manage people and at the same time want to stay out of it. So in this particular context, "EM+IC" is a misnomer for "EMs who also need to be able handle tech/coding tasks themselves".

> this is the usual name

I dunno if it's just me, but it seems like the term came out of nowhere just a couple years ago.

True! I meant the usual name now. For me it's the same as Engineer Manager: it seems to have come out of nowhere but it's the standard now. Before we called them simply "managers" (or sometimes "team leaders" of the non-technical variety).

PS: are you by any chance the same Izkata as the one in scifi.se?

Yep I am. Haven't been very active there for a while though, usually just end up there from Hot Questions when procrastinating.

I also never saw this until pretty recently. At first I assumed people were talking about independent contractors because it was the first thing that came to mind, it possibly fit the context I saw the term used in and nobody explained the acronym they just dropped it there like I was supposed to know what it meant.

Took a bit longer to realize they meant individual contributor.

And it sounds better than "assembly line worker."

> At first I assumed people were talking about independent contractors because it was the first thing that came to mind

Mine was "integrated circuit" which was like a really dystopian version of "human resources".

I've been hearing it for about 5-7 years now, usually in the context of career paths. I think it became popular when companies realized that non all developers are made for management and you need a separate career track for people who want to advance, but don't want to be a manager.

Principal engineer, architect, etc all fall into the IC career path, while, manager, director, VP of eng, etc all fall into the management track.

principal eng, architect et al must rely on managing devs for any meaningful project.

It's more project management than people management. You likely have to lead projects and maybe a team, but you're usually not responsible for anyone's career growth (other than your own).

Same; I saw an interview with Steve Jobs in the 80s or 90s where he used it. I was surprised.

To clarify, EM stands for Engineering Manager not Engineer Manager. EMs are generally expected to be technical, but not be engineers writing code on top of being a manager.

Yes, agreed: Engineering Manager.

I often make this mistake because English is not my first language, and I confuse "engineer" with "engineering": in both cases it sounds to me "a manager who manages engineers", not "a manager who is an engineer him/herself". Kind of like a "Product Manager" is a manager who manages the product, not a manager who is a product!

No worries, just wanted to make sure people didn't get confused and think it was a dual Engineer/Manager role :).

TLM is the term I've heard for that more often.

what does TLM mean? i wish that all you folks out there would understand that nobody outside your bubble knows what these daft abbreviations stands for, much less mean.

TLM (at Facebook) stands for Tech-Lead Manager - it’s a hybrid role, with engineering duties and people management duties.

From what I remember, it wasn’t intended as a long-term position, but was used in stop-gap circumstances (manager quits, tech lead temporarily takes on some people management duties) or for when an engineer was considering transitioning to the management track.

Yeah, it's an "M0" role. Generally folks who transition from senior engineer into management become TLMs. Staff engineers transition to "M1" or a full-fledged manager.

TLMs still have individual contributor responsibilities. M1s don't. The reason for that is generally that (especially junior) ICs aren't likely to push back against poor technical decisions knowing that the person they're pushing back against is also in charge of their rating. This feels quite fair based on my experience and as such I'm quite skeptical about TLMs in general.

> Yeah, it's an "M0" role.

Not true, TLMs can be D1+ level too at FB/Meta. Higher level TLMs more often than not tend to occur in more research-oriented organizations though (where the TLM is effectively a "principal investigator" type for some research area).

Oh that’s interesting; I haven’t heard of that at Google. Makes sense though as it maps well to a PI role in a large research org.

Tech Lead Manager is my guess. I'm familiar with the term "tech lead," at least.

Transfer length method :)

Too little motivation?

It’s honestly getting out of hand. It’s almost as if one requires a dictionary to communicate these days. Even though I know these abbreviations it’s just off putting.

Ever heard of Google?

Individual Contributor.

Don't ask me why in heavens that term makes any sense outside one that is myopic or only works with extremely fresh out of school junior engineers and unskilled workers.

when did this appear? i literally have never seen it before i read this post, and it makes no sense at all to me.

It has been in common use for at least 15, if not 20 years.

Very common phrase in the tech industry.

i have worked in tech for over 40 years at all levels and, as i said, i have never come across the term before today.

Just in the past week "IC" has appeared in 2 front page stories on HN.

Are you US based? Beginning my career in the mid 00s I was exposed to "IC" pretty much day 1 starting at Microsoft.

Other people around me in adjacent sectors also use the phrase to refer to non-managers, it is pretty common daily parlance, I am 99% sure I can ask any of my knowledge worker friends and they'll know what I am talking about.

Google trends show "individual contributor" has been a pretty popular phrase since at least 2011.

no, i am not us based, though i have worked there. but so what?

is "knowledge workers" still a thing? it was meaningless when it was introduced in the 60s, even more so now.

another bubble creature, i guess.

* * *

as a matter of interest what, as vaguely as you like, do you work on? because you seem uninformed to me and it is not obvious to me that you know what you are talking about. there is one tech giant that has always been based in seattle. well, make that two.

You seem to be the one who is uninformed, considering you've never heard the term IC.

Yes, everyone knows there are two tech giants based in Seattle. What this person was saying is that other large companies have also opened/grown Seattle offices in the past decade and vice versa, which has caused usage of corporate vocabulary to merge.

Maybe you should reflect on the fact that you don't seem to understand what people in this thread are talking about and stop acting like you do.

Naw, knowledge workers have developed into a real thing.

The labor group that requires significant creativity and autonomy to be effective. The artifacts they create are a minority of the value they create.

Mostly they became a real thing because traditional management techniques fail to work well with knowledge workers.

you said 20 years, now it seems to be down to 12

By "tech industry", a lot of people here tend to mean internet ad companies and/or startups designed to be acquired by them.

> It has been in common use for at least 15, if not 20 years.

I've been in the industry since 1998. The first time I saw it was on HN a few years ago (maybe 3 or 4).

I just searched HN and found references 12 years ago.

> I just searched HN and found references 12 years ago.

Hah!

I would just love to see that thread - may it is also filled with "What's an IC?" :-)

I am not sure. It has been around for at least 5 years I would say. I guess at some point they needed a nice sounding alternative category to people not becoming managers.

This is FAANG speak. They created this role for people who are not (directly) involved in management.

so i guess that managers are not individuals and don't contribute? might be true. but i've been a manager and an individual and contributed code. well, who knows?

As usual, "it depends." Many individual contributors don't actually contribute, either. Some actually have negative net contribution.

The point is that ICs are judged based on their individual contributions, i.e. their own code, design docs, etc, whereas managers are judged based on their team's contributions

i have never, ever come across a programmer working on a system of any complexity that did not depend on contributions from other programmers.

Why are you being so pedantic? At this point it seems like you're trolling.

> so i guess that managers are not individuals and don't contribute?

> i have never, ever come across a programmer working on a system of any complexity that did not depend on contributions from other programmers.

No one said non-ICs aren't individuals, and no one said they don't contribute. No one said that ICs don't work with others or depend on others.

What has been said, several times, is that their contributions (i.e. the code they produce, artifacts they create, etc) are largely individual contributions. They are the ones creating the thing, and are not responsible for others.

This gets a bit murky as you move up the IC chain, in that your contributions become less tangible and are in part measured on how you lead others and make those around you more efficient. But your performance is still largely judged on what you produced.

the nuance you are missing is that individual contributors are responsible for their own work and judged based on that. they are not responsible for the work of others. managers are of course responsible for the work of those they supervise

Or managers are individuals who contribute non-individually, making them non-ICs?

A->B != !A->!B

Lots of people who aren't part of the "working class" do plenty of work but that's the nomenclature society uses for some reason so if you want to communicate with everyone else, you have to go along with it.

I actually like the term as it seems pretty accurate to me and I don’t know if a more accurate term.

There’s many types of “managers” who are actually individual contributors (eg, sysadmin, project admin).

When you get into principal engineer and architect titles, sometimes those positions manage people and sometimes they don’t.

I think it also highlights how one version of contributor isn’t better than the others. Some people only produce value by being part of a team, some produce value by managing, and some produce value direct from themselves.

I've always like the term soldier. It's what organized crime syndicates, armies, and ant colonies all use. The worst is when someone gets called a "resource", but I can't get too exercised about IC.

As a consultant, I've become accustomed to being referred to as "the resource" by operations people. However, the day an engagement manager refers to me directly as "resource" is the day I openly start referring to them as my secretary.

i keep envisaging what some of these uber stupid job names would look like on a business card i might have to give to a client:

zab zonk

the resource

zab zonk

individual contributor

jesus wept

Nobody has IC as a title, it’s a whole class of job families that don’t require/revolve around managing other employees. Data Scientist, Software Engineer, Data Center Technician are all ICs. It’s just a more positive way of saying “not people manager”, especially when you are trying to build a culture that going into people management shouldn’t be the only career path.

why do you need to say "not manager"? most people are in the nature of things not managers. and if you do need, for bad, bad reasons want to differentiate them, how about NMs? oh, but that would be to obvious for the current crop.

Individual Contributor. Line engineer. Has a manager and likely doesn't have direct-reports of their own.

Individual Contributor

Individual contributor

Individual contributor.

Individual contributor

objectification of resource... “commoditizing your complement” for management.

edit to add "in my experiences" I have also seen good evidence via HN that not all management/admin is as dilbert like as I have seen.

I'm guessing Individual Contributor. Someone who is not management but also not support (administrator, sales, HR, etc.)

Writing code as a manager is my number 1 stressor.

As a manager, I have to deal with so much random bullshit. I don't mind it, but it's extremely difficult to manage that bullshit alongside code and sprint commitments. "I couldn't deliver" is remembered far more clearly than "I couldn't deliver because I was helping the team with X other thing that was far more important.".

You are very fortunate to have had that experience.

Usually, when a manager/director/etc decides to write a lot of code, the result is barrages of rushed pull requests made between meetings. You will be lucky if the code in any of those PRs was actually run, and you can forget about enforcing test discipline, so you have to scrutinize them much more carefully and clean up when they get merged without incorporating your suggestions.

Agreed. I'm a manager who doesn't write code anymore (at work) and, at best I'm adding log statements or updating documentation. I'm still encouraged to write code if I can, but it just doesn't make sense.

When I had a single digit number of developers on my team, writing code was still possible. When I started closing in on double digits, I realized that I had so many other things to do that, at best, I was only going to have a few scattered 30 minute or 1 hour blocks each day to write code. Also, a lot of my job is to handle the unknowns that come up, so I also couldn't really commit to any hard deadlines.

That means, best case scenario, I could only pick up work that wasn't high priority and that didn't require long periods of uninterrupted time. I still love writing code, but my philosophy has always been to focus on the things that only I can do. Low complexity projects that no one is waiting for can be done by just about anyone. My "staying in touch with the code" time is better spent doing PR reviews or reviewing design docs.

Anyone without intimate knowledge of the product they are working on is useless IMO. I was in the code daily when leading a team and don't respect any development team leader who isn't.

Absolutely. Of all the companies I've worked with, the one with absolutely the most effective management was the one where every manager was also a part-time IC. The head of mechanical engineering had to design a product while managing the team. The shop manager was also working as a machinist for most of their shift, or working on jig design and metrology. The head of accounting, of course, spent most of their time accounting, and only part of it managing the accountants. The head of software also wrote software, although not as much as their subordinates, and they were reviewing the codebase all the time. Of course none of the managers would chew through their IC work as quickly as people who could devote all their hours to it, so they mainly picked up tasks that weren't critical-path to avoid becoming blockers to their team.

The CEO rotated through positions, spending several months working in customer service, inventory, accounting, and even working directly on the production line. He mainly put himself on whichever team was most short-handed, although it was more to learn firsthand what their challenges were, and how the company could allocate resources to solve them. Fortunately he was a multitalented guy who could pick up those roles productively, and also humble and down-to-earth enough to not intimidate his colleagues too much when he took over the neighboring desk.

Aren't Product Managers & TPMs considered ICs? They don't have direct reports but aren't writing code either. I imagine this will be a more common option for these Engineering Managers who are managing other managers

It’s the same structure for PMs (ICs and managers of PMs). In general I’ve noticed PM managers spend more time in IC type of work than EMs

Product Manager can refer to an individual contributor IC or someone who also manages other Product Managers (and sometimes even adjacent functions) e.g. a Group Product Manager. The titles are not very standard though. Many of these roles are hybrid as well. For example, a Product manager who will be responsible for a Product portfolio and some products in that portfolio as an IC, while managing/supporting the work of PMs working on other products in that portfolio.

Same for TPMs. They can be ICs or managing other TPMs.

I have worked with some fantastic "people managers" in my career who don't write code. But they usually faded into the background most of the time, except for when they needed to communicate something or I needed their help with something.

The bad managers were always working hard to schedule more meetings, force extra process into every step of our work, make decisions about how we did our work, and to change our priorities to work on their pet projects.

The bad managers occupied 10X more of my time than the good managers. It only took one or two bad managers to completely derail productivity of an entire group.

> I have worked with some fantastic "people managers" in my career who don't write code. But they usually faded into the background most of the time, except for when they needed to communicate something or I needed their help with something.

Yep, that's familiar. Good "people managers" have always been the ones that removed obstacles, and didn't become one themselves.

> They instead encourage them to focus fully on process and sprint management.

Thats literally the point. Its totally fucking batshit that somewhere like meta still uses spreadsheet to plan. This is why properly trained people should be doing management.

Project management at scale is not something you "dip into" its a full time job to project manage and people manage. Its not something most ICs should be doing.

A chief surgeon leaves a team, but they don't manage the timesheets of the juniors, nurses and assistants. Meta very much expects that a chief surgeon not only does surgery, but fills rostas, recruits nurses, does some marketing and works on the legal policy for negligence.

The issue at meta is that with the growth there is no "leadership". What is a lowly IC supposed to work on? "create consensus" and "drive from the bottoms up". That doesn't work when you have 11 layers of management, all pissing about talking about impact, but not actually driving projects.

> I would think that the role of an "Engineering Manager" or "Tech Lead" or "Team Lead" etc. should all be pretty interchangeable, or at least have very high overlap.

You should try it. Its pretty clear you've not managed people at any level of scale or formality. Not everything is code, babes.

(No. I'm not a manager at meta, thank fuck, it sounds pretty shitty.)

Chief surgeons do all those things you describe. Check out the job description [0] as they are basically department heads doing recruiting, budgeting, supervising, etc. Chief Surgeon doesn’t mean best surgeon.

[0] https://www.betterteam.com/chief-surgeon-job-description

Sorry you are right, I meant a consultant.

But it is a bad analogy, as you've implied. What I was trying to get across is managers should be specialised, they should be someone who might or might not have been a programmer, but is now specifically managing people, or projects.

Managers who code, do exist, as to engineers who manage. But its better at large companies to have specialists to manage projects and people. With support, training and performance management, you tend to get a better outcome.

What’s interesting is that all chief surgeons were once surgeons, probably really good. So there’s idea that you have to do the thing to manage the thing.

Medicine is strange in many ways, but I think this isn’t a bad practice.

I’ve worked for non-dev managers and sometimes they are good. But I prefer to work for someone who at least once was a dev as I think they understand better what is possible and how to coordinate and lead.

When I managed teams I always tried to do something useful in the codebase. I don’t think it is possible to manage well and work deeply enough to make great software. But it’s possible to at least be able to do my own builds and at least test out different techniques.

My team at Amazon still uses spreadsheets and I much prefer it to Jira.

Pournell's Iron Law¹ in action. The administrators will always hoard the power and control promotions etc in an organisation.

Studies have shown time and again that small autonomous teams is the most optimal setup for software development. Having a layer of Director, SVP and VPs on top of EMs is just Pournell's Iron Law manifesting itself.

1: https://www.jerrypournelle.com/reports/jerryp/iron.html

You're pretty much just repeating the constant engineer gripe of "What do managers even do". The point of management is co-ordination and direction. They're not there to contribute to the codebase, they're there to ensure people are contributing the right things to the codebase. If you really think these managers/directors/VPs are useless, describe what you think they're meant to be doing, and how it would get done without them.

This is the sort of thing that you don't recognize until you become a manager, and then you do and you watch everyone on your team run around like a bunch of kids chasing whatever caught their attention that day and it all becomes a lot clearer.

"Why are we doing this" and "how does it align with the business's goals" and more pointedly "what are we not doing so we can do this instead" and "is that the right trade-off" are all questions even very technically gifted engineers seem to have a really hard time answering.

The issue is most managers don't tend to think this specific way. They think of how to align the business goals to suit their specific needs (i.e. getting promoted).

Every single re-org I've been involved in was bureaucratic mess to give a manager a higher salary. There was no explicit reason why we needed to re-org, and no org change ever made a difference in terms of productivity. Our individual teams still operated the same.

It's not that they are useless, it's that there are often too many of them. At a previous SV org I worked for, they had roughly 1 "dev manager" for every 4 engineers. You could have 1 for every 10 and achieve the same result.

I’m not sure if that’s true. 1 dev manager for 10 engineers might be tough. The sheer number of 1:1s would be insane, much less keeping track of the career trajectory of 10 different people at 10 different parts of their lives. I guess this would be less difficult if everyone was already at senior or staff level, but you’d still have so much of that managers time sucked into 1:1s, reviews, and team retrospectives. I’m not even a manager and I start to feel neglected as an engineer once my manager juggles more than 6 other people, because I see they start to forget what I’m working on, and those 6 start to compete for attention to get promotions…

I guess you have never been a manager.

There is no way you can manage 10 engineers and still have good technical knowledge of what they do and provide directions.

I have, though the team size was 7 (company ran out of cash.) 10 may be too many. But 4 is way too small.

Also, I want to add that the team with the manager of 4 engineers, he provided no technical direction. That was my job as the "tech lead."

I think it can go either way (and at Meta, I have no idea), but team size tells you nothing. You can have a team of 4 highly productive engineers working on a specific project with limited scope and 1 manager can manage that very effectively. But you can't have that manager manage two teams, you're literally just splitting their focus (and with 4 people the manager can be hands-on). On the other hand you have plenty of teams that were at one point 4 productive people, grew to a team of 10, now the manage is very productive! Managing a team of 10 people, but in reality that team of 10 is now struggling to work efficiently and are probably producing the same value as the previous team of 4. The management structure is entirely determined by the underlying scope of the work that needs to be done - and yes, very often it goes astray, but in every direction.

You are right about team size, but in many companies, the "dev manager" is certainly not hands on, even with small teams. The last team I was on, the "dev manager" never even set up his development environment. He always claimed he wanted to get more involved, but probably had too many other priorities. If you are managing a team of 4, not making any technical decisions, not writing any code either, in my opinion, it is a bad sign. You are too out of touch. Hands on is necessary with small teams.

In those environments, all the technical work and decisions are delegated to a tech lead / staff / principal eng. The "dev manager" is there for people management and high level sprint planning. Planning can be done with very little technical knowledge since the team itself does the sizing and scoping.

Obviously not every company is the same, but that was my experience at a mid-size SV tech company.

> What do managers even do

I understood the role of managers after I joined a chaotic startup which hired a bunch of people but didn't think of management. It was a complete mess. Senior engineers didn't want to manage, or didn't know how to do it. And good managers are very hard to find.

If coding is beneath you, working in software is beyond you.

> If coding is beneath you, working in software is beyond you.

maybe the problem you are trying to solve isn't code.

> ICs do not need managers, managers need ICs.

Given the level of infantilisation at meta, and big tech in general, I think this is clearly not the case. "self management" (ie bottoms up management) stopped working at meta many many years ago.

> Some managers have negative productivity.

So do a lot of ICs "I'm rewriting x in NEW_LANGUAGE because its faster" & "just read the code, that's where all the answers are" & "no you're doing it wrong, just re-write this major system to make it do something completely different because I've not taken the time to listen to your problem" Meta is a massive pile of "not invented here" tech debt, that was half arsed for impacc and then abandoned. Most of that is IC ill disciplined "oh but I'm BORED I'm going to make a new x".

Don't get me wrong. I've had some complete bellends of managers, but that's not a function of them being a manager, that's a function of no training and ineffective performance management.

Writing code is easy,

Writing good code is not so easy

Reusing other people's code is hard

Making an entire company reuse code is fucking difficult.

Getting prima-donnas to document code so that other people can use it quickly, super fucking difficult.

Managing programmers so they don't start gnawing at the furniture, rebuild everything every six months, wank over the interns and getting them produce a viable product, one that they can't/don't/wont use is top level hard. It's something I don't want to do.

I edited it as you replied, but sure.

If you think developers are prima donnas wait until you hear about managers. Compared to developers, many of them fit much more into the prima donna description.

Most managers don't document anything and when they do, it is of low quality and goes unmaintained quickly.

Most managers out there are redundant and have no idea about what leadership is. They just get an orgasm each time they say no and conflate that with being a true leader.

The reason hackathons produce amazing results is because it is what happens when managers get out of the way for 1 day: improvement driven by builders that care about the product, not office politics.

https://youtu.be/fj0hpsJvrko

> wait until you hear about managers.

You're assuming that I've never really worked anywhere with managers, good or otherwise.

> Most managers don't document anything

yup, and they are insufferable dicks for not doing it. But, in big companies you need to have presence, so managers that are successful tend to have a documented paper trail of "their" successes. Whether its useful documentation is very much another matter.

> Most managers out there are redundant and have no idea about what leadership is.

There are two issues here, lets do leadership first. Yes, leadership is not taught properly, and that annoys me greatly. Leadership can be taught, and its not to challenging to do. But on the flip side, leadership isn't just about keeping people happy, its about taking hard decisions and getting people to understand what they need to do.

Again, there are lots of bad examples out there.

Now as for redundant, if that was really the case, and that most manager are redundant, then surely they are ripe for "cost savings"? After all capitalism is mostly ruthless when it comes to staff costs.

The problem is that good managers increase productivity. However what "good" is can depend on where you sit on the hierarchy. If your CEO/CTO only talks to managers, then your manager controls the information flow. this is a company culture thing, and is closely coupled to how managers are expected react.

> The reason hackathons produce amazing results is because[..]

...of exposure bias. There are loads of ideas in hackathons, and lots of them are shite. But! the ones you remember are good, thus there appears to be a great signal to noise ratio. I've organised and participated in loads, they are good fun. But you can't run a company permanently in hackathon mode.

It is another aspect of cargo cult and checklist driven leadership.

When was Zuck’s last PR?

My experience is the exact opposite. Managers who code are usually talking about minutia bordering on micromanagement, never put or have enough time to develop people skills, ignore career development and growth, have little to no project management skills, do a terrible job with cross team planning etc.

My experience is just the opposite. Most of the really technical people who were promoted to management that I’ve worked with don’t know how to fight the political fights for their reports or get the raises, recognition or promotions that their reports want.

>Zuck has it right. All the worst managers/directors/VPs in engineering I've seen are people who don't contribute anything to the codebase. They actively discourage managers who want to write code from writing code. They

Wow. And these "good" managers coding, how do they meaningfully pursue strategical tasks that benefit the team and organization? Do they have time for these, 1:1s, team meetings, unblocking the blocked, translating the untranslated, and generally, um, managing?

Or do they work 80 hours?