9 ms·

This article is depressing, because it evokes a simplistic and dismissive management-style that I have found to be quite common. Rather I find that people deve

This article is depressing, because it evokes a simplistic and dismissive management-style that I have found to be quite common. 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.

twistedcheeslet 3y ago
In case you missed it in the article, the author seems to address this in the section titled 'Effectively Managing the Norm'.
- riazrizvi 3y ago
  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.
- pxue 3y ago
  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
  - gemstones 3y ago
    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?
    - ukj 3y ago
      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.
      - vasco 3y ago
        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.
lampshades 3y ago
This article is depressing because corporate America is depressing.
- honeybadger1 3y ago
  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.
  - bobboies 3y ago
    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.
iterminate 3y ago
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.
- nerdchum 3y ago
  Ive found way more difficult managers than difficult employees in my career. Difficult managers need to be terminated as well.
  - arpa 3y ago
    what do you mean it's an interactive system of shitiness?
  - datadrivenangel 3y ago
    At a certain point the rot starts from the head. Amazing how a few bad senior managers can allow for so much bad behavior.
TrackerFF 3y ago
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.
- Shaanie 3y ago
  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.
taylodl 3y ago
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.
- Perepiska 3y ago
  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
  - avidiax 3y ago
    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.
  - taylodl 3y ago
    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.
schneems 3y ago
> 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).
- ChrisMarshallNY 3y ago
  > 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-solutions/ https://littlegreenviper.com/miscellany/problems-and-solutio...
- riazrizvi 3y ago
  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.
  - pg_1234 3y ago
    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.

twistedcheeslet 3y ago

In case you missed it in the article, the author seems to address this in the section titled 'Effectively Managing the Norm'.

riazrizvi 3y ago
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.
pxue 3y ago
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
- gemstones 3y ago
  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?
  - ukj 3y ago
    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.
    - vasco 3y ago
      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.

lampshades 3y ago

This article is depressing because corporate America is depressing.

honeybadger1 3y ago
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.
- bobboies 3y ago
  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.

iterminate 3y ago

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.

nerdchum 3y ago
Ive found way more difficult managers than difficult employees in my career. Difficult managers need to be terminated as well.
- arpa 3y ago
  what do you mean it's an interactive system of shitiness?
- datadrivenangel 3y ago
  At a certain point the rot starts from the head. Amazing how a few bad senior managers can allow for so much bad behavior.

TrackerFF 3y ago

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.

Shaanie 3y ago
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.

taylodl 3y ago

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.

Perepiska 3y ago
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
- avidiax 3y ago
  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.
- taylodl 3y ago
  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.

schneems 3y ago

> 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).

ChrisMarshallNY 3y ago
> 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-solutions/ https://littlegreenviper.com/miscellany/problems-and-solutio...
riazrizvi 3y ago
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.
- pg_1234 3y ago
  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.