Hacker News new | past | comments | ask | show | jobs | submit login
You fired your top talent. I hope you’re happy (medium.com)
460 points by ech on Oct 16, 2017 | hide | past | web | favorite | 172 comments

There are quite a few places like this out there, typically technology has a muted role in decisions in these organizations, quality takes a backseat for the crunch for the next meeting demo, ad infinitum.

A smell of these types of places is they always blame the developers that just left, almost like a scapegoat or two minutes of hate rally. Another smell is estimation is rarely respected i.e. if you say it will take a month they should expect it to take that long or even twice as long as the programmer estimate, but at places like this, about halfway through they say it has to be done in a few days for a very important meeting or deal, if it is that important you want a solid product not a one off.

As a developer you also need to manage balance and workload. Consistent work discipline and good sleep/health are important. Take on challenges but be sure each project is a focus and you aren't spreading yourself too thin, work quality goes down when you don't have some buffer. A good developer would never design a system that is constantly pegged, don't do the same to your schedule/self as that is a single point of failure.

Wow, that exactly describes my company.

Our group ignores the ops stuff necessary to keep our product up and running to keep pushing out garbage for the next big demo. Most of our product is not working multiple days out of the month.

Some MBA guy with ambition learned enough technical skills to keep things up and running with some help from me.

Boss goes to MBA guy to keep things up and running and considers the problem "solved". MBA guy is running himself ragged by logging on after hours and screwing around with data files just to keep things running, then doing the same admin BS all day.

After MBA guy is let go, he is badmouthed for coming up with an unsustainable solution. All future admin work is explained as being necessary only because of him.

Eventually we had our "launch" and our PM did the "big presentation" to our company leadership. After everyone started to realize our product was garbage and we had boatloads of promises we could never keep, she just jumped ship.

I would have considered the whole thing a joke except it ruined my health and relationships for several months.

I see so many sides to this

-I’ve been a Rick, stayed at a company for nine years, knew where the bodies were buried because I buried most of them myself and became more disenchanted year after year which caused my attitude to get worse and worse. They wouldn’t fire me but they also wouldn’t promote me and give me raises - causing a horrible cycle.

I woke up one day 8 years later in 2008 and making only 10,000 more than I had made in 1999 as the raises were abysmal and the bonuses got cut realizing that I wasn’t competitive.

9 years, four companies, and a lot of humbly studying and learning from people a lot younger than I am, I’m finally in a position that I want to be in as the software developer lead for the company.

I saw myself becoming the bottleneck and working crazy hours for the first 5 or 6 months. I had to put a stop to it. I sat down with my manager, hired three more people. I now insist that everyone be responsible for making sure their work gets all the way to production, everyone does there own devops work, documentation is part of the “definition of done”. I let them solve their own problems even if I know I could solve it faster.

I’m training the team not to be dependent on me.

When it comes to meetings, each developer is responsible for chasing detailed requirements when there are gaps.

My responsibility is to hire, train, and to mentor. I will do the most critical pieces of the architecture that is a base for everything else. I also enforce a 40-45 hour work week. If you want to learn on your own that’s fine but no one should put in crazy hours. We don’t want to set that expectation.

When I read the original article I was immediately curious how Rick would've written about this, and whether he was really as bad as he sounded, because I also have been, at least, a semi-Rick. Or at least I can imagine someone writing about me in a way similar to this.

There's a lot I could say about my experience, but it boils down to a combination of bad practices/behavior on both sides (that I learned from immensely), broader circumstances, as well as a bad fit between me and my direct superior(s) or the nature of the company. I think the latter is often underestimated.

I believe that the 'true' story of bad employee/employer is often a lot more like a romantic relationship than we care to admit. And while my impression is that Rick was more at fault in this situation, I'd say that just like a romantic relationship, the best lessons to draw from these events are not the blame-game ones.

(of course, maybe that says more about my romantic entanglements than about work hierarchies...)

EDIT: tangentially related, but I just realized that one of the few ways in which I feel I can say I've 'matured' on my path to 'adulthood', is having experienced multiple sides of, in essence, the same situations. It makes empathy and productive solutions so much easier, even if not always in the moment.

This kerfuffle is a good reminder for me to keep an eye out for these types of lessons and to avoid reflexively looking for someone or something to blame.

Having an entire product rest on your shoulders sucks and emotionally drains you rather quickly. In my case it was a startup with a technology I created on the side that became the main business and eventually became the sole earner for a company whose other business had already been dwindling.

At the time there were maybe half a dozen people in the country that even worked in this particular niche. If I left the company it would likely go down, and the CEO kept telling me how many people would lose work if I left. And the pressure and responsibility kept growing and growing. And the sales people, who made up half of the staff, kept getting more and more antagonistic, as I couldn't meet their constantly larger expectations, which were often technically impossible (like sci-fi movie level). This situation lasted for over a year, culminating in a huge blowout between the CEO and I when I left.

I became a Rick real fast. I still feel like shit for being a Rick, and it's taken years for me to move that experience out of my "work baggage".

I agree with you 100%. Our relationships with our employers and with our work is very much like our romantic relationships. It sounds like Rick and management were both inexperienced and focusing too much on the short-term. Similar to breakups, sometimes we draw them out over many months (or years...) because we've invested so much into something already, it's hard to just pull the plug. And certainly the idea of the "frog in the boiling water" applies to both types of relationships. When things get bad slowly over time, we don't notice.

I also feel like I've been a little like Rick before (though in a non-developer role). I learned a lot from that experience and, like you, have matured as a result.

I’m in the opposite position now. When I see a developer complaining about working hard having to learn all of the new stuff I’m pushing on the department - unit testing, dependency injection, CI/CD, etc. since I’m not technically management, I’m not in a position to do anything but allow for comp days and put in a good word for the FTEs and sign the time sheets of the contractors. But anything they learn will help them in the future either at the current company or the next.

I want everyone to come from the job with a mixture of doing grunt work - Yet Another Enterprise CRUD app — and learning something new cool and useful. I don’t want anyone stuck on the same app forever.

Well, then I guess I am in a unique position, a reverse Rick of sorts ;)

I have tried and tried hard to stop people being dependent on me, writing detailed specs and documentations, generously sharing them with the team - not once but multiple times. The end result being people ask me either to do the stuff because "I am the expert" or resend the document link for them to study.

"The end result being people ask me either to do the stuff because "I am the expert" or resend the document link for them to study."

This is the most frustrating thing. If you can't even save the link or search your mailbox then I no longer WANT to help you. Figure it out.

While I can agree there are 'real' rockstar developers that act like the original article mentions, I don't think whether Rick was or wasn't one of them is what matters here. What matters most here is how management dealt with him and their lack of responsibility for Rick's work for the last two years(!) and the end as their result.

Other industries seem to get this better than ours. I've worked in quite a few places that assign too many projects or tasks to key developers and then reprimand them for lack of quality or quantity, which ever you will inevitably buckle under first and it's never the manager's fault for assigning too many tickets or not prioritising their tasks correctly (we're not mind readers) but yet it's always the developers fault for the perceived lack of skill or lack of effort. Don't get me started on the arbitrarily shifting release dates that correlate with buggy releases that we developers get angry emails about. Maybe I've worked at badly managed busineses, or hey, maybe I'm just a bad developer, but this seems like the normal to me.

But if you're managing someone and they fuck up, it's also your responsibility because you were meant to be managing them. That was your job. Even if Rick was told to stop working, take a break, and he didn't it's still not up to him, it's up to the manager to decide what's best for Rick and best for the project.

I worked for a company for five years as first a junior and later senior developer. My reviews were always glowing. I got promoted to lead shortly after our current lead left. I worked 10 hour days harder than I had ever worked in my life and developed a stress disorder I needed to take medication for.

When my review came around I was told I was not getting enough done. There was zero possibility of me getting more done. I had given so much of my life and my health for a company I thought I loved? The next day I contacted a former coworker who had been poking me to come work with him, and a couple weeks later I was gone. Best decision I’ve made in my life!

Some spend their entire lives working at a company to figure out how little they actually value them in the end. I know I've worked for people for far too long knowing this and always regret not leaving sooner. Glad you saw the light and had an opportunity to get out, some don't always get that sadly.

I've turned down contracts because the stress of working with certain businesses just isn't worth the money they are offering and they are a constant revolving door of people. Hiring a contractor, burning them out with insane expectations and micromanagement and firing them when they miss those deadlines or slip up. It seems like it might work in the short term but long term it has to be costing these companies. They always have the worst codebases too, funny that.

> Don't get me started on the arbitrarily shifting release dates that correlate with buggy releases that we developers get angry emails about.

I'm willing to bet that it likely causation in a majority of cases. I've been there. Business comes back with a list of wishes for the quarter. We're asked about the features as a whole, and I'm already on the fence about whether it can actually get done.

We start getting granular with the stories. By the end of the first sprint's estimations, we've definitively said, "There is no way we can finish all of these by the end of the quarter." That's taken back to upper management, and the whip is cracked. Too bad.

Sprint has started, and instead of a quarterly wish list, we now have hard, immobile release dates for different feature sets that don't give enough time. Some people are working long hours, and some of use are sticking to our 40 and done. The features are released as wished. The production defect count increases, and the production team grumbles.

I assume we'll repeat this until the clients get sick of shoddy workmanship and outages.

Working overtime without some sort of commiseration should be illegal, yet it is typically expected in a lot of salaried work. Even my local groceries makes their workers spend 10 minutes cleaning up before close, 'off the clock'. Game studios are notorious for the crunch at the end of a projects life cycle because of the random off the cuff date a publisher needs to fill up a void in their yearly lineup or quarter.

The thing is they don't explicitly say 'work over time' they say 'this feature needs to be complete and working by Monday or else' What does management think the developer will do, pull it out of our behind? Reminds me of Steve Jobs, actually.

I once had my boss explain to me if these features don't get completed before the end of the month, he will lose his house. I had already previously told him that it's impossible and had to explain we will need to compromise to reach that date. We released 1 month late but the software has a lot of issues and I'm now blamed for this as the lead developer of only two programmers. I worked 12 hour days 6 days a week for 1 month and he wanted me to work more. He still has his house.

It's a zero sum game. Developers only have so much time in a week and the more you chip at sleep and rest/play time, the more it's going to cost the developer's health and the project's cost.

It's frustrating because I'm just a developer (mostly contractor to boot) and yet I feel like I have valuable constructive criticism that would benefit management and the productivity of the project on the whole if they adapted it. You can rarely pull that off tastefully. Maybe I'm wrong, maybe these things exist for a good reason and I'm seeing this differently because I'm not in management so I have some confirmation bias. That's possible, but I've experienced the exact same scenario as you and it always seems harmful for the developer and harmful for the project.

I'm new in this industry, but based on my life, the experience of some close friends, and anecdotes like this, my impression is that you need enough career security and cash savings that you can just ignore stupid requests from your boss and not care about the fallout. Of course that is probably unsustainable outside of entry level jobs, so I am sort of convinced that I should have a 6-10 year plan to exit it

That's an interesting way of thinking about it. I'm not very assertive, so perhaps If I stood up to management a bit more everyone would be better for it anyway. Although it's easier to stand up to your boss when it falls under your domain (technology), but when it's their domain (managing people) it's harder to be assertive.

Also what happens when it just becomes a self fulfilling prophecy? Regardless, if you experience terrible management you should probably be finding another job anyway.

You're absolutely right. But sometimes it's just the confidence and competence. If you're actually good at your job and you know that, you can push back on insanity and not panic if you come up craps.

Quick question, what does your contract say about work hours? There is usually a well defined limit and the unpaid overtime you do should be regarded as illegal.

Don't put all the blames on management when developers do long hours. It's the developers who decide to stay late all the time when they should not.

A lot of us are contractors for the company with 40 hour work weeks. People at my company are salaried. I don't know about the other companies. I don't stray much from my 40 hours. If others want to put in that time, so be it. I always tell them to knock it off, but some people just can't be helped.

I don't put it all on management. It's a little of column A and a little of column B. It's tough standing up to management when they control your well-being.

I wonder what would happen if a company had overtime pay for developers. I'd be willing to put money on working hours getting reduced to something sane and deadlines pushed back to accommodate it.

Maybe one day I'll suggest a trial for it at my company ;)

I worked for a company where we were all regular W2 exempt employees, but paid hourly. We got paid for every hour worked.

Curiously, we all worked a lot, made a ton of money for years and years, and bled the company dry. They eventually brought in some accountants that told them they had to put the brakes on this, and we were converted to salary. The company still ended up shutting down a couple years later, but it was a wild and lucrative ride.

Just become a consultant. Much more lucrative and much more freedom.

I'm not sure other industries do handle it better.

I would argue that it's a prevalent problem. There has to be a reason, why there are a bunch of studies on success and failure ratios of projects. A lot of them explicitly stating that the top issues are bad communications, lack of priorities etc.

One of the standard PM exams even has frequent exam question about how sources of conflicts in projects in the following order:

schedules, project priorities, resources, technical opinions, administrative procedures, cost and personality

Personality is always last.

Yes, there are exceptions. There always are, but in general lack of experience at the top gets pushed down the chain. Top performers are always the first to be negatively affected though.

> I'm not sure other industries do handle it better.

They don't. The factory I used to work at routinely fires competent, productive engineers because they need scapegoats for management failures. The bigger the failure, the bigger the scapegoat, so sometimes it goes all the way up to director level, but that's only once every few years. Realizing that all it would take to lose my livelihood would be for me to be in the wrong place at the wrong time was one of the big reasons I left.

Personality is not a thing as such. What matter is the environment.

People adapt to their environment. Most character issues are a response to the work environment.

I'm not sure I follow, maybe I'm not understanding you correctly. Are you actually saying personality is only a result of environment?

Take for instance introverts vs extraverts. Introverts might be forced to be more social in an open office, but they would still work better in a private space and management has the ability prioritise their worker's personality and provide both open and private spaces for them.

The way you behave at work is in great part a result of the environment.

Let's say that every time you have a meeting, the manager and the client blame you for the project being late. Soon, enough, you probably gonna avoid them as much as you can or kill yourself in overtime, maybe both. It shouldn't take long before you get the reputation for being a dickhead and maybe someone will write a blog post about it.

None of this is really about you personally, it's simply the social dynamics in your work place.

I can give you a much simpler example. Put 10 people in an arena and give them a sword, gladiator style. The last standing gets to stay alive.

Congratulations, you just discovered that any human can be turned into a murderer in 10 minutes! They adapted to their environment.

I believe I understand what you mean now, although it's possible we might be conflating the environment having a large impact on ones behaviour (which I agree you are correct on), and; someone's innate personality developed due to genetics and their collected experiences in different environments and as such behaving better, worse, or different in those environments. Essentially we are arguing Nurture vs Nature, or Environment vs Genetics, right? I believe they both have a large impact and can cancel each other out.

For instance in your first example, a very charismatic person might not get a reputation for being a dickhead because everyone loves him due to his loveable personality, yet he's in the same environment and situation as the person who is known as a dickhead.

> I can give you a much simpler example. Put 10 people in an arena and give them a sword, gladiator style. The last standing gets to stay alive.

> Congratulations, you just discovered that any human can be turned into a murderer in 10 minutes! They adapted to their environment.

Have you ever been in a disaster or life threatening situation? There's a fight or flight response and that response can be different depending what sort of personality you have, right? I imagine not everyone would fight in your hyperbolic example if we simulated it thousands of times. I guarantee there are many people out there that would drop to the ground crying in a ball rather than fight to the death.

Yeah, wow.

I mean, Rick's a dick, no doubt. But much like Frankenstein's monster, it's incredibly easy to see who had a hand in transforming Rick into what he became. It's hard to read the original article and not see several large "where the hell was management" red flags:

> Any time there was a particularly challenging problem, Rick would handle it.

That's a management failure, and a particularly egregious one that I see new or overly passive managers make. How do you expect one person not to have all of your domain knowledge if they're solving all of the challenging problems?

Fixing this doesn't even involve being super confrontational:

"I'll fix <database issue 123>." "Hey, Rick, you're already working on XYZ and I want Summer to get some experience working with our database system, so I'd like for her to do it."

> First, he created a cult of dependence.

Because management idly sat by and let him do that. People want to feel irreplaceable and like they're exceptional. One way to do that is to create this cult of dependence. Management's job is to step in and re-assure Rick that he's a valued member of the team while also directly confronting this cult of dependence.

We do this all the time at my job, and we don't even do it using complete thoughts. We just say "bus factor" and everyone understands why one person can't be responsible all the time for something (or in this case, everything).

> Team members didn’t want to speak up and offer their own ideas because he always berated them for it.

Holy shit, you didn't torch his ass for berating people in meetings? Are there even managers at this company?

This, to me, is the worst failure. Either management is ignorant of the berating (bad) or they silently tolerated it (even worse).

I really hope the managers at that company are taking a long hard look in the mirror and doing a post-mortem on what went wrong with Rick. I suspect they're not, and attributing it to one bad employee, but I can hope.

> I mean, Rick's a dick, no doubt.

Who, when being worked 12x7, and when given the pressure of being a blocker of everybody else, isn't going to respond poorly? I've seen some of the nicest and even tempered people get short with others when the pressure cooker is really turned up. Rick sounds like he was a good guy to begin with - someone who regularly helped his coworkers, someone his coworkers trusted - until he was overloaded with work.

Fight or flight. When exposed to extreme stressers, people tend to take one of those two paths. Rick took the first. Someone else would have broken down balling, or spiraled into deep depression, or isolated themselves. Don't blame them for being human - blame the company for creating such a terrible environment.

None of that changes the fact that Rick became an awful co-worker and needed to be removed, whether temporarily or more permanently. Sorry, berating your co-workers repeatedly is a terminable offense in many places.

To go back to my analogy: Frankenstein’s monster still killed a bunch of people at the end of the day, even if it was Frankenstein’s fault that the monster existed at all.

We can blame Frankenstein while still agreeing that his monster should’ve faced consequences for its actions.

Giving someone more tasks than anyone could handle and then firing that person because they don't achieve it is only management's failure. He didn't need to be "removed", he only needed to be managed properly.

Did you read the original article? That wasn’t the crux of why they fired him.

You're missing the point. The way it all happened was essentially "yeah so we beat the guy with a baseball bat and he had the nerve to swing back at us while we did so"

Eh, no it’s not like that at all.

Again this is more like a dog that’s been abused over the years and then mauls a kid.

No ones surprised that the dog is aggressive, and the owners are obviously guilty of abusing an animal - a horrible thing for the owners to have done.

That doesn’t change that the dog’s aggressive now, though, and should be put down.

Correction: A dog that's been abused for years by a kid and then mauls the kid while he is himself beating the dog

And then the kid goes on to write an essay about how good he was for finally putting down the dirty beast.

The sheer depth of badness this comparison reaches is extremely impressive.

Developers are human. They don't need to be put down.

No, but sometimes they need to be fired because the work situation is unrecoverable. Regardless of who’s fault it is.

“Put down” here is an analogy for being fired. I don’t actually think Rick should be put down. I’d hoped that was obvious.

I know you did mean firing, but even that wasn't necessary. In germany we actually force companies to at least try and work things out. In order to fire someone you need 3 documented instances of misbehavior followed up improvement attampts, or an actual breach of law.

This gives everyone time to sit down, gain distance, sleep over it and calm down and try again.

Plus, if the feeling of not getting along remains after that, after some calming down it's often easier to work out a mutually acceptable separation. In a similar situation over here, Rick would've gotten a fairer treatment even on separation, other than "fuck you, bye".

I thought that was also the case in the UK, but it turns out you need to have been employed for 2 years for that rule to apply.

"fired" is a very negative word, but the point is there needs to be a break between company and employee. As someone who was fired for cause in a situation like this, it's the best thing that ever happened to me. The ship was on fire and sinking fast, and I was totally burned out, bailing as fast as I could. Requested my vacation time once we shipped(nearly on schedule) & got fired instead. Felt awful at the time and I was totally bitter, but looking back it was a godsend. 5 weeks later I had a new job, a vacation, and a huge raise. Now I can't imagine why I spent so long there doing miserable work with old dead end tech, crazy overtime, and all for a pittance. Yea it would have been nice to leave on my terms but the important thing was leaving, regardless of fault or method

Same story here.

Although, I was halfway through my journey home when I felt a huge weight had been taken off my back.

Sometimes getting fired is good.

I don't see how anyone who understands what an analogy is would come to the conclusion that the GP is proposing that developers are killed. What's shocking is how ridiculous your comment is.

I know he didn't mean killing. I elaborated in a comment above.

Is he, really? Seems like the most dedicated employee mentioned in the article. Could his devotion be tempered by management and molded into a better hammer for the company? Sure seems like it. Seems like Rick was well respected to be placed so much responsibility - the real dicks here are the ones who led to his decline without intervention.

Er, yeah, he is. You can be devoted, respected, and admired but still be an asshole. They’re not mutually exclusive traits.

See also: Steve Jobs, famously.

They responded to these points in a comment on the original article, which acknowledged management's responsibility for creating the problem, and they say they fired his manager first.

I'll admit that I'm particularly touchy about bad people managers, but it really does seem like they just washed their hands of the problem without trying to really discern:

* Why this became such a big problem (and wasn't resolved earlier)

* How to prevent it from happening in the future

Because if one team can effectively silo themselves so well that problems like Rick are allowed to fester for multiple years, I don't have high hopes for the future for them.

>I mean, Rick's a dick, no doubt.

"No doubt" a real person is a dick, because of a single-sourced account from those who fired him, which even at that, leaves the question of their own failures wide open?

Also, even assuming Rick is a dick, I think that might have been more sympathetically (and probably more accurately) rendered as "Rick became a dick".

As the article points out, working endless overtime to the detriment of the rest of your life - not to mention isolating yourself from those around you - will play havoc with your mental health, sense of perspective, and general wellbeing.

Ehhh sorry, saying things like "I'm Albert Einstein and you're all just fucking monkeys scratching in the dirt" doesn't strike me as the speech of someone who's particularly nice.

Most people (at least in my experience, you know, the one who's making the subjective judgement about him being a dick) can be angry without saying something pretentiously mean like that.

It's ok for the conclusion here to be, "Rick's an asshole who should've been fired but management fucked up pretty badly." Situations don't have to be binary with only one party at fault.

EDIT: Let's also not forget the accounts of Rick supposedly berating people in meetings. If multiple people think you're being mean to them, you're probably being mean.

I don't know: in my experience pretty much everyone has a breaking point somewhere and once they reach it things can get pretty random. I've seen people I thought had it all together just completely lose the plot and disintegrate too many times to believe it's all bubbling away there, just below the surface, in all of us.

Your reasons for being an asshole don’t change the end result though. It just changes the context around it.

Similarly I can understand how an aggressive dog came to be (poor training, etc.). That won’t change my opinion that the dog should be put down when it mauls a kid, you know?

Perhaps it's the dog's owners who should be put down. After all, they'll just get another dog and make it as aggressive as the previous one...

Blaming an innocent for how they were cultivated is silly. Especially when those innocents can be rehabilitated.

We're getting a little off topic, but this company is just setting up another Rick to take the blame when the train goes off the tracks again.

If you read my other comments, you’ll see that I agree with you completely.

That doesn’t mean the dog shouldn’t be put down. It just means there are also other parties at fault.

It absolutely means the dog shouldn't be put down. Dogs, and more importantly people, can be rehabilitated.

All it takes is one person in power to care enough to see to that rehabilitation to transform an aggressive "dick" back into a productive team member.

>Your reasons for being an asshole don’t change the end result though. It just changes the context around it.

No, it very much does.

We are not cavemen to assign labels to people based only on external outcomes. Ever courts take emotional state and other circumstances into account.

Sorry, it really really doesn’t.

The court might take your emotional state into account when you murder someone, but if they’ve got you dead-to-rights you’re still going to prison.

Does Rick deserve to get blacklisted? No. Would I have been incredibly upset if they named the individual? Yes.

Did Rick deserve to get fired even though they basically set him up to get fired? Yep, he still does.

Did Rick react inappropriately to a horrible situation? Yep, he did.

Actually no, just because you kill someone doesn't mean you're going to jail. If someone is attacking you and you lash out in self-defense, you're very likely to not go to jail as everyone is expected to be able to defend themselves. It sounds very much like this was a defense mechanism to overwork. The fact that they didn't give him time off before approaching him was kind of crappy in the first place. It should never have come to what it came to.

Most people (at least in my experience, you know, the one who's making the subjective judgement about him being a dick) can be angry without saying something pretentiously mean like that.

Doesn't matter.

Someone backed into a corner is just act like someone backed into a corner. The die was already cast. Everything that happens after is blame-shifting.

Uh, what? It absolutely does matter. There are appropriate reactions when you’re “backed into a corner”, and there are inappropriate reactions.

I absolutely get to say what the arbitrary line is in this case because I’m the one making the subjective judgment that Rick was most likely being an asshole.

If Rick had snapped and shot up the place would you think he should face no consequences?

If Rick had snapped and shot up the place would you think he should face no consequences?

I'm sorry I insufficiently hedged my tolerance of someone showing anger when pressed and didn't think to explicitly cover the case of escalation to violence.

I absolutely get to say what the arbitrary line is in this case because I’m the one making the subjective judgment

And I absolutely get to tell you that in my assessment you're wrong. That how opinions work.

> I’m sorry

Good, I’m glad we agree that you insufficiently argued that people backed into a corner aren’t responsible for their actions.

There were a lot of failures in the Rick story "on all sides" as POTUS would say. This author seems to identify with Rick and frames this type of developer as gifted, but taken advantage of. At the end of the day, we all have to manage our own careers. And in this field that especially includes "managing your manager". Whatever process you find yourself in, you have to be able to push back and say: "I'm working on X, if you want me to work on Y, what do you want first? What's the priority?"

If you find yourself in the pitiable position of fielding calls from Sales, Marketing, and Support, you need to get out of that situation by appealing to the CEO/CTO or someone. You have to have a buffer between these groups and development. If this doesn't exist or you can't get it, go elsewhere.

That's not really the point. The point is that the company is patting themselves on the back for firing someone who, by their own description, sounds like they could've provided a ton of value with better management (and even did, at first.) There's nobody who should be patting themselves on the back in this story. It's a story of a bunch of incompetent managers and a programmer that couldn't manage himself, and evidently someone high up in the company that's proud of this somehow.

If you treat your stars like cows, they become dogs.

If you stop feeding your milk cows and expecting higher output, eventually they stop producing at all.

>There were a lot of failures in the Rick story "on all sides" as POTUS would say.

Nope, there weren't. That's what management is for. Everything that happened, since they didn't attempt any change, is their fault and their only.

Naw, at the very least Rick was guilty of hubris and naïveté. I came in after a Rick left once, that guys ignorance and poor decisions hobbled that company for years. Icarus is not held in high regard, by anyone.

Yes. How dare Rick be human; to be missing traits which are typically obtained by teaching, not by osmosis. The story of Icarus is, one, completely fictional, and two, a parable used for teaching such traits.

If you are in technology, either you become responsible for learning on your own or you get left behind.

I’m not just referring to learning the latest new and shiny JavaScript Framework. I learned the hard way that technical skills will only take you so far. I had to learn the soft skills.

You are responsible for your own career though. By being the one subject matter expert and not doing documentation, it meant that he would probably never be put on new projects using new technologies and probably his own technical skills became outdated. So when he did get fired, he found it harder to find another job (been there done that - didn’t get fired but came close).

So it doesn’t matter whose “fault” it is, he was the one ultimately harmed by it.

And in this field that especially includes "managing your manager".

Managers get paid to have people skills. Programmers get paid to code. If you really are some genius, you may be able to write good code and also be more talented than your manager at people stuff such that you can manage your own boss with some seriously tricksy Machiavellian maneuvering. But, saying that is necessary is suggesting that all managers are incompetent dolts who cannot possibly do their job and, also, should not be expected to.

How would you feel about someone saying "Managers should be better at running the company than the CEO and it is their responsibility to somehow steer the ship to success in spite of an incompetent, alcoholic CEO routinely making stupid decisions"?

I'm really surprised how much pushback my comment about "managing your manager" has gotten here. I'll respond to your post in particular.

If you really are some genius, you may be able to write good code and also be more talented than your manager at people stuff such that you can manage your own boss with some seriously tricksy Machiavellian maneuvering.

Well, no, you aren't required to have better soft skills, or be decietful/conniving, to manage up as they say. Also as an aside, writing "good" code has very little to do with being a working programmer, sadly.

In my world view, managing up is better described as "standing up for oneself". Does your boss know the trouble you've had with the build, test, and deployment environments? Does your boss know that Senior Person X doesn't respond to emails or other queries in a timely manner? Does your boss remember they said to do task X before assigning you task Y? Does your boss intend for you to stay late every night for a week to accomplish X and Y or are you just assuming that? Do they remember you stayed late 3 nights last week? Managers are people, they forget things. I am advocating for keeping your activities and challenges front of mind for them. One must obviously must be engaged and delivering, for any of this to be effective.

I don't disagree with you that this is a good thing to do --if you know how to do it. I think you are getting pushback because your framing implicitly suggests it is Rick's fault he got fired and it does so in a way that implicitly absolves management of their role in this debacle.

Maybe your intent is more "Oh, gosh, if you find yourself in Rick's shoes, don't just let bad management crap on you like this and then railroad and scapegoat you." But that isn't what it sounds like you are saying.

From the company's perspective, though, at the end of the day the buck stops with the manager.

Yes it's important to manage up, but that's for your own benefit more than anyone else's. From the company's perspective, they pay the manager to handle you, not the other way around.

When you see a problem at your company, speak up. When you have a problem with your manager, try to help them. Things go much better if you take an active approach to your work problems than a passive one.

> Whatever process you find yourself in, you have to be able to push back and say: "I'm working on X, if you want me to work on Y, what do you want first? What's the priority?"

I asked an ex-manager that once when I had 2 important issues to deal with. His response : "They're both important dude, get going on them."

I don't know how to respond to that. Assholes will be assholes I suppose.

The way to respond to that is to say that time and resources are limited, he can choose which one he would like to prioritize. If he doesn't say you will pick one to work on and begin on the other afterward. If he doesn't like the one you worked on first, he should have chosen differently. You can physically only work on one thing at a time. They choose or you choose. You have the power.

> If he doesn't like the one you worked on first, he should have chosen differently.

And that, gives him power to fuck me over in my reviews if he doesn't like me. Logic didn't work on these assholes. I was told point blank in a conversation, "In this company, perception is reality.". So if someone "thinks" you were wrong, you were. Facts were not something people cared about.

If you are aware of the Gervais principle, this is a classic "heads I win, tails you lose" scenario. He covered his ass, and if things went wrong, fingers would be pointed at me.

"managing your manager" is great in theory, but a lack of managing up doesn't absolve management of their primary responsibility to do that job themselves. Their direct reports already have primary responsibilities to do the work, expecting them to also do yours is a little bit much.

Managers who want their reports to develop the skills to "manage up" have a responsibility to help them develop those skills and should not simply expect them.

Managing up is not a thing that managers expect. Managing up is something you learn in order to protect yourself from managers that can't manage. It's the skill of learning to enforce boundaries and stand up to bullies: a basic life skill for dealing with a hostile world. Your manager by definition is not in a position to teach you those skills when they are the one in need of being controlled.

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


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

A very similar scenario is described in the fictional work, "The Phoenix Project", is it not? There is a smart character who handles every escalation, but nothing is documented, he was the bottleneck, and his stress level was high.

Management had to figure out they needed to handle the escalations, prioritize, reduce the bottleneck, document the solutions, and teach others to fish.

This article seems to be addressing the same issue, albeit a bit more confrontationally. Anyone have recommendations for a non-fictional book on how managers can identify these problems and implement people-centric solutions?

The One-Minute Manager is a general book on how to appropriately manage people.

How to Win Friends and Influence People is a fantastic book on people in general.

Influence is a great book for managing up, or understanding why your people react the way that they do.

The basics for any manager are the following:

1. Know what you're solving for, know what your people are solving for. Make sure that they are in alignment.

2. Invest in your people. Time, money, etc. Not just technical skills, but soft skills. A smile and remembering someone's name go a long way.

3. Keep everything that isn't their job, out of their job. If someone is a bottleneck then there needs to be a defined point in time every week where they do documentation and/or training until they are no longer the bottleneck. Assume it will take other people longer to do the same task at first and accept it, make sure that they understand this is normal.

Edit: I'd also include this blog post in your reading: http://firstround.com/review/this-90-day-plan-turns-engineer...

Yup, very similar scenario in The Phoenix Project.

And thank you for the reminder of that. It occurred to me reading the original article and this reply to it that I may be somewhat putting myself in a Rick situation right now.

I don't have any good book recommendations, but I'd be delighted if anyone else did :)

It's simple to avoid:

1) don't work more than 45 hours a week, ever.

2) if you are forced to work any saturday or sunday, you take one day off in the following week.

3) don't work when you are outside of work. no remote access, no email, no slack, no app on your phone, don't accept calls from work.

I can sympathise. I've basically been brought in to take over from someone who was the technical bottleneck for the company I now work for so that he can get on with being CTO. For a while I was necessarily working alone, but now I've hired a team and am in the process of eliminating myself as the bottleneck: by the time I go on holiday at the end of this week I want to be off the critical path and never find myself on it again.

Are you me? :)

That's probably the solution: find at least one other person for this team. The CTO was amazingly taking care of all of the infrastructure himself, I came in to lighten his load, and I feel like we could use another person or two to bring it down to a manageable level.

When I was reading "The Phoenix Project" I thought that the outcome there was going to be the same as in the original article this post is responding to. The "hotshot" developer would be fired and everyone would live happily ever after without addressing the reason things got so bad.

I was pleasantly surprised when they acknowledged this is largely a management issue and worked to fix the underlying causes instead of using the developer as a scapegoat.

Can I ask what you're hoping to get out of a book?

You already seem aware of and thoughtful about the issue. (To the point you could identify a similar one in fiction.)

I'm always loathe to recommend books about techniques -- almost invariably, they're used in a process-as-proxy way. (If I had one piece of advice of managers, it would be that -- don't manage by proxy!)

I really liked both articles because they're starting to get at a fundamental issue that is at the core of a lot of the management vs engineering conflicts that tend to arise.

Personally I've been in Rick's shoes where I've been overburdened with tasks simply because product management (not necessarily direct managers) committed to accelerated timelines without consulting with the engineers. Although I brought up distributing my load to my peers, it was always deemed that there "wasn't enough time" to train them and the cycle repeated. I was always sympathetic to my direct managers because they were given an unreasonable task and had no mechanism of providing "upward" feedback or adjusting the schedule. At the end of the day I was just putting more pressure on myself. After a few years I had enough and left the company in the interest of my own well being.

At a conceptual level I think the issue is centered around making software a business. On one hand designing and implemented quality software is an iterative process and scales exponentially in terms of decision making (e.g. one week of technical debt can lead to months of problems). On the other hand businesses are deadline driven and function on a linear scale of time.

We re-released the product to this group. It consisted of 10% of Rick’s original code which was pretty stable. It also had a few thousand lines of new code to replace about 150,000 lines of incomprehensible mess. The team had replaced five years of work in about six months. Over the next few months we expanded from pilot to full customer release.

Up next: Manager on Medium bragging that he or she would be able to type out all ~1 000 000 words in the Harry Potter series in a couple hundred hours.

Actually, I'm pretty sure what happened next was a dozen influential customers enquiring where those multiple weird little edge-case features that they relied on had gone in in the new, seemingly "dumbed down" release - the features that they had explicitly requested two years ago, which Sales had promised to get the sale, and which Rick had implemented in a bit of a hurry, noting that it would need to be refactored later.

A team of 3 people for 6 months is a total of 3000 hours*men. They can do a lot.

I'm curious how they managed to refactor about 150,000 lines of code down to a few thousand lines.

Could be they slashed a bunch of features, but I wouldn't be surprised if they replaced a bunch of homebrewed frameworks with third party equivalents. "Line count" is such a vague measure, it's easy to get counter-intuitive results.

I used to routinely achieve 10-to-1 code refactors, without losing any functionality, and have probably done a few 20-to-1's. 50-to-1 is not really unbelievable. It's amazing the kind of pointless verbosity and over-complication some programmers are capable of.

Besides refactoring, there's also garbage cleanup. We've all seen instances of huge, 1000 line functions that do nothing because the result of their calculation was thrown away, or because it's never called in the first place.

What I find symptomatic is that everyone takes Rick being the superior genius as granted - while there is little evidence of his real superiority. In most likelihood, he was slightly more experienced then the rest of the team and knew slightly more at the beginning. The evidence of them being actually capable is there in the subsequent work. Which was better then Ricks, but note how they don't get to be praised for skill at all. Only Rick is.

The pattern I have seen multiple times in IT companies is that if you act the way Rick is described to act, you will create aura of geniality around you. If you are the slightly more experienced and a lot more confident, you rejecting other peoples ideas or criticizing their work will be unconditionally accepted as truth. And once aura is there, it is also pretty easy to frame every difference of opinion as objective truth that they are wrong.That gives others little chance in politics.

Describing experience: it does not matter that those slightly less experienced needed maybe two-three months to get up to speed, it does not matter that what they proposed was actually equally valid solution to the problem at hand. It does not matter that Rick saving day from someone else bad solution was may Rick rewriting equally valid code to another equally valid code.

What happens is that Rick acted arrogant and therefore everyone in leadership and in comments assumes he was the biggest rock star there was in the company. Other people cooperated well, therefore they are clearly less skilled than Rick was.

As for working 12 hours a day 7 days a week - it is irrational and invariably leads to inferior results. However a person who has discipline to go home, sleep, exercise, take rest, say no will not be praised as a role model, despite making better more rational decisions. Nope, the one who does irrational decisions is fallen genius hero.

There are various alternative ways to interpret the story. Like, "Yay, we finally outran one developer by using an entire team, and gutting the requirements." That's like moving the finish line closer without telling the forerunner.

Hey, only 5% of the users need this; let's remove it? What's 5%.

You know, that could be sometimes justified, but not always. Could we throw something out of Firefox or MS Word that only 5% of the users use?

It's not clear whether Rick himself invented all those additional requirements himself, or whether they were external.

Could it be that the man toiled earnestly to implement requirements coming at him from various people such as product managers and such? And then they crucified him for the software being too complicated due to doing things which the current political party suddenly finds unnecessary.

You don't get what you deserve. You get what you get.

There is a misconception that if you do the extra work you will get compensated some way either through promotion or bonus. It's simply not true. You are paid for the position you were hired for.

Rick should have left the moment he took on more work without matching compensation. Why wouldn't the business pile more work on Rick? It's free. As soon as it costs money, all of the issues brought up in the article would be addressed. Suddenly management cares.

There is a misconception that if you do the extra work you will get compensated some way either through promotion or bonus. It's simply not true. You are paid for the position you were hired for.

I agree on the surface. But I would add that extra work may not get you a promotion or more compensation at the company you are at now but the right kind of extra work where you are learning new skills or can say that you did a project that was important does help your resume and can make you more money somewhere else.

Plus, the people you work with and for might start their own company and offer you work, take you on as a well-paid freelancer, etc. Business is not all business.

Documentation, while important is also a bit overrated in it's capabilities. Don't get me wrong - It would be lovely if you could simply read a bit of documentation to understand what's going on in the code. Reality is different. The details of understanding code, is in the code itself and how it connects to all the other bits of code.

The original author of the code has an understanding that far exceeds the explanatory powers of any documentation or anyone else that can come along and try to understand what's going on. By all means, attempt to document as much as you can, but don't expect it to be a silver bullet for understanding code.

I wish more people understood this.

There is no excuse to not have any documentation. One must always make an attempt to write a reasonable amount of documentation so there isn't a situation where there is no hope to understand anything except read all the source code.

But a lot of people (managerial types especially) expect docs will be "step 1 look here, step 2 look there, step 3 fix with this exact command"

Docs should explain how a system works, and perhaps some important places to look, but it's not a checklist to fix all problems. The consumer must still possess the ability, and will, to investigate and fix problems using their own critical thinking.

At a minimum, shops should have some short documents that explain where the code is in source control, what is needed to build it, where it got deployed, and some general idea about how to do a full system test. Call it the "Hit by a bus" doc if you want. Or more nicely -- the new hire orientation doc. And it's management's job to ensure it gets kept up to date. Because it's a business continuity issue.

The whole situation reminded me of this sketch:


Given the kind of unreasonable demands, people do crack.

He's missing a few dimensions.

"Dimensions" are not the part of requirements.

>Given the kind of unreasonable demands, people do crack.

Haha. As in mentally or the drug? :D


Awesome video, thanks for sharing.

Right, because computer programming (unlike computer science!) does not take a genius. It is, basically, a routine work. Unfortunately, there is a tendency to say the same about fundamental science, for example here: http://www.slate.com/articles/health_and_science/science/201... and here : https://www.theguardian.com/commentisfree/2017/sep/30/we-hai... This worries me. Without outstanding contributions from individuals, science will turn into waste of human resources. We absolutely need to protect and care about our elites !

1:1 conversations outside of normal work context can help. Dropping the work context is critical to having a human:human conversation. Most people don't have the heart to do it (for real).

If your approach always begins/ends with 'from my side' or even worse 'from our side' (team/mgmt context), you will always fail to connect with and influence someone like Rick. This sort of language will just reinforce the division between Rick and everything else.

It takes one to know one. If you know that someone like Rick is just 'so different', or if you just have that 'gut feeling', you need to find someone who can connect with Rick. An age gap (20+ yrs) helps too; reach out to the respected elders in the company.

If you can show that you care about this person, and want them to be successful and healthy, then they might start to listen to you. All you really need is their attention.

Apparently they didn't fire their top talent. They fired the worst talent since the team brought it together after the tyrant was vacated and the quality of the work was questionable at best when reviewed.

> Instead, they played Rick like a fiddle, burned out all of his talent and skill, and once Rick was considered damaged goods, kicked his ass to the curb for the good of the company’s productivity. How brave! How heroic!

There is always two parties involved, the player and the fiddle. The assumption that the developer was sucked empty and thrown away is the OPs alone, the article referred to does not provide details of attempts at intervention.

I was a Rick once, though not by choice. The company underpaid, management received bonuses based on cutting staff, and the company wasn't a tech company. They refused to give raises or title only promotions. I tried to set up knowledge transfers, tried to spread workloads, instituted training, but it was never enough and all the work ended back with me. I eventually left and now make significantly more for less work. I've never let myself become a Rick again.

Maybe the pathology is that there is no management or that it is anemic. Everyone loves the idea of self-organizing teams until something like this happens. How would Agile or Holocracy solve this?

Thank you for writing this. The culture of one software developer deriding on other software developer work by badmouthing his/her work and bragging about how firing the developer solved the problem might have a place in politics but should not be celebrated/encouraged in the technical world.

As someone new in this industry, I'm noticing that whoever appears more normal in meetings instantly wins any conflict, regardless of who has the most valid arguments. I find myself preemptively doing as little work as possible on days I think I'll have some sort of discussion in a meeting, since being frazzled from writing code ensures that the other party can force their demands on you without issue. It seems like people are also throwing out little jabs constantly. If you are in a relaxed state of mind, you win and they look weak. If you are worked up and respond, they win. Basically I writing code seems like a horrific waste of time on most days.

Is this normal?

IMO, the most amazing quote from the original story:

  It also had a few thousand lines of new code
  to replace about 150,000 lines of incomprehensible
No one looked at the quality of work after maybe 10,000 lines of code?

These claims make me assume the original author exaggerated everything to the point that the whole story is essentially a lie. This guy was incredibly capable but copy-pasted everywhere and wrote shitty code? This doesn’t even make sense. It makes even less sense that somehow no one noticed his copy-paste coding for over two years until he was finally fired for other reasons. But then those same incompetents who didn’t notice the copy-pasting or generally overengineered spagetti code suddenly came together to rebuild the whole product in a quarter of the time with less than a tenth of the code.

Yeah right.

You haven't yet seen many SWEs decide on whether to do a rewrite yet have you ?

Great write-up. If your software team has a single point of failure, a linchpin developer that holds everything together, then your team is defective. Regardless of the attributes of this developer, management has failed in letting it come so far.

I have quit jobs for far less severe cases of this. Feeling like you can’t take time off and that the project will fail if you do not save it, is not healthy. If you find yourself in that situation, you need to seriously consider why your team is broken, and if its not your fault, quit. Find a job where you have colleagues that you can rely on to shoulder their part of the work.

Could you please not spam "funny pictures" in a post like this. It makes it annoying to read.

He was mocking the original: “Look at my story! I’m going to use pop culture character names and memes and shit to identify with my audience! Whee!”

Once would have been enough. Twice to make a point. But then the point's made.


Tastes vary.

I remember seeing maybe four, and thought they were enjoyable. Taste's a funny thing.

Oh, stop.

Rick needed leadership coaching and he never got it. So, he never learned to be a good leader. The problem wasn't documentation. The problem was, management never taught him about the value of delegation, ROI, opportunity cost and the ability to strategically eliminate certain features for a better outcome. Maybe he didn't want to learn these things, in which case, he should have been demoted to regular developer or if he's having a bad attitude about that, then fired.

Management can't teach what they don't know ;)

Personally, I'm patiently waiting for the third installment: "Our incredible story"

I'd really need more information about what Rick was building to make up my mind on this one. Based on what I could google about the author, he has always worked for a large research university IT department.

In this light, I've seen these back-room clerical apps, that need everyone's special requirements included, turn into boondogles of team bloat and mis-communication. If Rick thought he could ship it himself, and had a track record to make the estimate, I can't begrudge mgmt for hoping he could do it, even betting on him. As others have noted, it took a full team a year with scaled back feature set. A losing bet, that could have been played safer for sure, but maybe only wrong in project hind-sight.

From Rick's perspective, I'd speculate he was somewhat motivated by a threat of impending irrelevance, and somewhat justified in estimating the true penalty in his productivity from collaboration. Again, from snooping on the author, I think there was some Oracle, lots of Microsoft in tech stack. Knowing this type of 10x guy, his implementation style is usually somewhat deprecated from a decade of head down productivity. Also, one of the biggest problems outside "real tech stacks" is the lack of collaboration workflows and conventions. So it may indeed have been true that tripling man hours on the project could have resulted in negative productivity given the project's code base 6 months in. I still think Rick earned the right to gamble, fail, and go down with his ship. It was foolish because he would have likely only grown in esteem and compensation with some artful delegation. And doubly foolish, if his stack skills weren't highly marketable; limited upside with huge downside for him. But I find it commendable nonetheless he chose to Build when "Lead" would have been more rewarding; and ultimately if he makes the deadline, no crisis ever comes to head.

Finally, the "Rest of the Team" did what I think was the tough but right decision to move forward. No way can you "reset" the project while sustaining weekly second-guessing coming from an obsessive, knowledgeable, ego-bruised, senior team member. Ultimately, even self proclaimed logical dev's are irrational actors and as susceptible to group dynamics as anyone. We're all limited people: mgmt can't predict the future, proven-shippers sometimes come up short. I don't know if we need to read this as a call to blame.

If you are a CTO or manager, please do your developers a favor by not throwing buzzwords at them in 99% of your conversations that you don't even understand. As a consequence of your vague requirements, if a developer chose to implement something that you don't quite agree with, grow a pair and suggest an alternative.

The HN discussion thread for the article to which this is a response is here: https://news.ycombinator.com/item?id=15474893

the real MVP

I disagree with some of below comments and it is totally Managment fault.

I might be somewhat a little rick. But in my case it is the managment responsibility to set the expectation.

If a task takes 5 days to complete but your manager says I need build at the end of day. You can not deny it and you have no other option but to patch.

Let's assume another scenario. If your manager says he needs build at the end of day and you are spending 5 days to just write the beautiful thoughtful code than what will happen. You loose your creadibility and no one will trust you and say you are rockstar.

Then you will be fired like dumb.

It sounds like only Rick worked that much. While there is management to take part of the blame, I have seen multiple times developers working that much because they wanted to. Sometimes they thought it "must be that way", other times they wanted to pretend they are heroes to save the day and did things that could easily wait. Yet other times, they had no life out of work or messy life and this allowed them to pretend it is not the case.

Medium is trying to be Cracked with this article style.

Medium doesn't have editorial control over what its users post on the site.

"Rick" is generally actively supported by a non-technical manager who wants to keep the project from going to a more agile team ("it will take you 1000 man years to replace this and if you try we will make your attempts fail until we do it ourselves") and it locks in nice inflating budget.

Based on founders'/executives blog posts, can we have a list of toxic managers/companies that people can reference whenever they are considering a job offer? This would be based on public postings about how they treated their employees.

Generally, any company that has high turnover or is replacing senior level jobs on a regular basis should be reviewed with suspicion. High turnover is an indicator of the work not being commensurate with the pay or a toxic environment. Lots of senior-level openings in a company that isn't brand new signifies a company with leadership problems or funding problems.

Seeing that the author of this is a security engineer, I now understand why I relate so much to this. I know this to be true - the infosec field does have it's overworked so-called rockstars.

They did not fire Rick, they freed him. Ricks should not be slaved!

The story given in the original Medium article reflects what is, in my opinion, the single most important thing you will ever learn as a software engineer:

Those that ask the most, give the least.

likely Rick never could off load his work because of management. he may have been up against a wall of resistance where no one else did anymore than they had too. this is how you get Ricks. You have a general apathy among many of the developers which sets in because they don't see anyone held accountable so why should they exert the effort?

> likely Rick never could off load his work because of management.

It's possible. But it's also possible that he considered everyone else far below his acceptable level of skill and refused to delegate or allow other people's code into "his" codebase, even going as far as to ignore a team-blocking ticket for months until someone else picks it up, then blocks on the review, then when management finally say "get on this", rewrites it himself and commits his own code without review.

What? No, I'm not bitter about recent experiences. Not at all.

There are always choices — either change your environment or change your environment.

There is also another option, you genuinely like your work. For some reason, the team does not want to get involved and the management fails to notice this. Fixing the mess means either stepping up as a manager, or leaving. In both cases, you lost the work you liked. What do you do?

What is there to like about a job with bad management and bad team dynamics?

I also learned the hard way the cost of staying at a job for too long because I got comfortable - or at least was more comfortable with the devil I knew.

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.

Music to my ears.

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