Hacker News new | past | comments | ask | show | jobs | submit login

I briefed the original story, and one thing that stood out to me is that the author threw a 'bomb' named collaboration into the mix AFTER firing so-called Rick.

What author fails to understand, is that the problem could have been addressed by collaboration as well.

I caught a 'scrum-master' CTO wanna-be that wrote an article about (omitting my name) how he is happy I was gone because I was hard to manage. This guy showed up and hanged his scrum-master certificate on the wall and promoted a (fresh out of college) junior developer to management because he was there for a year longer than me and proceeded to enable and reward the most idiotic technical decisions I have ever seen while the rest of us was battling scalability problems.

He never talked to me; he was in the room with his new director of engineering (1 year of non-management experience, seriously) trying to come up with a strategy on how to do things and then try to run with it without getting any feedback.

Obviously, I shot them down, and it got to the point where they would come up with this stuff (no communication) and could not provide any details (why will this work? why is it better?).

I simply quit and never looked back at that point, they probably did collaborate a lot more. And by collaboration, I mean circle jerk whatever ideas sound great and force them on junior developers that do not know any better.

I vouched this comment.

I'm sure it was dinged for not using mild-mannered business vocabulary to describe the former workplace. But I've seen some form of this play out in real life enough times to tell your assessment probably isn't too far off, and you were right to get out of there.

Finding someone that's actually dedicated and not just willing to say "dedication" in an interview needs a position that won't burn them out, or the knowledge of when to quit. Having neither is a disaster waiting to happen.

Except that, in this case, project continued more successfully without Rick then it did with his unofficial leadership.

I'm not entirely sure that's true. I have no evidence, I just don't think any company would have a blog post "We had staffing problems, now we're buggered". Instead it's "We had staffing problems, we fixed them, now everything is amazing".

I also don't think things would have gotten this bad if the original dev team could have picked up more of the slack, but I don't have experience in dysfunctional workplaces. Still, the "We had one guy with all the domain experience, then we fired him and all our other devs magically became amazing" thing doesn't sit right with me.

They failed at fighting Rick, they failed at politics and they quite clearly are not ready to be leaders. They did not failed at programming once the above was solved by new leader.

Yeah, because that framing is imo wrong too.

1.) In all likelihood, they Rick was not that much genius, although he might have some more more knowledge initially and probably was not bad programmer either. There is nothing to show he was genius.

Here I will make the guess: Rick belittled other people and criticized everything they did and simultaneously had more initial knowledge. That made everyone assume Rick is genius and others are low skilled. The politics follow from there. Note that other people did not slacked at work nor took three hours long lunches (I assume). Them working overtime would fix nothing.

Local praised genius belittling other employees has predictable consequences - it is that others look significantly less skilled then they are to management (yeah management is to blame too) and those people know it. It also means those people will learn to not have ideas and not have initiative, because they get insulted for those and because those invariably turn against them. As I told, it is very predictable.

2.) The other people did not turned from people who are learned to be passive to people who suddenly got agency and autonomy. Nothing in their programming skills changed, only people management of leadership of company changed.

And note how them not being arrogant still means they get comparably very little credit for technical talent or skill. (I see that as pattern in it.)

But it wasn't the same project. It was a lot smaller.

It was the same project. Requirement and expectations management was done better. Communication about current status was done better. The descend to troubles described in original article is not just "too much work". It is bad decision making.

And I stand behind this 100%. Non technical management cant really do the above and where they can, it is only when technical staff feeds them accurate information about difficulty and scope. Someone making up requirements in his head and then coding something much more complicated is not a mark of genius. It is mark of someone who don't listen.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact