Live data from Hacker News

High Performance Individuals and Teams

pablasso.com

61–70 of 76 posts

Re: High Performance Individuals and Teams

#61
post #52
post #8

Earlier quoted context omitted.

> It's job security and furthermore if it's a valuable piece of the product then it can keep praise and rewards centered on you. That's part of it, but training people is also very difficult. If you know a system well it takes a day to add some feature, but it takes a few days of frustration to train someone else.

If those are actual numbers (a day versus a few days) then that should be an incredibly easy decision. A few extra days is nothing compared to doubling your capacity to deal with problems in that system!

That is a few extra days for one task. 6 months later you'll still be training the person, though the overhead will still be lower it still will be slower than doing it yourself. Then the person might leave and you start all over again.

Re: High Performance Individuals and Teams

#62
post #61
post #52

Earlier quoted context omitted.

If those are actual numbers (a day versus a few days) then that should be an incredibly easy decision. A few extra days is nothing compared to doubling your capacity to deal with problems in that system!

That is a few extra days for one task. 6 months later you'll still be training the person, though the overhead will still be lower it still will be slower than doing it yourself. Then the person might leave and you start all over again.

This seems like the common mistake of trying to optimise for individual efficiency at the expense of the rest of the system.

Yes, overhead will be higher, but since capacity also will be higher, cycle time will go down much more (non-linear effect) and you'll extract important value and feedback out of the tasks sooner, easily paying for further capacity improvements.

Re: High Performance Individuals and Teams

#63
I've worked with 10x-ers. They do exist.

In my experience they're extraordinary people in many, many aspects. More than anyone has a right to.

Besides the god-like ability to solve problems, they were amazing mentors, and clear communicators focused on what's right for the team at the time.

They were universally liked and working with them makes you a better professional.

Software is a a team sport, successes is hard to come by on your own.

Re: High Performance Individuals and Teams

#64
post #63

I've worked with 10x-ers. They do exist. In my experience they're extraordinary people in many, many aspects. More than anyone has a right to. Besides the god-like ability to solve problems, they were amazing mentors, and clear communicators focused on what's right for the team at the time. They were universally liked and working with them makes you a better professional. Software is a a team sport, successes is hard…

I also worked with 0.5x-ers. Whose presence alone would drop value in half.

Re: High Performance Individuals and Teams

#65
post #33

Earlier quoted context omitted.

> Putting my manager hat on, I ask: Can I replace 10 of my average engineers with this one person? The answer is never "yes". Well, yeah, people aren't interchangeable cogs. A person that is capable of delivering 10× value per unit of working time when properly employed probably isn't a drop in replacement for 10 1× developers. And managers thinking of people as interchangeable cogs where productivity multiples work…

> A person that is capable of delivering 10× value per unit of working time when properly employed probably isn't a drop in replacement for 10 1× developers. I find that claiming they produce 10x value per unit of working time, while also pointing out that they aren't interchangeable cogs, as a bit odd. If they are not interchangeable (which I agree they are not), then you shouldn't compare their productivity so glib…

> Lest "different people have different roles" is a confusing factor, let's eliminate the uncertainty. Say I have a team with many responsibilities (including non-technical ones), and it is every developer's responsibility to do these. You will likely never find a 10x employee there.

Yes, if you're team is so poorly managed that has neither top-down not bottom-up organization for efficient task distrobution but instead features mechanistic, blind task distribution, you'll both decrease output even of a team of whatever overall competence and minimize the performance differences on the team that aren't do to absolute superiority on every type of task. Which is why, whether it's agile self-organizing teams or other bottom-up approaches on one side or any kind of top-down management theory on the other, every approach to managing work is about.

> To be clear, I don't doubt that a person is 10x better than the average in doing X, but I've found that X is always a very narrow scope

I find 10× in a narrow scope to be very rare, though it probably happens somewhere. Something more like 3× in a narrow scope of focus personal tasks (e.g., the more complex design and coding tasks) and providing a 2× multiplier on the rest of the team by helping choose efficient direction of focus, identifying problems proactively early, and otherwise keeping the team from wasted/misdirected work that otherwise would get done is both more common than 10× in a narrow field and a bigger productivity win.

Re: High Performance Individuals and Teams

#66

> Even more important than finding great engineers is to avoid bad ones. After reading that sentence, I thought to myself, "How long did I go from the start of my career before meeting someone of whom I genuinely thought, 'this person is so bad they should definitely be fired asap'?". In my case, I think the answer is somewhere around 20 years. My takeaway from this is that at even with ~18 years of experience, my fo…

I was probably 6-7 years into my career before I encountered such a person. It was my first formally titled “software” role, having spent the years prior making software and calling it “websites”, for a mostly brochureware design firm. I had terrible impostor syndrome. But I recognized that a member of my team was simply not up to the task. And was very well liked by the team, so no one had spoken up.

But I was gaining responsibility, including (informal at the time) leadership of this individual. And it was a liability to the team, and to me, and ultimately to the person in question. So I spoke up. I felt terrible about it, I feared alienating everyone, and I feared I was putting the person in financial and career risk. But I didn’t see a way to bring them up to even a standard where their presence wouldn’t be a net negative, and I knew I wasn’t up to the challenge of carrying that weight. So I did what was best for the team.

The person was ultimately let go. And they did ultimately find a role that was better suited to them. So all is well. In hindsight I don’t think I should have been so torn up about it. It actually sucks to be in over your head, knowing it or not, and it’s possible finding a more fitting role is a better place for growth into more challenging roles.

I’m not sure how to conclude this, I’m not sure if there’s even any value sharing it. But I guess for anyone reading who finds themselves in my position (newish, relatively ascendant, full of self doubt but certain that a peer is in the wrong role), I would recommend trusting your gut. And I would say that there’s a lot of room in tech for a lot of people at almost any skill level. Just not always on your team. And that’s okay. They’ll very likely be okay.

Re: High Performance Individuals and Teams

#67

Earlier quoted context omitted.

I felt similarly as an IC, but my perspective changed as I shifted into management. I didn’t believe that “negative value” engineers existed when I was working on the front lines alongside other good engineers. In reality, I was seeing the end result of competent management teams who effectively filtered out negative employees in the hiring process or quickly dealt with anyone who became problematic after being hired…

I’ve gotten rid of the engineer you describe. He was technically proficient but lacking in literally every single other ancillary skill for an engineer or a human being. He could write complex code but it was overengineered and overcomplicated imposing a huge maintenance burden and making it brittle. His whole team was “Wow, he must be so smart!” but when asked on what basis he’d chosen the approach he’d taken instea…

> He was technically proficient

> He was not interested in learning new things.

So, sounds to me like he was only proficient with one specific technology.

Re: High Performance Individuals and Teams

#68
post #16

Earlier quoted context omitted.

What would you consider a bad engineer? Are we talking about the utterly hopeless or those who might only have an attitude problem? If it's the former I've perhaps encountered only one in the last ten years. If it's the latter it's almost every month.

I have met plenty of bad engineers so maybe it's just luck. Engineers that can't write simple code and always over engineer. Engineers that have no concept of encapsulation and use globals all over the place. Engineers that have no concept of perf. Engineers that can't ship and noodle the same piece of code for weeks that others would have finished and moved on in a 1/10th the time. Engineers that are all talk no wor…

I wonder what would happen if you also started walking around and stopped finishing code. Would the boss keep you too, or would you get fired despite having a family?

Re: High Performance Individuals and Teams

#69
post #36

"If you find a project where only one person know what is going on, chances are that person is not good at writing code for humans, not that is a coding god." This is hard for many to grasp, but if you get the opportunity to lead enough teams it will become clear. And it makes sense, if you think about it. An individual who ended up owning a particular piece of a codebase will be incentivized to obfuscate and obscure…

In my experience, the far more likely explanation for a bus-factor for an area of code is not that they want it to be that way, but because the organization has stretched them and other coders thin enough that it's hard to fix that. An organization can get surprisingly far with a huge number of bus-factors, and doing a learning-by-fire session whenever someone burns out and quits. If the engineer who's a bus-factor o…

If you don't care about the bus-factor, you can have 10 projects with 10 developers. Actually, even more than that, because one developer can work on multiple projects in parallel, or at least have one active project and one or more mostly stable projects where they are the only person doing maintenance.

But of course with 10 projects you will need at least 15 managers...

Re: High Performance Individuals and Teams

#70
post #63

I've worked with 10x-ers. They do exist. In my experience they're extraordinary people in many, many aspects. More than anyone has a right to. Besides the god-like ability to solve problems, they were amazing mentors, and clear communicators focused on what's right for the team at the time. They were universally liked and working with them makes you a better professional. Software is a a team sport, successes is hard…

Some people make it a false dilemma: either there are "mythical" 10x developers, or it is about teamwork. Then they prove the teamwork is important... and therefore 10x developers do not really exist!

But in fact, there are people who are 10x developers and are great team players. And there are also people with great technical skills, who are completely toxic. And there are also people with mediocre technical skills who believe themselves to be gods, and for some reason management seems to believe them. All of these are real, and I have met them.

For good cooperation, both the 10x developer and the rest of the team need to be good team players. Because some people are unable to teach, but also some people are unable to learn. Some people are condescending to those with less experience, but also some people are hostile to those with more experience. If the team works well together, the 10x developer can set the project architecture right, teach other team members to follow some good principles, and then all together do seemingly miracles.

Post reply on HN