In my case, I eventually learned that the odd hours weren't the key to his perceived success. Instead, he used the odd hours to force us to give him only work that could be accomplished alone. We were lulled into letting him make key architecture decisions in isolation, because no one else was awake or online at the same time to discuss them.

Eventually he became the architect by virtue of operating in isolation, where we couldn't discuss his decisions. Everyone else was forced to work around his code. If he refactored the codebase in the middle of the night to make his job easier, the other team members were all forced to work around his refactor and waste time updating their PRs to match his work.

Worse yet, having someone like that on the team drives away other great employees. Eventually everyone else will get sick of accommodating the architects isolated schedule. If they have other opportunities, they'll leave.

> I often think about how I could have better allowed his brilliance while not alienating the rest of his team, but in the end I failed.

It's not on you. 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.

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

Generally speaking, this is an occurrance that is exceedingly common and extremely under-recognized in our industry.

    Instead, he used the odd hours to force us to give him only 
    work that could be accomplished alone. We were lulled into 
    letting him make key architecture decisions in isolation

    Eventually he became the architect by virtue of operating in 
    isolation, where we couldn't discuss his decisions. Everyone 
    else was forced to work around his code. 

Our guy was genuinely, I think, the best engineer on a team of pretty good engineers. But in terms of sheer talent he was not a "10x" coder in terms of raw talent. Call him perhaps a "1.2x" or "1.5x" in terms of raw talent.

However, he was essentially able to operate as something like a "10x" talent because he got to do a lot of greenfield work, make sweeping architecture changes and decisions, and so forth. Meanwhile we were all left to deal with his fallout.

Whether or not you believe there are legitimate "10x" engineers (we'll set that debate aside for a moment) I think it is very, very obvious that we have misidentified the talent level of many engineers. Your actual output level as an engineer, be it 1x or 100x, is always a product of many factors and your actual talent level is only one of those factors.

    Worse yet, having someone like that on the team drives away other great employees.

1. It's not a good way to make software, obviously. Great employees want to make great software and will be frustrated.

2. It's career fucking suicide to work under somebody like that. It's impossible to shine when working under somebody like that. You can't clean up a mess as quickly as other people can create a mess. You just can't. With very rare exceptions you simply cannot mop a floor well enough to be seen as something other than a janitor.

I created a side project that became its own very successful product, and now there are a couple of other engineers in the team and I'm the "tech lead". We have a front end and backend component, and I have another brilliant full stack taking full charge of the frontend. the other two engineers are _very_ mediocre at best. The code is complex partly because I (without formal training) wrote it all myself, but also because it's a very complex priduct, not just a CRUD. I'm Constantly stymied by the fact that on the backend, asking the mediocre engineer to do something means it will take a full Sprint instead of the two hours it'll take me. The other engineers are also not able to fully understand the PRs (because the code is still too complex to them after six months joining the project) so I feel minimal upside to wait for their code reviews (which I still do anyways). I've asked to staff with better engineers but given the complexity of the product (directly query very large datasets with very complex jobs from a clean frontend) and our small orgs inability to attract great talent, I'm not getting anyone.

I'm forced with two possibilities: 1. Ask for the mediocre engineers to be removed from the team, and continue working on the backend solo (but making it actively a job to document and make it as easy as possible for a good engineer to take over after me). This would actually boost productivity 2x from what we are now frankly.

2. I stop coding fully or slow down 5x and work primarily as just someone who asks others to code. It would probably slow us down 3-4x,but I suppose it'll match the pattern of a regular team, though to what end I don't know.

Is there any advice you can give? I'm sure I'm not seeing something obvious here that I'm doing wrong, and am fully open to honest input.

The primary purpose of source code is to be understandable and manipulable by other engineers. No matter how well it accomplishes its goals, it's not "good code" unless it can be understood by other people.

I question whether you're actually working with a "very complex product" - it might just be that the way you're representing it is complex. If the code is still too complex to other engineers after 6 months, it's not the engineers who are wrong. At 6 months they should deeply understand some parts of the code and have confidence about diving into and understanding other parts with some ramp-up time.

I say this as someone who writes a lot of code that other people find hard to understand because it's "clever", and it's taken me a long time to fully internalize that, when someone else can't pick it up, it's not their problem, it's mine. Code is user interface, and good user interface meets the users where they are, not where you wish they would be.

Honestly, this aspect of software engineering is really the bottom line hardest part - it's not getting a working binary out of the compiler/interpreter, it's about getting a living system to evolve well. That means nomenclature and abstractions have to be top notch, not just the algorithms.

There's an old saw about "if it's twice as hard to debug code as to write it, never write code that's more than half as clever as you're capable of, otherwise you'll by-definition be unqualified to debug it", and I think there's a lot of truth there. One of my old director of operations used to say "If you can't run the playbook at 3am after being at the bar, it still needs work", and I think that's also true of non-ops related code.

Your next step is to reorient your role: your job is no longer to ship features, your job is to make the code easier for your coworkers to execute in. You're right that you'll "stop coding" as seen by management: your new bosses are your coworkers. Treat them as your customers, have them file tickets, the whole nine yards. When you reach the point that your coworkers are faster at getting things done than you are at the moment, then you can turn your sights back to production work, but until then, your job is technical debt remediation.

I've never worked in a fantastical position like this. The only purpose of the source code that I've been a part of was to provide a real solution to a real problem, in a limited amount of time, with too few resources. Technical debt always increased slowly until features are removed or break, forcing some dedicated work.

Can I ask what industry you're involved in where code quality is held higher than profit/deadlines/solutions? I would happily make the jump.

I've actually been doing a lot of turnaround consulting with companies that took a short term mindset, got stuck, and had to step back and revamp their technical processes like you say. It's always more expensive to redo it after the fact, but I'm happy to take their money and fix their mistakes.

And that's not to say that it's not a tradeoff, but it's about being conscious of the tradeoffs involved and making reasonable choices.

(1) spaghetti code that relies on the author having a great deal of it memorized. It uses opaque types that get passed through multiple modules. There is no hard separation of modules. Consequently it’s easy for someone who knows the system to reach into any part from one part and immediately get something done. However it’s a nightmare to make changes on otherwise. Unless you have an near-eidetic memory, it will likely negate any coding skills.

(2) Strongly typed and modularized code that takes advantage of advanced language features. In this case, it requires somebody of a certain proficiency in the language, but they only need to focus on one module at a time, and the compiler will stop them from violating architectural assumptions.

And these aren’t mutually exclusive, nor are they binary.

Story time to drive home my points: I started 7 years ago, fresh out of uni with a diploma, but not enough experience, and did something overly complex, with a lot of frankly bad code. Then, 5 years ago, we expanded the team (which means I was no longer the sole developer, but we were now 2).

At first, I was not satisfied with the other developer (fresh out of uni as well). Instead of trying to fire him, I bit the bullet and answered every question, took a lot of time to explain things to him. Yes it slowed me a lot. It also forced me to up my game to make our codebase readable (not MY code, our codebase), add comments etc...

In the end, he is now a valuable team member (we are still only 2 devs, with the occasional intern) who knows most of the codebase as well, if not better, than me. It has been the case since about 3 years (it took him 6 months to have a decent development speed, and about 2 year to develop at about the same speed as me). Neither of us consider himself a "rockstar" developer and that's fine. We work as a team, and as a result our code is better, faster, more readable and as less bugs. I couldn't achieve that level alone no matter how much I tried.

To sum up: train them relentlessly, without loosing patience, and use that as an opportunity to make the codebase more readable.

You didn't mention how much time those engineers have been working with you though. Common knowledge is that it takes at least about 3 months to be proficient with a codebase you are new to. More if you are not experienced.

Second, you probably should be taking some of that time you are coding and instead extensively documenting how it works, the design methodology, and making sure the unit tests are covering the code. After all, there are many implicit decisions in the code that they have to re-discover.

If you don't have tests, it makes working on a project as a new engineer difficult because you have no guard rails to know if something broke, especially because the specification is only in your head.

If you invest in your other engineers and in the process, they will become much faster and that slow down is a temporary bump in the road.

In fact, I might say that pretty much every engineer will be guilty of this if they have been in the industry long enough.

It doesn't mean you're evil! It just means you're the one who created a bunch of stuff and naturally you can work with your own stuff more efficiently than others can.

In fact I actually was "this guy" with one section of the code at my old company; the one where we had the "faux 10x" architect-dictator. I did manage to achieve a fairly clean transition once my involvement in that bit of the code ended.

    Ask for the mediocre engineers to be 
    removed from the team

    "asking the mediocre engineer to do something 
    means it will take a full Sprint instead of 
    the two hours it'll take me"

    "[Transitioning from coder to mgmt/mentor] 
    would probably slow us down 3-4x"

Maybe you could divide your time in a way that's not too painful. Perhaps you could spend a fixed 1-2 hours per day on knowledge transfer (pair programming, etc) and not impact your productivity.

Here's what I would say.

0. Get buy-in from the rest of the management/leadership team. They should fully support your efforts to get others up to speed. Tell them you are concerned about being the only one who can maintain the product effectively. They should NOT want you, personally, to remain an indispensible single point of failure. What if you leave? What if you are hit by a bus?

1. As I said above, if you can devote perhaps 25% of your week to full-time knowledge transfer, you might find that you accomplish a lot without sacrificing your other productivity unduly.

2. Pair programming is, I think, the fastest form of knowledge transfer. An hour or two of pairing with the newbie engineers at the outset of a task goes a LONG way and may save dozens of hours later in the sprint. It sounds like these engies should never, ever begin a task without this guidance from you. They will learn the code, they will learn the thought process that went into the code, and they will learn your problem-solving process.

3. Is your test suite awesome? Writing or improving tests can be an excellent way for folks to get up to speed on the code in a low risk way. And a strong test suite has long-lasting benefits. If you don't have a test suite at all, even a very rudimentary one will reap large rewards down the road.

4. I document my code (via inline code comments) more than most. My opinion is that if a bit of code represents a non-obvious technical kludge, or a bit of business logic, it should have an explanatory note. Theoretically this could be accomplished via diligent commit messages, but sifting through hundreds of commit messages is awfully tough.

5. YOUR ENGINEERS ARE PEOPLE. Working on your legacy hairball of code is... frustrating. Recognize their pain. Be sure to get them some "wins" on a regular basis so they can feel good. Praise their efforts in private, and in front of others in meetings.

Good luck to you! My email is john edmund rose "at" gmail if you want to correspond. I'd like that!

“Average” engineers manage to be productive with React, Spring, WPF[1]... These are not simple technologies. Why can’t “average” engineers be productive with my stuff?

Quite often it’s because these bigger, more complex, projects have far more comprehensive docs.

It sounds like this codebase has a fair few abstract concepts in it. Those things can be hard to understand without comments and docs explaining core concepts.

Sequence diagrams are also great. I like generating sequence diagrams from logs during automated testing so they never go out of date.

I also find it useful to have docs at the top of each class (or file) explaining 1. what its responsibilities are, and 2. what it collaborates with. Like the old CRC cards.

Obviously this stuff can drift out of date, but it’s less of a problem with the core bits of the system once they’ve settled a bit.

If they don’t exist already, it’s nice to write docs by pairing with new devs.

It is of course possible your engineers really aren’t up to the job, in which case the effort you put in to explaining things now will still make things easier for their eventual replacements.

I had all this wrong for so many years.

[1] whether these are “good” technologies is beside the point here

I was a lot happier and less busy trying to be a 3x engineer making everyone else into 1.5x engineers.

That sort of work often goes unrecognized though, if you are an in-the-trenches engineer. Unless your manager is pretty hands on and spends time “in the trenches” with the team they won’t see that. Most organizations reward selfishness and punish benevolence. Not on purpose. They just can’t see it, because they are too far removed from the work and benevolence is nontrivial to measure. So it takes a back seat to trivial measures.

These days I'm more likely to fix things that bother me and then share them after they're debugged. And often after I have my fingers in something new.

It makes me wonder if the proportion of 'scratch your itch' projects wouldn't be lower if people weren't disillusioned by the process of doing something solely for other programmers.

This causes other people to have to follow the style, but it also prevents them from making something worse.

However.

Howwwwwever....

The ILLUSION of democratic (or at least collegial) meritocracy is how our faux-10x engineer pulled the wool over folks’ eyes. He gave the appearance of soliciting feedback. We had internal RFCs and everything. But in the end though he really did just push his ideas through unmolested, because he had management's blessing to do so.

Not sure how much was an intentional masquerade on his part. I think he really did think it was a meritocracy and his ideas were simply the best. It is certainly not unheard-of for folks to fail to recognize their own privilege. Whatever the case, management enabled it. He was not an awful guy in general, and I rather liked him, just not as architect-dictator.

One of his favorite tactics was to spend weeks or months coming up with something in isolation. If you raised objections he’d brush them off by demanding to know your alternative. Which was horseshit - how could you have a viable alternative when he’d had weeks to come up with his idea and you’d only had 10 seconds, especially when these "ideas" are his fulltime responsibility and your responsibility is to ship 40 or 50 hours' worth of software a week. And past experiences had taught you resistance was futile anyway, so why pour your heart into a doomed battle in this latest bit of asymmetrical warfare?

This tactic played well to management though. He looked like the brilliant idea guy and you looked like the negative Nancy. This is a very common bit of political and rhetorical warfare and you see it everywhere.

It is, essentially, a tactic that has much in common with the dreaded "Gish gallop" - you fling stuff at your opponent faster than they could possibly refute it.

https://en.wikipedia.org/wiki/Gish_gallop

The cure for this in the software simple and difficult. Managers "simply" need to be aware of this possibility. However, they also need a certain level of technical chops IMO. If they're too far removed "from the trenches" they can't accurately judge the situation.

    "The cure for this in the software simple and difficult"

    "The cure for this, both in software development and 
    elsewhere, is both simple and difficult"

Luckily, I'm out of that predicament. It was actually really hard to see it for what it was when I was in it. That environment had all the trappings of a healthy engineering culture, and sometimes it truly was healthy, but only in hindsight have I realized some of the ways in which it was deeply screwed up.

What helped was talking with former coworkers, and going to work someplace that is actually healthy. It's not totally unlike finding yourself in a healthy relationship again after being in an unhealthy one.

If there's someone with a proven track record of making sound decisions at the required level, often the team benefits from just following their lead.

Obviously, this can't be another case of the 4x engineer making everyone else 0.4x engineers. Fairly situational indeed.

I would agree that it certainly shouldn't be a "one person, one vote" style democracy that makes everybody exactly equal regardless of talent, dedication, experience, domain knowledge, etc!

This does not mean that vision should come from a single person. Ideally, it comes from the people who are able to contribute and critique that vision (other senior developers), with the acknowledgment of the people who don't have the information to contribute or critique (the junior coder).

This harkens back to the MMM and Mills's proposal.

> The surgeon. Mills calls him a chief programmer. He personally defines the functional and performance specifications, designs the program, codes it, tests it, and writes its documentation.

> The copilot. He is the alter ego of the surgeon, able to do any part of the job, but is less experienced. His main function is to share in the design as a thinker, discussant, and evaluator. The surgeon tries ideas on him, but is not bound by his advice.

> The success of the scaling-up process depends upon the fact that the conceptual integrity of each piece has been radically improved—that the number of minds determining the design has been divided by seven. So it is possible to put 200 people on a problem and face the problem of coordinating only 20 minds, those of the surgeons.

Chapter 4 is all about conceptual integrity of a project.

> Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds.

1) Lack of focus - everyone had their own annoying part of the system they wanted to fix badly and were not aware much about what going on elsewhere.

2) Our group of ~10 people would cost 10x of senior salaries to the company to do such architecture work. No manager would ever authorize that.

That worked pretty well and kept each review fairly focused.

And it was generally one of my favorite parts of the day from either end.

It’s really nice to be able to sit with a group of engineers, hear each other’s thoughts, find things you missed, and get away from the laptops for a bit to thing about new systems.

A group of 10 seems too large and counterproductive. I think a group of roughly 3 seems about right.

Wikipedia says:

    People with hero syndrome generally cause an 
    accident or disaster with the intention of 
    then coming in to render aid, and become the 
    'hero'. The reasons for this often vary. 
    The perpetrator may be trying to validate 
    their own self-worth, or be seen as brave 
    by others. 

I think things are a little less clear-cut in the sort of (common, IMO) engineering scenario I was talking about.

I feel it's often more of a systemic situation, where the company/team does not properly value the knowledge transfer, empowerment, and management skill necessary to avoid those situations.

In the specific situation I described I don't think our architect intentionally created messes, and I think probably believed at each step of the way that his actions were best for the company.

When you are in flow state you are producing a lot of output but aren't asking any questions. That turns into big, solid chunks of the system with no oversight, no consensus, no introspection, no empathy. And when someone does ask questions - because who wouldn't? - we aren't questioning a small isolated part of the architecture, we're questioning a very big piece. One that the author feels very warm feelings about because they had An Experience while writing it.

Flow state is useful, possibly great for refactoring. It's occasionally a waking nightmare for new code, and not a great experience for everyone else the rest of the time.

This almost sounds like bitterness coming from the other side of the team.

Not everything is a team decision and nor should it be.

Often times brilliant engineers, in order to express that brilliance, need to be left alone by over zealous managers and jealous teammates that would rather argue than get work done.

In my experience, it is not as often as you might think. The key issue comes down to brilliance coupled with selfishness.

If you look for it, you can see some common themes in these comments: "...the other team members were all forced to work around his refactor and waste time updating their PRs to match his work," or "Meanwhile we were all left to deal with his fallout," or "...this particular eng ... ended up costing almost as much to clean up his mess as the value we got from him in the first place." We have all had to work with that guy. In the early part of my career, I have been that guy.

People are not arguing because they don't understand your brilliance and are jealous of your productivity. It is because you are making their lives harder. That is what makes people bitter.

Turn the problem around: instead of asking "how can I get all of these over-zealous, jealous people to leave me alone", ask, "how can I apply my brilliance to make their lives easier instead of harder?" Unless you are doing something basically trivial, there is usually too much work for any one person to do it all by themselves, no matter how brilliant. You need those people. So help them out. You will have a much better time. And so will they.

I think you missed the point.

It's easy to operate in a vacuum. If you maneuver yourself into a position where you can only ever operate in a vacuum, you avoid the real difficult work: Coordination, communication, cooperation. That work doesn't just disappear, though. The rest of the team has to pick up the slack, fix the leftover bugs, work around the lone wolf's quirks, and so on.

If a project requires more than a single person to scale, then those people need to work together as peers. If you let one person run away with the fun work and leave everyone else to clean up the bugs and pick up the scraps, it's not a sustainable situation.

If he should have been. Then he should probably have been lead eng or something.

His authority and actions were mismatched. Management can change either side of the equation.

You want the "quirky rockstars" as your prototypers, not your architects. Then everyone can thrive.

If you're a manager, the math of having true rockstars on your team rarely works. They take more effort to manage yet produce fractional more output (they might be 10x better than a terrible developer but they're not multiples of solid devs). So I'm way further ahead if I can focus my efforts on improving broad-based productivity 5-10% than if I cater to my rare unicorns that are 30-50% better than my average team. Something I think ICs often overlook is a focus on leverage and scale to drive big improvements.

Mind expanding on "leverage and scale" in this context?

An outlet for unicorns that keeps them away from the company bread & butter and unicorns.

The problem is there aren't many prototype gigs out there, so it's not a great specialty.

I haven't seen R&D Divisions at companies, but I'm sure something exists.

I was on contract so I just left. No way was I going to deal with that environment. I lost all respect for the technical management there too. The director in charge of the project seemed to be confusing arrogance and belligerence for ability. Rather than reign in a clearly toxic employee he actually encouraged everyone to work around him and touted the benefits of the crazy XML system he was building. These benefits, of course, were no more than empty promises from the employee himself. But they were politically expedient ... the director could claim the team was building some advanced system that could potentially be reused. It gave him some cover to explain why things were taking so long to deliver.

IMO, this is the worst environment possible for development. You have directors favouring empty promises for incredibly complex systems to give them good talking points. You have toxic developers who make any dissent to their bad ideas so unpleasant that they gain control. This creates a feedback loop where good engineers see bad ideas and bad behaviour get rewarded with special treatment.

Q: was the programmer in question fairly young and inexperienced? My gut tells me that these types of “brilliant programmers” flare up early on in their careers, think they are hotshots, but mature a few years into it.

I definitely believe people with those kind of negative attitudes can be reformed because I've seen it with my own eyes. Often all it takes is a supportive manager and some positive role models.

It's ironic, right?

The more fragile and over-complicated the system, the more the engineers who created the mess in the first are considered "brilliant."

I've seen this countless times.

(In defense of such engineers, it's often not their fault. They built one thing, and then management and business needs dictated a plethora of changes and technical debt against their wishes. I have been one of these engineers on occasion)

I have seen this play out multiple times - acting like asshole can make you look smarter then you are and smarter then nicer people.

First, he ended up dominating discussions, so other peoples ideas were not told. This is simple, he is having ideas and they seemingly don't.

Second, other people got criticized a lot and he did not got criticized. Hence, others looking like having bad ideas and him looking like having good ideas. Yes, criticism was actually insults and dismiss and actually actual arguments, but it unfortunately often does not matter when people make impressions.

Third, people have tendency to buffer criticism with praise. So when they criticize him for having been asshole, they will first euphemise with "low social skills" and then add something like "but he is good programmer/professional" to it. So that they dont sound biased or overly negative. Unfortunately, they rarely buffer praise with praise "he is so nice" is rarely followed with "and also good programmer" cause it feels unnecessary.

It does not work that way for every kind of asshole through, not everyone can achieve the same. But when it works this way, imo, above are factors.

He offered a grand vision for a highly-configurable system. This vision meshed with the directors desire to have such a system. He was effective in promising all of the features of such a system that the director wanted. In fact, he promised even more! To be fair to him as a developer, he was trying his best to deliver on this promise. The system as promised was beyond what he could produce.

Within the giant mess he had created were many of the elements required for the grand system, they were just buried underneath very complicated XML systems and over-engineered code. He would prototype new system features working (held together with digital tape and bubble gum) to prove viability. The fact that these features were incomplete would be hand-waved away. Of course, sooner or later the system would have to be "filled in" so that all of the details were correctly handled - which would inevitably require further massive rewrites to all systems. This gave a feeling of progress but that progress was actually hollow.

If anyone pointed out that most of the systems he was implementing were basically prototypes and would fail on any case other than the ones he used as examples - he would become extremely toxic. I mean, literal yelling matches. His tactic was to belittle anyone who pointed out issues in his design or his code. Most of the developers on the project were junior so they didn't stand up to his tirades, the rest just didn't want to deal with it. I have no idea why the director allowed that behaviour to continue but it was a regular occurrence. This meant that his examples worked barely enough and no one else could get their own code working without his input. That matched his toxic rhetoric that everyone else was just getting in the way of him getting things done. It also gave him the cover to work late nights when no one else was around, so no one would interrupt him while he completed this grand system.

This attitude of "I am so great that others are getting in my way" is now a huge red flag for me. If your attitude is "once I'm done my grand system, everyone will thank me" then I want you off my team. Your grand system will never be done and if you develop it in isolation I can guarantee it will be of no use to anyone. If you react to feedback about your grand system with "you are too stupid to understand it" then that is even worse and I cannot get rid of you fast enough. If your system cannot be understood then that is your problem, not a problem for everyone else. The fact that someone with either of those attitudes is seen as "brilliant" by anyone is a mystery to me.

You're right that people need to be on the same page, but being on the same page should not be 5 scattered 15-minute meetings in a day on top of "Hey did you see my e-mail" and "Hey check this out" and "Hey where is that site you mentioned yesterday".

Real work gets done when people work undisturbed in blocks of time. Meetings should be scheduled such that engineers have large blocks of continuous time. Meetings should be focused on generating action items and establishing the prerequisites for those action items so that further ad hoc requests are minimized.

For example, you might find that 1pm is a good time for meetings because it accommodates all (early/late-shifted) commute schedules, is right after lunch which people need to take a break for anyway, and leaves a continuous block of work time after the meeting until the end of the day. The timing may differ in your work place but you should figure out what works best. Asking your engineers is a good first step.

That sounds like a process rather than schedule issues: important architectural decisions shouldn't be performed "on the spot" but only after some sort of discussion. Preferably in writing.

> If he refactored the codebase in the middle of the night to make his job easier, the other team members were all forced to work around his refactor.

Don't you do code review? People shouldn't be able to push code without another person looking over it.

These issues would also apply to remote or off-shore workers.

"Clean up" would be things like fixing typos/docs, bumping version numbers, fixing a build script because some path/version/etc of some external dependency changed, and sure -- mostly that's fine. If you're doing proper CI, there should be little to no surprises like this in your master branch, because you shouldn't be merging branches that break the build, and the "final release" build is really no different from any other build, other than you label it "release" (or "GA" or "RTM" or whatever) after the fact.

Refactors and any thing that could be classified as an "architectural change" really must go through code review. If someone thinks their skill is so great that reviews are pointless -- I absolutely guarantee in 100% of cases that they're gravely mistaken.

If the rest of the team can't understand the changes, well, they're bad changes, full stop. This is the team working on the code base, they are the ones that have to be able to understand it. This can be fixed of course, by firing everyone and getting a better team (just kidding), helping raise the skill level of the team, or by simplifying the changes. In my experience though, if no one understands it's usually a sign of overly-complex and/or under-documented code.

Code reviews are a two-way street, and learning is not just for the reviewee -- it's a great opportunity for the reviewers to learn, too. They get to see how someone else solved a particular problem, with rationale, the opportunity to ask questions (and 80%+ of the time, a question about how/why is usually an indicator a comment in the code is missing), and "current context" (eg: it's a change that's probably been discussed in the days/weeks before).

If the changes really are good, and it's a good PR (eg, not a massive, surprise major refactor that touches thousands of lines of code) then the PR will pass easily.

And seriously, if you need to do a massive change like this in a rush right before a release, then the team probably missed something major and the release simply isn't (and was never) ready. Major refactors means brand new code, and putting brand new code into a release with no testing (not even dev testing!) is a terrible idea.

Also, to be frank, if his code is reverberating all over the code base like that, causing merge conflicts and re-write all over the place, he is a terrible engineer - not a brilliant engineer. He clearly had no knowledge of the basic SOLID principles, modularization, encapsulation, etc. He was a rookie blasting experiments all over the code base.

Sometimes individual people can be very focused on their particular assignment and greatly resent somebody forcing them to make even small changes. Even if those are to make a global API smaller and more consistent.

It should be possible to set up asynchronous communication channels, like a collaborative document-editing service (Google Docs, Dropbox Paper, etc).

I get that asynchronous does not always work, but it has some benefits, especially for tasks such as architecturing an app. I'd be worried if such discussions would happen only in an oral fashion, or in chat channels.

Good documentation is also invaluable, and good documentation being 1:N is often more valuable than a 1:1 synchronous discussion for certain things.

Ding ding ding. We have a winner!

A big problem with people like that is that at the end of the day, writing code or building stuff is the easy part. Communication, coordination, mentoring, onboarding, figuring shit out, etc, is the hard part.

People who hide for large parts of the day or multiple days are usually just dumping the hard part on others. Since the industry is often stuck thinking that line of codes === worth, these people seem more productive. Often, it's the polar opposite. They're freagin useless and anyone else in their situation would do the same or better. Everyone else is slower because of the increased burden (who's answering questions when Mr "I work from 5pm to midnight" isn't around?

And you can often work faster if the code is better organized and self-documenting than if you have to spend an hour meeting with another dev to understand it.

I had opportunity to see some projects that went in the wrong direction by bad architectural decisions resulting from an opposite behaviour. Every architectural decision would be made based on everyone's input where most junior people's opinions would weight the same as most experienced. In the end decisions were made primarily based on how simple the solution appears and not based on its suitability for performance, future extensibility, maintainability etc.

McCarthy's 1995 book "Dynamics of Software Development" has a chapter devoted to this phenomenon.

I say this because bipolar disorder is a protected condition under the ADA, which allows for work modification. We tend to end up in positions where deadlines are soft and there's a lot of individual work that can be done asynchronously, so there are a lot of us in software.

This may not have been the case with him, but I do think there's a lack of awareness of mental health issues in the workplace. People who struggle with mental health can still be great employees in the right circumstances. If there were better awareness that people struggle with issues like these, I think there would be fewer issues with co-workers.

Take me, for instance: as far as I know, I'm not bipolar, or anything else. The best framework for understanding myself I've found is that I'm an INFP.

Though it might look like I prefer to work in bursts and then chill out for a while, the reality is that few things stress me out more than deadlines, and getting into a flow can take a while; while I'm in it, I'm reluctant to let it go prematurely, so I end up going until I tire out, and then I need a rest, which (in a perfect world) can sometimes take two or three times as long as the preceding flow period. I'm also only really motivated internally -- doing things just because I'm supposed to is a recipe for me doing them badly, but doing things I care about is nearly always a recipe for producing very strong work.

I'm also pretty emotionally-driven (from the MBTI standpoint, I'm Fi-dominant) and am drawn towards my negative (Te-inferior), so it's no surprise that I do creative work (music) that requires lots of control and technical know-how (writing music to picture i.e. solving a problem, lots of gear to understand; this draw-towards-the-negative is why I've ended up frequenting a place like HN -- I like the control that programming gives me, even I'm still quite an amateur). This industry has terrible deadlines though, so that's still a problem that I simply endure, and do my best to work around with workflow and efficiency hacks.

Being primarily motivated by my feelings and values means that I can easily get into a slump. It's like depression, but as far as I can tell, probably not "real" depression. Just more like "Highly-Sensitive Person" living.

From the outside, I suppose that my way of being could totally be seen as bipolar or something like that. But the devil is in the details. All sorts of states can produce similar results.

Mental health disorders are very, very, very, very hard. Not giving engineers with mental health disorders the room that they need to grow is doing everyone a disservice. And yet, the stigma around mental health disorders is so high that that conversation will not happen anytime in my lifetime. At the end of the day, myself and the others like me, are pushed into the dark further and further. It really sucks, and the only place for conversation about it is in therapy and close friends. Mentioning it at work leads to risk of retaliation. So, we cope. And then people write blogs about people like us, without taking into consideration that there's likely some mental health issue going on.

And, for what it's worth, talking about things in terms of MBTI isn't helpful in a conversation about mental health disorders. You might as well be talking about horoscopes.

For example, a good friend of mine was internet-diagnosed with Schizophrenia. He believed it, and going down that rabbit hole screwed him up for a while.

Turns out that he and a long-term daily weed habit just weren't really a good mix (the paranoia led him to take it more seriously than he should have -- and the fact that "paranoia" was one of the supposed "signs" of Schizophrenia only made it more believable). He stopped smoking, and within a couple weeks saw just how ridiculous a turn things had taken.w

My point was simply that people are complex, and one single behavior isn't really enough to go around stating that a person might be X. A person can be inclined towards a certain work habit for loads of reasons.

If Greg has issues concentrating, and someone says "I know people with autism can suffer from that, and they find stimming helps", then even if Greg is not autistic, they may be well served by that advice.

That said, they won't necessarily be well served by all advice (Ask your doctor for Ritalin!), and I'd personally rather leave it to themselves and their medical practicioner to diagnose/decide whether they're actually part of any given group.

I am literally never manic. Sometimes I get pretty down -- that's it. Very well within "normal" range. And yes, I've talked with a professional about these sorts of things (when I saw a therapist for a couple of years), and the notion that I am mentally ill, beyond perhaps being a so-called "Highly-Sensitive Person" (a classification I find fuzzy and dubious, but whatever), was outright dismissed and was honestly found to be kind of laughable -- me brining it up was more a sign of my own insecurity/difficulty in accepting that I was seeing a therapist than anything else.

I don't really care to get into a discussion about Meyers-Briggs, as they don't really go anywhere on this site. If you care to read, I've explained my views on the topic elsewhere on HN in more detail: https://news.ycombinator.com/item?id=20888175

However, most people cannot regularly work 48 hour shifts except under duress. (IE, their life, job, or crisis depends on it.) Many can do it once, but need a significant break afterwards.

If someone is regularly cycling like that, it very well could be a coping mechanism for bipolar.

48 hours, even once, is a serious problem.

I know it’s not healthy, but I have unresolved issues that remain unresolved after 10 years trying to get help. At least it’s not alcohol. But that’s also perhaps why people don’t see the distress.

I work to forget.

I'm still suspicious whether it was actually 48 hours straight with no rest because -- no matter how brilliant someone is -- I would be extremely leery of the code written toward the end of that session.

In my case one had genuine clinical manic episodes and was open about his mental illness; another seriously burnt out; older friends in the games industry spoke of multi-month post-launch vacations (back in the late 90s) to cool off.

(And that was best case, if your infrastructure and deployment scripts were up-to-date. Most people's weren't; probably the ratio is only slightly better today.)

(OTOH, there are other explanations for the weird schedule. Substance issues, unusual home life, etc. I think people generally should be tolerant of weirdness, but ready to hear about the seemingly brilliant people's awful struggles.)

Unfortunately, he carried substance abuse and relationship issues with him as well, and eventually his health deteriorated.

When I reflect back, I realize nobody could relate to him because he was ill and needed help. Not because he was smarter or more capable than everyone else.

In my _personal_ experience, manic phases last 2 weeks to 2 months, followed by 4-10 months of catatonia.

It is approximately the same for my aunt and grandmother. In their cases, lithium and electroconvulsive therapy were the only things that work. For me, lamotrigine and modafinil are life-changing wonder drugs.

That said, people in my group therapy reported cycles as short as days to weeks - rapid cycling, as you say.

Note that the "off time" need not be matched by a depressive episode (and in fact I find that unlikely, since depression is not very restful) -- it could simply be exhaustion hiding the symptoms of the underlying (long) manic episode.

Consider that it's "just" a mood disorder, where mood management can be affected by random stimuli. So, their mood might be stable until some stimulus comes by. And that stimulus could just be a random memory, which can create a feedback loop. It's "fun".

Allows for but doesn't require. Workplace accommodations for any disability have to be reasonable and it's generally up to the business to decide what's reasonable. You can sue but most businesses would not find it difficult explain why it's important for employees to be working roughly equivalent hours and in the office if that's what everyone is doing.

BTW, deciding your own hours with little direction about how you complete tasks sounds more like a contractor than an employee.

"Of course not. There is only room for one Dennis Rodman on this team. In fact, you really can only have a very few Dennis Rodmans in society as a whole; otherwise, we would degenerate into anarchy."

Similarly, John Madden on Terrell Owens:

"If you hold the bus for everyone on the team, then you’ll be so late that you’ll miss the game, so you can’t do that. The bus must leave on time. However, sometimes you’ll have a player that’s so good that you hold the bus for him, but only him."

Obama got the peace prize before even entering office and EU is a study in dysfunction ...

Senior Architect

Legendary Architect

It's not fool-proof by any means—you can still build up processes and expectations that lead to micromanagement if your managers or culture are so inclined—but it makes the default behavior of the team distinctly less oriented towards micromanagement. You'll waste a lot less time and energy worrying about optics if people being present at a particular place and time is not an obvious signal of dedication/hard work/whatever.

Well, after a panic attack I changed my approach and asked my colleagues to write me mails instead or ask me on teams where I would only be online on certain days. Everybody just said sure, and work is finally fun again. I think I wasn't the only one either, more and more people started avoiding slack and only look into it maybe once a week.

A week later, the same manager got angry at me for not responding to client's urgent issue which was announced by Slack an hour ago.

So... yeah, closing Slack improves things, until it suddenly makes them worse.

Worked for that kind of team before. Never again.

Much of work is theater, and the only time you should put on a show, should stretch your legs is when there is an emergency in production (its down and your not making money) every other "emergency" is bluster and poor planing.

People ask “what am I supposed to do, slow down to their pace?” That’s exactly what you’re supposed to do. Put that manic energy into things that will pay off for you later (like passive income), not make your manager’s bonus.

It's extremely common for brilliant people to be twice exceptional. Problems like ADHD, ASD, OCD, etc. are fairly strongly associated with very high IQs.

This means if they pull an all-nighter, it's not because they pushed themselves to be productive. It's because their brain was on fire with an idea and they needed to get it all out right now and literally were incapable of sleeping until they could get it done.

That can't be replicated from the other direction. You can't say "I know! I will stay up and work all night and it will be brilliant!" That's not how that works. Not by a long shot.

The alternative is strict hierarchies where its made clear that some people have better abilities. That comes with extra privileges (money, flexibility, etc).

The one thing you can’t get away with is pretending everyone is equal but some are more equal than others.

I love that my company has a loose work from home policy. To me that means, I can go in the zone without being interrupted, but also that I can work on those not-so rare nights of productivity boosts from like 11pm-3am.

I'm no rockstar tho. Just a regular employee with wierd productivity graphs.

In contrast to your case, the managers in our team do not do any coding at all. I imagine you are talking particularly about senior ICs.

There's a strong tendency to "watermark" your productivity, and ignore circumstances around it.

Today is a perfect example, I got to look at code only for the first hour before I got a pinged about an issue somebody thought was related to code pushed out last week. It turned out the issue had nothing to do with it, but I had to investigate that. Then I got pulled into a conversation about why a certain number was up and how we might ameliorate that; came up with a pretty simple solution someone else is implementing... but then I got asked if I still was working on some low priority ticket so I had to figure out what that was, and then my boss wanted more details in our weekly status update so I had to search up some docs and tickets and stick them in there. Right now I have 15 minutes between lunch and a meeting with HR, and no, I'm not using it productively - because how far can I really get in such a small time window?

I budget for this reality in my estimates, but often get pushback. "Is this really going to take a week?" Well, no, it's not. If all this crap was pushed out of the way it could get done in a couple days, like project X did. But the reality is I'm halfway through my workday and had at best an hour to code uninterrupted - much of which I spent checking my email and doing code reviews because I often get tagged for not doing those things often enough

There are quiet days when I can just code, and there are days like this. And even in the former category, not everything is perfect; sometimes I didn't sleep well or have other personal stuff. But the days everything went well sets the expectations, while the reality is much less predictable.

The founders and executive team completely fucked it up. They kept hiring crappy/unmotivated people, prioritizing growing the team in quantity over quality, and with every added mediocre head it only amplified the morale drag when I'd be delivering huge progress after multi-day sleepless sprints while everyone else was barely getting anything done in the 9-5 office productivity theatre of standups and meetings.

I started absolutely dreading coming to the office after completing one of my kamikaze sprints. The VP of Eng had established this twisted pattern of holding a standup the moment I leisurely walked in the door at whatever hour I happened to make it in after not being seen for days, which for over a year was the weekly norm. Everyone in engineering would have little to nothing to say about their progress, and I'd drop another mother lode. It just made everyone else feel inferior, and I started to increasingly abhor their lack of progress and feel like I was the only person actually taking the opportunity seriously enough to make an effort.

It culminated in my abrupt departure three years in. And for years afterwards they failed to deliver any major new features successfully. Burned through many more millions of dollars, before eventually going bankrupt.

My mistake was not leaving earlier. That experience left such an awful taste in my mouth I've basically never made that level of sacrifice of my own life/time at another company since.

Edit:

To clarify, the hard lesson I learned at this job was that no amount of individual contribution can save a sinking ship. This particular experience was 15 years ago, and I've worked at numerous startups since, some with successful exits. I haven't seen any correlation between the amount of my contribution and the likelihood of a successful exit, absolutely none. Surely this is different for founders, but I haven't gone down that road yet. What I have seen however is some companies are far more dysfunctional than others, and the best thing you can do is learn to identify them quickly and RUN, the opportunity cost is too great.

Me & another consultant were brought it. Early on, the client decided to put me in lead. I tried some things for 2 weeks, with them watching my screen to 'learn'.. and nothing was progressing. One day, I told them I need to work alone, spent couple nights awake, until I got a light bulb moment to process queries in parallel instead of sequentially. Found sample code on internet, modified it to work on client codebase, prepared a demo, ignored writing a 'status report' (which pissed off the Project Manager), and did a demo to the clientele of 15 managers, directors & SVP - all in the span of 2 days (wed to fri).

Guess what had happened during those 2 days behind my back? The client, PM, and my manager had decided to replace me with a more senior architect starting Monday, and were ready to take me off on Fri at 3 pm. At 1 p.m I did my demo, which literally floored them. I then came to know about the machinations, and then the PM and my manager called me at 4 p.m apologizing, and saying they definitely wanted me on the project. I told them it was a perfect storm of mis-understanding, under-communication and over-reaction, which given the project's short & intense deadline, was just part of the game, and to forget about it and move on.

During my annual review, the Client/PM/Manager called me a 'cowboy' and gave a 'poor performance' rating. I told my manager that I accept the first part as a compliment and reject the second part as incorrect judgement.

I got fired. I left with a smile on my face.

For me, the reality was that my ego needed the boost from my perceived superiority. I had little else in my life that I Was proud of. Looking back, I understand how my behavior was an expression of a great deal of talent plus insecurity.

I've spent a lot of time working on myself, and my career and life satisfaction are significantly higher because of it.

I probably should have mentioned somewhere, I'm not that talented. I've worked enough places to know I'm just average. My apparent special ability is in the long hours department. If I commit to doing something, it's getting done, to a fault. I've been this way since my teens, staying up for days without even realizing it while figuring something out.

I'm already too introspective, you have no idea.

"The Psychology of Computer Programming", Gerald M. Weinberg

I've done a small number of 48 hour stints in circumstances where the need arose, and I've never in my life touched amphetamines or anything else like them.

But consistently doing this as described in the thread isn't "mania" phases of bipolar. It means one is on stimulants.

If the other employees want more time off, the correct solution is not to ask them to pull all nighters but just ask why. Usually extra time off can be accomodated with occasional work from home or allowing shifted start times. Or, possibly, your employees didn't even want the two days off a week -- maybe they were just feeling left behind and unappreciated that you just loved that coworker so much, and they came to perceive his odd working hours as a status symbol and reward.

Just want to verify my assumption that you were too small to have a "Research" or "Tech Strategy" department to move that guy into?

Are you saying that would be a guaranteed liability?

If so, how good is too good? You need to be sure to let your engineers know to stop progressing before they get there.

If they are really brilliant and you want to keep them with special treatment, promote them with a very visible title that clearly tells other why they can not get the special treatment which he gets.

But in my opinion if you look deeply these people are more of liability than asset for a general average SWE scenario.

It seemed to work out well from what I observed.

10x gets flexible work hours and, more importantly, interesting and varied projects.

Team doesn't get annoyed by one odd guy, but they are still available to support them, and other teams.

And there is mentoring in there too - this system basically makes them share their knowledge and thought process with potential others like them.

EDIT: There is also a benefit of not having them be a cornerstone of any project(ie - if they leave it fails).

On the other hand, you had the result: failed attempts by compatriots to emulate the hero.

Maybe the problem wasn't that you had a hero, or too many non-heroes.

Maybe the problem was you.

The idea that everyone can perform the same way when given the same opportunity is local to you, the manager. Perhaps what you needed to do was recognise that some members of your team couldn't be the same kind of hero - but maybe there was another quest for them. Maybe the heroes you thought your were enabling by letting them follow the same schedule rules, really actually just needed you to let them be a different kind of hero: the kind that gets things done on a normal, 9-5, business-like schedule.

There is room for this experiment to be repeated.

I understand it works for some, but since it doesn't work for everyone, I can see how people would be offended by an "unfair" policy.

Sure, if there is a clear start and end, these things could work. But on creative work that could go on forever, it's easy to cut corners.

The inability to track actual output levels doesn't go away when everyone is in the office. Instead you promote the person who is best at looking busy instead of the one actually outputting the most work.

I don't get how anti-remote persons manage to track office workers' performance.

Either you measure output, or you don't.

There are valid arguments against remote work, usually related to communication, but performance measurement? Nah

So you had a management issue rather than a worker issue.

It doesn't matter if a worker is secretly pulling 80 hours or 10 hours a week instead of the 40 (apart from legal/contract issues). If he's doing less than agreed between the parties, that's a problem. If management bought his excuses, then there's a problem with management.

Not meaning to devalue your comment, but this is such a bs excuse from him. Like, I definitely think about solutions to work-related problems outside of work way more times than just during my commute, and I bet that's the case for a lot of people that do any sort of intellectual work (all kinds of engineers, lawyers, researchers, accountants, etc.).

Less likely to be employed by someone who measures your output by hours.

I also think that you're wrong in making it the manager's job to police to work habits of their subordinates. I think a good manager should recognize signs of burnout in their subordinates and bring it up to try and address it, but you're arguing that the manager should impose their own idea of a healthy schedule on their subordinates rather than trusting them to know what works best for them. That strikes me as paternalistic.

That kind of thinking is along the lines of "just always pass Michael Jordan the ball". But that's not how healthy teams function. And it wasn't how Phil Jackson managed his team.

And you can credit John Carmack all you want. But his peak was when he worked alongside John Romero. Even Carmack himself has stated this. And Michael Abrash taught him the theory of how to do 3D rendering properly.

There is no "I" in "team".

But there is a "me".

"Manager time" and a set workday are there for reasons. There is no one so brilliant that they don't need to collaborate and in order to collaborate everybody needs to be following the same book of rules.

> I often think about how I could have better allowed his brilliance while not alienating the rest of his team, but in the end I failed.

Expect your brilliant engineer to be in the office during core business hours, and if he can't brook that schedule, fire him.

I'm pretty sure I'm absorbing this massive application and all the external transactions it does pretty fast, all things considered.

If I was constantly interrupting my train of thought and research to 'sync up' or 'collaborate' or whatever other personal fear of missing out that you're strapping your team into massaging, I'd dare say I won't be a solid contributor anywhere near as fast.

Assume everyone thinks the way you do and you throw away the chance for them to excel under even a slightly different structure.