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

From a comment on the original post:

"Unfortunately Rick rejected months of overtures by leadership. He refused to take time off or allow any work to be delegated. He also repeatedly rejected attempts to introduce free open source frameworks to replace hard-to-maintain bespoke tools. Including the security framework as you mentioned."

Also:

"Another poster blamed management. I agree that the situation that came about was also his manager’s fault. He never should have been allowed to take on so much. If it gives comfort to anyone else reading this, the manager went first because ultimately management bears responsibility, always."




This still reeks of CYA.

> "He refused to take time off or allow any work to be delegated. He also repeatedly rejected attempts to introduce free open source frameworks to replace hard-to-maintain bespoke tools."

Why did he have the authority in either of those last two decisions?

> "I agree that the situation that came about was also his manager’s fault. "

And his manager's manager, and basically anyone who was aware of this project and the fact that it was delayed by two years.

Nobody above Rick's manager was looking into this project when it was delayed by two years? Nobody took a look at the JIRA/whatever board and saw that one person was blocking everyone despite working 100 hours a week?


Two years past a committed delivery date is a very long time in software terms and is a sign heads need to roll all over the organization.

I think an argument could be made for everyone in Rick’s chain up to and potentially including the CEO should be let go.

> I’d been aware of the project for a while, because it had grown infamous in my organization, but hadn’t been assigned to it.

And especially the blog post writer who knew about the problem for a long time self admittedly and did nothing about it, only to then pat himself on the back for handling the situation poorly when it was finally assigned to him.


One thing not clear, it might be an outsourcing company doing a product for an external client.

If so, we're talking 3 years overdue while billing an entire team. That's typically considered a success for the outsourcing firm. Remember that they bill by time*men, not by project delivered, coulnd't care less about the software and the people.


> "Unfortunately Rick rejected months of overtures by leadership. He refused to take time off or allow any work to be delegated. He also repeatedly rejected attempts to introduce free open source frameworks to replace hard-to-maintain bespoke tools. Including the security framework as you mentioned."

How late in the game was this though?

It should have been really clear cut:

Rick: I'm going to take on this extra work

Manager: Have you finished all your existing work?

Rick: No

Manager: Then No.

Rick: But..

Manager: No.

A good manager would have nipped this in the bud before it started.

People complain that Rick was snappy - you would be too if you'd been working 12 hours a day 7 days a week for a year or two and the weight of the entire product was on your shoulders and getting heavier by the day - also something a good manager should have nipped in the bud.


> A good manager would have nipped this in the bud before it started.

The problem here is that "good managers" are incredibly thin on the ground and even then, this situation can arise due to circumstances beyond their control (consider a politically well-connected developer, for example.)


> "good managers" are incredibly thin on the ground

True, but that should be a problem to solve, not an excuse (for the industry at large). Are companies providing leadership training? Are they trying to find out if a managerial candidate is actually "good" (by whatever definition they choose)? Are they evaluating the existing managers and trying to prevent problems before they start? Are they treating their managers as resources to be invested in or scapegoats?

There is a bit of chicken/egg there (they need to be good managers of their managers), but overall you can't expect to get what you aren't trying to get. If the incentives are to work on big projects to pad your resume and point fingers when they fail, you have an incentive to CREATE big projects, and an incentive to treat coders et al as someone to start building a blame narrative for in case it is useful.

I've had great managers and terrible ones. The great ones maintained a long view (don't overcommit, understand tech debt, know people are human) and would fight for you, whether that meant talking with upper management or having a hard talk with you. The terrible ones assumed their job was to assign work and chide are threaten as needed. The great ones would ask for details to understand, and only occasionally raise concerns. When they did, they brought their concerns to me first, to ask what I thought should be done. The terrible managers would also ask for details, but it was to micromanage. The great managers appreciated all their staff, even the troublesome ones, and viewed their job as finding the best point of mutual happiness between that employee and the company. The terrible ones mentally (or more) divided people up into "poor", "acceptable", and "great", and then showed favoritism to the greats and disdained the floors.

One constant for both, however, was that the managers that thrived at any given company were decided by the incentives the company provided, be they financial, cultural, or social.


> The problem here is that "good managers" are incredibly thin on the ground

The problem in this case was really caused by a bad manager though - who ended up being fired. That didn't make it in to the original story and was only noted by the author in the comments.

Where was the exposé on the mistakes made by management, which seem to be equally egregious? I mean you don't even have to be an exceptional manager to prevent this sort of problem, just a competent one.


Even competent managers can be comprehensively stymied by a politically connected and savvy developer.


Personally I think those are important enough points to be included in the main post. People shouldn't need to dig through the comments to see those.

But these statements came ex-post and that too when people pointed out obvious holes in the original post. So these sound like the original writer was coming up with excuses to absolve the company of wrongdoing. Oh..you mean vacation..yea sure we did that.....you mean manager was responsible....ye sure we fired him.


I can imagine the writer not intentionally hiding these things, but I do agree that they should be added to the original article.


I am not too sure because if I want to make noise about how my developer screwed up, highlighting the incompetence of the direct manager played a big part as well. Yea sure maybe the minute detail of management overtures being refused can be missed because they wanted to portray themselves as a good guy.

From the looks of it the whole thing was written from "an expose on star developer culture" point of view. In which case, admitting your own mistakes in the first draft takes backseat and it's all about the "star developer".

What is even more surprising is given that so many people have pointed out this hole, there hasn't been an edit to clarify this point. I am not digital content expert but if it does spread wide, no one is going to care what is in the comments.


Depends where the poster stands in the organization.

Highlighting failure of an employee is always a bad idea. Highlighting failure of many employees and the entire chain of command is a suicide move.




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

Search: