Managing difficult software engineers
Table of Contents
Hello dear reader, I will be improving this article based on the feedback that I received. I don't see myself as an expert, more like ever-learning amateur, so if you point out something, I will try to understand your point of view and correct any mistakes. Feel free to comment the article below, any and all feedback is welcome, just stay civil.
In the grand scheme of a software engineering path, there's a thread that weaves through every project, every failure, and every challenge. That thread is people. As a person with an engineering background, I do enjoy solving hard puzzles and fixing problems. But the most complex, intriguing, and ultimately rewarding aspect of my journey has always been managing people. I wasn’t a people person before — It’s not something I could do naturally — I had to read a lot, learn a lot, try different methodologies, and figure stuff out on the fly, but it’s still the most rewarding aspect of my job.
This guide is born out of those countless interactions, conversations, and experiences. Things that I’ve failed at. It's a distillation of lessons learned, a roadmap to help you, the engineering managers of today, navigate the choppy waters of managing difficult software engineers.
I'm not an expert, and am not trying to position myself as one, so if you disagree with anything here, let me know in the comments and we'll have a healthy discussion.
🏄 Some people call developers snowflakes — they’re brilliant, opinionated, and unique in many ways. It’s easy to manage those that don’t deviate too much from all the other engineers. Still, I will focus more on those difficult employees rather than the general management of all developers.
Why focus on the difficult ones, you ask? Well, it's simple. When everything is smooth sailing, when your team is balanced like a well-oiled machine, you don't need a guide. It's when you have conflicts, ego clashes, lone wolves, or when you're faced with a team member who's not pulling their weight, causing friction, or just not fitting in that's when you need a compass to guide you. And that's what this guide aims to be.
In the following sections, we'll delve into the various types of difficult employees you might encounter - from procrastinators and lone wolves to negative Nancies and over-promisers. We'll explore typical scenarios, describe their behaviors, and, most importantly, provide strategies for managing difficult employees effectively.
I will also touch a bit on the importance of communication techniques like Nonviolent Communication. We'll walk through the steps of implementing a Performance Improvement Plan and when it might be time to escalate issues and part ways.
🏄 This guide is not a magic wand that will solve all your management challenges. But it's a starting point. It's also very subjective. Your mileage may vary. It's a collection of insights and advice that I hope will help you become a better manager to your team, even if some of them are not the most pleasant people to work with.
So, let's embark on this journey together. Let's navigate these rough seas with your crew and turn challenges into opportunities for growth. As any seasoned sailor will tell you, it's not the calm seas but the storms that make a good captain.
Effectively Managing the Norm
Before diving deep into managing the difficult engineers, let’s focus first on managing those that are not as atypical. The "norm" refers to the majority of your team members who come in daily, do their job, and contribute to the team’s success — they’re competent professionals with healthy mental states and won't require any special attention. No issues, no conflicts, no special needs. These individuals form the backbone of your team and will probably represent 90% of the people you meet and work with.
I use a simple strategy to make sure these kinds of employees are happy — Trust, Growth, Comfort.
Trusting Them to Do the Right Things
- Assume Intelligence: Always start with the assumption that your team members are intelligent and will make informed decisions. This mindset fosters an environment of respect and empowers individuals to take initiative. It’s even better to assume they’re smarter than you and might know something you don’t. You probably hired them, so unless you’re hiring people who are worse than yourself (and I sure hope you don’t), you should assume they have better ideas than you do.
- Accountable Autonomy: Give them the freedom to make decisions and act on them. Keeping them accountable for those decisions is far more productive than questioning their every move. Autonomy comes with the price of accountability and should be stated explicitly. Do whatever you want, but you’re responsible for the fuck-ups as well.
- Allow fixable mistakes to happen: Trust means allowing room for errors. Of course, I’m not talking about senior developers with privileged access running rm -rf on production or dropping production database and deleting backups, and saying whoops — that’s a cause for corrective action. The mistakes can be divided into two parts: Mistakes that can be fixed and mistakes that cannot. Mistakes that can be fixed is anything where you write a postmortem, do a debriefing and continue on your way with lessons learned. Mistakes that cannot be fixed is people dying, something blowing up or your company going bankrupt. Allow them to make mistakes from which the company can recover and help them learn from them. Update: Here's a cautionary tail that bankrupted a company in 45 minutes due to a failed deployment and the relevant HN comments.
Challenging Them to Become Better
- Challenge Regularly: Push your team members out of their comfort zones. Not talking about dropping them cold into projects where they have zero knowledge and expecting them to perform. More of — encouraging them to take on tasks that stretch their abilities, a bit more complicated than they’re used to, fostering their growth.
- Praise and Recognition: Recognize their achievements. Show them the milestones they can reach and celebrate with them when they do — be it with monetary incentives or a public announcement of their achievements. This not only boosts morale but also motivates them to aim higher.
- Constructive Feedback and clear Path: While praise is essential, it's equally important to address areas where they’re lacking. Nobody is perfect, and some of us are better at different things. However, the focus should be on improving where we excel and pulling up those things we’re bad at. They’re good at algorithms but bad at databases — time to deep dive into DBs. They’re good at small tasks but struggle with bigger things — time to learn software architecture. In any way, the feedback should be a tool for growth, not a weapon for criticism.
Keeping It Comfortable
- Limit Interruptions: Respect their time and focus. Avoid unnecessary meetings and interruptions. Embrace asynchronous communication, allowing team members to respond when it's most convenient, fostering efficiency and respect for individual work rhythms. If the wheels are turning, there’s no need to run around interrupting them constantly. Let people work.
- Streamlined Processes: Ensure that all auxiliary processes, from software tools to administrative tasks, are efficient, user-friendly, and non-interrupting (see above). A smooth operational environment reduces frustration and allows team members to focus on what needs to be done without constant notifications.
- Less thinking, more creating: As software engineers are more creative, the fewer decisions they have to make outside of their project, the better decisions they make inside of the project. Instead of them figuring out, “Is tomorrow a non-working day or not” — make the info easily accessible. Instead of them figuring out where to get snacks — have snacks ready. You get the idea.
The list above can be the catalyst that propels your team to a new steady height of productivity. These are low-hanging fruits that can create a positive atmosphere that permeates every line of code. It can enhance the quality of the software your team produces, ensuring that every product you deliver is as good as it possibly can be.
Enjoyed the read? Join a growing community of more than 2,000 (🤯) future CTOs.
But let's not sugarcoat it - being an effective leader in a software engineering team is not without its challenges. You're dealing with people, each with their unique personalities, strengths, weaknesses, and quirks.
🏄 One of the most common - and often most daunting - challenges is dealing with difficult employees. Whether it's the brilliant coder who can't meet a deadline, that he himself has set, the seasoned engineer who struggles with teamwork, or the talented newcomer who's always negative — there will be many, many individuals that will require more empathy and understanding than usual to make sure everyone stays productive.
Let's explore the challenging types of software engineers, understand their behaviors, and learn practical strategies to manage them. Because at the end of the day, it's not just about building great software; it's about having fun while building great teams.
Difficult Software Engineers
I use the term "difficult" to differentiate between those employees where everything is going smoothly, and those where more effort is required.
Why is it important to understand different types of difficult employees? Well, think of it this way - if you're trying to debug a piece of code, you first need to understand what each line of code is doing, right? Similarly, to address and manage problematic behaviors effectively, you first need to understand these behaviors, their motivations, and their impact on the team.
In this section, we'll explore a variety of difficult employee types that you might encounter in a software engineering team. Each of these types presents unique challenges and opportunities for growth and improvement. By understanding these behaviors, you'll be better equipped to manage them effectively, turning potential obstacles into stepping stones toward a more harmonious and productive team.
I want to note that some scenarios are hyperbolized, and I’m not a communications guru, so if you have better examples— please put them in the comments; much appreciated.
Imagine this: It's a week before a major software release. Your team is buzzing with activity, tying up loose ends, and running final tests. But there's one team member, let's call him Joe, who's yet to complete a crucial piece of the project. Despite repeated reminders, Joe always seems to have an excuse — the build is taking too long, or it works on my machine but is failing on staging — always promises to get it fixed by “tomorrow". This is a classic example of a Procrastinator.
Procrastinators tend to delay tasks, often focusing on less important tasks while ignoring the critical ones. They may have poor time management skills, often underestimating the time required to complete tasks. This behavior can lead to missed deadlines, increased stress for the team, and potential risks to the project.
Managing a Procrastinator requires a balance of firmness and support. Set clear deadlines and regularly check in on their progress. Make them accountable for those deadlines. Help them prioritize tasks and offer time management training if necessary. Ensure they update the Project Management tools daily with the progress made and things finished.
Remember, the goal is not micromanaging but guiding them toward better work habits.
The Lone Wolf
Picture this: Your team is brainstorming ideas for a new feature. Ideas are flying around, and the energy is high. But there's one person, let's call her Lisa, who's sitting quietly, not participating. Later, you find out that Lisa has gone ahead and started working on the feature without discussing her approach with the team. She assumed she knows best how to tackle the problem. This is a typical Lone Wolf scenario.
Lone Wolves assume they’re the most competent person and prefer to work alone, often resisting collaborative efforts — I mean, why would you need someone else’s help if they’re far inferior to you? Usually, they do not participate in team discussions unless to tell everyone that they “could’ve done that in 3 days”. While their self-reliance can sometimes be an asset, it can also lead to a lack of cohesion and potential misalignment with team goals. And most importantly — people don’t enjoy working with Lone Wolves.
🏄 I see Lone Wolves as a teenager mentality. They’re stuck in this mindset that they’re the most brilliant badass coders ever.
There are two ways to manage the Lone Wolf — to embrace or make them collaborate. Embracing the Lone Wolves means that this person is of very high value to your business, and keeping him comfortable is more important than the overall team morale. Not recommended, but still a possible tradeoff if the Lone Wolf is a 100x Engineer in your eyes.
Managing a Lone Wolf involves forcing a culture of collaboration. Encourage them to share their ideas in the meetings and involve them in team decisions more directly. It would be great if you could put them in a team where they would not be the smartest. Assign them a mentor to help them see themselves in a different light. Give them tasks that require collaboration and, most important of all — provide constructive criticism of their behavior and set ground rules for collaboration — they can either stay on the same level as they are now or grow out of this lone wolf mentality and be an even more awesome coder who people enjoy working with.
The Negative Nancy
Let's set the scene: Your team is in a meeting discussing a new project. There's a sense of excitement in the air, a buzz of anticipation. But then there's one person, let's call him Mark, who seems to find a problem with every idea, a flaw in every plan. He constantly focuses on the negatives, rarely offers solutions, and thinks everything is impossible and the status quo is just fine. This is your typical Negative Nancy.
First of all — seeing issues in ideas is not a problem per se. It’s mostly the negative way the issue is portrayed. Suppose there’s a challenge that needs to be overcome to achieve the idea. In that case, Negative Nancies usually tend to say it’s impossible because of X, not that “we can make it happen if we do X and Y, which will require significant effort, but it’s still doable.”
Negative Nancies tend to overly focus on the negative aspects of situations, overlooking potential solutions. They may complain frequently, resist change, and spread negativity within the team. This behavior can dampen team morale and hinder creativity and innovation. “Why are they forcing us to do X? Urgh, I like how things are now.”
Managing a Negative Nancy involves understanding where they’re coming from — from a position of “nothing should affect my comfort, the more issues I find, the less I need to do and the less I need to move out of my comfort zone”. This negativity should be addressed directly and privately, asking them to bring solutions instead of problems. Encourage positive interactions and remind them that change will happen regardless of them and that things will move on without them if they continue to focus on the negatives. If the behavior continues, involving HR or considering whether this employee is a good fit for the team may be necessary.
Imagine this: You're planning a new software release. One of your team members, let's call her Sarah, promises to deliver a complex functionality within a month. You're impressed by her confidence, but two weeks after she told you that “everything is fine, I’m handling it,” the functionality is nowhere near complete; even worse, it’s about 20% done. This is a classic Over-Promiser scenario.
Over-Promisers tend to be overly optimistic about their capabilities or the time required to complete tasks and secretive when things don’t go as planned. Even during status updates, they can say, “It’s going great,” even though they’re struggling to find a solution and face some blockers — because they still hope to finish it on time. They often fail to deliver on their promises, which leads to frustration and mistrust within the team and with the Product Owners.
🏄 Over-Promisers are usually the younger developers who have not missed deadlines that often yet, and they’re still getting the hang of how much they can do and how fast.
Managing an Over-Promiser involves setting realistic expectations together with the teammates — figuring out a proper deadline for this big thing that needs to be built and splitting it up into meaningful tasks (also together with the teammates) — after that, everyone agrees on how much time each of those parts will take. I don’t think there’s a way to help them make more accurate commitments besides getting more experience. If it’s a senior dev — make them accountable for the deadlines that they set. Encourage them to communicate early and openly about any challenges they're facing.
Enjoyed the read? Join a growing community of more than 2,000 (🤯) future CTOs.
Possible Scenario: You're in a team meeting, discussing a complex problem. Different team members suggest solutions, debating pros and cons, and a healthy collaboration is happening. But then, all of a sudden, someone, let’s call him Alex, speaks up and says that he’s heard enough, everyone is stupid, all the solutions are bullshit, and his solution is the only correct one. No way you should question or poke holes in his suggestion, as nobody is more brilliant than him. He vehemently dismisses others' ideas and resists feedback. This is your typical Know-It-All.
🏄 It’s very similar to lone wolf, but they don’t insist on working alone — they insist on their solution being built and praised.
Know-It-Alls tend to be arrogant and closed-minded. They often lack the ability to listen to others and are highly resistant to change or new ideas. As you can imagine, this behavior is quite annoying for others who want to spar with ideas and figure out the best way to build something. Overall this stifles creativity, hinders team collaboration, and creates a hostile work environment.
Nobody enjoys working with the know-it-alls. They tend to shut down any, even small improvement suggestions. Imagine someone with a superiority complex — any hint that their idea is imperfect leads to a defensive discussion.
How to handle the know-it-all — the first step is addressing the behavior directly in a 1:1 meeting — they are likely unaware of their shortcomings, as they think everything they do is perfect. Send them this article, and tell them if they see themselves in the description above. After the confrontation — emphasize mutual respect and open-mindedness — all ideas need to be discussed/sparred/disassembled, even if they seem perfect; only then can anyone be sure the solution is correct. Encourage them to ask for feedback all the time.
If the behavior continues, give a formal warning and consider involving HR in the meeting.
The Silent Type
Scenario: Your team is in a lively discussion, brainstorming ideas for a new awesome feature. Everyone is participating except for one person. Let’s call her Emily. She sits quietly, not contributing to the discussion. Later, you find out that she had a great idea but didn't feel comfortable sharing it. This is a typical Silent Type scenario.
I’m writing about this type irrespective of the gender of the person. Still, I’d like to point out that female developers often have a more challenging time voicing their opinion when the team culture is similar to the frat house and values the loudest voices the most.
Silent Types, in general, tend to be introverted and may struggle with communication. Even though they might immediately see the issues with the solution, they might think, “It’s not worth it to share the concerns, to antagonize someone.” They often keep their thoughts to themselves, which can lead to misunderstandings or missed opportunities for collaboration.
🏄 The silent type is usually a by-product of a toxic culture where the conflicts don’t get resolved in a healthy way; hence everyone avoids them instead of dealing with them head-on. This also means other “bad” archetypes are present on the team, e.g., the know-it-all.
Managing a Silent Type involves creating a safe and inclusive environment and encouraging others to speak up even when there will be conflicts of ideas. Healthy debates must happen regularly so everyone sees that voicing their opinion is not something to be afraid of. Provide various channels/platforms for communication — one-on-one meetings, meetings in a smaller group, group chats, email discussion — which may be more comfortable for them.
But most important, recognize and value their contributions to make them feel more included even if they’re not the loudest voice in the room.
So, let’s set the scene: You see a Pull Request pop up from one of your team members. Let’s call him Tom. You start reviewing a piece of code — The code is well-written and does the job, but Tom is not satisfied. He's been tweaking and refining it for days, trying to make it "perfect,” eventually turning it into a one-liner. The problem? Other tasks are piling up, deadlines are looming, code looks cool only to Tom, and Tom's quest for perfection is causing delays. This is your typical Perfectionist.
Very often, Perfectionists are recent graduates. They tend to focus on minute details, often at the expense of the bigger picture. They may struggle with the KISS principles and delegation and have high, sometimes unrealistic, standards for themselves and others. In their mind, the code is art, and they should not be rushed while creating an art piece. This behavior leads to inefficiencies, missed deadlines, and increased stress for the whole team.
So how can you manage a perfectionist? Easy. Lower their expectations of themselves, help them focus on what's most important — a working solution that is not-overengineered, does not read like a poem, and is maintainable in 2 years. Encourage them to prioritize simple solutions and set realistic standards. Ask them for a second opinion on the “readiness” of the code.
If necessary, provide coaching on time management and book suggestions to build effective coding habits.
The Unreliable One
Scenario: You're managing a project with a tight deadline. One of your team members, let's call her Anna, is responsible for a critical part of the project. Despite her assurances that she'll complete the task on time, the deadline comes and goes, and the task is still incomplete. This is a classic Unreliable One scenario.
Unreliable employees are identified by their tardiness — constantly late, submitting unfinished work, and skipping meetings. They lack commitment, discipline, or time management skills. Or all three combined. Their inconsistent performance can lead to mistrust and frustration within the team and potentially (highly likely) jeopardize project timelines.
Managing an Unreliable One involves setting clear expectations and holding them accountable — meaning giving formal warning after the first incident. During the first incident, provide feedback on the impact of their behavior on the team and the project. If the habit continues, set up a performance improvement plan and agree transparently on future disciplinary action. Remember, reliability is a key component of a high-performing team, and addressing issues promptly and effectively is important.
If you don’t handle the unreliable employees, you’re doing a disservice to your team, who are trying to be effective and rely on them. They will need to spend time thinking about ways to work around them rather than work with them.
The Conflict Instigator
Picture this: Your team is working harmoniously on a project, but there's one person, let's call him Jake, who seems to thrive on conflict. He makes fun of others’ code, pokes at people, and often instigates arguments, spreads rumors, or creates a hostile environment. This is your typical Conflict Instigator.
Conflict Instigators tend to be argumentative, aggressive, and disruptive. They thrive on drama and create a toxic work environment. This behavior can lead to decreased team morale, increased stress, and reduced productivity.
In my opinion (Of course, you can correct me in the comments) — There’s only one way to handle such employees — with immediate addressing of the actions in private, emphasizing the importance of staying professional and a zero-tolerance policy for such behavior in the future. If it continues — cut fast and don’t look back. It’s not worth the effort to keep them on the team. Remember, a healthy team is a productive team, and toxic conflict should be addressed promptly and effectively.
The Burned-Out Employee
Scenario: One of your top performers, let's call her Lisa, has been showing signs of burnout. She's been great the last year, hitting milestone after milestone, but recently she’s been working long hours, missing deadlines, and seems disengaged. She's not the enthusiastic, motivated team member she used to be. This is a typical Burned-Out Employee scenario.
🏄 I don’t consider a burned-out employee as a “bad employee,” but they can still have a negative impact — they are the ones you need to help and make sure they can thrive again.
Burned-out employees exhibit signs of exhaustion, cynicism, and reduced professional efficacy. They struggle to meet deadlines, have the lowest output on the team, and make more mistakes than over the previous observable period.
Managing a Burned-Out Employee involves addressing the issue with as much empathy and concern as you have. Suggest they take a vacation or sabbatical. Go all-in on work-life balance and provide resources for stress management.
Remember, your team members are your most valuable asset, and their well-being should always be a priority.
Managing difficult employees means figuring out ways to ensure you and your employees thrive, even if the circumstances are against you. One tool stands out as particularly crucial: communication. In a software engineering team, clear and effective communication is not just a nice-to-have; it's a must-have. Bad communication is the reason teams fail.
Think about it. How often have you seen a project go off track due to a simple misunderstanding? How many conflicts could have been avoided with better communication? How many great ideas have been lost in the noise of poor communication?
One powerful communication tool I've found particularly useful is Nonviolent Communication (NVC). Developed by psychologist Marshall Rosenberg, NVC is a method of communication that promotes empathy and understanding.
At its core, NVC involves four steps: Observation, Feeling, Need, and Request.
- Observation involves stating the facts we observe that are affecting our well-being.
- Feeling is about sharing how we feel in relation to what we observe.
- Need is expressing what we need or value that is causing our feelings.
- Request involves clearly requesting what we want without demanding it.
In a management context, NVC can be a game-changer. It can help you communicate effectively with your team, constructively address issues, and build strong, positive relationships.
I’m not going to talk much about it, but I’m going to give you some links to read:
Active Listening and Empathy
As a manager, your role is not just to talk; it's also to listen. Active listening is a crucial skill that involves fully focusing on the speaker, understanding their message, and responding thoughtfully. It's not just about hearing the words; it's about understanding the emotions, ideas, and thoughts behind those words.
🏄 My business partner, who’s a great salesperson, has this rule — after someone finishes talking to you — wait a few seconds before responding, organize your thoughts, and process what they said, only after you’re sure they’ve said everything they wanted to do you respond to them.
Active listening can be improved through paraphrasing, asking open-ended questions, and showing empathy. Empathy, the ability to understand and share the feelings of others, plays a crucial role in management. Cultivating compassion involves being open to others' perspectives, showing genuine interest in their experiences, and responding with kindness and understanding. Simply put, before you judge anyone as a "difficult" employee, you put yourself in their shoes and see from their side. Talk with them, listen, we're all humans.
Your role is not just to lead; it's also to support, understand, and inspire.
What to do next?
Once you've identified and understood the types of difficult employees in your team and have communicated effectively with them, the question arises - what's the next step? What are the options? This section will guide you through the subsequent stages, from implementing Performance Improvement Plans to escalating issues when necessary.
Performance Improvement Plans
If, after many 1:1s with the person, you could not find a solution that helps both — the employee and the company — and they still continue behavior, it's time to make it formal.
A Performance Improvement Plan (PIP) is a formal document that outlines an employee's performance issues and the steps they need to take to improve. It's an escalation tool that can help managers address performance issues in a structured, supportive manner.
A PIP may be necessary when an employee's performance is consistently not meeting expectations, despite feedback and coaching. It's a step that should be taken when other, less formal interventions have not resulted in any improvement.
Implementing a PIP involves several steps — first, clearly outline the performance issues and the expected improvements. Then, set realistic, measurable goals and a timeline for achieving them. Provide support and resources to help the employee improve, and schedule regular check-ins to discuss progress.
Monitoring progress is crucial. Regular feedback can help the employee understand where they're improving and where they still need to work. Remember, the goal of a PIP is not to punish but to support the employee in their transformation and to improve their performance.
To illustrate, let's consider a case study. An engineer in our team was consistently missing deadlines and marking tickets as done that would later be returned from the QA as unfinished. We implemented a PIP, setting clear expectations and defining strict rules how the behavior needed to change. Regular check-ins helped keep the engineer on track, and within a few months, their performance had significantly improved. The key lessons? Making it formal — helps a lot. It’s like getting a police ticket; people tend to react more seriously when you make it clear that it’s already escalating.
Time to Escalate
Sometimes, despite your best efforts, an issue may need to be escalated. This could be due to persistent performance issues, serious misconduct, or if the employee's behavior negatively affects the team, e.g., with the conflict instigator.
Documenting the issue is crucial. Keep a record of the performance issues, the steps taken to address them, and the employee's response. This documentation can provide a clear picture of the problem and the efforts made to resolve it.
When escalating an issue, follow your organization's procedures. This may involve discussing the matter with HR or higher management. Remember, escalation is not a failure on your part as a manager. It's a step towards resolving an issue that's beyond your control. It's about ensuring a positive, productive work environment for your entire team.
Time to Part Ways
There will come a time when, despite all efforts to improve a situation, it becomes clear that an employee is not a good fit for the team or the organization. This is a difficult realization and one that should not be taken lightly.
Termination should be considered when an employee's behavior or performance is consistently and significantly below expectations, despite repeated feedback, coaching, and support. Other reasons might include severe misconduct or an evident lack of alignment with the company's values or culture.
Termination is a last resort and should be considered only when all other avenues have been exhausted. It's a decision that can significantly impact the individual and the team, so it's crucial to handle it with care.
The process should be clear, fair, and transparent. The employee should be informed of the decision in a private, face-to-face meeting, and the reasons for the termination should be explained clearly. Treat the employee, even if you think they’re a “bad employee,” with respect and dignity throughout the process. Offer support where possible, and provide feedback to help them in their future careers.
Managing difficult employees is not just about addressing problematic habits; it's about understanding these behaviors, communicating effectively, and guiding your team members toward improvement.
Everyone has to have a second chance at becoming better.
Other Newsletter Issues:
- Rules of Thumb for Software Development Estimations
- The Surprising Power of Documentation
- Being a good mentor – a developers guide
- Contracts you should never sign
P.S I'm pretty sure there are more types of employees that can be mentioned here as well different ways YOU would've handled the scenarios, let me know in the comments below.
There is a key bit here which I find missing: while enumerating the stereotypes of various “bear downs” on the team nowhere is there a question of “does our org have to do with this?”. Spoiler: most people do not just turn into Negative Nancies overnight, and most people do not turn into one of these archetypes because of home issues (young parents is one important factor). Often it is the org itself, the way of working, constant pressure, ignoring basic needs, denying promotions, denying creative freedom and input – which goes on for literally years – which leads people to turn to these sour behaviours as a mechanism of self-preservation. The one key bit which I miss (and why I personally slotted myself into these archetypes) is a bit of managerial self-reflection and appropriate conversation to go with it. Very simple questions (they do require a lot of candor and openness):
* How is our org killing you right now?
* List 3 things that should change in our org so that you can feel safe
* If the org cannot change to make you feel safe – are you OK with looking for a different place?
A manager can’t reform an entire org and right all the wrongs – but if the operation of the org involves boiling people in shit a base expectation is they have the gusto to say it out loud, instead of bringing on PIPs and other tools of punishment.
I love it how you start your essay with “you probably hired them because they are better than you …”, yet you have the audacity to assume, that you can coach & mentor all these “bad engineers” in basic one-on-ones where you tell them they should change their behavior.
From my experience, all these difficult types are cause by bad leadership, de-motivation or flat out frustration. None of these are “person types”. All of them are specific reactions to specific triggers. I have acted like every single “difficult type” in the past (besides the Silent Type maybe). From my point of view, I had very good reasons to act that way.
Most people are usually coherent and logical in their own perception. That means, that everyone has (in their world) very good reasons why they act the way they do. The only thing that I found out to really work is this: Take the time and empathy to understand why someone behaves the way they do. Understand their motivations, their frustration and their perception of reality. Only then you can help them get another perspective. Sometimes, this perspective or piece of information is all they need to change their behavior. Sometimes, they are pissed for other reasons and that is their way to take it out on you or your team. In that case, you need to work on that.
Jannis! Amazing response! 100% Spot on!
Very insightful, thanks you
I like how half o the difficult behaviors solutions described here involve one-on-ones, telling a person that they misbehave and that’s it, maybe call HR next time. I don’t know, maybe this idealistic approach works in places like FAANG or other well funded and reputable companies that receive hundreds of resumes from experienced developers every day, and therefore can afford to select the best people for the job and say good bye at any time to those who do not fit. But the reality of the rest of the world is that there are not enough experienced devs out there for us because the best ones are scooped by all those big data, fortune 500 and Silicon Valley startups swimming in VCs’ cash. When we finally hire a decent dev, we do everything to keep them. Calling them to 1:1s and pretty much threatening them with firing by simply telling them that their behavior is unacceptable and needs to stop, will not work because one week later they are showing up with their notice in your office. I will not tell you what is the right solution to each problem you described – I consider myself a terrible manager and so I recently gave up on doing people management jobs. One thing I know: you claim you are describing types of people here but the solutions you provide are for types of behaviors. You need to review your approach to that, remember those negative symptoms you list are inseparable part of personalities. It is not possible to correct someone’s personality by bashing them for their traits in 1:1 meeting and giving them personal goals list or one month repair plan. As others already said in their comments, as a manager you need to look at them in the context of the whole team. Don’t try fixing people, you will fail at this, unless you also happen to be a psychatrist or have 10 years with them to play a mentor. Use their personalities to your advantage when possible, when not, learn how to live with them. Know your people. That’s your job as a manager, not picking on, on everyone’s flaws and trying to fix them.
I think the most important thing about being a manager is empathy. People can change, sometimes they just need guidance, I’ve seen it hundreds of times, a procrastinator might just need more pressure, a negative person might just come from a more confrontational culture/upbringing, and someone who is burned out might just need a break. All these processes also serve to formalise the process and avoid personal biases and to provide a framework for action for managers.
The negative Nancy example seems steeped in managerial infallibility and ripe for abuse for situation where a team might be apathetic (previous discussions with the manager were also take the same way “do not care, change will happen with you or without you” and other examples where you quoted your approach) the few that speak up are managed out this way… it is not the point that is wrong, if I ask you to draw three red lines with blue ink it is you the expert being negative and not thinking creatively. It reads very authoritarian, but again you are honest and do this publicly so. It hiding yourself and I would give you props for that.
It’s sad that there is no like/dislike button and ordering by it, because not all comments are created equal .-.
As usual for neurotypicals, zero tolerance or even minimal awareness of neurodiversity.
well the neurodiverse also need to make an effort to fit in with the rest of the society. it’s a two way street
There is no place for recognizing any sort of mental “divergence” or lack thereof in the professional space. There is only empathy and communication. Regardless of whether you are “neurodivergent” or not, everyone is on the same, equal playing field. There is no place for excuses or insults. Only communication and teamwork. It’s as simple as that.
3.6, 3.8, and 3.12
It seems like there are more than a few commenters who take issue with this post, which means the author must have hit a nerve.
Are employees always the problem? Of course not; they’re likely the problem less than half the time. But the article is titled “Managing Bad Engineers”, not “Solving Every Work Environment Issue”. Any attempt to train managers to better understand their team and engage with them in an empathetic way should be encouraged.
Sure, neurodivergence is a relatively frequent condition in our field. However, toxic behavior can’t be excused because it carries a certain label. If a difficult team member is causing issues for the rest of the team because of their behavior or inability to perform, the entire team’s well-being must be considered in any response. Managers and team leads are not and cannot be responsible for that member’s holistic well-being; the best they can do in these scenarios is mitigate symptoms and coach the difficult employee towards personal and professional growth.
While measuring the performance of the team is important, someone needs to be measure the performance of the individual, you need to identify people would are struggling so you can help them, or ensure the company is the best fit for them.
I think there’s a common flaw in your arguments, as some commenters have pointed out below: you primarily focus on individuals rather than the results of the team as a whole. For instance, neurodivergent individuals are prevalent in IT, someone might be labeled as a “procrastinator.” However, that same individual might excel in maintaining long periods of focus, establishing connections between ideas, creative work, etc.
In one of my previous jobs, three months in, I had a 1:1 with my engineering manager. Suddenly he decided to share his screen to show me the list of my authored GitHub PRs, pointing out that the “quantity” of my pull requests was slightly lower than that of others on my team. He lacked insight into the impact of my work, yet he held the authority to write down his half-baked perceptions in my performance review. I ended up leaving after a year because of the toxicity in the team; Everyone played nice using NVC publicly, but I was dragged into these nasty private Telegram chats filled with daily aggressiveness and insults towards management, other teams or “excluded” team members. I figured out in that context it was I who was the difficult employee, not a silent one but surely I matched at least half of your definitions.
Good luck thanks for sharing
Till Helge Helwig
(3) There is one flaw in this summary in general: The precondition for doing any of this is to have leaders, who actually have the mandate and the time to take care of their employees. This is often overlooked. People leadership takes time, because good conversations take time. Leaders, who are almost on the edge of their seat, because they have to hurry to the next meeting right away, will most likely miss key signals.
Till Helge Helwig
(2) You’re skipping over one very important part: neurodiverse engineers. Some behaviors (e.g. procrastination) can be caused by anxiety or other situations. They are a lot more common than people usually expect. And taking disciplinary action of any kind is the worst possible reaction in such cases. You mention empathy and active listening, which certainly are vital to notice what’s happening. But solutions have to look a lot different in such cases. That can range from reassignment to a better suited task (after analyzing with the engineer what kind of tasks that should be, e.g. working on internal tooling instead of the high-load webapp) to educating yourself about the condition before doing anything else.
Till Helge Helwig
Here are a few thoughts I had after reading your article:
(1) Personally, I would have preferred if you had explained traits rather than “classes” of people. I understand that this is easier to convey, but most situations are not as clear-cut and there is often a mixture of different traits and reasons behind them, so most people will fall partially into multiple of your categories. Which of the proposed solutions is the right one to pick then? All at once? Any attempt at labeling people always ends up with this flaw.
(I’m trying to split this up, because your WordPress considers me a spammer for some reason…)
Jesper Louis Andersen
You need to factor in neurodivergence. A lot of great software people are neurodivergent one way or the other. You might accidentally end up categorizing those as being difficult. But if you try to solve the problem by using (some of) your suggested tools, you won’t have much success. Rather, you risk creating more problems in the long run.
A common trap is to impose your own thought patterns and assume other people fundamentally work the same way as yourself. In turn, solutions you suggest are solutions which will work for some people, but they might not for others.
Context also matters. Perfection and rigor are excellent traits to posses for a mission critical part of the system where you want pieces to move slowly and be thoroughly tested and coherent. But in another part of the system where this matters less, perfectionism can be a hinderance.
I see myself in every bad engineer described here, should take a rest?
It feels like you are describing a scenario where a team is not able to self-organise, and manage themselves. I don’t want to criticise you, but I recommend staying open-minded in future. You approach is to pretty much about micro manage everything, your pejorative descriptions of people tell a lot about your attitude. Maybe you should start from describing yourself in first place.
The next step in your career should be to join a self-organising team/teal organisation as a IC. A healthy group of people will manage itself, and they won’t think of perforative labels in this process.
I think I would have liked more emphasis put on the support phase, were the manager investigates, tries to understand and offers the neccesary support. In the end the main responsability of a manager is to create the environment where the team thrives.
In my career, I’ve been able to mostly focus on creating the right environment and most of the performance issues solved on their own, not needing formal processes.
I think o would have liked to see much more written about how a manager should spend time and effort to understand and offer support, before mitigating with expectations and deadlines. It’s the main responsibility of a manager to create the right environment where everyone thrives.
I for one, as a former engineer, i struggle to some extent with managing teams/individuals which are technically way less experienced than me; and it just happens that some have inflated egos not accepting a technical manager that asks questions and, challenges decisions/facts and provides input.
This screed is more a reflection of you than of your employees. Your thoughts look like caricatures, and nowhere do you discuss your own faults. A proper manager would see the entire system he is running and see where the problems lie: the tooling, the software quality, the uneven competence of the team, the deadlines, etc. Instead, you sound like a hammer and everything to you is a nail: bad engineer. You also seem to be twisting NVC to your own ends: it isn’t just a tool to get your way while pretending to be nice. I recall a manager like you. He only manages himself these days.
For procrastinators and other types of slow-walking types behavior, I’ve found that many times the root of if is fear, especially of the deployment. Confidence building and making sure they know they won’t be alone during the deployment can help with this.
PIPs, If it doesn’t include a reflective management improvement segment it’s not properly though through.
Remember, like some reels and shorts, start the PDCA half way through at ‘check’. It’s a 2-way communication.
It’s essential to differentiate between a lack of skills and a lack of effort. Some of the types you mentioned rely purely on the lack of effort from their side. While skills can be developed with time and training, a lack of effort or motivation requires a different management approach. Also a reminder that quick judgments can be detrimental and that every engineer deserves an opportunity to prove themselves.
As you mentioned, instead of immediately dismissing someone as a “bad engineer,” it’s essential to invest in their growth and provide them with the necessary resources.
I’ve found that some engineers can be very confrontational when their work or design is criticised, even constructively. I’ve found that it almost always comes from previous employment where there was a ‘finger-pointing’ blame culture.
Thanks for the read. I took a look at the comments bellow. I’m 50/50 on whether it’s okay to hold engineers accountable for their mistakes. Of course you can blame the process and remove the responbility, but that just means only the managers can be liable? I agree with the point that before labeling someone as a ‘difficult engineer,’ it’s essential to identify the root cause of the problem. It’s easy to jump to conclusions without understanding the underlying issues, be it personal or professional.
I’ve been a manager for over a decade now, and the challenge of managing difficult people never really goes away. So many different people, so many different lives. we should remember to put ourselves in their shoes before any disciplinary actions.
Thank you. I’m dealing with a bad manager and this helped me understand how I can be a better employee, what I can reasonably expect, and what my manager can do better. Communication and collaboration are the main problems, we do not practice any form of DevOps.
Yikes!! Is this post satire? Engineers that are not “deviants” had “good childhoods”?
The way to manage the “unreliable one” is to immediately issue a formal warning and then put them on a pip? The way to handle procrastinators is by setting deadlines and “stating what will start happening if they continue to miss them”?
How about instead of threatening your reports, you demonstrate some basic human empathy and try to understand why they’re struggling? Procrastinators are usually such because they find big tasks impossibly anxiety-inducing, and teaching them to break tasks into smaller pieces is much better than terrifying them with a PIP and ultimately firing them. or maybe YOUR work assignment strategy leaves them unclear as to how to prioritize their main work vs urgent interruptions.
You want to fire people for mistakes that can’t be fixed? How about instead of blaming the new college hire for accidentally deleting data on prod, you do some introspection and ask why your shitty development process left them with prod write access in the first place?
Frankly, you should delete this post
We can put labels on people all we want, but the question always is will they change or not? If a procrastinator is procrastinating due to finding big tasks anxiety inducing why not speak up, why be a procrastinator when they can change themselves, why wait for the manager to notice them as a procrastinator? Breaking down the tasks into smaller pieces treats the symptoms, not the cause.
And how do we treat the cause? I would like to know. I was of the opinion that breaking down tasks was the solution.
How about: Just get the task done or ask for help. Really.
My own experience with procrastinators was that they just didn’t care ab anything; team, company..like “why bother”.
But even then, as a manager, my strategy has always been to try to understand and find ways to support, in this case by getting the person well motivated.
My experience with procastinators is that they usually lack motivation moreso than lacking the skill of work breakdown; managing motivation which is one of the core duties and skills of a manager.
“Mistakes that cannot be fixed should not happen and should be handled with disciplinary action or termination.“
This is such a disgusting toxic mindset. I don’t want you anywhere near a team I work on. Mistakes happen even with the most seasoned of engineers. Instead ask why the process allowed for such a thing to happen and use the mistake as an opportunity to improve process.
Maliciousness should be met with disciplinary action. Accidents should be met with process improvements. Everyone at every level makes mistakes. You’re failure to see this is worrisome.
No. Suggesting that someone be fired for a mistake, regardless of the gravity of it, is promoting a toxic work environment. If anything, the manager is the one who should be held accountable, by not putting procedures and processes in place to prevent the mistake from happening.
Right, and the manager — the person responsible for delivery and oversight of the team — is the captain in this scenario. If the captain then tried to blame someone on the crew for their failure I would agree that the captain should be fired.
No, non-malicious failures of procedure are a learning opportunity. Someone who causes a large failure is the last likely person to repeat it. Managers are ultimately responsible for procedures being in place. If a manager refuses to accept responsibility and instead tries to shift blame onto someone who pushed a button, that’s ass-covering behaviour and a strong indicator of an ego problem. It certainly doesn’t benefit the company.
Disciplinary feedback has no room for honest mistakes. As the CTO you need to accept blame for all failures. It’s your fault for not instilling better engineering practices. Everyone under you plays by your rules. Every mistake is a learning opportunity to improve the organization. I’ve been at companies where an engineer lost millions of dollars. The result? A more robust system so it doesn’t happen again now that we’re bigger and earn more.
No it is very clear.
As a SME in many areas, I assume, I won’t be fired if things go wrong… simply because they know I’m giving my best, and sometimes… the ship is already sunk when I get there. I may only be called in as a last ditch effort.
Holding someone accountable for a mistake is a great way to create an environment where nobody will take risks.
I’m someone who will take on extreme risk. But I am careful about how I contain that risk.
It’s your premise that the system allows a single action from a single person to have an effect of that severity that bothers me.
You’ve quadrupled down on this in the comments and talk about the Captain. Yes, in some time sensitive environments we rely on a captain, a pilot, a driver to make critical decisions.
If you have created your company that fragile and unstable then it’s an institutional failure. Doesn’t matter who it was who ends up triggering that fault, it would have happened eventually.
Outside of sport we do strive to have redundancy, we mitigate failures, we recover and learn from our mistakes.
What product do you make?
That is a completely illegitimate analogy, as 99.999999999999% of “mistakes” that you would consider firing someone for do not have that impact.
> I believe that in certain high-stakes environments, some mistakes can have irreversible consequences. Depending on the industry, it can be people dying or stuff blowing up or your company going bankrupt.
What percent of environments are such a high-stakes ordeal? If the vast majority of environments are not high-stakes, why does your point still stand for the majority of your audience?
Firing for unfixable blunders???
Rubbish. Mistakes happen regardless of context. Engineers are people. All people are fallible no matter who they are. YOU included. If the mistake is through gross negligence and they fully understood what possible consequences would be, sure. Otherwise thats just malicious. I have both been an engineer and managed teams through my 2 decade career and I can assure you, a career that contains no major blunders is an unrealistic expectation. I actually recall deleting really important data in prod and thought I’d surely be fired. I definitely had a talking to, but my CEO asked, why would he fire one of his engineers that just learnt an invaluable lesson. Mistakes are costly, but the lessons learnt can be equally invaluable. I’d quit long before you could fire me. And if you stuck a PIP Infront of me, for the reasons you stated, you’d have my resignation on your desk before end of day.
Here’s a blog post written by Max Levchin about the time he almost bankrupt PayPal by bricking the database that contained 100% of their customer card data. This was the result of a new cryptography service that he implemented and deployed which didn’t behave as expected in production. Through sheer luck, they were able to recover the database after many hours of the site being down. If they hadn’t got lucky that day, the right disciplinary action have been a moot point, since there would be no more company.
It’s essential to create a culture where people are not afraid to stick their heads out and take risks. If the right processes and culture are in place, then the 0.00000001 type of unrecoverable incidents are not worth belaboring, and it’s better to spend that time focusing on creating an environment where engineers can fail safely and learn from it.