How to discipline a software developer

24 Aug 2021

Midjourney: How to discipline a software developer in the style of Jack kirby --ar 16:9

Let’s say you are a manager of a software development team and an employee has done something so heinous that you need to discipline them in whatever way your company officially reprimands people. I’ve seen this go badly so I have some advice:


Really. You are not the parent of your team. You are not their school teacher. Unless you are intending to fire someone or have them leave, do not formally discipline an adult knowledge worker. When was the last time you were publicly reprimanded? By your mom? Teacher? Did you feel that response was fair? Was your relationship with that authority open and honest after that?

I think you can see where I’m going with this. People HATE being made to feel like a child. That was the last time they had no power to respond to an attack and punishment WILL be seen as an attack. Even if the manager feels like this consequence is completely justified, there is a near 100% chance the developer will feel that a judgment is unfair.

What to do instead? Reversing the thinking from “They did a bad thing and therefore some punishment must follow” to “Why would a grown person behave or perform like that?” For instance: A developer gets mad enough to swear at you? What can be done to repair this relationship?

I know. You’re thinking of a situation where the developer is a trash fire and gets along with no one. This is not the situation I’m talking about. In the case of a clear verbal abuser who you’ve tried to work with then this is a firing situation. What I’m trying to get at is the case where the manager doesn’t think the employee should be fired, just that they need to fix a problem. Why would a normally high performing, easy going developer issue angry swear words at their manager? They don’t yell at anyone else so why you?

The not cool part about this is that you probably fucked up. Bad behavior on the part of employees often is how a manager finds out that they have screwed up. Which sucks. They are being a jerk and you have to become all self reflective? Yes. 1000 times yes. This is the really hard and completely critical part of the job no one likes and always seems to come up just before the quarterly bullshit report is due. Some might say all the time spent on tracking and planning is the reason a manger doesn’t know why there’s problems on the team, but that’s another article.

A common cause of ‘acting out’ is, perhaps unintentional, high pressure. Do you find yourself saying “We have to get project X done by June/Friday/whatever.” You may not intend that as a threat but it will absolutely be heard as one. Imagine if you were constantly blowing deadlines your manager set for you: You’d feel pretty bad about yourself even if no punishment comes. The anticipation of punishment is often nearly as morale draining as actual punishment. If a deadline is more of “desire” than a command than saying “I’d be great if we could get project X done before the end of the iteration, is that going to be possible?” is about a million times better. A lot of managers assume that if they aren’t always applying pressure their employees will slack off. Regretfully, if you have hired smart folk who get things done then they almost assuredly have high standards for themselves. They want to get things done and all the manager needs to do is support them and get out of the way. A diligent employee will be eaten up inside by the constant implications that they are working too slow (missing implied or inferred deadlines) especially if they know these deadlines are unfair or arbitrary or both.

Push back hard on arbitrary deadlines from above. Making a team fear for their jobs, feel like they should be working when living, all for something that will sit on a shelf produces an accelerating devastation of morale. I know it seems obvious to say the previous statement but I’ve known managers who are stunningly hesitant to push back on directives from on high. There will be plenty of “Someone made an unrevealed/implied promise and now the team has to drop everything because this client is ‘influential in the industry’” type projects that stress the team; There is no need to add more.

Sometimes the team atmosphere has become toxic to thinking straight. I’ve been on teams where we made multiple huge context switches daily and it was brutal. A day might start working on a DevOps project to improve our servers, then switch to bug that involves figuring out a Java stack trace in another application, then a pivot to answer some questions/spike out some code for a project written in a functional language with a nosql db, and perhaps a quick trip into the main OO app using a relational db. I found myself not only making mistakes that I haven’t made in decades but, even worse, my pair wasn’t catching all of them. Developers who take pride in their work HATE producing bugs. But I did and I felt terrible about it.

Now one way to approach the larger problem of officially disciplining a developer would be to ‘write up’ the most senior developer on the team and make sure they promise to never do it again. That would, of course, be a bit counterproductive. The problem is the situation but the solution might not be easy. To reduce context swapping a company could shed some responsibilities from a team or hire on more people. That may not be in the budget. A manger in that situation has some hard choices to make at that point. They could push hard on upper management to spend money to fix the situation. This is stressful and may influence their odds of promotion. However, leaving the situation the way it is sets your team up to fail in production. Upper management hates that. The time may come where, if you can’t protect your team from a bad environment, you may need to move on to another company.

If a company is going to set a team up to fail and then ding their career(s), then you really don’t want to work at that company. Full stop. Unfortunately that, my fellow humans, is going to be very hard to admit to yourself. Switching companies is A LOT so it is incredibly natural for one’s mind to reject any ideas that lead down that path. Convincing yourself that whatever horrible thing will soon be over once project ‘Make It Easy’ completes is surprisingly easy.

Authoritarian relationships with other adults are extremely hard in difficult situations. Telling another adult that they have “done wrong” and this “will go on their permanent record” is a near sure fire way to erode your relationship with them.

I sent a draft of this off to a friend who’s done more management than I’ll ever do and his response was interesting. I’ve decided to include it. The following is written by Ken Scott-Hlebek:

I’m reminded of the Retrospective Prime Directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

That’s actually a pretty good way to approach every day as a manager. Or as a developer. Hell, as a person. Starting with the premise that everyone on the team genuinely did their best, that everyone genuinely wants to contribute as best they can – is life-changing. Not when it’s held as some easily-tossed-away assumption, but when it is held as a core belief, it will, in my experience, always yield the best possible results. Not always the results I thought I wanted, but usually results even better than I thought possible. People will surprise you in wonderful ways if you let them, if you trust them.

I would rather get occasionally taken advantage of, if that means that I can bring out the best in most people, most of the time.

That fear – of being made a fool, of being taken advantage of – is very real for most, and can be very hard to overcome as either a manager or developer, especially when there is a lack of psychological safety. But I’ve found that fear to be merely a self-fulfilling prophecy; you make it more likely to happen by acting from that very fear.

See, I’ve found it to be a self-fulfilling prophecy either way. Believe that people want to contribute and be part of an amazing team – trust that, and trust them – and you will be proven right. Believe that people are lazy and always trying to get away with something, and again, you will be proven right.

But sometimes someone will have something going on that keeps them from being a good teammate. On a healthy team, the manager rarely has to worry about that – but when it does come up, they can earn their entire year’s pay by handling it well. Ron Jeffries once told a story about team members who were acting against the best interest of the team (which is really the only reasonable criteria for needing to step in as a manager). Ron said he would have a series of 3 calm, private conversations with the person. In the first, he would explain to them how their behavior was impacting the team. In the second, he would explain how their behavior will impact their role and their employment. In the third, he would walk them to the door. I’ve actually lived by that as a manager. I’ve rarely needed a second conversation, let alone a third. When there is genuine trust built up, it only takes the smallest of conversations to curb concerning behavior.

A note about the image at the top of this post: It was created by Midjourney with the prompt “How to discipline a software developer in the style of Jack kirby –ar 16:9” then I used the upscale feature.