Managing difficult software engineers
Quick disclaimer: I’m still figuring this stuff out like everyone else. If something here feels off, poke holes in it—I read every comment and usually learn something new in the process.
Summer 2014, first time I had to tell an engineer twice my age that his pull-request wasn’t going into production. I had the technical arguments lined up, and yet the conversation derailed in under five minutes. That was the moment it clicked for me: algorithms are easy, people are the hard part. I’m not a natural “people person” (my default weekend plan is Vim and espresso), so I started taking notes, reading management books on trains, and stress-testing every technique on real teams. What follows is the cheat-sheet distilled from those experiments—some worked, some back-fired spectacularly.
One caveat before we dive into the weird edge-cases: many so-called “difficult” behaviours are side-effects of broken process. Five daily stand-ups, shifting scope, or a product roadmap that changes every sprint will turn the calmest senior into a flamethrower. Fix the environment first, then judge the individual. (I got this backwards my first couple of years and paid for it in churn.)
🏄 Developers get labeled snowflakes because we hire them for strong opinions and then act surprised when those opinions surface. I’ll focus on the outliers—the 5-10 % who soak up 90 % of a lead’s attention.
When every sprint review feels like Sunday brunch—smooth, pleasant, mostly croissants—you don’t need a playbook. The real test is when someone derails planning, ghosts a critical task, or quietly poisons morale. That’s the terrain this article covers.
We’ll walk through archetypes—procrastinators, lone wolves, negative Nancies, and so on—plus the levers that usually help. I’ll sprinkle in the two tools that saved me more than once: Non-Violent Communication and the nuclear option, a formal Performance Improvement Plan (PIP).
🏄 This isn’t a silver bullet. More like the map I wish I’d had when I shipped my first team into production.
Alright, coffee topped up? Let’s get to it.
Effectively Managing the Norm
Before hunting edge-cases, keep the baseline humming. Roughly nine out of ten engineers I’ve managed just want space to build cool things, learn, and go home on time. Keep them productive and most of the “difficult” behaviour never materialises. The mantra I fall back on is Trust → Growth → Comfort.
I could be wrong, but every time I skimp on one of those three, retention dips within a quarter.
Trust
Trusting Them to Do the Right Things
- Assume Intelligence: Start from “they know something I don’t.” You hired them for that knowledge. Questioning every commit out of fear is the fastest path to a passive team.
- Accountable Autonomy: Freedom plus a scoreboard. Engineers pick the how; we agree on the what/when and review the scoreboard openly. (Side note: first time I published burn-down charts on a TV, pair-programming requests doubled. Peer pressure beats lectures.)
- Allow fixable mistakes: If nobody ever breaks staging, you’re moving too slow. Draw the hard line at irreversible damage—data loss, legal violations, people getting hurt. Everything else is tuition.
Growth
Challenging Them to Become Better
- Challenge Regularly: Stretch tickets, not stress tickets. Assign something 20 % outside comfort, pair them with someone who’s done it before, and debrief afterwards.
- Praise and Recognition: Shout-outs in Slack are cheap dopamine and still underrated. I keep a standing budget for surprise book vouchers.
- Constructive Feedback & Clear Path: Feedback without a roadmap feels like criticism. Tie every weakness to a next step—course, mentor, shadow session.
Comfort
Keeping It Comfortable
- Limit Interruptions: My rule—no meeting can be longer than the prep time required to make it unnecessary. Async first, call second.
- Streamlined Processes: Burn a day scripting away a manual deployment, save a week of future sighs.
- Less thinking, more creating: Make admin invisible—clear holiday calendars, stocked coffee machine, working CI pipeline. Every decision token spent on bureaucracy is one less for product design.
Get those basics right and suddenly the edge cases look less terrifying.
Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.
That said, chaos occasionally walks through the door with a laptop. Time to meet the rogues’ gallery.
🏄 The frustrating part: 80 % of “difficult” behaviour evaporates if spec clarity, estimation buffers, and roadmap stability exist. But life’s messy, so let’s cover the remaining 20 %.
I’ll describe the patterns I’ve seen, plus the levers that nudged them back to productive, or at least harmless.
Difficult Software Engineers
I say “difficult” with caution—sometimes it’s the org chart that’s weird, not the person.
Like debugging memory leaks, naming the bug is half the fix. Labels below are imperfect shortcuts, nothing more.
If your mileage differs, drop a comment; I update my mental models constantly.
The Procrastinator
A developer swears the feature is “almost done” right up until the branch refuses to compile. Classic procrastination pattern.
Common root causes I’ve found: (a) task too big, (b) unclear acceptance criteria, (c) fear of showing imperfect work. Only one of those is a character flaw.
Fixes that worked for me: break work into daily-demo-able chunks, co-write the definition of done, and time-box with public checkpoints. Also, involve them in estimation so missed deadlines expose our collective optimism, not just their time management.
The goal is visibility, not babysitting.
The Lone Wolf
A developer disappears for a week and returns with 5k lines nobody asked for. Brilliant, but off-road.
Lone wolves often grew up in teams where design reviews were performative rubber stamps. They assume consensus is a brake pedal. Two tactics: put them in a pod where someone outranks them technically, and make architectural decisions require a lightweight RFC that must get two peers’ +1. (I should be upfront—this worked at 25 engineers; no idea if it scales to 250.)
🏄 Feels like teenage rebellion: “I’ll show you how it’s done.” Channel that energy, don’t squash it.
Celebrate the parts they nail, but draw a hard line at undocumented one-person rewrites.
The Negative Nancy
A developer shoots down every idea before the second slide. Fun.
Two managers ago, the same behaviour got him lauded as “rigor incarnate.” Different framing, different label. Remember that before you brand someone cynical.
Ask for one counter-proposal per criticism—suddenly half the negativity morphs into valid risk analysis. For the other half, a private chat about impact usually helps. If they still prefer snark to solutions, consider rotating them onto a bug-fix squad where finding flaws is the actual job.
The Over-Promiser
A developer claims she can build a Stripe clone in four weeks. Spoiler: she can’t.
Early-career devs mis-estimate by an order of magnitude; seniors by a factor of two. Pair them with peers during planning poker, add buffer, and publish rolling velocity so learning happens fast. Accountability still matters—missed by 20 %? Fine, we adjust. Missed by 5× and stayed silent? That’s a performance issue.
🏄 Confidence is great until it hides trouble. Visibility beats optimism.
Encourage early flag-raising; reward it publicly to kill the fear of looking weak.
Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.
The Know-It-All
A developer explains why everyone is wrong before hearing them out. Feels like an internet forum leaked into the office.
My playbook: 1:1 mirror their behaviour (“Here’s what I heard: you believe alternative X is ‘nonsense’. Did I get that right?”). Half the time they realise the tone issue on the spot. Then enforce a rule: every proposal must withstand at least two rounds of critical questions before we pick it. Forces humility.
Second violation → formal warning. Egos are expensive.
The Silent Type
A developer is brilliant but barely audible. In meetings she’ll DM me thoughts afterwards that would have saved 30 minutes.
Silence is often a lagging indicator of a culture that rewards volume over insight.
Solution stack: pre-reads so ideas travel without shouting, round-robin during meetings (“everyone speaks once before anyone speaks twice”), and private praise when they do share. Over a quarter the voice usually grows.
The Perfectionist
A developer turns a three-line fix into a weekend refactor. Clean, elegant, two sprints late.
I ask them to write the rollback plan first—forces clarity on scope. Also set a “review freeze” date: after that, tests > beauty. Remind them Git history is infinite; we can improve later.
Sometimes a tight SL A (ship, learn, adjust) beats another abstraction layer.
The Unreliable One
A developer misses stand-ups, merges half-finished code, and ghosts Jira.
First step: ask what’s going on. I’ve uncovered caregiving duties, visa stress, and silent burnout that way. If it’s personal crisis, lighten load, point to counselling, set flexible hours. If it’s pure discipline, outline expectations, one written warning, then PIP.
Punishing a crisis is cruelty; ignoring a pattern is unfair to the team. Balance is the job.
The Conflict Instigator
A developer lives for drama, critiques in public, jokes that land like insults.
Zero-tolerance policy, communicated day one. Private warning first offence, termination second. Teams aren’t therapy stages.
The Burned-Out Employee
A developer used to close more tickets than anyone. Lately she stares at the monitor and sighs.
🏄 Burnout doesn’t make someone “difficult” but it can tank a roadmap just the same.
Signs: cynicism, slipping quality, emotional distance. Treatment: mandatory vacation (yes, force the PTO), workload triage, maybe a no-meeting month. Offer counselling stipends; anonymity matters.
I can’t guarantee full recovery, but pretending it’s laziness guarantees failure.
Communication Tips
Almost every blow-up I’ve investigated started as a miscommunication. My favourite fixes: Non-Violent Communication, deliberate pause after the other person stops talking, and written follow-ups.
Silence for three seconds before responding feels awkward at first but reveals hidden context. Try it in your next 1:1; you’ll be amazed what surfaces.
Nonviolent Communication
NVC is basically four questions: What happened? How do I feel? What do I need? What do I request? Stripped of blame, the conversation stays about behaviour, not identity. I use it when feedback gets emotional.
If you want the deep dive, start with Rosenberg’s book or Dave Bailey’s summary:
- https://www.dave-bailey.com/blog/nonviolent-communication
- https://www.amazon.com/Nonviolent-Communication-Language-Life-Changing-Relationships/dp/189200528X
Active Listening and Empathy
You can’t debug code you refuse to read; same with humans. Paraphrase, ask open questions, empathise before judging. Sounds fluffy, saves hours.
🏄 My co-founder’s rule: person stops talking → count to three → respond.
Try it—your brain catches up to your mouth.
What to do next?
After the conversations, sometimes behaviour shifts. When it doesn’t, we get formal.
Performance Improvement Plans
PIPs feel scary but they’re just written clarity: behaviour, impact, expectation, deadline, support. I’ve run three in the past five years; two succeeded, one ended in exit. Success correlated with weekly check-ins and explicit company backing (HR in the intro meeting).
Think of it as a contract: we commit resources, you commit change. If either side defaults, we part ways with eyes open.
Time to Escalate
Escalation isn’t personal; it’s recognising the limits of your role. Document everything—dates, quotes, impacts. Future you (or legal) will thank present you.
Follow company process; if there is none, write one before the crisis.
Time to Part Ways
Firing someone is the hardest button you’ll push. Do it swiftly, respectfully, and with HR in the room. I schedule exits for early in the week so the team can regroup, not stew all weekend.
And remember: engineers also deal with difficult managers. Solicit upward feedback, run anonymous surveys, and fix your own bugs regularly.
Everyone deserves a second chance; not everyone earns a third.
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 sure I missed a few archetypes or better tricks—drop them below, I steal good ideas shamelessly.
Worried your codebase might be full of AI slop?
I've been reviewing code for 15 years. Let me take a look at yours and tell you honestly what's built to last and what isn't.
Learn about the AI Audit →No-Bullshit CTO Guide
268 pages of practical advice for CTOs and tech leads. Everything I know about building teams, scaling technology, and being a good technical founder — compiled into a printable PDF.
Get the guide →
72 Comments
“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.
I appreciate your perspective and understand where you’re coming from.
However, 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.
Of course, it’s important to foster a culture of learning and growth, but it’s equally crucial to recognize the gravity of certain errors. I think what you’re missing is the balance between compassion and accountability.
It’s not about promoting a toxic culture but ensuring that people are accountable and work towards making sure “unfixable” errors never happen — with better processes, with safeguards, with documentation, with whatever they need to make sure irreversible errors don’t happen.
I think blaming the processes is a weak argument for a senior software engineer.
Nevertheless, every situation is unique, and the approach should be tailored accordingly.
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.
Hello Anonymous. I think we’re talking about different things here. If a company goes bankrupt due to your mistake as a senior software engineer — that’s what I call an “unfixable” mistake — then there’s only going to be ONE accident, and there’s no process to fix.
I understand the sentiment behind distinguishing between malicious intent and genuine mistakes. It’s worth noting that not all accidents are solely due to process flaws — most of those that ARE — can be easily fixed, and as I mention in the article those are not as bad as the “unfixable” mistakes.
Everyone makes fixable mistakes from which they can learn.
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.
Hello Steve, I disagree with that statement. If a captain of a ship crashes the vessel into the docks due to a mistake on their part, they will be fired. If people die during this mistake, there will also be prosecution.
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.
Hello Grabe, so what you’re saying — The manager CAN get fired for mistakes in the area that they’re responsible for, but software engineers cannot?
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.
I partially agree with your statement. But taking from your comment you think only managers are allowed to be fired for mistakes, as they’re “ultimately responsible” for procedures?
In the article, we’re discussing mostly software engineers. Senior Software Engineers, as well as Managers, should be able to accept responsibility and be held accountable without pointing fingers (both ways) “I made a mistake because the manager did not set up proper processes” or “I made a mistake because the developer did their job improperly”.
Just to be clear, I’m not saying people should get fired left and right, what I am saying is there’s a level of mistake (unfixable/unrecoverable from) e.g. Captain crashing a ship (where the Captain is the Software Engineer) that should have at least some disciplinary feedback. I think my statement regarding the “unfixable” mistakes has been blown out of proportion.
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?
I’d agree with this. The level of failure that sinks a company or kills people is the failure of a system and not the failure of an individual. If it is possible for a single engineer of whatever seniority you want to take down a company or kill people without any oversight, then that is a catastrophic failure of process. The accountability in these sorts of scenarios rightly sits with management and it is likely to attach to a quite senior level.
Accountability matters for individual contributors and gross misconduct definitely exists. But I can’t think of a one time mistake that would lead to firing without some level of malice or intent. Deliberately deploying something that you’d been told not to? Or deliberately nuking an important DB. It’s that sort of level.
I find it far more common that people absolutely beat themselves up over mistakes. When you peel it back, whatever the original mistake, there have been half a dozen opportunities to correct that we’ve either ignored or worse doubled down on. If people adopt the mindset that “we succeed or fail as a team” they are much more likely to have people’s backs and question things.
That is a completely illegitimate analogy, as 99.999999999999% of “mistakes” that you would consider firing someone for do not have that impact.
Why do you say that? That’s exactly the level of mistake I meant in the comments and the article itself. If you can point to the place in the article that is confusing or wrong, I would much appreciate it, I would like to improve the article.
> 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?
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.
https://max.levch.in/post/724289457144070144/shamir-secret-sharing-its-3am-paul-the-head-of
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.
“The Pessimist” might be a better name than “Negative Nancy”
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
Hi Anonymous. I’m not sure if you read the whole post, but I’m still going to leave your comment here.
I did not mention any college hire who has access to prod and I would also not fire them for it if that happened.
I have changed the wording, as it was not intended to be understood that way.
That’s what I wrote about in the second part of the post.
I have changed the word deviant to “atypical”, as I’d like to emphasize that some people require more effort.
Yes, I have included this strategy in the section about the over-promiser.
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.
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.
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.
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 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.
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.
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.
Good input, thank you
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.
Thanks for the feedback! I will add it to the article
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.
Hello, thank you for the feedback. I mentioned in the article that the difficult engineers account for at most 10% of the developers you meet, so I’m not sure how you concluded that I’m a hammer and everyone is bad.
NVC was included without any modification to the original ideas, and I’m also not saying that it’s a tool to get my way while pretending to be nice. Can you point where it say that in the article, so I can improve it?
The 10% looks really precise like URA and PIP quotas.
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.
Great writeup!
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.
Hey Catalin, thanks for sharing your experience! I agree cultivating the right support environment is really helpful to making sure the employee feels understood and can thrive.
Hello Vadim,
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 see myself in every bad engineer described here, should take a rest?
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.
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…)
Continuation:
(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.
Continuation:
(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.
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
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.
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.
3.6, 3.8, and 3.12
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.
It’s sad that there is no like/dislike button and ordering by it, because not all comments are created equal .-.
I’ll see if I can add upvoting/downvoting comments in the future 🙂 thanks for the suggestion.
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.
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.
Very insightful, thanks you
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!
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.
Thanks Vadim for a good article, which mostly resonated for me. Don’t be put off by some of the hyperbolic responses!
When I first stepped into a team lead role, I had to learn to deal with a variety of engineering attitudes. One approach that halped me was initiating candid weekly one-on-ones. Surprisingly, this open line of communication led to uncovering hidden team friction and misaligned project expectations.
Well you really kicked the hornets nest with this one.
I’ve been in most of these categories listed in your article.
I’m currently a lone wolf/silent type after graduating from the know it all.
im new to a company. I went through the first 2 months listening to the rah rah chants of pair-programming. An activity that nobody did. People would disappear and turn up 2-3 days later after ignoring DMs on slack with a PR to ask you to sign off on it. On stand ups…. the pairing mantra is still trumpeted loud and proud for all to hear.
I would gladly call these rag tag individuals as amateurs. The code I have seen has been tragic.
Of course when you propose a better solution you are shut down…. because…. the know-it-all thing.
I have been asked to toe the line. The problem is that I heard from one of the POs that they had backend developers that let them down. The devs I work with just wave bad code through.
One of them refuses to write docs forcing all to reach out to him for help.
Is there a section for the games-player type?
The project is a greenfield project that already is grinding under the yoke of incompetence. Theres a lot of complicity in just writing code that; when it fails; we need to spend more time fixing. New features take more time because previous code has been over-engineered or is just dirt.
I always wonder about the IQ of management. When they hear 9 out of 10 people in the group agree, doesn’t make the solution right. I think some things are problematic.
If you care, you get shut down. Now I don’t care and I am happier. There is currently a feature backlog.
The problem with backlogs is that sometimes teams end up making problems that they need to eventually fix.
In my team, there’s a lot of games players. I just chose to not play.
I think your article is flawed. The know it all gives their opinion because they care. If they didnt then they would just keep their mouth shut.
The biggest flaw I have with your article is that I always ask myself; these people that I work with, why didn’t anybody speak up? said that this may not be the right way? Is it to keep group cohesion? Make sure to not be labelled as one of the above?
Its an interesting article but maybe theres a lot of quarter backing.
As someone on the ground, if someone is playing with fire… it is incumbent on someone to be brave enough to slap the sugar out of them.
footnote: I’m a team player now… I do my tickets and STFU
I have the same problem right now.
First software company I worked at, was using C#, SQL and Powershell. I was a know it all but I quickly realised I knew little when paired with, at first which was a grating experience, but now I consider one of the best engineers I ever worked with. There he taught me IoC, dependency injection, separation of concerns, you name it, he taught me loads of ways that enterprise software should be written so it can be tested.
After that I moved onto python, my first python job had very similar styles of IoC and DI.
However after brexit that all ended, but I got another python job… But due to the allowances it gives, you can get some pretty bad code.
My current job I’m faced with a colleague who thinks manual patching by string references of imports is better than pytest fixtures, using dicts and not using pydantic is better for data input and formatting because it’s “faster” (premature op), doesn’t comment anything, refuses to refactor functions and make them unit testable, doesn’t understand dependency injection or IoC, wants to throw parallelism at every problem instead where async would be more appropriate, global references to a single logger, and workarounds to parallelising because of the global logger reference. When you bring any of this up you are met with hostility. Any attempt to sanitise new repos with a better structure has failed to win over the team because they’re so used to the same broken copy pasta code instead of learning new and better techniques.
Anyway, that project has failed once before by the team that came before this one due to underlying perf issues, and I suspect this one will fail too due to the use of http as a messaging system between microservices… Probably performance issues somewhere down the line or some problem with debugging the entire mess.
It’s a far cry from the techniques I learnt to love and realise we’re powerful.
“agitator”, you are right my fellow. You will be labeled as a problematic know-it-all for caring and trying to make the project and product better. Their mediocrity triggers narcissistic wounds when faced with someone who knows better and has good intentions. The best solution is to know if the team deserves your energy, most don’t.
The problem is managers. They are obsessed with deadlines. A lot of good engineers are procrastinators. Having to do daily updates is a productivity and morale killer. If you just give a great procrastinator clear direction and remind them to work in that direction sometimes, they will both accomplish a lot in that project. As well as in others they work on while they are procrastinating.
I would fit best into “lone wolf”, but I think its only because my manager is terrible. He doesn’t value my ideas or suggestions, makes me feel unimportant. I think his ideas/objections are either rooted in ego or ignorance, so I find it best to just start writing stuff on my own. They rarely find bugs in my code, so who am I hurting? I don’t mean to be an asshole, but my manager is difficult to deal with. I would do much better in an environment where everyone is made to feel respected & valued. The management is pretty openly abusive, I don’t think being a “lone wolf” is my fault in this situation.