Hacker News Reader

Comment by raphar | Hacker News Reader

This is key. I see that there are two aspects of this story:

1. The OP is obviously far ahead technically than his work environmment. He has the experience, know the practices and can improve the software process.

2. Second but key, he sucks at working in a team and also at communication. You don't change a mess such as the one he describes in 5 months. That culture of the company, if you are not the boss, only changes by soft proposals, influence, bond building, debate.... Nothing is going to change to new practices or behaviours if not for conviction (or fear). It's a slow process, an not one you can win only by logic. The subject is huge.

That said, I agree that it was better for him to leave.

View on HN

> Second but key, he sucks at working in a team and also at communication. You don't change a mess such as the one he describes in 5 months.

Well, he sucked in that team. It's good to know the kind of person you are. I've learned, somewhat the hard way, that I become a bit of a nightmare in situations where I can't make a difference quickly. This tends to lead me away from very large, very process-driven, very political organisations, because I simply don't have the temperament for it, and towards smaller, scrappier companies, where it's possible to make forward progress quickly.

One day, after all, I will die. I don't want to have spent too much time between now and then having to deal with torrents of organisational bullshit. The fact that I don't know how much time I have left only adds impetus to cut through the nonsense.

Whereas some people can survive, and indeed thrive, in that kind of environment. They have the patience to see it through, and gain their satisfaction in other ways than merely seeing the product taking shape quickly.

Right. OP was providing leadership. Sometimes that means stepping on others' toes, and how they react is key. That team was a problem anyways.

Maybe that's the problem; he wasn't hired or looked to as a leader, or as previous commentators have said, he hadn't earned the respect of the team yet.

That's not what leadership means, unfortunately. Being right in a non-productive way is also a failure in leadership.

At the end of the day, if you do want to provide technical leadership, the skills to understand the team and how to interact with them effectively are at least as important as the technical skills.

If you cant achieve change, camt negotiate and cant explain, you are not providing leadership. Regardless of whether you are right.

What clarified things for me while reading it was coming across this line:

> Well, I AM actually stubborn!! But if the metrics had shown that BATCH was worse, I would absolutely be the first to change my mind.

He's self-critical. I also think he's only right about being stubborn in its original meaning (untameable) rather than the new colour the word seems to have (unwilling to change despite evidence).

What happened here was an NHL player joined a team thinking it was another major league team, but it wasn't even college ice. That's fine, but his mistake was not just leaving for a different team. If you come into a team thats slightly beneath you you can raise it up to your level and change peoples careers / lives for the better, but getting too far off just doesn't work. You're way too ahead of them and you're new so they don't trust you or want to listen to you. Just move on to a more pro project.

Exactly, I remember this stellar test lead was hired by a previous company I was at. Once he was on the ground And saw the state of affairs he resigned and said this company isn't ready for him. We an org is running too crudely you can take a professional hit working on structuring things that don't stretch you professionally. To stick around in a technically immature environment can cost you.

Its often very common that those with the best insights into improving a system also have the least power / knowledge of how to pull levers of power.

I mean that's not particularly surprising, since someone who both had the insights into how to improve a system and also the knowledge and power to change that same system (and who cares) will generally make those improvements. So if you see a broken system, and someone who knows how to fix it, and that person is not fixing it, there must be something (organizational badness, higher priority fires elsewhere, apathy, etc.) blocking them from fixing it.

So the way you see it, the people who have the power to fix things do actually fix everything they know how to fix. So then over time the situation stabilizes around people who have the power to fix, but everything that remains is beyond their insight. Anyone who has the insight is a relatively powerless newcomer.

Yes, pretty much. Well, newcomer or someone who just learned something new.

Very well put. It's like how hard/right decisions are "difficult" decisions to make. If the right decision is easy, everyone makes it without too much consideration. If the decision is hard and wrong, no one would opt for it.

Currently I'm the "surviving senior dev" for a very old crufty mission-critical legacy app, and I'm painfully aware how broken it is and the ways in which is breaks.

So sometimes I have to kindly remind myself that its current state isn't indicative of some damning (yet oddly egotistical) personal failure, where I "shoulda" rewritten everything from scratch by now.

On the plus side, the QA team is gradually learning to do more than manual browser tests...

Maybe we only hear about their frustration precisely because they don’t have the power to change things. “Leadership changed things for the better” isn’t much of a headline, it’s the expected/desired outcome.

This is exactly why it's so valuable to keep good notes while onboarding a new engineer... A fresh set of eyes gives you a rare opportunity to see problems that familiarity has blinded you to -- yet a new engineer is in the worst position to fix these problems.

I don't think his expectations were unreasonable and I don't blame him for not wanting to spend years of his life slowly trying to fix a dysfunctional team/process. I know it's not easy, but companies should do a better job at hiring so that both parties time isn't wasted.

Why do you assume he sucks working in a team and that the other team members were not the issue?

When everyone else appears to be the issue, perhaps it's worth considering one other possibility...

There's something about the writing style on that page too. Hard to describe.

"If you encounter three jerks in one day, you're the jerk."

Community of jerks usually easily accept another jerks, so it's quite possible to find yourself among jerks even if you're not jerk.

Ha! You've never worked as an air traffic controller. That job attracts type-A personality jerks like honey attracts flies. I've met dozens of jerks at one time. And not a single one of them would call me a jerk. Okay, maybe one or two of them would. It's such a toxic environment—I had to resign.

He's obviously not a team player!

(I'm totally kidding; your question is an excellent one.)

What's funny to me is how sometimes there are two qualities -- being both more competent (than one's peers) and not liked -- that in combination can further perceptions that someone "isn't a team player"..in the eyes of The Majority, the same people who are the real problem.

If the team says pigs can fly, the sky is red and Bob isn't a team player, all of those things might as well be true. After all, perception is reality.

Honestly? Because the whole article reads like it was written by the sort of socially oblivious person who doesn't work well in a team.

A team has its dynamics. It is difficult to join a team if you have a self assigned mission from the get go. The author seemed to have done that.

The author was also smarter before he was empathetic. When he saw someone become touched after the criticism he put forth, he should have changed pace. And changed focus. Instead of focusing on the critiques, he could have focused on the outlying problems contributing to those critiques.

Instead of ignoring the responses everyone made to good suggestions, he could have been more accepting and started to beat the same drum.

Point is to find common ground first. Solutions come second.

Reply on news.ycombinator.com