Hypotheticals

Today's topic; efficiency. Let me present to you a list of hypothetical employees. Employee #1 is disgruntled, unhappy to be there, and only does the bare minimum. Employee #2 is the polar opposite. They're enthused to be there, and often work overtime. They rarely take time off and as an engineer spearhead code rewrites without prompting. Employee #3 is a balance between the first and the second. They show up to work on time, excited to do their job, but they never stay late or do any extra work.

Employee #4 is probably a bit older. They're generally well liked by their coworkers but as far as you can tell they aren't producing a bunch of code. What code they do produce however, is immaculate. Employee #5 appears to be a model employee. They are always at work on time, they are often even at the office late. But, for whatever reason their code output is marginal at best, and while it's not full of bugs and errors its not immaculate either. If the company offers a hybrid opportunities you'll always find them in the office.

Let's talk about these employees. I suspect, many reading this, will prioritize employees #2 and #5. I suspect, many reading this, would seek to eliminate employees #3 and #4. But in my mind these trends should be reversed. So, let's get into it!

Employee #1: The Disgruntled Former Star

I think most people can identify that employee #1 isn't a good employee. But what if I told you that previously they behaved much like employee #2? If the person previously was hard working but suddenly has become difficult to work with it's possible that they feel betrayed by the company. It's very likely that they're even spending some of the work day trying to find a job somewhere else. While it's still probably in everyone's best interest to let them go, this person demonstrates that there's a failing somewhere in the organization. Trying to figure out what changed with this individual may give a company the chance to find something that's gone wrong and fix it before there's more damage.

If employee #1 is leaving because of mismanagement and they were previously a stellar employee then rest assured that problem is likely to repeat itself. If employee #1 felt like they got passed over for a promotion or that there's no path for them to advance then their only option is to find another company. This too is an issue that's likely to reoccur. Rather than writing that employee off as "a bad employee" try and figure out what circumstances were that lead them to be this way.

VERY few people get hired if they're unfriendly, hard to work with and have no work ethic unless a company's hiring process is really bad at screening candidates. It's way more likely that there's something wrong with the organization or it's processes for a good employee to become a bad one.

Employee #2: The Burnout

Most companies would be thrilled to have employee #2, after all they consistently go above and beyond, producing tons of lines of code. But what if I told you that employee #2, (especially if they aren't a senior+ engineer), is actually a liability? While producing tons of lines of code seems like a win at first blush that's only actually true if those lines of code don't contain any bugs. (I talk more about this in bad heuristics companies use anyways). Otherwise what they're producing is more work for every other person in the company as they find the bugs in question, patch them, test them, and then roll a new deploy to make up for the burnout's mistakes.

Going rogue is also an anti-pattern. If there's important work that needs to be done then it should be verbalized, planned, contain a clear set of acceptance criteria and have metrics associated with it to validate if the project was a success or not. This allows for a sustainable pace, the establishing of the correct priorities, and steps to plan/architect the right solution with input from the people whose code is being rewritten. If your company is reliant on the heroic effort of lone individuals to erase tech debt then it's not going to be sustainable. Rather than chip away it tech debt with good process you're relying on people effectively working outside of normal working hours to be able to keep producing code.

To be very clear, that is NOT cause for celebration. What happens in most of those cases is that your programmers working extra hours find themselves burning out and all of their work suffers, further contributing to a surge in bugs. They're effectively a problem just waiting to happen the moment they get stressed.

I should also point out that taking time to clear your head between projects is important. It's why we have the adage "sleep on it". When we are able to disconnect from a problem and focus on other things it gives our subconscious time to work on those problems. In programming one of the best things you can do when you're stuck is step away from a problem and think about something else. When you come back to the problem you do so with fresh eyes and will often catch things you missed before.

But that only happens if you actually take time away from work. If you work during work hours, then also work off work hours, and you don't have a life outside of work or don't ever take PTO then you never get that moment of separation that allows you to reflect on whatever you were working on. So while it may seem like employee #2 is an ideal candidate, in more cases then not they'll be a liability. Maintaining good work/life balance is key to being able to produce quality code at a sustainable pace. Having a employees who constantly go rogue on their off work hours and are perpetually on the verge of burnout isn't a good thing.

Employee #3: The High Performer

In many cases employee #3 will be accused of "quiet quitting" if folks will remember that whole movement. But employee #3 actually has a lot of things going for them, so hear me out. For one, a person who is able to disconnect from work and then come back each day refreshed is more likely to be able to solve thorny problems that the burnout is likely to get stuck on. Perpetually being able to have fresh perspective on problems is going to help with solving them.

Second, a person who is fresh, as a result of being fulfilled by their life outside of work, is less likely to make mistakes than either employees #1 or #2. They aren't distracted by negative emotions, nor are they exhausted from putting in a ton of extra hours. There's also something to be said for having the interpersonal skills to be able to enforce their work/life boundaries. That individual is likely better able to manage their time then someone who hasn't developed the ability to have a work/life balance.

In many cases this person will embody the adage "work smarter not harder". Despite not putting in as many hours they may actually be the most productive member of the team. Part of this is due to the fact that after about ~6 hours of mental focus our ability to do that kind of deep focus falls off a cliff, and that lack of efficiency compounds the longer we push past the limits of our focus. So even though the burnout might work an extra few hours there's a good chance they're getting less work than the high performer whose working a fraction of the time but at a much higher efficiency. What's also likely true is that, because they want to enjoy their time at home, when they're on the clock they're focused on getting their work done rather than goofing off or just burning time till the end of the day.

Employee #4: The Mentor

Employee #4 I like to think of as the mentor. The reason why their own number of lines of code produced isn't higher is because they're spending a ton of time doing things that help the engineering side of a company's organization flourish. Maybe this is code review, or mentorship, or establishing technical documentation for how systems work. Maybe this looks like writing out the specs for projects, or spending time in meetings with other stakeholders for a project to understand the requirements.

Whatever it is, this more senior person is doing good for the organization on the whole, but just not in a way that immediately maps to number of lines of code produced. In a lot of organizations seeing a person who is well compensated but not producing as many lines of code as the other engineers would have the organization look to get rid of that individual to reduce costs. But I think the kind of engineer that mentors others and contributes to the health of the engineering department should be cherished instead.

Employee #5: The Slacker

Employee #5 I like to think of the embodiment of all the bad heuristics that companies use to measure efficiency. If there's an office then they show up to it so they can be a butt in a seat. But over the course of the day they're going to wander from their desk to get snacks, drinks or to just chat up their neighbor which is actually making other people less productive. So despite being around they're not actually working. This is true even if they're around after some of the other programmers/employees have left. Sure they may be at their computer but it's just as likely they're on social media as they are actually getting code done.

They'll often complete their own tasks but manage to avoid helping out the rest of the team by doing things like code review. If they're on the receiving end of a code review, they don't actually care about the feedback that would make them a better programmer. Instead they only care about getting their task marked off, so they'll argue with their code reviewer about the changes and then only make what changes are required to get it past code review.

While their code isn't particularly buggy, they also don't do the due diligence to check their work, instead relying on QA to find any errors they've introduced. In many cases they'll also argue with QA when they find something wrong with their code. At the end of the day this person is lazy, in all the wrong ways, because they don't actually care about their job.

Employee #5 is the emblematic slacker. They do the bare minimum to be perceived as valuable without actually caring about their work. If an organization is only tracking things like, the hours that individual is around, or the number of tasks they've completed, then they appear to be a model employee. But anyone who has had to spend time working with them, or cleaning up after them knows better.

Closing out

So how about it? Are you surprised by this analysis of hypothetical employees? Did you guess that the burnout employee or the slacker would be valuable? Did you guess that the high performer or the mentor were deadweight? Take a moment to feel your way through this reframing of your employees or coworkers. Does it change the way you think about them? Are there coworker archetypes that I missed? Let me know!