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.

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.

Manager may have some challenging performances lined up and the creative operator has to really toe the line, but the purpose of the team is to support that to the best of their ability.

Anything less, and the desired expression of talent might be dampened. If this is too severe expect the star to move away toward a more functional arrangement.

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.

Or I need to stop saying it that way myself.

MMMV?

One thing I noticed is that I’d probably feel off calling a group of female coworkers gals, so I tend to refer to them as women I work with.

Conversely though, I rarely refer to group of male coworkers as men I work with and would probably say “a couple of guys at work” or something.

Language is funny like that, and intent, tone, familiarity, and cultural background matter a lot too.

For instance I’d never call anyone honey at work, but when an older black woman would say something like “oh honey, we can’t do this like that” it was totally fine because it was quite clear that was just her lexicon and it wasn’t uncomfortable for anyone at all.

Life is full of ambiguities, generally if you have to ask “might this make someone uncomfortable?”, I generally just avoid it.

Which can be a bit tough for me sometimes, I definitely grew up and would pepper my speech with curse words as in “oh shit!” Or “holy fuck really?”, but I’ve learned to limit that a bit over time.

Know your audience.

I definitely agree with this with a slight alteration....early stages of a project

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.

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.

Time to let go.

(btw might look into Aspergers/ASD)

You're conflating lies/truth, empathy/hate, peers/team, productivity, etc all together, it's bananas.

But the basic gist is that it sounds like you're not suitable for larger companies at all. You should limit yourself to companies smaller than 50 people.

I mean, avoiding allocating memory unnecessarily is not related to moral nor ethics.

And you know.. just because you have a moral opinion doesn't mean you MUST point out divergence with others, when they pronounce their world view. I really find it unusual to point out "morals" in a topic like this one.

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.

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.

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.

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.

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.

Well intentioned work can still be bad or not usable or not the thing the code needs right now.

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

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.

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)

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).