Managing difficult software engineers
vadimkravcenko.com
vadimkravcenko.com
Rather I find that people develop workplace behaviors that are rational responses to what they can see from their vantage point, and most of the time they have the organization's interests at heart, as well as their own, just as managers do. For example, sometimes, engineers procrastinate on releases and deliverables because they intuit negative consequences that will impact them more than others, once the release happens.
When workers are entrenched in workplace behaviors that are not aligned with the needs of the org as a whole, I believe it is important to start from a position that they have a good reason for behaving as they do. Then we walk them on the path from how they behave now, to how we agree they need to perform, by establishing a current routine that over time, shifts into a routine that is mutually aligned. It's a two way street of learning, where also bottom-up issues are addressed along the way, and incorporated into how the team functions as a whole.
Low-competence managers like to oversimplify the work of getting stuff done, because they want to feel like they have the answers, but in a serious endeavor that has domain experts in the team, insight-discovery does not happen primarily top-down.
Programmers and mathematicians train to be “the utmost correct” and everyone thinks they figured it out. On this quest for hyper-optimization, hyper-correctness, and so on, EVERYONE has become ridiculous.
You’ll be accountable for team deadlines regardless - would you rather be allowed to sail over a deadline you didn’t know existed and be reprimanded for it by higher ups, or have a clear picture of deadlines and someone checking up on progress?
I said I was going to do it for the following (rather good!) reasons.
It is around that time when I am usually informed that I have zero autonomy over such decisions.
Now I know.
If I am not allowed any autonomy then could you please be explicit and upfront with all the trade-offs I am allowed to make, all the risks I am allowed to accept and the technical debts I am allowed to accrue?
Oh, don't be a perfectionist! I am not - I have no autonomy on such decisions. Here's a list of known defects - tell me which ones I am allowed to ignore.
Аpparently I am a difficult enginer. Meanwhile the leadership is outstanding.
A competent professional understands from context the amount of time available, the absolute requirements of the role (ie regulatory compliance, internal engineering practices, whatever), and their own sense of "would I put my name on this crap" and then says a number.
If you hire a plumber he doesn't ask you if you give him 2 days or 2 weeks or if he should use copper or plastic or if he should bring his good tools or his bad tools. He just gives you a reasonable estimate and does a reasonable job. If he is asked for better, he knows how to make it more robust by spending a little more time or using better materials, the same way you should know to make it scale up to more users or spend time refactoring into some better abstractions. But there is a bar that he won't go under and no amount of company policy or explicit bosses are gonna fix the fact that at the end of the day, it's a professional's job to predict how they are going to go about their work and how long they think it'll take.
And the variance in effort due to lack of standardization, technical intricacy and hidden complexity is orders of magnitude greater than plumbing so our initial estimates always suck. Most competent proffessional in this insdustry know that nobody knows how to do accurate time estimates on delivering complex software projects, so why don't you know this and why do you want me to lie to you about the crudeness of my estimates?
Frankly, I've worked with hundreds of managers too and you sound difficult to work with. You seem to have unreasonable expectations that are impossible to manage with facts.
Your trivialization of the complexity is laughable.
The tools are "standard". The data models aren’t.
It's like plumbing alright. With random, unknown substances in the pipes.
Software industry estimates are way off the mark compared to plumbing industry estimates.
People who don’t like this fact refuse to understand why software isn’t like plumbing.
Anyway thanks for the advice on how it came across, I struggle with how to give this sort of view on things without coming across judgemental and I guess I failed here again, but I was honestly trying to say that I've seen your view shared before and I think the difference between you and other engineers that tend to be easier to work with isn't skills, it's just a slight difference in approach. But there's many different dystopian teams with unreasonable expectations for me to say that I'd think any different had I had the same teams and bosses that you had. Take care!
I relate with this. Any skilled engineer worth their salt know that there are going to be a lot of unknown unknowns. Slippage is 99% guaranteed.
What surprises me is that managers are surprised at slippages. Like, did they ever engineer anything in the past?
> If I am not allowed any autonomy then could you please be explicit and upfront with all the trade-offs I am allowed to make, all the risks I am allowed to accept and the technical debts I am allowed to accrue?
This question is the one that irks managers. Because in reality, they want to be "own" only the successful decisions, not the failures. And they dare not ever clarify anything because it may end up leading to a failure. BUT, they also want to penalize you for the failure.
Managers are the biggest cop out there are.
Difficult engineers are difficult because they're difficult just like a difficult sales executive is difficult because they're difficult. I've worked in great companies and terrible companies with great people and difficult people. The reason difficult people don't survive as long at good companies is because the organization has the breathing room to get rid of them, whereas in a chaotic mismanaged organization there's still a framing in which a difficult engineer is valuable -- because mismanaged organizations aren't considering the long term implications of difficult employees, they're focused on answering "can this person help put out our current fire?".
Difficult engineers are given far too much room to be difficult because we're seen as geniuses who just need tending to. We should show employees kindness and support them in doing their best work and growing to benefit the organization, but we should not try to fix difficult people. If you're a manager dealing with a difficult engineer, you can be sure every one of their co-workers hates them and is making their life worse.
Terminate your difficult employees, don't change the number of points allocated to a sprint.
Difficult managers need to be terminated as well.
Amazing how a few bad senior managers can allow for so much bad behavior.
Yep. They set the tone. And if the manager's tone is not one of honesty, the ICs will intuitively not continue to be honest. Because they intuitively know that honesty will get penalized.
I feel like this is overstated. Yes, ultimstely the job is just a job and most people have other things in their life. However its hard to devote 40-ish hours a week to some cause without starting to identify with the cause. In my experience most people do start to care about org goals, or they go crazy and get burned out spending so much time on goals they dont care about.
It absolutely sucks if you want to do good work and that doesn't align with company goals or doesn't get you paid (since most people need money). Those three things are not always reconcilable and I have seen how people can break if this creates an area of tension.
It's particularly bad if you otherwise love your coworkers, your immediate manager, and what the company does enough to stick around indefinitely, but come find you're never actually allowed the opportunity to "do the right thing", because there's instead just always something else more pressing pushed on you. You'll never get the chance to fix the big problems that you see solutions to. You realize that for everything else you appreciate about your position, you're still just a cog in the machine. Then you feel depressed and slip into some negative developer stereotype.
Why does fulfilling your contracted role not align with the "interests" of the organization?
If by "interests" you mean giving more than what you were contracted to do, then that does qualify as a dysfunctional organization in my book.
The list goes on, but the bottom line is that many folks will be happy to optimize for their personal "local minima" but literally harm the organization in the process.
If the reviewers and QA folks are doing their job, nothing like what you're describing should get through, and true "problem" engineers are simply those who are never able to get something through.
When this falls apart it is invariably leadership's fault for writing bad tickets or not implementing proper CI, quality control, or testing practices, or not allocating sufficient time and resources to the code review process.
And this stuff is only becoming more important as we integrate LLMs into our workflows...
Other problems, like dishonesty, not doing enough work, not appearing to level up, honestly all come back to comp/benefits/company-culture. I genuinely believe that a good manager with sufficient resources can get good engineering work out of literally anyone, given sufficient time and (possibly quite high) resources.
And sometimes, the employees that require the highest investment in that regard can have a very high return when they finally do level up. In fact, I find that a really good predictor of success is simply ambition to level up. I care about that much more than I care about raw skill at the time of hiring.
Do I own the org? If I produce 5x more, do I get rewarded 5x more? What about the other way around: will the org work "for my benefit" every step of the way?
Folks, most people work where they work because they have to. You work or you starve, that's the deal society gives us.
So many clueless managers buy into this crap and go on to become horrible managers "for the benefit of the org".
This phrase is completely nonsensical because it implies that the employee, that has no real stake in the company (no, stock options don't count), should be altruistic and work in the benefit of the organization above his own interests. I say above his own interests because if the interests of the organization and the individual's were aligned, this would be a non-issue.
The reality is that the absolute majority of organizations don't want to fix their incentives because it's cheaper and easier to label people "difficult employees" and fire them. After all, we're all replaceable.
Anecdotal but I've never come across someone that was actively trying to harm their employers. Even the ones labelled "difficult". It was always about bad incentives from the organization.
This is also why I believe after many many failed iterations and variations of capitalism, we will arrive at worker-owned co-ops winning in the end. It is the only way to truly align interests while still working within this ridiculous capitalist framework.
The fun part is the union leader becomes the CEO, gets elected, etc.
If you wanna tout around "professionalism", at least explain to all of us what that entails in your world view. Because, for me, someone that does what they're paid to do is professional with or without a blind sense of loyalty to "the organization".
You're talking about a platonic ideal that rarely ever occurs in real life, except for very simple systems.
When short term gains outweigh long term gains, short sighted decisions will be favored.
When nobody really cares about quality, people ship sloppy code. See the broken window parable.
When rewards are given for shipping fast and not thinking about the whole picture, teams will ship without caring about other teams.
I acknowledge there are outliers that really do not give a f***, but those are rare. Personally I have yet to find a real "difficult engineer" in all my 15+ years in software. What I have found were dysfunctional organizations and managers that set the wrong incentives then fail to comprehend the ramifications.
Yes, because doing exactly what you're supposed to, exactly how its asked, and then clocking out "harms" the organization. No one has passion for your CRUD app for dogs. Everyone wants to make money, go home, and live their lives.
Maybe the managers should write better specs that capture the company vision instead of this dysfunctional bullshit we call agile. Agile creates the drive to the local minima. I don't care about anything happening outside my bubble and have been gainfully employed for decades now. In fact, everything you said can be solved by BETTER MANAGEMENT:
> Sloppy code that barely meets the requirements.
Not the developer's problem. Give me 2 sprint points and shitty specs you get what you wrote. I'm a squeaky wheel. In every company I've worked at I learn to shut up because asking for sprint points to double to in order to insure good, clean, testable code (not "perfect code") is looked at with ire because, allegedly, developers are just people who want "perfect everything" and without "proper management" they will end up rewriting the entire operating system every ticket. The result is garbage in garbage out. Give me a day to finish a ticket with tests and you're going to get a rock bottom solution designed to fit the exact use case, no more, no less. No matter how many "I told you so's" I give I've never been able to get a manager to understand why the alarms going off are related to their shitty decisions months prior.
> Zero coordination on a release that clearly left another team scrambling because it placed significant load on their service/ introduced a disruptive user story/ broke or delayed another team's clearly announced pending release
Sounds like the management should be coordinating releases between teams because they have a broader perspective on the ecosystem. You know, MANAGING the systems.
Your entire post reeks of the entitlement of an all-smiles CEO that uses the word "family" as a comma.
Of course there are cases where the company can influence a certain type of behavior, but I've seen several of these stereotypes in companies which definitely did not "cause" it. Pretty much everyone can be difficult now and then, but there are definitely quite a few chronic cases out there.
The fact is these people exist - and they can derail a high-performing team. Some, such as the Lone Wolfe, are particularly toxic to a team. Most of the others the team is able to recognize and work around them. The Lone Wolfe? Management must deal with them. They're the most destructive individuals.
Developers and management both need the opportunity to try new things and make mistakes.
Being the voice of wisdom doesn't necessarily mean being the force of wisdom.
I haven't done any code reviews for the past 15 years. Why? They're a complete waste of time. I follow the "show me, don't tell me" mantra. Show me evidence your code works. That evidence is in the form of repeatable tests. I'm going to review the quality of your tests - did you test the so-called "blue sky" case and a few of the most obvious error cases? Cool. People are stunned when I don't even look at their code. I don't need to.
Does this bite the team in the ass every now and then? Sure, but not as often as you think. When it does it's a teachable moment. I now have a younger engineer wanting to be mentored by the old gray-haired guy how they can improve. I always tell them there's no single best or right answer - engineering is all about trade-offs. I teach them how to recognize those trade-offs and how to evaluate them. As time goes on they come to me while they've evaluating the trade-offs and I can help them work through it. This is far better than any code review checking for style conventions. Besides which, architecture and design matter far more than any silly code style conventions.
A huge pet peeve of mine: I ask a really difficult question that might be impossible to answer, then someone interprets it as needing ANY answer (rather than a correct answer) and they just start talking. Or they answer the surface level question but don’t understand how much deeper it goes.
Then if you respond to them to clarify they didn’t answer your question they either try again or seem wounded/hurt/offended when what I want them to come with curiosity and ask enough questions to make sure they understand the full scope of the question.
In the book Multipliers one of the things they say is that managers should be responsible for asking the right questions (rather than thinking they need to have the answers).
That's pretty much the gist of this shortie: https://littlegreenviper.com/miscellany/problems-and-solutio...
> Difficult engineers are difficult because they’re difficult
It’s a statement with no information. Just a declaration on an intellectual map that says I don’t go past here.
"I use the term "difficult" to differentiate between those employees where everything is going smoothly, and those where more effort is required."
... apparently "difficult" software engineers are those that might require the manager to do ANY WORK AT ALL.
Seriously, if this is anything to go by, managers of non-difficult software engineers could be replaced by a cardboard cut-out ... which would be a major cost saving.
It's funny how many HN comments fit this mold. Which actually makes this site very entertainig, because there's not that many other sites where you can hear utterly deranged opinions about things you know about :D
I have experienced myself being one of each type of "difficult" software engineer during my career. Not every day, not every month, but from time to time. Sometimes because of the environment (e.g., type of company I worked for), sometimes because of internal issues (e.g., family issues), and sometimes because I really felt like that (e.g., when I was in my mid 20s).
I haven't met any engineer who's never shown any traits of the thirteen "personas" listed in the post. If you're looking for an engineer that has zero traits like the ones listed above, you are perhaps looking for a robot.
Perhaps what's special for Software Engineers is that it's a profession with a skew towards younger workers, so you might see larger groups of people who are still emotionally immature, and thus displaying these traits, than in other industries.
Lone Wolf?
Not the other way around?
It is very weird to be in a situation where (for example) we’re working on a project in python and one person refuses to use python. Weird enough that I’ve never seen anyone with a personal tech stack, most people just try to adopt the local custom of the team they’re hired into.
Why should I care about the teams’ other tech stacks (and vice versa)?
Relatable. I'd love to talk to them about my private Rust projects.
> You can blame the company for making these teams up (I did/do), but that how things are.
But... how did this work out in practice? There's a software project in language X, framework Y, domain Z, which everyone was familiar with, and you were brought in not knowing X and Y? That's like hiring for a Java position where the applicant couldn't care less for that the language. Strange.
Current job, I was hired in a team of macOS devs for a macOS product. Several reorgs, mergers and downsizing, my old team is basically gone, and I find myself in a team of web devs and backend engineers.
I do miss having people around who can keep up a conversation in my tech niche.
A good example from a recent gig: one of our scientists had a HUGE pile very complicated MATLAB, based on several dissertations worth of novel work on both numerical analysis and highly domain-specific mathematical modeling.
Our software engineers needed to either call into or directly use the MATLAB code. Sometimes changes were necessary. This caused a ton of friction for two reasons. First, our SWEs didn't know much MATLAB. Second, you'd have to read two or three papers of complicated mathematics to even understand what the code was doing prior to changing it, and most of our software engineers topped out with Calculus or maybe a Linear Algebra course. So our engineers were unfamiliar with both the tech stack and also the "knowledge" stack.
In that case, I think it's more accurate to say that the software engineers were unfamiliar with the scientist's tech stack than the other way around. There's no way in hell them or anyone else was going to come anywhere close to correctly rewriting the MATLAB code in any reasonable amount of time. And even if you could, the knowledge stack problem still exists.
You can think of hiring those types of scientists as one-man startups that are bringing in their own tech stack and debt that your existing org has no idea how to integrate. You need to plan that reality into both compensation amount and vesting/earning scheduling.
For compensation, err on the side of "way over asking", since this is going to suck harder than the scientist thinks. They are probably going to want to leave, and you need to be able to get them to stick around. (The dynamics here are similar to a startup founder or exec after a merger, but with slight difference: the scientist's "FU money" is a pretty much guaranteed cushy professor of practice gig.)
For vesting, err on the side of paying out bonuses or RSUs early but with a big vesting cliff 2-4 years out. So they get the cash before it vests. Get 'em hooked and don't let 'em leave until the work is caught.
And definitely bank on them leaving once the first cliff is hit.
I think what's most important is to be aware. If traits aren't too pronounced, betterment is possible, and awareness helps eventually taming them. There's no need to eradicate: as you put it, the end game of that is a robot.
>"you are perhaps looking for a robot."
It's clear from the definition...
I use the term "difficult" to differentiate between those employees where everything is going smoothly, and those where more effort is required.
It's just humans that constantly misunderstand my managerial instructions.
To people who also see themselves here, but weren't fortunate enough to be working with a smart and compassionate manager:
- Listen to the feedback from your peers. Go have after-work beers if a more formal setting doesn't work.
- Figure out if you can move horizontally within your org, to a position where either your flaws won't be getting as much in your or someone else's way, or - if you're brave - to a less comfortable position, where you need to face and fix them.
- Show the article to your manager! Understanding is an acquired thing.
Ah yes, the LLM persona: the Hallucinator.
I’ve worked on a code base where someone implemented the core data structure as a tree instead of a simpler data structure. It was completely unnecessary for performance and killed productivity on the project.
I was tasked of enabling us to backtrack on our decision of building a microservice rather than a library. The service was using postgres, and was connected to multiple website, one of which was targeted to use the service as a library. The challenge lied in the fact we used JSON to store some metadata as a shallow tree of depth 2-3, and the targeted website used mysql (which did not support JSON data at the time). Concretely it required to introduce edits in more than 300 files and manually take care of parsing a couple datetimes. Maybe there were other gotchas I have forgotten but it was hard enough with respect to the test suite I decided to write an ORM adapter to add support for json in mysql (dump it as a string, retrieve it, parse the string as native datastructures, walk the tree to convert datetime strings). I know this sounds crude, but it was enough for these tiny JSON data we only looked at when investigating problems at the command line. I took the steps to isolate this adapter as an independent library so that we could take the same decision of transforming the microservice as a library dependency on other websites we maintained ... basically at the cost of adding a library dependency in the project config.
After a code review that astutely pointed out my adapter ran at every loading of an object from the database (which I corrected by running it lazily upon accessing specific fields), it was decided my code was a gas factory and the CTO proceeded to do the right thing, get rid of that perky – but working and ready to go in production ! – library (took me 2 days to write) and just update the damn code. 3 days later he still wasn't finished with the 300 files edits, and he ended up abandoning and splitting the library in two. One would be used by the microservice, and the other as a library on the website. He traded treewalking our datastructures with treewalking our codebases, program efficiency with programmers efficiency (we were 15 on the team while our competitors had 50 devs). This way any modification brought to that service/library: - is not transferred to the other version, leading to organizational complexity - is transferred and the time it takes to dev a features is multiplied by a number between 1 and 2. - or there are complex surprises under the surface and this factor is greater than 2.
I'm always surprised when people think that other people actually fit into a box while obviously seeing that themselves could fit into many boxes at different times.
People are more or less of one thing or another and the loadings change over time and depending on circumstances. The goal is not to build a set of discrete categories but to build a vector space of sorts.
There's only the particular behaviour that's getting in your way within a given context.
The bug you have to patch to make me line up with your expectations.
What the author describes as "procrastination" (focusing on less important tasks while ignoring the critical ones.) in one context is "attention to detail" in another.
Given that we are a complex multitude of principle components the single principle component in focus and of interest to a manager is that which the manager has (mis?)identified as the minimum viable change in behaviour necessary to get the employee back on track. They've already done the analysis - the employee's behaviour is the problem now all the manager just has to correct it.
Even if the behaviour is intentional and rational given the employee's (mis?)understanding of the situation; or a systemic organizational failure of sorts.
But hey, pointing out systemic issues which are making it difficult to deliver in accordance with expectations is confirming what the manager already believes - that the engineer is difficult to manage.
It would be so much easier if the engineer just shuts up and does what they are told... All these strong opinons aren't necessary from people with zero autonomy.
The Big Five personality traits (openness to experience, conscientiousness, extraversion, agreeableness, and neuroticism) actually have empirical data supporting them. Unless someone has done similar research on engineering personality types, we're basically talking astrology and horoscopes.
That's just https://en.m.wikipedia.org/wiki/Fundamental_attribution_erro..., isn't it?
All models are wrong, some are useful.
But the classification instinct is strong in some people, which is how we end up with systems like MBTI and, worse, why people buy into them.
While I think that the author could have done a better job at humanizing the engineers, I think the post in general offers some quite reasonable suggestions on how to help the engineers help themselves (rather than traditional micromanagement suggestions).
In particular, I've seen people (and been that person myself) who gets really negative because impossible deadlines get set by non-technical people with no bearing for the reality of the situation on the ground. I've also seen a lot of people give up on arguing with those non-technical people about scope and time, say "OK", roll their eyes, and know they'll miss the deadline before it even starts.
I had a manager who pretended they could manage our product-consultancy team the same way they managed their previous research-code-monkey team. They had trouble because of their inability to do much besides say "replicate this paper". To them I probably looked like all of these archetypal "difficult engineers" at various times. From my perspective I wasn't getting the pay nor the time and respect from higher-ups to go through the hard slog of managing up, but I was getting paid enough to stick around, so I just ended up burning out super hard.
I guess my point is, sometimes managing others starts with managing yourself. This insight extends far beyond the context of a day job.
> I've also seen a lot of people give up on arguing with those non-technical people about scope and time, say "OK"
I understand why this happens, and it is extremely frustrating; consequently, this is why I really dislike the trend of complaining on social media about issues because at least with my company, this is an almost guaranteed way to ensure that a C-Level will "step in to correct this", which in fact just means that now the company needs to do what the C-Level said so the C-Level doesn't look stupid in public, even if the thing to do is absolutely disastrous.
The best advice I can give if you're in a technical leadership position and you know this kind of thing happens in your org is:
1. Figure out who these non-technical persons with the ability to make said bad calls actually are in your company; do a process review on the last few events that triggered poor decision processes and find out from whom those decisions actually came from
2. Understand how that person processes information, how they're getting alerted, and most importantly, just get to understand them and what makes them "tick." (e.g., one of our lead PMs, usually a very good PM, unfortunately has a huge ego. Arguing with them in any public fashion causes them to get very defensive out of fear of looking "stupid"; a quick chat with them in private usually is enough to convince them of their mistake, and then we get more reasonable reactions)
3. Become professionally friendly with the common reporters of the issues that usually prompt bad decisions; if a particular sales team is finding actual issues but representing them in a way that results in rushed/poor decisions, teach them another place to report the issues so that more necessary stakeholders are able to view the issue before it gets to the decision process
4. Develop strong and strict change management processes that will protect from the issues; don't attach these processes to specific incidents, but instead present it neutrally as a best practice in change management, and then use the process to protect against such rash changes. The first few times upholding the process might be rough, but just remind people why the process exists, that the goal isn't to stop all decisions, but instead to ensure you are properly vetting decisions on core elements
Implementing this is difficult, especially in orgs with poor discipline and process control already, but from experience with such orgs, most persons will pay lip-service to the initial neutral presentation, and won't realize that the bad behaviors they have which the process is meant to stop will be impacted. The goal here isn't to be dishonest with people, but instead to introduce a process-based prevention in a palatable way which makes future discussions easier as they'll carry a common point of agreement. At least with the C-Levels I've had to deal with, it was effective because they didn't want to look stupid in front of other C-Levels and higher management who were telling the C-Level "this breaks our internal processes, we need to review this first as last time we rushed decisions without the stakeholder input, we ended up with huge costs". It doesn't stop every C-Level, but it has greatly reduced the number of meetings I've had to have where I have to give "Explain it like I'm 5" presentations to non-technical decision makers to prevent disastrous decisions/changes.
Edit/Addendum: I am well aware that the "real" solution is that decision makers just stop making drastic and ridiculous decisions/promises, but I don't think it's reasonable to expect to change personalities/poor thinking skills in a person, much less to force changes of management. Instead, I'd rather just use process to enforce this and deal with the occasional raised voices.
Also Edit: fixed numbered list formatting.
Early in my career I remember had a manager that brought it up to me in a 1-2-1 that I was "the negative nancy", which I found strange because I strive to be honest and try to do what is best for the projects I am working on, I never thought of myself as someone like that.
I didn't change despite getting those comment, and it kept being brought up in my 1-2-1. I was producing beyond my expectations so nothing was formally written down. It was just the impression.
After a while my manager moved on and a new manager stepped in.
And from then on in my following 1-2-1 I was getting feedback contrary to my usual feedback. Now I got told that I was a very positive(!) and valuable member of the team making a positive impact.
You yourself rarely change, but the first impression you give away combined with your managers capabilities and characteristics can very much color how other perceive you.
Managers need to stop using words such as difficult and use their tools and skills to do their job and work with understanding and resolving challenges.
To use a malapropism: impressions are 9/10ths of the law. If you give your manager an impression that you are one of these stereotypes, you’ll never shake it. You’ll always be seen that way.
And because people rarely change, or at least it takes a while, the only real way to escape such an impression is to find a different manager.
But supporting people is the manager's job. You can't do that if you pathologize literally everything messy or nuanced.
Some of these categories are people learning to estimate for the first time, or responding to pressure to say "yes" to impossible things by saying "yes" to impossible things. Also notably absent is any mention of air cover. There's usually a reason people get burned out or start sounding the alarm about a project. But rather than get to the bottom of that and help with the root causes, in every single of one of these cases he assumes the problem is basically their personalities.
Programmers find themselves in the position of "managing" the most difficult possible sort of subordinate - the computer itself. It doesn't care what you want. It doesn't care about your deadlines. It does _exactly_ what you told it to do, and if you told it the wrong thing, it will do that anyway and it's entirely your problem to figure out which part was wrong.
No "people manager" could put up with such an obstinate employee, but doing so is literally our job description, and occasionally we have to report back up that we still haven't figured out why the computer is being "difficult" - and then we get blamed for that difficulty.
Some managers just feel the need to criticize _something_, and when you're killing it, they can always be critical of something nebulous like "you're not enough of a cheerleader". It's not quantified in any objective manner, no jira ticket counts, no commit counts, there's no limit to how much more positivity one can ask for. It's equivalent to asking you to smile more, this manager belongs in a Starbucks.
I'm reminded of [0], "you're doing great, but let's just do it with more energy, alright?"
If the software engineers were left to actually do engineering instead of also having to spend half their day silently picking up the slack for these figureheads, maybe shit would actually get done.
My fears were correct, as it has been steadily going downhill from an engineering perspective. But hey, line goes up and to the right so it must be a great idea.
> they lack commitment, discipline, or time management skills
They could also need time or space or latitude to resolve something that’s going on. When you have someone who is a high performer one year and a poor one the next, often something is going on that isn’t any of the offered reasons. Offering leave, a lessened workload, or something a little more human centric is a way to invest that person in working with you - browbeating and adding pressure doesn’t always work.
Talking about the general population, sure. But we're talking about software engineers, the most highly paid while at the same time the most accessible profession of all time.
There are high school dropouts making 5 times the national average wage in SWE, and that's not unusual at all - you have the ones making 10 times for the "unusual" category. A person that knows nothing can get a job that pays the national average wage in this industry.
I personally helped 7 people get from 0 to a job within a year. All of them are now (after 1-3 years of experience) making at least 5 times more than they did before they switched careers.
Collectively we can stop acting like every SSE in America is sipping champagne and eating caviar every day, because they really aren't.
> 5 times the national average wage in SWEE, and that's not unusual at all
In the US. Everywhere else, that's incredibly unusual. 5x the average wage in the UK is 150k plus - that's _very_ unusual.
Also, the average wage in the US is $75k. The "average case" engineer isn't making $375k with 10 years experience, nevermind with 1-3 years experience.
> A person that knows nothing can get a job that pays the national average wage in this industry.
This is nonsense.
I am in Europe and it's normal here. Maybe not the UK, I'm in continental. Looking at it in detail, high taxes seem to mess with this a lot. I'm in a very low taxed region (my full income tax + health and social insurance combined was 9% of my income last year).
> This is nonsense.
No, it's not. I've just helped a junior friend get a job that pays 1.5x the average wage, the only thing they know is the very basics of HTML.
I helped other friends too, those knew a little more (basic programming skills - variables, conditions, cycles) and immediately got 2x the average wage.
For individual full-time workers, it's $57,200[1].
In my experience, this would be the case for cca 20-25% of the people I work with. So yeah, definitely not average - but definitely not something you never see. Every team has few devs like that.
Expensive illness in the family, divorce, triplets, cost of living crisis, natural disasters, accidents, unexpected salary cuts.
People's expenses typically track income, if your income for whatever reason suddenly decreases, a lot of folks, even "rich" software engineers can easily be in financial trouble.
I'f I wanted to buy a house here I'd have to make a minimum of 3x my current salary despite being "well paid".
We're not all rich.
Very few Canadians actually want to live in an apartment, home ownership is the goal.
Canada's home ownership rate is currently 66.5%[1] which is higher than many countries, but it used to be higher.
https://www150.statcan.gc.ca/n1/daily-quotidien/220921/mc-b0...
Houses used to be cheap here (in the capital) as well and even I still remember that time, but we had to adapt to the new situation. My grandmother had a 200m^2 flat and that was normal; I have 100m^2 and am considered very rich, people in my age and family situation (2 people) usually live in 35-45m^2.
Of course everybody would love to own a whole house in the capital! It's like asking "who wants to be rich?" and being surprised that everybody does.
> home ownership is the goal.
We own the apartments, though (home ownership rate over 75%). You can't buy an apartment in Canada? Perhaps that'd be the first thing to fix...
I'd also like to #include SilverBirch's post, which has deep wisdom: https://news.ycombinator.com/item?id=37164426
It is never bad resource allocation, time management or toxic behavior in the workplace. The fault has to always be the individual.
The person is an interchangable robot or resource, where you simply push some buttons to magically "reset" it.
Then you are shocked when the problem arises again and in other people as well.
> Make them accountable for those deadlines.
I've seen this advice a lot, and it's a terrible approach. You've got a team member you already know has bad time management or bad prioritization skills, and/or busted estimates. You've already stuck them in the bucket so it's not your first rodeo.
You already know they're not just unmotivated, because you'd take a completely different approach otherwise.
That's were comes the interesting part: you're either punishing them for something they're motivated to do but aren't good at, and you couldn't find a way to help them the first few times (they still got late despite all the micro management you did).
Or you're punishing them for deadlines that you knew were busted but didn't adjust on your part, even as the whole project is affected by that decision. You should be the one accountable for that.
I'm not saying that for certain Lisa wasn't a lone wolf, all I'm saying is that diagnosing people into these categories may do more harm than good. And often the advice that's suggested is just absurd. Treat the people who work for you as people. Communicate with them, let them understand your expectations and when they aren't meeting them and work with them to fix problems where they exist. Most importantly, if you're part of a good team, let others lead, and learn from them and learn to work with them. Often the negative nancy is the person who will throw a thousand problems up the first time you talk to them, and the second time you talk to them they've got a neat solution on how to solve them all. That's fine - now you know, give them the space they need to work.
Oh and also? A PIP isn't a way to fix a problem. It's an HR tool to build the documentation up to fire an employee with the minimum risk of legal problems. It's a way to fire people 99.9% of the time, and you need to know that going in, because even if miraculously it works and the employee improves, you have put that employee on the short list for any layoff and that may well be totally out of your hands.
The general answer is: quit. That's where the saying "people don't leave bad jobs, they leave bad managers" comes from, there aren't a lot of great solutions for dealing with that power dynamic.
People, like software, have different things they are compatible with, and if you try to shove incompatible things together then these problems arise. The managerial response is overwhelmingly “the problem is the incompatibility” and not “the problem is with our organization”.
Team formation is a combinatorial exercise where the best person to have in a team is a function of the other team members. Accept this basic truth and all else follows.
A difficult employee is a failing manager. Either there is something wrong in the organization or the employee does not belong there and you need to fix it.
>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.
That's right - activate your empathy! Tell them to get lost for a while. Send them a link to a mindfulness video on YouTube. Whatever you do, don't actually engage any literature on burnout and certainly do NOT have a discussion with the burned out employee about their burnout.
Remember, your team members are your most valuable asset and their wellbeing is critical to your making money!
Seriously this is just a LinkedIn post taken too far. God help anyone working under this guy.
For me, this type of view only causes more harm than good. Instead of actually sitting down with the "difficult engineer" and figuring out what is happening, managers will label them as "X" and poison their view of them moving forward. Sometimes even publicly.
Good managers know you're dealing with people and you actually get to the bottom of what is happening on each situation. As others pointed out, there may be a reason you're the "lone wolf", "procrastinator" or any other of these simplistic labels at any given moment.
But the average manager just wants labels and recipes to follow, which this type of article provides. Then when reality hits and nobody perfectly fits those buckets and the recipes don't really work as expected, all we can hope is they realize how bad of a manager they've turned into.
To any managers reading: do your actual job and remember you're dealing with real people. Don't label everyone and follow magical recipes. That's how you become a bad manager.
Sometimes some of the developers who "get shit done" and ship on time are the most destructive of all. Creating huge inefficiency savings for relatively modest savings in the short term.
Spending an extra day thinking about the system you're writing when you know it's going to take weeks, before you write it, costs you a small %. The inevitable rewrite could take weeks.
90% of my time as a developer is unfucking previous kludges and weak designs
If there is any at all, it's probably the inverse. When I think back on all the projects that needed fixing, they were usually systems that were over-engineered the hell out of and that someone spent a lot of time "thinking about", where a much simpler solution would have sufficed.
I think part of the problem here is that (some) engineers (sometimes) spend the time "thinking about" the problem, and then think that their solution has to match time spent thinking in terms of complexity. And that time is often spent aimlessly "thinking about" the problem rather than understanding and breaking down the problem and doing structured engineering.
I agree that I've seen people build monstrous things full of pointless technical abstractions to do the simplest business requirement possible.
I've also seen people build the stupidest collection of logic into a maze of rules in one simple but massively long class to accomplish what is actually a trivial business problem that could have been clearly solved in 5 lines.
I would rather they spend a bit more time thinking about how the business problem and whether they are solving it appropriately.
I feel for "Unreliable Anna". Her mother is actually in hospital so she's stressed but trying to put a brave face on things. Her dickhead manager hasn't bothered to ask about her situation and is instead putting her through for a formal warning.
Meanwhile the whole team find Lone Wolf Lisa toxic as she undoes other people's work and should be shown the door since she's clearly not a good fit and this isn't the first time. Her team can't understand why she's kept around so get demotivated.
I could go on...
My understanding is that most research on procrastination suggests that it is not caused by poor time management but emotional management, and that the appearence of poor time management is more a symptom than a cause.
Content marketing is adding so much noise, muddying up the waters.
Also find it funny how a person who doesn't act and do stuff exactly how you want is considered "difficult".
We definitely need more "difficult" persons.. That is not a virtue by itself but ironically is the only thing that will save us from this depressing "corporate" bullshit.
"Managing difficult managers"
Of the list, it's the most relevant to me. Would a "shock therapy" work, where I force myself to treat all solutions superficially, only making things work without trying to understand and polish it all? If such a project is then successful, maybe that leaves a lasting, "healing" mental impression.
On the other hand, I have started to embrace it. It's a tough one to flip into a plus though, as it's a highly two-sided sword (other traits like charisma are useful without downsides, for example). For self-employment, startup founders etc., I suspect it's one of the worst blockers. For an IT forensics researcher, probably the opposite.
Any stories of how perfectionism turned out a winning trait?
Many, especially artists. But I would not take any solace from these exceptions because it hides the number of lives ruined by it.
> Can perfectionism be "cured"?
From my own perspective, there is no cure but you can prevent it blighting your life. Backsliding is always around the corner given a change in environment. The simplest solution is to work in an environment where the most crippling behaviours (extended procrastination, punishing rumination) are just not possible e.g. the type of work with non-negotiable external deadlines where you don't control "good enough". A solo startup developer it's probably the very worst environment and the best might something like a producer of live TV coverage.
I don't really consider it a "cure" but the way I manage my perfectionism (and holistic completionism) is to simply re-frame my goals to not meet perfect but to get as close to perfection as possible. As long as my actions get me closer to my goal, I am satisfied. It's a very brute-force and reduced version, but another way to say it is that if you want to go North, just never walk South and iterate in steps.
Also, I've basically eliminated failure from my personal language. Any task that doesn't achieve the desired result is simply a delay and I re-adjust immediately to find a new tactic that will put me back on track. If the time-effort to proceed isn't worth it, I dump the effort and change strategies. I long ago got rid of the idea that anything I create is special or worth saving. Outcomes are what matter. It's a very pragmatic approach and eliminates the perfection tendencies because it gets things done.
Yes, this is holding me back!
I have a bunch of stuff on GitHub, obsessing over every code comment, never to be read by anyone else. The few lines of code that are there are cared for meticulously. Yet these projects don't really DO much and therefore receive minimal attention.
Just the thought of these things being public "forever" is stifling.
If you are putting your energetic resource in a way not requested or required by the project, then you are wasting it. Or your incentives are not aligned or properly communicated.
How many times in commercial software, do you put all your heart into a thing and it gets promptly thrown into the garbage? All the time, in my experience.
Do what's barely good enough, and reasonably maintainable, and always focus on how your efforts translate into business income. That's a new definition of perfectionism that is universally valued.
I feel like I am extremely empathetic towards other engineer, as well as customers. I hate slow and buggy software as an end user. I don’t want other people to have to deal with it.
I also don’t want teammates to have to do things they aren’t good at, or interested in. A backend dev should not need to learn the many intricacies of InnoDB tuning; they just want the ORM to talk nicely to the DB. I on the other hand absolutely love tweaking low-level things like that. So far, the devs have also expressed joy and gratitude that I enjoy this stuff. I have to assume customers enjoy reduced latency.
So anyway, no, don’t focus purely on revenue. Focus on making people’s jobs easier and more pleasant, and on making customers happy. Revenue follows.
Disclaimer, not a business person nor any interest in it whatsoever.
I'd call myself a perfectionist in that I really want complete and correct solutions to problems and for everything to be "just so". What was crippling in my early career was that I wanted this level of perfection at every step of building.
I was fortunate to work with some really good engineers who convinced me that I couldn't make large things to a high standard by keeping them perfect at every stage. Instead I needed a "forward wave" of problems I was choosing to solve now, and a list of side problems that I'd slap a good enough solution on till I could come back. (there's a real art to ordering what goes into that wave, mastery of this skill implies seniority).
If you can then learn to understand when you can leave all the "good enough solutions" that really are good enough, you'll find you actually iterate quite quickly.
> "They will need to spend time thinking about ways to work around them rather than work with them."
managing expectations and simply not caring about most things are very under rated skills imo.
The only time I've seen someone that does NOT have these negative traits, seem to be typically very silent, or not outspoken.
I've worked with some pretty good engineers that didn't have these negative traits. But they also didn't drive decisions. They could competently do something given to them.
But it seems like to be pushing boundaries, or driving to a solution, someone necessarily has some of these negative traits.
"Why are you lying to me? What the hell is wrong with you?"
https://respectfulleadership.substack.com/p/a-true-story-sof...
"How to deal with weird passive-aggressive text communication from your co-workers or subordinates"
https://respectfulleadership.substack.com/p/how-to-deal-with...
"Is Anger Ever Strategic?"
https://respectfulleadership.substack.com/p/is-anger-ever-st...
You are recounting an argument that you are proud to have won, and where you are proud to have put a subordinate in his place. In your eyes, this is an example of good leadership because you did it in a way that was merely firm rather than, say, abusive.
You achieved behavioral compliance, which is definitely better than nothing, but genuinely good leadership in that situation would have involved more two-way communication, empathy and active listening to build a mutual understanding.
By the end of the article, I'm left with no understanding of what Jerry's motives were or why he behaved and communicated the way he did. You didn't seem to be interested in engaging him more deeply to find out. Instead, you seem exclusively focused on achieving your "I'm right, you're wrong" moment.
At points, you offer uncharitable speculation:
> Maybe he was feeling lazy or maybe he was trying to defend the code he'd written in the past.
Which to me raise more questions. Why is he feeling lazy? Why is he feeling defensive? These are certainly not things that people regularly experience in workplaces where they feel respected.
I did not feel your attitude in the situation, or recounting of it, was respectful to Jerry at all. At best, this interaction feels like a behavioral "quick fix" that falls short of identifying and fixing the underlying issues and risks long term resentment and disengagement.
1. Fully understood, respectful leadership means respect for everyone, not just the person I happen to be talking to right now. Aggressively pushing Jerry to be more honest in the future was, in part, how I demonstrated my respect for the Travel Deals Team and for Sonia. They were not in the room to defend themselves, but Jerry had disrespected them, so I needed to defend the importance of their work.
2. Some managers adopt a passive-aggressive style where they pretend there has been no conflict, even when there has been conflict. This passive-aggressive style does tremendous damage to an organization. Where there has been some kind of conflict, you need to address it directly. The commenter is suggesting that I should simply assume that Jerry was operating in good faith, even though I had some evidence that he was not. "Innocent until proven guilty" is a necessary legal standard to protect us from the overwhelming power of the government, but among private citizens if you assume someone is innocent and operating in good faith when you have evidence that they are not, then you are simply a sucker who is going to be easily manipulated by bad faith actors. Keep in mind, I spoke to Jerry in good faith during our first conversation, it was only in our final conversation that I assumed he had been operating in bad faith.
3. I encourage a democratic culture, but that means the people on my teams have to be honest with each other. No one doubted that Jerry was a talented engineer, but if he made changes secretly, or if he secretly ignored directions from the Travel Deals Team, then he was undermining our democratic process.
4. If you value a democratic process, then you must enforce compliance to that process. Failure to enforce compliance is not democratic or empowering or generous or liberal or kind or intelligent. A failure to defend your process is simply idiocy or cowardice. If you think your process is a bad one, then you have an obligation to change it, but once you’ve got a process that you think is a good one, then you need to enforce compliance to it, or you have no process, merely anarchy, and your company will not survive.
5. There is a time and a place for healthy debate regarding all of our decisions. Jerry was free to meet with people and make his opinions known. Of the people who report to me, no one has ever been punished for making a strong case for their ideas, even if their ideas disagree with what the majority of the team favors. But all such conversations have to be done in compliance with the overall process, and that process means that once a decision is made, we all stick with it. In other words, if you want to run a business in a democratic fashion, you need a strong dose of "democratic centralism." By contrast, anarchism is the enemy of group decisions.
6. Jerry's motivation was implied when he said “I don’t like the idea of showing deals for Bermuda when someone searches for Caribbean.” This suggests that his ego was so great that he was willing to defy the clear intent of the Travel Deals Team, while also ignoring the feedback he was getting from Sonia. He was using his control of the code to impose his will on the situation, in defiance of all of the other stakeholders at the company. This cannot be tolerated or ignored, it has to be confronted. And, again, this is not a court of law, a manager in this situation should not wait till they have overwhelming evidence, they should demand a confrontation as soon as their instincts tell them that something is a bit off or suspicious. I gave Jerry multiple chances to reassure me he respected the decisions being made by others, but he did not give me any such assurance till, at the very end, I forced it out of him.
I’ve met a lot of the qualities/challenges that make up a lot of these types. Maybe especially the “unreliable” type, but never in a way that is laid out here and I certainly wouldn’t call them uncommitted or unreliable. I view them much more as rebellious, to which they are afforded leeway that very few professions. But to me, the inability to meet deadlines, often tells more more about the deadlines than the employees. Maybe that is because I’m from a technical background myself and the management I’ve done has been more Helle Hein and Scandinavian inspired than what is common in the US, but programmers are hard to fit into your organisation because they don’t have any fucks to give about your red tape. Now, programmers and other techies are quite famous for this, but the way I see it, this is what organisations should expect from younger employees in general going into the 2020ies. Young people are not going to respect the authorities of the past. To prove my point, just look at all the rave about silent quitters, which is essentially employees who aren’t going to go above and beyond for you because they just don’t respect that the way older generations did.
The way I see it is that old famous trove about how some programmers wear shorts and sandals to a suit only dress code office. And they get away with it because ultimately the work they do matters more than them respecting some draconian corporate rules. It’s the mind set that you’re going to have to pay attention to. Because those programmers aren’t necessarily douche bags, they may be some of the nicest most committed employees you have, they just don’t care about your corporate red tape. Which is the way I see a lot of these “stereotypes” in this article. But how the author paints them… like they are broken or annoying, well… good luck getting any useful management tips from someone who views employees like that.
One example I’ll dig into is the deadline bit. I’ve never once seen someone miss a deadline without it being the deadlines fault. Ok, I have, but then it was because they got sick or something similar got in the way. If you have employees who continuously miss deadlines it’s very likely that your estimation is simply wrong. Yes, you can try to limit distractions, but once you start putting the responsibility on the employees with silly things like “agreements of responsibility and expectations” you’re also either increasing their stress or sending them directly into the job section on LinkedIn. Depending on what sort of person they are. There is no magical way that you can possibly make someone who continually misses deadlines suddenly start making them without giving them less things to do or more time to do it. It’s just not possible. Hell, if you have someone who misses a lot of deadlines, you don’t have a difficult employee you have a super stressed employee who needs help.