Hacker News Reader

Comment by YZF | Hacker News Reader

360 isn't perfect but it's better than the alternative.

You're basically saying that those who worked daily in close interaction with the 10x developer and had to work with the code that developer produced, had lower regard for his technical ability than a manager who presumably is further removed?

You can't ignore the social aspect. A team with social frictions isn't going to work as well as a team that enjoys working together. Obviously just being social isn't enough but a strong team needs a combination of the social and technical aspects. Also 360 should mean going beyond the team, so the manager should be evaluated by his peers, his managers and his team and technical people on the team should be evaluated by members of other teams they work with.

View on HN

Yes, I know what a 360 is, I've participated in them.

In the situations I indicated I was also a developer on the team so I knew how productive and skilled the 10x prickly developer was. His peers ranked him high on technical skills but only as high as more amicable and lessor skilled peers.

I'm not saying I ignored the social aspect, in fact that is why I called him "prickly". I'm just saying that, while his teamwork related areas were properly low, his technical areas were improperly low because of this halo effect.

Did you manage a self-selected team?

I swiped the Roman Evaluation Method from Luke Hohmann. During interviews, a No from one is a No from all. Self selecting teams is one of those agile advices.

If your prickly superstar was chosen collectively, he would have been given a lot of latitude. Eyes wide open kinda thing.

The only sticky interpersonal problems I've had is when some higher ranking genius assigns people to my teams, mostly unwanted and unwelcome.

And sometimes just plan bad soup. People good individually, bad together. Like when the boss assigned an outspoken Lebonese and an outspoken Israeli to my team. They got along as well as peanut butter and lug nuts.

Self-selected teams while good from that perspective actually have a huge downside: politics and pleasing your friends.

Next thing that happens is people start choosing members based on how much comfortable they are (which doesn't translate into technical skills and delivering stuff) or start talking to each other, trying to convince people.. this sucks!

While it might work for small companies with not much variation in technical skills and sociability between employees.. for anything else it's kinda hard.

Plus, that initial list of 2-3 employees that start talking and picking others was selected by someone, wasn't it? And the list that they can pick from was also selected, no?

I think if you need a team of 10 and you have 30 possibly good candidates within your company (and they are all available to move to your team).. sure, why not. You as a manager already pre-selects a bunch of people and then let your team members filter it even further.

But putting that responsibility from the beginning solely on the team members.. I guess that's risky. But anyway, how often does that happen?

If we are talking about selecting 1-2 people for a already formed team than fine.. of course other team members should do it (but that's mostly the norm in a lot of companies.. the manager/tech lead runs the resumes through people he/she trusts, ask them to participate in interviews.. no big difference there).

> I knew how productive and skilled the 10x prickly developer was

How? What makes you so sure you weren't biased?

Well, I certainly am biased, in a way I'm probably not aware of :-)

How? He wrote a ton of great code in a short period of time that worked amazingly well. How else would you tell somebody was productive and skilled?

But, think whatever you want!

Makes me wonder if he wasn't a prolific tech debt producer who was seen by management to GTD.

No, but I know exactly what you mean. Years ago I was on a team where the "super star" was assigned all new work. The rest of us had to fix the bugs in their code.

At the finale, 5 people were doing nothing but fixing bugs in the "stars" previous projects. That's when senior management finally clued in to the problem and fired both the manager and the "super star".

going by the upvotes, we aren't the only people to have seen this anti-pattern...

Yeah, this is why I kind of like project ownership even though it's now considered out of fashion. If you create technical debt, you own it and it's your future productivity that takes the hit. Eventually your productivity grinds to a halt as you fix problems in the crap you wrote before.

I look at it as technically informed product ownership - merging business and technical domain knowledge to make the right tradeoffs. How else can you execute effectively?

Reply on news.ycombinator.com