author of the post here: apologies for the acronyms! I code-switched from academia/research to industry via FB a few years back and just picked up a bunch of terms that I thought were universal in industry. IC does mean Individual Contributor or "person that is not a manager" -- I'll add a definition on top!
I wonder if it says anything about Facebook's culture that I've never heard of the term Individual Contributor before. Everywhere else, it's Team Member or something along those lines indicating that you're not on your own.
I would add that, in context- it’s commonly used to differentiate job functions between managers and… well, ICs at companies where managers and ICs are peers or where ICs are potentially more senior than some managers in title and pay, sometimes by a lot.
So yeah, it’s a term of industry that often shows up in tech companies because of the usefulness of that distinction in those environments.
> Everywhere else, it's Team Member or something along those lines indicating that you're not on your own.
Individual Contributor means you don't manage other people, but it doesn't imply you are a team member. It helps to think of it as a role where at some point one is senior/skilled/specialized enough to contribute as a team of 1, working with one or more teams at a time.
I've only ever seen it to mean "individual contributor", but then this would make it odd/bad advice. There should only be 1 "customer". Sure, that customer may have a whole team that actually needs the product, and may provide them for clarification or what not, but to avoid unrecorded/incorrect handshake agreements, specs, or pet requirements that have nothing to do with the initial product ordered there should only be 1 POC for the product unless otherwise specified.
When multiple teams are using the thing, talking to at least one developer on each of those teams is going to surface things you won't find out anywhere else.
I agree that an individual user shouldn't be driving roadmap stuff directly, but getting their perspective, pet peeves, war stories etc. is still valuable advisory input to the overall process.
You should keep a record of what you're doing and why, but getting clear and accurate feedback from the real decision makers who have control over the technical success of your product is essential.
Despite all that, I still find it absolutely necessary to get in the same headspace with someone on the other "side". We can and should always float any outcomes to the primary points of contact on either side, but a POC is a primary point of contact, not the only point of contact.
Put differently, interfacing directly with customer ICs is good and necessary, so long as it's done with the go-ahead and oversight of each POC.
Where does the whole Individual Contributor terminology suddenly come from? I've suddenly seen it pop up many times over the last months and tbh the term doesn't make any sense. We just used to call them developers, engineers, or whatever.
I've been hearing the term in silicon valley for over a decade, it's not particularly new.
A lot of time in projects like these you end up getting shunted to tech leads, managers, etc, whose job it is to "take the coordination work" so that people writing code can "focus on implementation". The point of this advice is very specifically to bypass the coordinators and go directly to the people using your project in their code to make sure you understand their concerns, and don't play political telephone.
I've seen its popularity coincide with emphasis on non-managerial growth opportunities in large tech companies. Gitlab uses it for determining compensation, for example (the top IC is equivalent to a VP in their org).
Guessing by the context, I'm pretty sure it means "individual contributor", or "person that is not a manager".