8 ms·

> Brilliance and individual productivity aren't everything in a team setting. If your project must scale past a single person, you need everyone operating on th

> Brilliance and individual productivity aren't everything in a team setting. If your project must scale past a single person, you need everyone operating on the same page. It's painful in the short term to lose the quirky rockstars, but it makes for a healthier team in the long run. I think this is a self-inflicting ailment in the tech world. Many who are ICs fancies themselves one of these mythical "rockstars" who can code the business saving solution in 24 hour benders. Management/hiring/culture in general put too much emphasis on the brilliance of a single person on the team. But as you said, there's a time and place for the brilliant IC, and that's usually the very very early stages of a business. I've seen this sort of situation play out at my current job. We had a "rockstar" who was with us from the beginning. He was able to ship solutions extremely fast, was a fantastic eng, but loved to do things on his own schedule. He was the backbone of the eng side of the business... until he decided to take an offer somewhere else. He pulled off a crazy last 48 hour bender to wrap things up he was working on, but in his haste left behind a half-finished total rework of the back end which nobody other than him had a vision for. We spent the next 6 months trying to understand and finish where he was going with this rework. The manager who enabled this from the beginning also left, so we were left with a bigger mess than when we started. Sure, this particular eng got a metric ton of features shipped in our early days, but in the end ended up costing almost as much to clean up his mess as the value we got from him in the first place. There's a way to make these situations work, but blindly enabling the whims of the rockstar is not it.

hanniabu 7y ago
> there's a time and place for the brilliant IC, and that's usually the very very early stages of a business I definitely agree with this with a slight alteration....early stages of a project
- cgrealy 7y ago
  Ehhh... everyone is brilliant in the early stages of a project. Coming up with a fantastic green fields design isn't hard and represents a fraction of a percentage of the overall work. Give me a solid engineer who can deal with all the legacy cruft and still produce a maintainable piece of software.
- taneq 7y ago
  I'd offer a third option: Early stages of a product. The hyper-productive antisocial back room whiz kid is perfect for an R&D role. They can launch off solo and come back a few weeks later with a working prototype to prove the viability of a new product line. Then, before they get bored and stop being productive, you send them off on another deep space mission to invent something else. All the while, you have a team of less flashy but more dependable and cooperative engineers taking the prototypes and building sustainable systems and marketable products out of them.
  - throwaway35784 7y ago
    I need that role. In a week I turn out what takes a team several months and many times they've already spent that many trying to show any visible progress. I've done the impossible since I was in college. Still am. I'm resented by peers. Feared by less competent managers. I can't be controlled. I have a deep sense of integrity. I refuse to compromise my morals. I will not be forced to implement anything I believe could be used for unethical purposes. I won't bury the truth. I won't keep my mouth shut if blame is cast inappropriately. I will not see people thrown under the bus. I work too hard. I'm an over achiever. Others start to believe they are looking bad by comparison. I'm held back by them. I work all night. I get 'er done. I care. I listen. I empathize. I'm hated. I'm not a team player because I am able to do all the jobs but focus what I do best. I'll help you do your job better but I won't do it for you. I won't tolerate lies. I have high standards for myself and my team. I won't fall in line. People assume I'm arrogant but I always under promise and over deliver. I'm lost. There is no place for me. I'm alone.
    - taneq 7y ago
      Sounds like you need to start your own company where you can call the shots and surround yourself with like-minded people.
    - goto11 7y ago
      Look for consulting work or start you own business. If you are difficult and not a team player, you are going to have a hard time in teams regardless of your ninja rockstar abilities. But there are plenty of opportunities for a sole developers where you might thrive.
bobthepanda 7y ago
Why not just revert the rework? If no one has any context you're probably better off sticking with what you had even if the rework had good intentions.
- asaph 7y ago
  Undoing someone else's well intentioned work can be viewed as passive aggressive behavior.
  - stevens32 7y ago
    If they're still around sure, but the engineer in this case had left and wasn't around to maintain the work anymore
  - malloci 7y ago
    I think they were referring to reverting the work of the employee that left that put the organization in a bind, not someone still on the team. I had the same thought—revert the changes to get the rest of the team back on track. The problem could be that the changes could be over the course of many commits, so rolling back is complicated and almost as difficult as moving forward.
    - protonimitate 7y ago
      Yep multiple commits over a long period of time + different services (microservices). Was possible to revert, but the work needed to be done. The biggest mistake was letting this singular person take control and not let anyone else in on it. Reverting would have been a big effort as well.
  - munchbunny 7y ago
    That’s only if you don’t discuss it first. Well intentioned work can still be bad or not usable or not the thing the code needs right now.
goatinaboat 7y ago
But as you said, there's a time and place for the brilliant IC, and that's usually the very very early stages of a business. There are two kinds of ICs that I like to call capability guys and capacity guys. Capability guys can bring new skills into the organisation, and capacity guys can do the bread-and-butter work that actually pays the bills. You need to balance the two. Make sure the capacity guys benefit from learning the new skills and make sure the capability guys don’t go off on a tangent, and it can be a very enriching experience for everyone.
- caseyohara 7y ago
  What does IC mean?
  - taormina 7y ago
    Individual Contributor
  - desas 7y ago
    individual contributor. i.e. not a manager or leader.
- jodrellblank 7y ago
  Everyone except women, it seems?
  - zentiggr 7y ago
    In many contexts, "guys" is used to refer to any individual... not always in the perfectly neutral way I grew up with, but often enough that no difference / prejudice / sarcasm / etc is intended. Or I need to stop saying it that way myself. MMMV?
    - zadokshi 7y ago
      Great question. My perception is that ‘guys’ is generally still perceived as gender neutral by people (except for those into feminist blogs), but sometimes I wonder. It would be good to have a proper answer to this question. How do we get an answer without stepping on a political minefield?
brightball 7y ago
It’s easy for people to reflect on the brilliance without the casualties they sometimes cause.
- iri9n 7y ago
  Overly dramatic language aside, what else are engineers that come into a place that isn’t rife with greenfield opportunities expecting? Most software work out there is babysitting. Oh I know, I know we’re rockstars inside. In the early days, as the story goes, one person shipped a bunch of features. This part of the anecdote is underdeveloped, IMO. Hazy past recollections formed after emotionally processing a big shift. Was someone bringing this up before manager and rockstar bailed? Sounds like the team and upper management as a hole lacked foresight, and this is an after the fact realization. It’s a TEAM effort after all. Poor organization isn’t the fault of one brilliant eng or manager.
  - zer00eyz 7y ago
    > Most software work out there is babysitting. Yes, of a sort. Green fields are rare, and with the way things are today your picking up a massive pile of pre written infrastructure and libraries that you hardly look at (until they are a problem). The rockstar mentality is not wrong, but some days you need to pick up the pack and walk up the mountain too. The problem starts at the interview. We give people coding tests to see if they can produce, but that's less than 10% of the technical side of the job. Really we should be giving code reading tests. What does this do, is there anything wrong with it, is there anything you would change and so on.
    - whoisthemachine 7y ago
      Even most "green fields" these days tend to be fields where the grass is torn out, some re-landscaping is done, and some new grass that is a lot like the old grass is planted.
1MoreThing 7y ago
As a manager, a big part of our job is to mitigate risk and single points of failure. If enabling someone to work like this increases risk and creates SPOF in our teams, we're screwing up letting them do it.
- suls 7y ago
  Absolutely agree. This point however is generally only understood by a previously engineer-turned-manager.
- lixtra 7y ago
  > As a manager, a big part of our job is to mitigate risk and single points of failure. No, your job as a manager is to understand the trade-offs of taking such risks and make a decision that fits your situation. I.e. your competitor may capture your market with a single engaged risky engineer before you can produce anything usable with your best practice low risk team. Once they capture the market, they can stabilize later and hire your team, because you went out of business.
  - ameixaseca 7y ago
    That is one of the very important points a lot of people are missing here, and a key argument of the article: a fast rendering engine was a requirement for quake to be as popular as it was and it was a product of a brilliant engineer doing something innovative. More often then not, innovation comes from a reduced number of people doing things differently, and it's very hard to assemble a team of engineers which is willing or even capable of doing this sort of work. This also comes back to the "decision shielding" from working different hours: it's very common for managers or people averse to risks to try to stick to solutions they know, even if they are suboptimal or do not fit the problem very nicely. Anyone capable of doing more will soon realize they are spending most of their time solving mismatches between what solution was used/implemented and the problem they were trying to solve. If they don't find an alternative or a way around these limitations, they will leave.
    - fuzzfactor 7y ago
gpvos 7y ago
IC = ? edit: IC = individual contributor (just found that answered somewhat deeper in another subthread)
- deleted 7y ago
  [deleted]
- munchbunny 7y ago
  “Individual Contributor”, as opposed to “Manager”. The term is often used in reference to the engineer career track where you don’t become a manager but instead focus on technical leadership, but more generally it refers to being a leaf on the org tree.
- Namrog84 7y ago
  Individual contributor. In contrast to a lead, manager, or pm. The IC is usually the person who actually writes software/code. (The bulk of employees at a software company are ICs)
  - HiFaraz 7y ago
    PM is typically an IC too unless they are directly managing others.
HammockWarrior 7y ago
I'm a little confused by your comment. If his 48 hour rewrite of the codebase didn't end up working out well (and how could it really), why not just rollback to where you were previously? That way you wouldn't need to spend 6 months making it work?
- protonimitate 7y ago
  It was an on-going rewrite that consistent of multiple PRs against multiple services (micro-services arch). The 48 hour push was to "finish" which didn't end up happening. Reverting was possible, but would have been just as much work as pushing forward (since the rewrite needed to happen anyway).

hanniabu 7y ago

> there's a time and place for the brilliant IC, and that's usually the very very early stages of a business I definitely agree with this with a slight alteration....early stages of a project

cgrealy 7y ago
Ehhh... everyone is brilliant in the early stages of a project. Coming up with a fantastic green fields design isn't hard and represents a fraction of a percentage of the overall work. Give me a solid engineer who can deal with all the legacy cruft and still produce a maintainable piece of software.
taneq 7y ago
I'd offer a third option: Early stages of a product. The hyper-productive antisocial back room whiz kid is perfect for an R&D role. They can launch off solo and come back a few weeks later with a working prototype to prove the viability of a new product line. Then, before they get bored and stop being productive, you send them off on another deep space mission to invent something else. All the while, you have a team of less flashy but more dependable and cooperative engineers taking the prototypes and building sustainable systems and marketable products out of them.
- throwaway35784 7y ago
  I need that role. In a week I turn out what takes a team several months and many times they've already spent that many trying to show any visible progress. I've done the impossible since I was in college. Still am. I'm resented by peers. Feared by less competent managers. I can't be controlled. I have a deep sense of integrity. I refuse to compromise my morals. I will not be forced to implement anything I believe could be used for unethical purposes. I won't bury the truth. I won't keep my mouth shut if blame is cast inappropriately. I will not see people thrown under the bus. I work too hard. I'm an over achiever. Others start to believe they are looking bad by comparison. I'm held back by them. I work all night. I get 'er done. I care. I listen. I empathize. I'm hated. I'm not a team player because I am able to do all the jobs but focus what I do best. I'll help you do your job better but I won't do it for you. I won't tolerate lies. I have high standards for myself and my team. I won't fall in line. People assume I'm arrogant but I always under promise and over deliver. I'm lost. There is no place for me. I'm alone.
  - taneq 7y ago
    Sounds like you need to start your own company where you can call the shots and surround yourself with like-minded people.
  - goto11 7y ago
    Look for consulting work or start you own business. If you are difficult and not a team player, you are going to have a hard time in teams regardless of your ninja rockstar abilities. But there are plenty of opportunities for a sole developers where you might thrive.

bobthepanda 7y ago

Why not just revert the rework? If no one has any context you're probably better off sticking with what you had even if the rework had good intentions.

asaph 7y ago
Undoing someone else's well intentioned work can be viewed as passive aggressive behavior.
- stevens32 7y ago
  If they're still around sure, but the engineer in this case had left and wasn't around to maintain the work anymore
- malloci 7y ago
  I think they were referring to reverting the work of the employee that left that put the organization in a bind, not someone still on the team. I had the same thought—revert the changes to get the rest of the team back on track. The problem could be that the changes could be over the course of many commits, so rolling back is complicated and almost as difficult as moving forward.
  - protonimitate 7y ago
    Yep multiple commits over a long period of time + different services (microservices). Was possible to revert, but the work needed to be done. The biggest mistake was letting this singular person take control and not let anyone else in on it. Reverting would have been a big effort as well.
- munchbunny 7y ago
  That’s only if you don’t discuss it first. Well intentioned work can still be bad or not usable or not the thing the code needs right now.

goatinaboat 7y ago

But as you said, there's a time and place for the brilliant IC, and that's usually the very very early stages of a business. There are two kinds of ICs that I like to call capability guys and capacity guys. Capability guys can bring new skills into the organisation, and capacity guys can do the bread-and-butter work that actually pays the bills. You need to balance the two. Make sure the capacity guys benefit from learning the new skills and make sure the capability guys don’t go off on a tangent, and it can be a very enriching experience for everyone.

caseyohara 7y ago
What does IC mean?
- taormina 7y ago
  Individual Contributor
- desas 7y ago
  individual contributor. i.e. not a manager or leader.
jodrellblank 7y ago
Everyone except women, it seems?
- zentiggr 7y ago
  In many contexts, "guys" is used to refer to any individual... not always in the perfectly neutral way I grew up with, but often enough that no difference / prejudice / sarcasm / etc is intended. Or I need to stop saying it that way myself. MMMV?
  - zadokshi 7y ago
    Great question. My perception is that ‘guys’ is generally still perceived as gender neutral by people (except for those into feminist blogs), but sometimes I wonder. It would be good to have a proper answer to this question. How do we get an answer without stepping on a political minefield?

brightball 7y ago

It’s easy for people to reflect on the brilliance without the casualties they sometimes cause.

iri9n 7y ago
Overly dramatic language aside, what else are engineers that come into a place that isn’t rife with greenfield opportunities expecting? Most software work out there is babysitting. Oh I know, I know we’re rockstars inside. In the early days, as the story goes, one person shipped a bunch of features. This part of the anecdote is underdeveloped, IMO. Hazy past recollections formed after emotionally processing a big shift. Was someone bringing this up before manager and rockstar bailed? Sounds like the team and upper management as a hole lacked foresight, and this is an after the fact realization. It’s a TEAM effort after all. Poor organization isn’t the fault of one brilliant eng or manager.
- zer00eyz 7y ago
  > Most software work out there is babysitting. Yes, of a sort. Green fields are rare, and with the way things are today your picking up a massive pile of pre written infrastructure and libraries that you hardly look at (until they are a problem). The rockstar mentality is not wrong, but some days you need to pick up the pack and walk up the mountain too. The problem starts at the interview. We give people coding tests to see if they can produce, but that's less than 10% of the technical side of the job. Really we should be giving code reading tests. What does this do, is there anything wrong with it, is there anything you would change and so on.
  - whoisthemachine 7y ago
    Even most "green fields" these days tend to be fields where the grass is torn out, some re-landscaping is done, and some new grass that is a lot like the old grass is planted.

1MoreThing 7y ago

As a manager, a big part of our job is to mitigate risk and single points of failure. If enabling someone to work like this increases risk and creates SPOF in our teams, we're screwing up letting them do it.

suls 7y ago
Absolutely agree. This point however is generally only understood by a previously engineer-turned-manager.
lixtra 7y ago
> As a manager, a big part of our job is to mitigate risk and single points of failure. No, your job as a manager is to understand the trade-offs of taking such risks and make a decision that fits your situation. I.e. your competitor may capture your market with a single engaged risky engineer before you can produce anything usable with your best practice low risk team. Once they capture the market, they can stabilize later and hire your team, because you went out of business.
- ameixaseca 7y ago
  That is one of the very important points a lot of people are missing here, and a key argument of the article: a fast rendering engine was a requirement for quake to be as popular as it was and it was a product of a brilliant engineer doing something innovative. More often then not, innovation comes from a reduced number of people doing things differently, and it's very hard to assemble a team of engineers which is willing or even capable of doing this sort of work. This also comes back to the "decision shielding" from working different hours: it's very common for managers or people averse to risks to try to stick to solutions they know, even if they are suboptimal or do not fit the problem very nicely. Anyone capable of doing more will soon realize they are spending most of their time solving mismatches between what solution was used/implemented and the problem they were trying to solve. If they don't find an alternative or a way around these limitations, they will leave.
  - fuzzfactor 7y ago

gpvos 7y ago

IC = ? edit: IC = individual contributor (just found that answered somewhat deeper in another subthread)

deleted 7y ago
[deleted]
munchbunny 7y ago
“Individual Contributor”, as opposed to “Manager”. The term is often used in reference to the engineer career track where you don’t become a manager but instead focus on technical leadership, but more generally it refers to being a leaf on the org tree.
Namrog84 7y ago
Individual contributor. In contrast to a lead, manager, or pm. The IC is usually the person who actually writes software/code. (The bulk of employees at a software company are ICs)
- HiFaraz 7y ago
  PM is typically an IC too unless they are directly managing others.

HammockWarrior 7y ago

I'm a little confused by your comment. If his 48 hour rewrite of the codebase didn't end up working out well (and how could it really), why not just rollback to where you were previously? That way you wouldn't need to spend 6 months making it work?

protonimitate 7y ago
It was an on-going rewrite that consistent of multiple PRs against multiple services (micro-services arch). The 48 hour push was to "finish" which didn't end up happening. Reverting was possible, but would have been just as much work as pushing forward (since the rewrite needed to happen anyway).