Managing difficult software engineers(vadimkravcenko.com)
vadimkravcenko.com
Managing difficult software engineers
https://vadimkravcenko.com/shorts/managing-bad-engineers/
177 comments
I very much disagree with the premise that most of the time difficult engineers have the organization's best interests at heart. Most people (across any discipline) have very little regard for the "interests" of the organization that they're working for. Not because of incompetence or malice or organizational dysfunction but because most people just want to show up, do their time and get out to live their life with what little time they have left of their day. Maybe, at best, they care about the interests of some of their co-workers that they like.
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 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.
> Most people (across any discipline) have very little regard for the "interests" of the organization that they're working for. Not because of incompetence or malice or organizational dysfunction but because most people just want to show up, do their time and get out to live their life with what little time they have left of their day. Maybe, at best, they care about the interests of some of their co-workers that they like.
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.
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.
Short sighted decision making that doesn't account for the larger ecosystem. Sloppy code that barely meets the requirements. 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.
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.
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.
"local minima" is entirely a function of what processes and requirements are in place for code to be accepted. In a well designed engineering org, the "local minima" and "optimal" are indistinguishable from each other, because you only let through fully tested code that passes the hopefully many CI steps you have and has also been subjected to extensive code review, QA, etc.
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...
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...
> In a well designed engineering org, the "local minima" and "optimal" are indistinguishable from each other
You're talking about a platonic ideal that rarely ever occurs in real life, except for very simple systems.
You're talking about a platonic ideal that rarely ever occurs in real life, except for very simple systems.
All of that said, engineers are not static -- everyone is learning and changing all the time, so "problem" engineers after you've eliminated the above are simply people who have a ways to go before they change enough to become effective in your org (or, quite possibly, your org and its processes have a ways to go before more than an extremely specific type of engineer can become effective). Then it's just a value-prop of "do we think it's worth it to wait it out for this particular employee" because they're always learning and leveling up.
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.
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.
Of course what you are saying is true but there is more nuance here. The fact is that regardless of architecture, requirments and test cases the engineer is going to make lots of small decisions, and if they are not motivated to make good decisions for the benefit of the org then there will be consequences that maybe could be mitigated but will still impose significant costs. So the fact remains that these engineers need to exit the org.
Every time I read a variation of the "for the benefit of the org" phrase I cannot help but laugh at the absurdity of it.
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.
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.
Some people are motivated by a sense of professional responsibility. Others are not, thats true. I prefer to work with the former.
That's a big mischaracterization of what I wrote. No, it's not a binary choice between professional or not professional. This kind of simplification is exactly the type of harm the original article reinforces.
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".
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".
Very based, very true.
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.
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.
> 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.
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.
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.
Yes these things happen, but in my experience it's about incentives set by the environment.
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.
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.
Ive found way more difficult managers than difficult employees in my career.
Difficult managers need to be terminated as well.
Difficult managers need to be terminated as well.
> Ive found way more difficult managers than difficult employees in my career.
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.
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.
At a certain point the rot starts from the head.
Amazing how a few bad senior managers can allow for so much bad behavior.
Amazing how a few bad senior managers can allow for so much bad behavior.
They're harder to fire. Sometimes the org going belly-up is the consequence.
Well... were you ever a manager to actually know that?
what do you mean it's an interactive system of shitiness?
> but because most people just want to show up, do their time and get out to live their life with what little time they have left of their day.
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.
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.
Generally people have a work ethic and want to do good work that gets recognized as such. So it's somewhere _between_ "just to get paid" and "align with company goals".
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 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 absolutely sucks if you want to do good work and that doesn't align with company goals.
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.
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.
> because they want to feel like they have the answers
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).
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).
> 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.
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
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
It's clear there's been a bozo explosion.
> Or they answer the surface level question but don’t understand how much deeper it goes.
That's pretty much the gist of this shortie: https://littlegreenviper.com/miscellany/problems-and-solutio...
That's pretty much the gist of this shortie: https://littlegreenviper.com/miscellany/problems-and-solutio...
Indeed. In the thread, we see that when people don’t understand something, rather than recognize that, they wrap the territory beyond understanding with superficial word wrapping. I guess it’s an intellectual/social strategy to economize mental load and also project confidence, but at the cost of curiosity and awareness.
> 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.
> 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.
The really telling sentence is:
"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.
"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.
Also “difficult” then, are software engineers who identify and raise a problem with the direction that the manager doesn’t get.
The article matches my observations that I've seen across several teams and several companies over the past 40 years. I've seen these people everywhere.
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.
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.
I've been such a 'toxic' person on some startup for couple of years.
Impotent management was unable to setup code style conventions and outsourced all decisions to the team in 'democratic' way. Weak inexperienced developers always voted against well known practices and started to invent something ridiculous all the time :D
Does it matter whether you are right? If people do something in a way you didn't prefer, and it goes well, can you admit that your preference didn't matter? If it goes poorly, can you admit that you may not know that it would have been better if your preference was honored?
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.
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.
As I said, I've been developing software for the past 40 years. In that time one thing I have discovered is code style conventions is 100% a waste of time. Actually, I take that back - they're a 110% waste of time. Why? Because code style conventions have nothing to do with the performance or maintainability of the code and wasting time on such trivialities is destroying team morale which is destructive to productivity.
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.
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.
Some people just have difficult personalities, period. They're difficult from the get-go, they were difficult before they entered to workforce. They're not a result of their work place, to put it that way.
It wouldn't be a HN thread without the top comment being something like a middlebrow dismissal (the comment you're replying to).
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.
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.
In case you missed it in the article, the author seems to address this in the section titled 'Effectively Managing the Norm'.
Personally I use a show-don't-tell approach, and what I saw in the article was a few words at the beginning telling how we should trust people, followed by a giant section of showing how we actually don't.
The author went from "trust them to do the right thing" to "Set clear deadlines and regularly check in on their progress. Make them accountable for those deadlines" real fast
The opposite is “set vague deadlines and don’t check in on their progress.”
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?
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 am always incredibly surprised when people are surprised when I miss deadlines.
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.
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.
I've had 1-1's with about 500 engineers between working with them or interviewing them. I honestly think you are being difficult under this described situation, yes. I mention the number only in case you'd trust that you are not alone in thinking this but:
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.
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.
A competent project manager in this undustry also understands that software engineering is not plumbing.
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.
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.
I'd say that my teams tend to meet the goals we set for ourselves (lol biased) without spending that long on estimation. We have an idea of our normal throughput and can use that to be somewhat accurate, and nobody gets shit if something ends up being harder than what we thought it was from our investigation, sometimes there are truly new things that are harder to predict. In those cases we take smaller chunks out of the big problem and focus on that first.
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!
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!
Eh, for the majority of cases, software engineering is more like plumbing than like R&D. There are exceptions, like building a new DB, or similar. But if the tools you need to solve the problem are postgres + Django + react, there shouldn't really be that much hidden complexity for you to uncover.
So the domain model has already been made explicit and is implemented for you? All the design choices have been removed from you? You don’t have to do any actual software engineering - just extending business logic? That’s nice.
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.
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.
Plumbers don't get to decide how the pipes were laid out in the houses they come and work in, either - technically those are unknowns that could throw off a job. Doesn't mean it would be professional of them to insinuate that the variation in each individual building means they can't give a good faith estimate for a job.
It means exactly that.
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.
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.
> I am always incredibly surprised when people are surprised when I miss deadlines.
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.
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.
This article is depressing because corporate America is depressing.
Agree fully...I have found working in corporate America, that it is quite effective at stripping off branching talents or 'non-core' skills of a bright person and making them form a lane of specialization. Essentially stunting their natural curiosity and desire for more knowledge, malforming them into a one trick pony.
Woe is me, I’m a cog in the machine but I want to be the machine itself. I think the technology industry is detached from the rest of the world.
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.
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.
3.4. The Procrastinator
3.5. The Lone Wolf
3.6. The Negative Nancy
3.7. The Over-Promiser
3.8. The Know-It-All
3.9. The Silent Type
3.10. The Perfectionist
3.11. The Unreliable One
3.12. The Conflict Instigator
3.13. The Burned-Out Employee
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.
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.
Whenever you see someone describe "types of people" you should have the understanding that nobody has a type. People behave in complex ways and display traits that can be attributed to several types. Like a scientific model that has limits, putting fictional people into types allows us to describe patterns of behavior and their caracteritics in better ways than just going "ahhh chuck everyone is different there's nothing I can learn". You can apply this thinking to "archetypes of staff engineers" or any sort of personality trait quiz that purports to find your "type".
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.
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.
> 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.
That's just https://en.m.wikipedia.org/wiki/Fundamental_attribution_erro..., isn't it?
That's just https://en.m.wikipedia.org/wiki/Fundamental_attribution_erro..., isn't it?
I fully agree. Our industry is obsessed with tools, frameworks and methodologies, but when it comes to people, I find those barely useful for anything other than teaching those without any experience.
All models are wrong, some are useful.
All models are wrong, some are useful.
You can think of archetypes as "principal components" if it helps to assuage the reaction to being unfairly labeled or pigeonholed.
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.
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 no such thing as "principal component" to a human. To quote Walt Whitman - I am large, I contain multitudes.
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.
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.
They mean principal component as in principal component analysis. There can be a multitude of principal components.
I know what they mean and we aren't disagereing.
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.
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 problem with most so-called personality archetypes is they aren't based on any rigorous empirical research. They're just arbitrary categories someone came up with.
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.
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.
archetypes are no better than astrology.
Expand your last paragraph to apply to almost all human beings in any industry. There are burned-out doctors, know-it all priests, negative nancy teachers, perfectionist lawyers and silent type librarians.
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.
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.
I can identify with every one of the items on that list.
I can also identify that about 60-80% of the time I've been called a "procrastinator"; or a lone wolf; or a negative nancy (or any one of the pejoratives) it's because I've been fed bad incomplete or incorrect information about what's expected from me or from the team.
>"you are perhaps looking for a robot."
It's clear from the definition...
It's just humans that constantly misunderstand my managerial instructions.
>"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.
Second that, reading through the article felt like looking in a mirror. It's helpful to be more self-conscious about one's flaws, at least you can spot yourself doing the thing and get a chance at reversing course.
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.
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.
> you are perhaps looking for a robot
Ah yes, the LLM persona: the Hallucinator.
Ah yes, the LLM persona: the Hallucinator.
My former boss had an employee like that. He was prolific, but his code was extremely convoluted and had complicated solutions to simple problems.
I've been categorized as such for having the audacity of writing a tree traversal function.
Was it strictly necessary?
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’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.
You will be the judge.
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 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 worked on a piece if software that had originally been developed by a single engineer who fit that description. After struggling to understand and work effectively with the code for some time, and questioning my own abilities, I learned that much of the code had been written under the influence of LSD…and everything made so much more sense.
Moreover, you can be multiple types of software engineer at the same time. I am currently working on two projects. On one I am unfortunately the "Over-Promiser", because I frequently underestimate how bad the legacy code is that we are working on (and how litte we are motivated on this project). On the other project, that is actually quite awesome, I am the "Lone Wolf", because I actually know how to do things best for parts of the project. I hate being the Over-Promiser and love being the Lone Wolf.
It's okay to have some of those traits, but I've also experienced colleagues which were basically comic book versions of some those types to the point that they ended up being impossible to work with.
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).
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).
Exactly what I wanted to say! Out of the list, I can identify with most things. Almost scary...
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.
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.
Those are symptoms, not causes...
3.14 the one you call back one full year after he left because otherwise you're fired as a manager.
Now I imagine a list of similar personnalities for codebases:
1. The Sand Tower. 2. The Sacred Pile of Poo 3. The closed Clue Shop. 4. For the Family 5. The Spreadsheet 6. The Silent Trainwreck. 7. The Warden 8. Gilga-mesh
I think I have about seven of those simultaneously.
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.
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.
“Pobody’s nerfect”. The ones who refuse to acknowledge their shortcomings, refuse to adapt and learn, to try something new, those are the difficult ones.
> e.g., when I was in my mid 20s
Lone Wolf?
Lone Wolf?
I’ve become more of a lone wolf in my 30s, actually. A combination of gained knowledge and experience, teams not familiar with my tech stack, remote hours (both because of timezone difference and also my crazy work hours) and also, yes, less trust in other people’s opinions. This also happens. It’s not just teenagers that feel sometimes they have the most experienced opinion. After listening to bad discussion for long enough, one becomes burned out and cynical of the “team discussions” and just looks inward to find solutions for the most difficult problems.
> teams not familiar with my tech stack
Not the other way around?
Not the other way around?
Saying that an entire team is unfamiliar with an IC's tech stack is indeed weird in most cases. But it can make sense, and largely depends on the relationship between the team and the person involved.
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.
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.
It’s all about perspective. In two companies now, I’ve been in teams that don’t really care about my tech stack. It was mutual, of course. You can blame the company for making these teams up (I did/do), but that how things are.
Normally the technology stack refers to the languages and frameworks underpinning the project.
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.
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.
In my previous job, I was hired into a team of tech leads, each in their own field. In the current job, I was hired into a product team that was about a macOS app. After several reorgs, mergers and downsizing, the team is mostly web devs, backend devs (Go) and me, still developing the macOS app.
Why should I care about the teams’ other tech stacks (and vice versa)?
Why should I care about the teams’ other tech stacks (and vice versa)?
> teams that don’t really care about my tech stack
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.
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.
In my previous job, I was hired in a team of tech leads, each in a different domain. But the development at large in that company was web development, which I didn’t know how much I’d end up disliking. So I focused on my things within the company minimizing interaction with tech stacks I didn’t care about.
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.
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.
I've seen all of these at one point or another and a lot of the time they're circumstance dependent because of nuts decisions the company has made that put people under stress.
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.
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.
And quite often the person who causes these circumstantial stresses can be the same person for whom this guide is intended, but I'm not able to find a lot of acknowledgement of that fact in the guide.
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 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 can relate to this, especially as someone from a technical management position that has to fight such decisions frequently to try to protect my team from such pointless exercises in stress.
> 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.
> 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.
Thanks for the thoughtful reply. Lots for me to mull over in that.
thats exactly what i do...theyll ask for a time estimate and then whether it can be cut by half because issues...i then say yes of course it can and proceed to delivery way past the deadline
How you are being perceived is based on the assumptions and character of your manager.
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.
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.
Yes. I hate this article. It presupposes "the norm" doesn't need anything special and everyone else is "difficult."
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.
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.
> everyone else is "difficult."
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.
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.
This, 100%.
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.
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.
It's not even necessarily a first impression anything.
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?"
[0] https://www.youtube.com/watch?v=N7qrL6dWnoQ&t=88s
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?"
[0] https://www.youtube.com/watch?v=N7qrL6dWnoQ&t=88s
I think there's a different problem with exactly this stereotype and people throwing it around a bit, even if you are not just being negative, but offering criticism including some solutions.
I've been called that at times, but if it's not your job to solve the problem, just to add some input as a reviewer, what can you do if all you see is problems? You may argue that it's easy to criticize and not fix it, but if fixing it takes time you don't have, should you just not say anything?
The people who should be put on PIP are the dead weight (non-technical management). Fire them and most of this "difficult behavior" magically disappears. They're the biggest source of miscommunication, worthless meetings, wasted time, bad estimates, imprecise language, and flat out lies.
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.
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 company started a sales org shortly after I arrived, which was disappointing as it was extremely engineering-heavy initially.
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.
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.
I think management often believes it's existence is justified by "protecting" the engineers. Of course, they are protecting them from other managers. So it's an arms race - or more technically, going from the good Nash equilibrium to the bad one.
One thing that strikes me as missing is the suggestion of people having trouble in general with their lives, whether mental health, personal relationship problems, or financial struggles. This is especially the case when going over the “unreliable” worker.
> 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.
> 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.
I agree, I don't like much of the advice this article gives. It seems trite. I think it often ignores the human factor and comes across very wooden and one-way—sit your employee down and instruct them so-and-so. I'd like to see more emphasis on active listening, and (as you said) consideration of outside circumstances.
I'd also like to #include SilverBirch's post, which has deep wisdom: https://news.ycombinator.com/item?id=37164426
I'd also like to #include SilverBirch's post, which has deep wisdom: https://news.ycombinator.com/item?id=37164426
[deleted]
> financial struggles
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.
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.
You never know what someone is dealing with unless they tell you. A bad business decision as a sole trader, an ex-marriage with kids and a SAH parent that they're supporting, difficult/societal pressures around family (care is _very_ expensive), a gambling problem.
> 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.
> 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.
Average wage isn't $75k. That's average household, which frequently has two wage earners.
For individual full-time workers, it's $57,200[1].
[1] https://www.bls.gov/news.release/pdf/wkyeng.pdf
For individual full-time workers, it's $57,200[1].
[1] https://www.bls.gov/news.release/pdf/wkyeng.pdf
Ok replace 75k with 57k, the average swe is not making $275k
I didn't say average, I said it's not unusual. Obviously you need to be good to get to that level. But you can do it without any schools, just by sitting down at home and learning, and then replying to few LinkedIn messages.
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.
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.
> In the US. Everywhere else, that's incredibly unusual. 5x the average wage in the UK is 150k plus - that's _very_ unusual.
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.
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.
In the US that's true, but not necessarily everywhere. My wife was out of work for 15 years after a burnout and while raising kids with their own difficulties, and it was definitely financially stressful where I am (Netherlands). Besides being very stressful in general, of course.
Software engineers, too, will have financial struggles.
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.
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 live in Canada and make a few thousand more than the median income in my current city. It's certainly not 2x as much less 5x what others are making here.
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.
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.
Where I live it's normal to live in apartments. Entire houses are pretty much inaccessible to anyone except the richest - and they are all split into apartments anyways. This is normal, I don't know why this would be an indicator of anything.
Because not all countries are the same. In Canada owning a home is the historical norm and until a few years ago someone making the median income could have afforded one in most places.
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...
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...
Few decades ago it didn't matter much whether you live in the capital, in a small town or in a village, today the capital is much more desirable than either of the other places. Now there are also many foreign people moving in who can't even go to the other places because people don't speak English there. And frankly, we have big issues with new construction - it takes 8 years to obtain the necessary government approvals!
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...
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...
There's lots of people out there who are at higher than national average in places that have a cost of living 3x+ the national average, who have exceptional expenses like caring for a special needs child or a sick relative, and/or have childcare costs that folks in lower COLA places often have covered by parents or by a stay-at-home parent.
Collectively we can stop acting like every SSE in America is sipping champagne and eating caviar every day, because they really aren't.
Collectively we can stop acting like every SSE in America is sipping champagne and eating caviar every day, because they really aren't.
I'm European, from the former Eastern Bloc.
This post shows why working is so uncomfortable.
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.
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.
Yes, I agree. Reading "The Unreliable One" section in the context of someone who is being pulled in too many different directions by incompetent management really changes how it comes across.
You are free to do what we tell you!
> Procrastinators [...] may have poor time management skills, often underestimating the time required to complete tasks.
> 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.
> 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 started reading this with high hopes. Unfortunately it quickly started to spiral. The procrastinator may well not be procrastinating, they may genuinely be struggling technically. "It's works locally but not on staging" is a technical, solvable problem. Sure, it might be a lie, it might be actually they're off doing other things, but in itself that doesn't sound like procrastination. The lone wolf? When you describe that scenario to me, it sounds like Lisa might not have appreciated the 5th time her entirely male team shouted her down in the last "high energy" discussion. I once got to sit in on a team who would do planning poker, it was arduous, and one of my colleagues completely ruined it when she pointed out it was pointless because they always just deferred to Rik. It was like an hour a week where Rik got to decide what everyone did.
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.
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.
I'd be much more interested in a reverse article: managing difficult bosses. That's more often than not the problem, the lower ranks usually know their stuff and bad apples are rare, the other way around seems to select for incompetence and obstruction. Good managers are just as rare as difficult software engineers.
It is called "managing up"
Which is easy if you have a good manager, and a great way to get fired if you have a bad one, which I think was the original question posed here, how do you "manage up" a bad manager.
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.
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.
I have this in my bookmarks that might be of help: https://news.ycombinator.com/item?id=18988939 "Design Patterns for Managing Up"
The lengths that engineering leaders will go to in order to avoid learning basic lessons about team building astounds me. “The norm” here is not very productive, it just means they are not killing themselves and each other.
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.
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.
I haven't had a single employer that didn't blatantly lie to me during the hiring process. Infuriating stuff such as saying it's company policy to pay for training, and then refusing to do it. So my rule of thumb is that if it isn't in the contract, it's bullshit. But it aggravates me nonetheless.
The Burned Out employee section is just embarrassing.
>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.
>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.
This article is patronizing and tries to simplify the complexities of managing people by putting them into buckets and listing recipes.
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.
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.
My thesis:
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
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
I don't think that there is any correlation between time spent "thinking about the system" and likelihood that it needs "unfucking".
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.
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.
We want more thinking about business complexity and much much less thinking about accidental technical complexity.
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 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 think an article about "Working around difficult managers" would be more beneficial than marking almost any talented sweng "difficult" from the management perspective.
Very simplistic. Any article like this needs to be far more nuanced.
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...
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...
> Procrastinators tend to delay tasks, often focusing on less important tasks while ignoring the critical ones. They may have poor time management skills, often underestimating the time required to complete tasks
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.
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.
Careful with advice from someone who never managed large teams, successfully. Look at the author's LI bio.
Content marketing is adding so much noise, muddying up the waters.
Content marketing is adding so much noise, muddying up the waters.
I'd like to see the inverse for dealing with difficult managers, including boxing them into similar reductive stereotypes like the "spineless doormat" and the "non-technical MBA."
If the author is here, a nitpick on the writing: if you use the "let call him XYZ" thing, then _use XYZ to address the persona_ later in the text! Mark, Sarah and Emily for instance appear exactly ONCE in the text, when you say "let's call them XYZ".
So basically how to "manage" pretty much every person regardless of what they are doing professionally..
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.
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.
Perhaps someone can write the inverse version of this post?
"Managing difficult managers"
"Managing difficult managers"
Can perfectionism be "cured"?
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?
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?
> Can perfectionism be "cured"?
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.
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.
> I long ago got rid of the idea that anything I create is special or worth saving. Outcomes are what matter.
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.
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.
It might be that you can redefine perfectionism.
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.
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 have to disagree here.
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 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.
"Perfectionism" ends up being too vague IMO.
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.
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.
> 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.
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 aspire to be "The Unreliable One"
> "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.
> "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.
Not caring is critical, IMO. It's a job, not your life, and everything you think matters can be taken away by the whims of management who have the authority to do so. If they care about something, then you are no longer allowed to.
I really pity kids these days that wrap their whole life’s identity in their work, take every minor criticism as a personal insult, every dislike of their product as a personal attack on their self-worth. It’s understandable why it happens, especially with cynical and conniving companies trying their best to be in every facet of people’s lives, from dog walking to kid day care to social activities “after work”. People should really resist these conveniences and separate their work from their lives.
Unfortunately, with takes like this, most of us will be learning this lesson after we've already overinvested into such an identity. How can we as a society be more proactive?
I’m not sure. I am a cynical person, so I am naturally repelled by these tactics. And by now, I’ve learned to get too attached emotionally to my tech or products. I’m not sure where and how these lessons can be taught to young employees to be.
I'm absolutely positive that I've been described as "difficult" many times throughout my 30-year career as a computer programmer. I've picked up on a lot of frustration from other people around me - but that's almost always when I tell them I don't know the answer to the question that they just asked me for an answer to. I can figure it out, I'm qualified to figure it out, but I don't know the answer _right this ver instant_. So I'm "difficult".
Aren't a lot of people an amalgamation of all of these characteristics?
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.
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 introduce names (a la "let's call him Mark") but never refer to them?
because much writing is like code so you start with an intention as to what you will need later, get done and realize you didn't need everything you thought, and if you're a junior or really tired or on a very heavy deadline don't do an adequate cleanup.
maybe this observation should be part of my next article - managing difficult article writers.
If you find engineers difficult then you should not be a manager in a technical field. Real world is difficult and thats what engineers have to conquer. If you are not ready to hear hard truths, choose another field.
[deleted]
[deleted]
There's one type of "difficult" personality missing I'm seeing a lot recently, and that's the resume padder.
The nerve to tack on nonviolent communication after issuing the most sweeping damnation of peoples' circumstances...
If this subject interests anyone, I have written a great deal on the topic:
"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...
"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...
I read the dishonest employee story and, candidly, I did not find it to be an example of good leadership.
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.
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.
Keep in mind these things:
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.
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 miss The overcomplicator type.
I’ve never met any of these types in two decades of software engineering. Well, maybe the “negative Nancy” and the lone wolf, but even then not really.
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.
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.
HN has huge numbers of articles on the technical side of software engineering but very few on the people side. Even if this is just one slightly idiosyncratic take, I still gained more from it than yet another article on LLMs, or the most efficient low level code possible in C++ or Rust, etc. Hopefully there are more similar submissions. Also, when people complain that it talks in idealised, simplified models rather than real world messy people: there's obviously no way the author could write up details of real people, so non-personal generalizations is the best that's possible.
[deleted]
This is an okay read, but doesn't measure up to the genre classic: "Academic Programmers: A Spotter's Guide".
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.