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