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.
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.
Edit: P.S. Not sure why a couple of people decided to downvote this opinion.
Also to other commenters: it sounds to me less as a be a team player title (like the soldier one suggested) and more like an isolated resource that makes interchangeable contributions.
Anyways, I think that there is a distinction between "(Team) Lead" and Manager with the Team Lead usually classified as an IC says everything for most organizational approaches.
I agree more with the Meta take here.
> 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.
Very common phrase in the tech industry.
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.
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.
Every country, and even different regions of a country, has linguistic differences. This is true even if all the countries being talked about have the same national language.
For example, nobody in the US tech sector is going to know what a Boffin is unless they read The Register.
Even on the west coast of the US, vocabulary is different between California and the Pacific Northwest, although things started to merge together when the Silicon Valley based tech companies began opening offices up in Seattle.
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.
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.
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).
Hah!
I would just love to see that thread - may it is also filled with "What's an IC?" :-)
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.
zab zonk
the resource
zab zonk
individual contributor
jesus wept
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".
I dunno if it's just me, but it seems like the term came out of nowhere just a couple years ago.
PS: are you by any chance the same Izkata as the one in scifi.se?
Took a bit longer to realize they meant individual contributor.
Mine was "integrated circuit" which was like a really dystopian version of "human resources".
Principal engineer, architect, etc all fall into the IC career path, while, manager, director, VP of eng, etc all fall into the management track.
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.
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.
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).
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!
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.
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.".
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.
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.
"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.
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.
There is no way you can manage 10 engineers and still have good technical knowledge of what they do and provide directions.
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."
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.
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.
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 <Edit> consultant[1]</Edit> surgeon leads a team, but they don't manage the timesheets of the juniors, nurses and assistants. Meta very much expects that a consultant 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.)
[1]https://www.rcseng.ac.uk/careers-in-surgery/surgical-care-te...
edit I meant uk consultant surgeon, thank you to commentor for pointing out my mistake
[0] https://www.betterteam.com/chief-surgeon-job-description
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.
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.
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.
Yep, that's familiar. Good "people managers" have always been the ones that removed obstacles, and didn't become one themselves.
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.
Same for TPMs. They can be ICs or managing other TPMs.
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?
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.
If you are a people person and love helping people so much, go work as a social worker, no?
Managers are employees same as ICs. An IC can have more impact than a manager.
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.
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.
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.