Now for some organizational and career lessons I've learned over 30 years.

The Team's the Thing

Over the years, I've been fortunate to have worked with many excellent people - successful founders, coding machines, people who have changed the direction of technology from CPUs up to distributed storage systems. Here's the thing: not one of them was at their best as a lone wolf ... and I'm using that metaphor for a specific reason. The common usage of "lone wolf" is a bit counterfactual. Wolves are pack animals. The lone wolf is the one who was cast out of the pack, and is likely to struggle quite a bit unless/until they find a new one. How fitting. In just the same way, the successful wolf is the one who stays with the pack.

Every excellent engineer I've worked with has been at their best when they work with four or five others who were just pretty darn good. That was me, by the way. I had my moments at the front, but much more often I was one of the first to come behind the trailblazer, recognizing and addressing the things that were left to do while the trailblazer had moved further ahead. After all, we all have different strengths - different subject areas, but also different stages, from architecture or writing huge amounts of raw code to debugging and cleaning up technical debt. It's a waste to take somebody who's 300% at one task and force them to do another where they're only 50% (and I've seen bigger ratios). You might not be able to find the people to have 300% at every position, but 150% should be achievable and that's a lot.

But it's not just about skills. Chemistry also matters ... but what is chemistry? I might have struggled to explain, but I recently found this article that does much of the explaining for me. The concept of "psychological safety" there is very consistent with my own experience. The best teams I've been on, performing well above the level you'd expect based on pure skill, were those where people had each other's backs. They'd see each other's errors, but forgive - or even cover for - them instead of trying to exploit them. Those were also the jobs I enjoyed the most, like TCI or Clam or SiCortex. The worst teams I've been on, performing well below their skill-defined level, were the ones where people were stabbing each other's backs. That's why I didn't enjoy my time at Sequoia or Mango or EMC so much.

In fact, I'd go so far as to say that all of my other suggestions really come back to reinforcing this notion of safety and comfort with one another. You don't have to be friends, this isn't a social thing, but mutual support can go a long way.

Don't Allow Guerilla Warfare

One of the most safety-destroying behaviors that I've seen wreck teams over and over again is people who just can't let go of a decision that went against them. Every new bug, every new performance result, sometimes it seems every change in the wind direction, becomes a reason to re-open the old discussion. There was a guy at Revivio who had to be fired because of this, and he wasn't the first; I had been hired largely to replace the previous example. There was plenty of this on MPFS as well, and it's most of what made that such a miserable experience. I've almost certainly been guilty of this myself. It's hard to watch people persist in making what you believe is a mistake, and swallowing your objections is a skill that must be learned.

The thing is, even if a mistake was made, undoing or even constantly questioning a prior decision carries a cost too. If you're five miles into the ten-mile fork of a trail, you might regret not having taken the six-mile fork. However, forging ahead is still better than turning back. Cutting across might be even worse. And no matter which fork you chose, you'll be better off committing to it than continually stopping to re-hash the decision or having the dissenter take personal pot shots at the leader. Watch out for this, and stamp it out.

Don't Confuse Skill With Leadership

Another thing I've often seen destroy group cohesion is misunderstanding the role or selection criteria for technical leaders. The role of a tech lead is to choose and facilitate the best solutions, not necessarily to come up with them on their own. A good tech lead will fairly evaluate ideas that are not their own, that might even seem alien or irrelevant. A bad tech lead will always make give their own ideas pride of place, making them default no matter how hastily drawn up they are, only changing when the weight of evidence becomes so great that they'd look like a fool for persisting.

Being the best individual contributor (IC) on a team, with the greatest skill or domain knowledge, is not the same as being a good tech lead. They're different roles. If your tech lead is also your best IC, then (a) you're probably wasting their real talents and (b) you have to watch out for the often-subtle assumption that their ideas are better. In particular, they might be your best IC because they have great depth in a particular area, but a tech lead needs breadth as well. I've said before and I'll say again: someone whose only significant experience is on one project or even within one tech stack is not qualified to be a tech lead on anything. This is also why I think it's important to get exposure to a broad selection of ideas and environments early in your career.

If your team lead (good or bad) is not your strongest IC, you might have a different problem. That strongest IC can easily use the credibility associated with their recognized knowledge and/or productivity to undermine the tech lead. Sometimes this is the "guerilla warfare" I mentioned above. Far more often it's unintentional, just a natural conflict of perspectives and roles. This particular pairing can be very powerful, both for good and for ill. It might not hurt to get your tech lead and your star IC together and be explicit about how they can support instead of contending with one another.

You Get What You Measure

Lastly, let's talk about performance reviews. One of the worst fads I've seen, particularly prevalent among the so-called FAANG companies and their imitators, is making "impact" the main factor in how people are evaluated and given (or not given) raises and promotions. It seems like a good idea. Quantitative measurements, used to root out all kinds of subjectivity and bias - what's not to like? The problem is that performance reviews are inherently individual. Have you ever been at a company that analyzed whole teams at the same level of detail and diligence? I haven't. The problem is that measuring individuals this way incentivizes behavior that destroys that all-important sense of psychological safety.

• People rush in code changes, the infamous "commit race" that forces other team members to do the work of resolving conflicts.
• Sometimes rushed changes cause breakage (because testing is another thing left behind in the rush), perhaps affecting only other team members but possibly affecting most of the company.
• People leave code riddled with technical debt, because they're always rushing to the next thing and never stopping or going back to clean up, and that eventually catches up with them. Besides the wasted time, people can see who the culprits are and that also erodes team trust.
• People make big "brag posts" full of cherry-picked metrics at the end of each evaluation period, giving an unfair advantage to those who are better at writing and/or creating pretty charts. (Are those really the most important qualities to select for?)
• People de-prioritize tasks that don't relate to their own personal impact, so those often have to be done in a rush later, or re-done, or dumped on others. Again, not good for either code quality or team trust.

None of these are done maliciously, or even deliberately. Even people whose natural inclination is to do the right thing feel forced to put on the blinders and charge ahead, so they don't even see enough of the picture to know what the right thing is. Gentle reminders from people who do see make no impression, because actions speak louder than words and the action is to incentivize irresponsible behavior. For all of the problems with subjectivity etc., there's something to be said for managers having discretion to reward those they know - that everyone usually knows - is putting the team first and letting others excel.

Pace Yourself

This is at the end because it's most important. A career is a long time - typically twice as long as your entire schooling, maybe a bit less if you went to grad school and/or plan to retire early. Intense jobs/projects do burn you out. I had to take a sabbatical and then work part time for a while at Red Hat. It's also why I started working from home full time at that point, though that could be worse in some ways or for some people. I probably should have done it earlier, though not sure when. When you're selecting jobs, projects, or roles, your energy level should be one of the factors you consider. Do you really want to jump right into another round of Startup Grind when the whole reason you're leaving your current job is that it ground you down? It's OK to take a break, or a "lower" position in the same company. I demoted myself at Revivio right after my daughter was born, from "product architect" to individual contributor. Everybody understood.

Another part of career management is trying different things. The high-bragging-rights specialties like game development and HPC are actually pretty miserable in some ways. Every specialty has its own unique technical focus and culture. You might be surprised how much you enjoy tackling the challenges in a more "boring" specialty, or how much people will pay you for it. You might find that you enjoy your work more when you can see it having a positive effect in the world, or conversely that you enjoy it less when you see that effect is negative. Data storage was not my first choice of an area to work in. I was fortunate that I got to try many different things early in my career, and storage is just what I found that suited me. It's hard to describe, but a lot of the problems I get to think about - data distribution, communication protocols, managing performance across resources as different as CPUs and networks and disks - are just fun for me. Other people might get more of a kick out of the algorithms relevant to warehouse management, or the math specific to digital image processing, or creating new experiences for users to enjoy. Find what kind of work you actually enjoy doing, not just what looks good at first.

In the end - which is where we are - there's more to you than your career. There's more while you're still working, and hopefully more afterward. Make sure you reserve enough energy to look after your health, stay close to friends and family, do other things that you find enjoyable or fulfilling. Would you want to spend thirty or forty years isolated inside a literal bubble, perhaps in one of those desert experiments or on your way to Mars? Being isolated that long inside the tech-work bubble isn't that different. Sooner or later you'll want to get out, like I did.