[NOTE: This is the conclusion of a two-part story. If you haven't read part one (https://dev.to/bytebodger/Ron-the-untouchable-invincible-no-good-developer-25f4), this narrative may be a bit confusing. This story is told without embellishment. Everything is true, to the best of my recollection.]
There I was. The shiny new Development Manager for a major bank in my hometown. Leading a brand new team. And because I've apparently done horrible things to people in my prior lives, the fates had chosen to mete out some karmic justice by placing Ron on my team.
While I obviously had a very poor opinion of Ron, he had never before been my direct report. When I was in the role of contractor, he was, more or less, a minor "obstacle" to be dealt with. So as long as we could keep him out of our way, no one ever spent too much time obsessing over his incompetence.
But now that I was formally his manager, I first resolved to evaluate him on a more thorough level. Despite his failings, and the fact that I'd given him a scathing performance review, he was an affable guy and he had allies in the organization.
I assessed (correctly) that it wouldn't fly if they said, "Welcome to the staff, Adam. Here's your new team." And I immediately responded by saying, "Thank you! And as my first official act, I'm firing Ron!" So I set about diving deeper into the enigma that was Ron...
Observing Ron
When I've encountered incompetents in the past, they usually get bored trying to trudge through the code that they're incapable of writing/fixing. So they end up spending a lot of time goofing off. To his credit(?), Ron didn't do this.
He took days to finish something that other junior devs could complete in hours. But he didn't resort to surfing the web or taking 2-hour coffee breaks. He'd be there. All day. Pretty much just... staring at his computer. He'd have the app running in front of him, and you could tell that he was tinkering with very minor things. (I believe he was trying to teach himself through slow, painful experimentation.) But he nearly always had the code up in front of him. This meant that, to the casual observer, he was always working diligently - if not productively.
For reasons I won't bore you with here, we were working on a trunk-based, release-branch strategy. Most of our tasks were small in nature, so we kept committing them to a single release branch shared by the whole team. CI/CD would then push them to the QA environments for testing.
We had a simple policy for our team. At the end of every day, you checked in whatever you were working on. It didn't matter if your task wasn't completed. You just had to make sure that your latest changes were in the branch and that the code, on a very minimal level, had to "work". In other words, the code just had to compile. Then, when we started up again in the morning, we'd all get latest from the repo and continue working.
This process seemed to break poor Ron's brain. He'd usually come in right around 9AM. I don't know how many times I, or another team member, got in an hour-or-two before him, pulled the latest code, and then found that we couldn't run the app locally - because it wouldn't compile.
Eventually I resolved to give him only tickets that could be completely finished in a single day. For Ron, that meant giving him tickets that were almost silly in their simplicity.
After a few weeks in my new role, I had to do one of those all-day meeting sessions. When I came back the next morning, I was reviewing the day's commits and found that someone had done a "drive-by" on Ron - asking him directly to do, what they believed to be, a minor task. Since I wasn't there to look over his shoulder and he wanted to fulfill the request, he tried to do the work and checked in his code.
Luckily, I got eyes on his change right before the automated morning deployment to QA. If I hadn't, his change would've actually deleted a good chunk of the database in the QA environment and would've caused several hours of headaches for devops as they tried to restore everything from tape backups.
Obviously, his blunder never made it anywhere near prod. But it was so egregious that I felt I had no choice but to formally write up the incident. I also implemented a new policy: He was not to even check in his code until he'd called me over and I'd personally reviewed it, on his screen.
The Final Straw
We had a request from marketing to add some custom attribute to a single DOM element on a single page. This seemed like a perfect 3rd-grade-level task for Ron. One which would probably take him the entire day and keep him out of my anxieties.
So I was first surprised, then confused, then annoyed when I saw that he'd "filled" the ticket shortly before noon. I was surprised that he'd complete anything that fast. I was confused to see that he'd closed the ticket without committing any code. I was annoyed when I read his notes on the ticket explaining why he closed it.
Ron closed the ticket because, according to his explanation, it simply couldn't be done. You read that right. Marketing wanted a single custom attribute added to a single DOM element on a single page of HTML - and Ron's response was that it was... impossible.
When I walked over to his desk, he gladly pulled up the ASPX page to demonstrate this "impossibility" to me. Specifically, he opened the code in Visual Studio, in the visual editor, and tabbed into the element in question. As he did, Intellisense kicked in and showed him all of Visual Studio's auto-fill options for attributes that he could possibly add to this element (which was, in fact, being rendered by one of ASPX's UX controls).
"See?" he said. "The attribute they're asking for isn't an option."
I think I stared at him for about 37 minutes. For some reason, I just didn't want to believe that he could be this incompetent. But I immediately knew what the "issue" was. In his mind, the only way to create the element was to leverage the associated ASPX control, and then to configure that control in whatever way is allowed to you by Visual Studio.
I asked, "You do realize that an ASPX control, after it's processed by the server, results in nothing more than HTML being sent to the browser, right???"
"Well, yeah," he responded.
I continued, "And you do realize, that if you care to, you can send any text to the browser on your own, without leveraging an ASPX control???"
"Well, yeah," he responded. (But to be frank, I don't think he really knew this before I spelled it out in such simple terms.)
"Then find some way - any way you have to - to generate an <input> field on the screen with the custom attribute they've asked for."
"Well, OK." He was pretty meek by this point.
"And one more thing, do not close any more tickets. I'll close the tickets."
For me, that was pretty much the last straw. He rarely wrote anything that didn't have to be completely reworked by another dev. He was painstakingly slow at the simplest tasks. He'd already tried to promote blatantly dangerous code. But for my money, the greatest sin was sheer incompetence.
I didn't realize, until that day, that he was pretty much incapable of "writing" any code that wasn't autocompleted for him in Visual Studio's IDE. That's when I knew that he had to go.
Corporate Hurdles
Having only recently become an employee, I didn't know what formal boxes needed to be checked to actually terminate someone at the bank. Every company has their own special quirks about such things. So I scheduled a call with HR. I had no idea about the frustration that would follow.
I explained the whole scenario to HR Lady. Told her about his repeated incompetence on the CMS project. Showed her his abysmal performance review. Showed her the writeup I'd given him for writing and trying to promote dangerous code. Talked her through other examples of his base incompetence. Then I asked her what exactly I'd have to do to complete the termination.
The following is obviously not an exact transcript of our discussion, but it's a faithful representation of it according to my memory:
Me: So what do I need to do to officially have him fired?
HR Lady: Well... We can't really fire him. Not yet.
Me: Huh?? But... I just showed you his review. I showed you the writeup. I've explained the whole situation to you.
HR Lady: Right. But we have to give him a chance to improve.
Me: Wait. I understand that, if someone keeps coming in late, you create a formal process where you notify them and give them a set period of time to show they've improved. But this isn't a disciplinary issue or a matter of some specialized skill that he needs to practice. He's, quite literally, incapable of doing the job for which he was hired.
HR Lady: Yeahhhh, I know. But we still have to give him a formal opportunity to improve.
Me: You mean, a "formal opportunity" to learn his job from scratch??
HR Lady: Well... everyone needs the same chance.
Me: And exactly how long does this chance last?
HR Lady: 90 days.
Me: This guy can't even do his job. He drains inordinate time from me and the other senior devs because we always have to go through every line of his code. He doesn't understand the simplest of concepts. He introduces dangerous security holes. But we have to continue dealing with him for the next 3 months???
HR Lady: That's the policy.
Me: What would you do if he was on the team that supports the trading desk? One bad line of code on that team and you could cost the company a million dollars. Would we still insist that he struggle to do his job for 3 months if he were on that team??
She had no good answer. She was clearly annoyed by my line of questioning. I was clearly exasperated. I know it came through in my words and my voice. I had no reason to hide that.
I never swore or said anything unprofessional to her. But it was clear from her tone that she did not appreciate me having the nerve to openly challenge their blind corporate policy. I guess you just shouldn't question the ridiculous idea that everyone must get a 90-day Performance Improvement Plan - even if it's already been shown that they don't have even the most basic of skills needed to do their job.
Marking Time
So I gave Ron his "Performance Improvement Plan". It was difficult to even figure out how to complete the forms.
What steps must the employee complete to demonstrate improvement?
Learn to code.
Describe all instances where the employee has failed to meet expectations.
If I describe them here, in any detail, Ron won't understand them. Because he's not a coder.
(And if you're thinking that this is my fault because I'm a sarcastic jerk, no, I did not actually write those exact responses. But it was tough to find any way to describe the situation in terms that implied there was any potential "improvement" he could make.)
When I delivered the PIP to Ron, he was pretty subdued. Much like when I delivered his performance review. It's not that he was happy about it. But it didn't seem to phase him much. Ron's superpower was an uncanny and unwavering lack of situational awareness.
For the next several weeks, I frequently burned a few hours out of each day tending to Ron and his "Improvement Plan". You see, I really wanted to just ignore him for the next 90 days until I could finally release him. But given the galling lack of support from HR, I was afraid that, if I didn't demonstrate a yeoman's effort to genuinely help him, he'd tell HR that he wasn't given a fair chance, and they'd dictate another 90-day PIP.
The CIO
A few weeks into Ron's PIP, I got called upstairs to the CIO's office. The purpose of the meeting had nothing to do with Ron - there was a big project coming up and he wanted me to give him some info on realistic delivery dates.
[NOTE: The picture above is obviously not a picture of the bank's actual CIO. This is obvious because the person in the picture above is a person of color. And it'll be 100 years before that bank ever sees a person of color seated in their executive suite. You could find more diversity at the Montana State Fair.]
As we were wrapping up our meeting, the CIO decided to probe around a little bit. The conversation went like this:
CIO: How are you settling into your new job?
Me: Pretty well. I'm figuring out all of the bank's processes. And the team is meeting its deliverables.
CIO: And how have things been going with Ron?
Me: Not so well. He has none of the skills needed to do the job, and he drains a huge portion of my time every day.
CIO: Anything I could do to help?
Me: Let me fire Ron.
CIO: Well... give it some time. I'm sure it will work itself out.
Me: Uh-huh.
CIO: Are you getting along well with everyone else?
Me: Absolutely.
CIO: I've been getting some... feedback about you.
Me: Oh??
CIO: Yeah. Some reports that you're "difficult to work with"?
I can't remember exactly how I responded to that statement. I don't think I said much of anything. I was flabbergasted.
I was offered a permanent position after my contract gig because everyone was thrilled with the delivery of the CMS project. With my new team, our sole "client" was Marketing. And I was absolutely certain that all of the stakeholders in Marketing were very comfortable with me. Other than Ron, I was totally confident that all the other members of my team liked and respected me.
At the time of this conversation, I'd only been an employee for about 2 months. I'd barely had time to have any significant interactions with anyone outside my team or Marketing. So who would be giving the CIO reports that I'm "difficult to work with"?? There was only one logical answer: HR Lady.
HR was on the same floor as the executive suite. Heck, I had to walk past her desk on the way to the elevators. There was only one person in the entire organization (outside of Ron) with whom I'd ever had a conversation that was even remotely "uncomfortable". And my conversation with her was only uncomfortable for her - because she was annoyed with the idea that I had the nerve to question corporate policy.
So there I was, 2 months into my new management job, and I had a demonstrably incompetent employee that I didn't have the authority to terminate until I'd demonstrated 3 months of proper bloodletting. And because I had the audacity to question HR, the CIO had the impression that I was "difficult to work with".
It's Good To Be King
A month later, and 6 weeks into Ron's PIP, I was in the CIO's office again for another Big Project Planning meeting. He was pressing me on a couple of my projected delivery dates.
CIO: It will take a month to hit this milestone?
Me: Yes, sir.
CIO: That seems like an awfully long time?
Me: I agree. But you have to consider that there are 4 devs on my team, plus me. Ron cannot be trusted to deliver anything. And I can't yet backfill his position - because I can't yet fire him. So, functionally speaking, there's really just 3 devs on my team, plus me. When I'm not in meetings, almost all of my time is spent watching over Ron. So I can't contribute anything to the dev effort myself, leaving those 3 devs to do all the work. When I am in meetings, one of the other devs has to babysit Ron. Meaning that there are only 2 devs left to do real work.
The CIO sat quiet for a few moments.
CIO: Ron hasn't gotten any better??
Me: I work with him every single day. And no, he hasn't gotten any better.
He picked up the phone, got HR Lady on the line, and asked her to join us in the conference room. When she walked in, she saw me there and gave me one of those, "Ohh... it's you" smiles.
CIO: We're still having problems with Ron.
HR Lady: I understand. We have him on a Performance Improvement Plan.
The CIO got quiet again for a few more moments.
CIO: This all seems a bit Dickensian, doesn't it?
HR Lady: Well... I don't-
CIO: I mean, it's like we're punishing the kid just because he's in a job that he can't do.
HR Lady: But we have to give him a chance to-
CIO: Isn't there some way that we can just end this??
HR Lady was not pleased. But she was talking to a C-level executive. I could almost feel her innards twisting in knots as she forced the following words out of her mouth.
HR Lady: Of course. We can take care of it right away.
Poof!
And that was it. After months of dealing with Ron's incompetence. After being painted as "difficult" because I didn't want to babysit him for 3 months. It was all over.
Within 24 hours, Ron was terminated. It was like he just... disappeared. And all it took was a decree from His Majesty, the CIO.
Top comments (33)
I learned to code in university, I barely passed the first programming course because 80% of the grade was based on documenting the code. It wasn't until the second course that the concepts really 'clicked' for me. However, some people just keep failing these courses year after year. I admire the perseverance and I really believe in a 'growth mindset' instead of a 'fixed set of skills', but at some point you just have to be realistic with yourself that being a developer might not be the best fit for you. Raj is a perfect example of this.
I understand the pain of having such a person on your team, draining time and resources from your project. The worst thing is that you have to work around this person (like you said, 3 + 1 = 2) and only assign grunt work to them because you know you can't rely on them for finishing their tasks in time. I think you did the right thing, give them honest feedback and a chance to improve, nothing else you really can do in your position.
I'm glad it worked out. Probably for Ron too.
In my comment on your last post, I didn't get a full picture of Ron's lack of abilities. But now reading part 2, I can say that, yeah, Ron just didn't have the necessary skillset.
I think in these cases, it is often the best for both parties to part ways, which I think is ok. Social media, especially Twitter influencers trying to get follows sometimes touts the line of "if you get fired for lack of experience, something is wrong in the company, they should learn to teach you".
But if the expected skills are lacking by such a large margin, trying to force feed a developer just puts unmaintainable stress on both sides and just doesn't work.
Bingo! Saying that you're firing / releasing / terminating someone typically has a very negative connotation - for obvious reasons. And it's almost always a "negative" thing, in the short term, for all parties involved. But if everyone's being thoughtful and considerate about the situation, a termination can be a very positive thing - at least, in the long run.
Several years before this, I had an employee literally thank me as I was letting him go. I had tried to work with him. And I also made it exceedingly clear that, if he couldn't hit certain benchmarks, he'd be gone (cuz I wanted him to do everything possible to prepare for such a moment without it hitting him "out of the blue").
I've also had the experience of seeing someone that I had to terminate years earlier, and them telling me how great it was that I terminated them. Of course, they weren't saying that on the day that I let them go. But once they were out of the situation, it quickly became clear to them that they had been in the wrong company / environment / team / etc.
Teaching folks often makes good sense - when that teaching involves some additional skill - a skill that buttresses their existing expertise. But teaching makes no sense if you need to teach them everything - from scratch.
I always remember the CIO specifically using the word Dickensian. I really thought that "nailed it". It's like you're punishing someone just because they're a poor fit in their current role.
The part that followed this was underwhelming. Blame my fictional-literature-acclimatized brain, but I expected a more intriguing plot twist there, like Ron being her husband, or holding an indispensable position like being the Boss the CIO answers to
Sometimes a factual narrative doesn't carry the same punch as fiction.
OMG, reminds me of a gig I had a large telco. I was one of three contract technical writers and we needed another person to help. So they handed us Jim. Apparently Jim had worn out his welcome in a number of other business units, so we were the patsies.
I quickly learned Jim had no idea how the product worked, or how to explain anything about anything. So as the de facto lead I gave him simple tasks. Something I could have done in about an hour. A week later he was still not done, so I looked at what he had done so far. He had decided to work on something entirely tangential to the assignment.
So I went to Bill (the pill was our nickname as he could only trot out management-speak) and asked him to pull Jim from out team. I got the runaround and we had to put up with Jim for months before my constant negative feedback to Bill sunk in.
So they moved Jim to customer support. OMG. No wonder customers hated our help line.
Who develop here ? you or your IDE ?
You know I love you Adam, but please don't use real names in any of these stories going forward (unless the story is about how awesome someone is). Just use neutral, made up name that don't suggest ethnicity or an actual person that can be easily tracked down using linked-in.
I've also grappled with similar situations and I guess what's missing for me here is how you've grown and changed as a result of this whole ordeal or what you could have done better.
For example, I saw people successfully transition from devs to product/project managers or technical sales in similar scenarios (not to say that programming is superior to these professions, just that it requires a different skillset and might be better suited).
Cheers
I hear you. But I specifically decided that the Tales From The Dev Side series would be just that - tales. Not lessons. Or best practices. Just... tales. And I totally get that won't appeal to everyone.
All my other "normal" articles are basically extensions of my real-life experiences, with additional information about how I've changed, or what I've learned. As for this particular story, there are, quite literally, about a half dozen different takeaways (for me), and I didn't wanna make it even longer by adding a whole bunch of preachy "what have we learned today?" findings.
I just wanted to tell the story. I'll do others like that in the future. Just telling that story - and letting the readers draw what they will from it.
I didn't mean in a preachy way but in a "in good storytelling the main character (you) usually grows and changes" way.
It is your story though and you can tell it however you like. I fully respect that.
I was enjoying your stories until you had to insult the entire state of Montana. lol
😂😂😂
Adam Nathaniel Davis
I am asking these questions because I was once in Ron's shoe - well, I had to switch language and framework (from python Django to js node/express). I was not really interested in web development but it was paying the bill so I had to do it.
There were many ways for Ron to improve. There were many of way for me to help him improve. To be completely fair to Ron, he was trying to improve. And although I basically knew where this was going, I was trying to help him improve.
I'm not trying to dodge your question, but asking how Ron could improve is kinda missing the point. I've had numerous employees over the years who were not quite "up to snuff" in critical aspects of their tech skills. And, in some cases, we were even able to work out a happy ending that kept them in their job and allowed them to grow professionally.
The real issue with Ron was just that he was in wayyyyyy over his head in that particular job. If I had a large team with room for some very junior folks, I could've kept him on and allowed him to grow into the role. But I had a small team - there was only budget for 4 devs + me. So we really didn't have any room for a (very) junior dev - especially one who was supposed to be much better. His presence was literally handicapping everyone else.
This is also why I found the requirement for a Performance Improvement Plan to be so galling. If you're a solid dev who just doesn't have much experience with Angular, that should be no big deal. We can bring you up-to-speed (most likely, without any formal PIP). But if you simply can't code, there's really not much to be done. I can't sit down and take you from Intro to Coding up to the level that's needed to function on that team. It'd take years.
Hmm I have to say I'm totally missing the point of this two-part article and why it was written. It's been tagged as motivation but there's absolutely nothing motivating here and it seems that you just feel personally wronged by what happened and it has led to some grudge(?) on your part. I believe this, even more, considering you kept his name in the article which means I could in theory personally identify him and know who this incompetent developer was (which is unprofessional and unnecessary to me).
I understand this is your blog so you can post what you please and clearly, a lot of energy and time of yours was wasted but it seems like you should have directed your frustrations at the people you worked with who didn't listen to you and deemed you difficult (which also seems to have upset you). You come across as someone who feels personally wronged and character assassinated as a result of this experience and it hasn't left you all these years. There's even a comment from you on the first part of this article talking about how there's a rumour he is launching a start-up on a "laughably-bad premise". Plus the image of "idiot of the year" in that first article and yikes you just come across as rude... regardless of how you were the victim in this situation.
I'm writing this just to let you know how this comes across and how it reflects on your character. I think you should let the emotions you're carrying around this go.
Thanks for the awesome feedback!!!
Good read. What's fascinating to me was , it had only "Raj's" name explicitly mentioned. If not fictional, I am curious why just "HR Lady" and "CIO"? "Raj" could have been just "Developer". Those 2 characters also seemed crucial.
I changed Raj's name just now because some people seem to be freaking out about it - even though Raj is like Joe to Indians.
I have no idea what HR Lady's real name was. I forgot it about a month after I left the company.
The CIO's name was Jim. But I wouldn't put "Jim" in the article. Every time I mentioned him, it was more important for the reader to remember that he was the CIO - and not that his name is "Jim".
Well you're not gonna hear me complaining if you change it back haha
Some comments have been hidden by the post's author - find out more