Those kinds of people are generally stuck at a lower level. L7/8/9 is very much a political game. To get there (generally) you need to make your entire org/company look very good, and generally to make your team look good you need to work well with them so that you can convince them to work on the high impact projects that you identify.
The best teams IMO have about a 10/10/80 split between people who do great work and know it, people who do great work and don't know it, and people who don't do great work (caveat: they should do ACCEPTABLE work) but are aware of their limitations. There's only so much work that you want your talent to be doing and you can try and keep the major touch points to your power players, and then you try to silo off the drudgery to the folks who are happy to have something hard to fail at. The personality type of the good-and-knows-it tends to need to be offset by the humble good-but-unsure types. Heaven forbid you get even one worker who can crank out productivity like no tomorrow and claims to be doing good work because in a vacuum everything is functional but they optimize only to close tasks and leave the system in total disrepair. It takes literal years to clean up some messes, and from experience I tend to prefer working with people who adhere to N > quality(output) > 0 over those at |quality(output)| > N.
Yes, this mirrors directly that old adage from that German general [1].
I don't want to work with brilliant people. I want to work with productive people. I've worked with people who are great at solving hard problems that don't need to be solved (and I've been that person myself).
In my experience, people are productive when they're on a team that encourages everyone to be productive and keeps them all aligned in the right direction. That's hard to do with jerks on the team, brilliant or otherwise.
(To be clear, I think it's totally fine for different teams to have different priorities; I don't think there's a one-size-fits-all. I just have strong preferences for what teams I myself am on.)
How do you build teamwork with both low eq and high eq employees? Seems to me that it's hard to have a team with people on both extremes since they'll continuously argue about what is important.
Then the higher skilled members should devote a significant amount of time getting others to level up. It is a team. Management should have structure in place to incentivice it. If they don't have a structure in place then the high skilled members should devote time to make a proposal and pitch it. Find a way to win as a team.
If most of the team are actually 0.1s then a 1 will seem like a x10.
Anyway, I've worked with plenty of people who can get stuff done, and I've been able to get stuff done myself sometimes. However, it's all relative and if I'd been at Xerox Parc in the 70s I'd have been a 0.001 for sure.
What even is a low and high performer? This depends highly on context and on the environment.
Something I do see though is that there is a trend towards more and more distraction. Always be available in slack, large offices where someone always wants something, etc.
Also, in my experience, some companies just love to have pointless meetings with many people that cannot contribute at all, because it's just not relevant to their work.
I do like to work in teams, in general, but it has to work for everyone at the end of the day.
Except there's a great caveat with this approach. People that are highly productive and self-motivated often don't give a pleasant impression because they are fascinated with the idea and don't care for the looks. And vice versa, those who will look like a great friendly team, will be passionate about, well, looking great and friendly. They will spend time getting together, having endless pleasant talks about the latest news and their favorite TV show and couldn't be bothered to get out of the comfort zone and actually deliver something measurable.
You take a high performing team and rank its members. You take a low performing team and rank its members. When the numbers go to the next level up, the worst person in the good team and the worst person in the bad team look the same to the system - even if the worst person in the good team is better than the best person in the bad team! This is how the system works in practice. Good people get shafted because they sought to work with other good people.
It's not that simple in the real world, there's politics involved. The people who own a successful product aren't going to give up half their team. The success of it gives them an excuse to keep them all and keep growing the team. Which is counter-productive and hurts the product and the company, but helps certain individuals in the short term.
All good, i try not take things too seriously. Appreciate your bluntness and curiosity.
Most of my career has been with early stage tech but I’ve also been in companies of thousands. I think I’m best cast in teams of 5-20 and I’ve found I’ve done well building good culture around working within the limits of what the business needs (realistic costing, time estimates, alignment to product vision) while finding ways to intertwine the quality developers want to see in their own work with the objectives of product and the leadership team.
I think to try put it in simpler terms, the best people want an environment where they can do their best work. The question i encourage people to ask themselves is if they actually know what that environment looks like? Often they have an idea of what’s worked best so far, but not what is optimal. I like having discussions around that as you can go from there to a) learn from their perspective and see if you can include part of that in the environment you’re presently operating under and b) determine if that’s a good near team goal or long term goal for the current environment and set realistic expectations with that individual as to not “bait and switch” them. I really see little point wasting someone’s time with promises of utopia when you’ve got a team that just isn’t working…that’ll end predictably.
I’ve said before my best skill has been building small teams of very bright people, retaining them and out performing larger teams. It’s pretty trivial to out perform larger teams if you can retain people, but to retain them they need to like what they’re doing and how they’re doing it.
That's a fair criticism for certain contexts. Most people I've worked with desire to do well and to feel good about their accomplishments. In those sorts of teams, this works. It would likely not work as well in an environment where people were just hoping to do the minimum possible.
Ok but serious question...what do you do with highly ineffective teams that you inherit, and/or are contractors, and/or are the only engineers available, and/or are only motivated by a paycheck, and/or would rather be working on their five side projects, etc..... in many cases who have demonstrated repeatedly that they make lots of mistakes and get sloppy and will fully refuse to cooperate.
Yet your job is to somehow produce high quality software. This is the not uncommon outside elite startups in my experience.
This fits with my experience that low-ego people are better to work with and low-ego teams tend to thrive more often. I think it's important to separate status and authority deriving from other authorities compared with status and authority earned fairly in the eyes group/team members, though.
There is no linear ordering on workers! You might be dumb at algorithms but great at stakeholder management and average at coding. Takes all sorts of strengths to make a good team.
What happens when you work under a group of people who are satisfied at stage one of project X? You know you can iterate to get two stages further, but they want you to work on projects Y and Z. This is a very common situation where you, or even the whole development team has very little control.
Of course, management should be supportive of quality improvements, but their reality is either one where they are under genuine pressure to deliver projects X and Y to stage of quality through to not understanding or caring about quality.
My own experience is that individual programmers have vastly different ideas of quality is based on their experience and education. You can be struggling to get a team to improve and then you hire a somewhat normal individual with a very different background who makes a sizeable impact on quality and the culture of this in the team. I'm thinking specifically of someone who joined from aerospace, but I've seen it with finance backgrounds. I think the background matters less than the perspective and ability to hold people accountable (including yourself.)
People that show that they want to be there often make for excellent teammates, because they actually care (the old missionaries vs mercenaries idea), and will often be willing to put in the effort to fill whatever gaps they lack, while creating a positive work environment.
Plus, they might have a really good feel for the product and market, because they're genuinely interested in it. You want people like that on your team.
Now, of course - businesses are not a charity that only employ people because they want to be there. There is a minimum bar of skills required and plenty of other traits that matter. And on the employer side, there's a ton of factors there too (budget, existing skills of the team, etc etc).
So yes, I was generalizing. But in general: I'd take someone who wants to be there with high aptitude who has things to learn over someone who has skills but doesn't actually give a crap about the product or company any day of the week, for the types of companies I'm trying to build. That doesn't mean my or your companies needs/goals are the same.
Exactly. In fact, you NEED average people on your team to play the roles that the superstars are unwilling to play. Places like Facebook where the dirty and boring work is respected and rewarded (according to a Quora post by Yishan Wong) are rare. In a lot of places, the superstars do the superstar thing, and other people do the other stuff.
Good teams will always find a place for people. Ironically enough, this sometimes may even mean promoting someone with poor technical skills to management, among various other drastic measures. Their technical skills may suck, but their interpersonal skills and organizational skills may be off the charts, and they'll still have enough technical background to understand what the heck they're managing. That kind of thing.
When my friend first started at Google, he commented that there seemed to be a lot of underlying impatience and discontent because Google only hired superstars, and so many superstars had to stay on the bench. Not everyone can go do the glamorous job. Various anecdotal blog posts seem to have given us that even Google hasn't been able to 100% figure it out.
oh no. you're responsible for a group of skilled and not so skilled engineers in a domain that you don't understand. all is not lost.
what is your only goal - to maximize your teams contribution to the goals of the company. full stop. its not to stack rank your employees unless it serves that greater goal.
but you don't understand the domain. oh no. all you can do is develop a human relationship with the team. listen to them. you can't judge the quality of their work, but they can.
don't ask them to rank each other (I've seen this), but just be attentive. after not to much time you can really start to understand how people are helping the effort, and how they are undermining it. in broad terms, without understanding the gory details.
this is the only thing that works. everything else is just obfuscation.
These types of questions are somewhat simple to go into in smaller teams/projects/companies. It becomes very complex in large enterprises where politics and nepotism plays a role. It's all good in theory. My approach is more based on values, morals, priorities, way of life and so on. This has enabled me to gather great individuals working in poor environments...
reply