You fired your top talent. I hope you’re happy
medium.com
medium.com
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.
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’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.
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.
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.
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 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 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.
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.
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 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.
People adapt to their environment. Most character issues are a response to the work 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.
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.
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.
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.
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!
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.
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.
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.
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.
Maybe one day I'll suggest a trial for it at my company ;)
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.
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.
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.
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.
* 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.
"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?
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.
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?
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.
That doesn’t mean the dog shouldn’t be put down. It just means there are also other parties at fault.
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.
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.
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.
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.
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?
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.
Good, I’m glad we agree that you insufficiently argued that people backed into a corner aren’t responsible for their actions.
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.
See also: Steve Jobs, famously.
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.
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.
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.
Developers are human. They don't need to be put down.
“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.
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.
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".
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.
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.
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.
So it doesn’t matter whose “fault” it is, he was the one ultimately harmed by it.
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.
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"?
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.
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.
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.
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.
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.
"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."
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.
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.
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.
> "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?
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.
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.
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.
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.)
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 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.
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?
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 :)
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.
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.
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 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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
https://www.youtube.com/watch?v=BKorP55Aqvg
Given the kind of unreasonable demands, people do crack.
Haha. As in mentally or the drug? :D
P.S.
Awesome video, thanks for sharing.
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.
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.
Is this normal?
It also had a few thousand lines of new code
to replace about 150,000 lines of incomprehensible
mess.
Yeah right.
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.
Tastes vary.
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.
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.
Those that ask the most, give the least.
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.
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.
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'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.
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.
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.
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.)