4 ms·

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 delega

by pault 9y ago

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."

thisisit 9y ago
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.
- mercer 9y ago
  I can imagine the writer not intentionally hiding these things, but I do agree that they should be added to the original article.
  - thisisit 9y ago
    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.
    - user5994461 9y ago
      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.
cupscale 9y ago
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?
- jsjohnst 9y ago
  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.
- user5994461 9y ago
  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.
imron 9y ago
> "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.
- zimpenfish 9y ago
  > 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.)
  - ergothus 9y ago
    > "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.

by pault 9y ago

thisisit 9y ago

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.

mercer 9y ago
I can imagine the writer not intentionally hiding these things, but I do agree that they should be added to the original article.
- thisisit 9y ago
  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.
  - user5994461 9y ago
    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.

cupscale 9y ago

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?

jsjohnst 9y ago
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.
user5994461 9y ago
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.

imron 9y ago

> "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.

zimpenfish 9y ago
> 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.)
- ergothus 9y ago
  > "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.