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.
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.
> 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).
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.
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.
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.
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.
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.
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...
I use the term "difficult" to differentiate between those employees where everything is going smoothly, and those where more effort is required.
Everything's always going smoothly with my computers they do exactly as I tell them.
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.
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).
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.
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
“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.
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.
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 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.
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.
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.
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?"
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.
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.
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.
> 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.
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'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.
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.
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.
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.
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 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.
> 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.
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."
[+] [-] riazrizvi|2 years ago|reply
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.
[+] [-] iterminate|2 years ago|reply
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.
[+] [-] schneems|2 years ago|reply
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).
[+] [-] taylodl|2 years ago|reply
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.
[+] [-] TrackerFF|2 years ago|reply
[+] [-] twistedcheeslet|2 years ago|reply
[+] [-] lampshades|2 years ago|reply
[+] [-] danwee|2 years ago|reply
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.
[+] [-] vasco|2 years ago|reply
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.
[+] [-] glimshe|2 years ago|reply
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.
[+] [-] ukj|2 years ago|reply
>"you are perhaps looking for a robot."
It's clear from the definition...
Everything's always going smoothly with my computers they do exactly as I tell them.It's just humans that constantly misunderstand my managerial instructions.
[+] [-] rollcat|2 years ago|reply
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.
[+] [-] intelVISA|2 years ago|reply
Ah yes, the LLM persona: the Hallucinator.
[+] [-] jansan|2 years ago|reply
[+] [-] hobofan|2 years ago|reply
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).
[+] [-] diarrhea|2 years ago|reply
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.
[+] [-] jacquesm|2 years ago|reply
[+] [-] StackOverlord|2 years ago|reply
[+] [-] p0nce|2 years ago|reply
[+] [-] antonvs|2 years ago|reply
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.
[+] [-] chasd00|2 years ago|reply
[+] [-] flir|2 years ago|reply
Lone Wolf?
[+] [-] physicsguy|2 years ago|reply
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.
[+] [-] uoaei|2 years ago|reply
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.
[+] [-] csydas|2 years ago|reply
> 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.
[+] [-] pestatije|2 years ago|reply
[+] [-] makach|2 years ago|reply
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.
[+] [-] coffeefirst|2 years ago|reply
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.
[+] [-] agentultra|2 years ago|reply
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.
[+] [-] pengaru|2 years ago|reply
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
[+] [-] wink|2 years ago|reply
[+] [-] sublinear|2 years ago|reply
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.
[+] [-] sgarland|2 years ago|reply
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.
[+] [-] javajosh|2 years ago|reply
[+] [-] taurath|2 years ago|reply
> 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.
[+] [-] mawadev|2 years ago|reply
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.
[+] [-] makeitdouble|2 years ago|reply
> 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.
[+] [-] SilverBirch|2 years ago|reply
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.
[+] [-] jacquesm|2 years ago|reply
[+] [-] fidotron|2 years ago|reply
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.
[+] [-] mkl95|2 years ago|reply
[+] [-] 000ooo000|2 years ago|reply
>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.
[+] [-] Draiken|2 years ago|reply
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.
[+] [-] nly|2 years ago|reply
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
[+] [-] treprinum|2 years ago|reply
[+] [-] nprateem|2 years ago|reply
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...
[+] [-] bawolff|2 years ago|reply
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.
[+] [-] shadowtree|2 years ago|reply
Content marketing is adding so much noise, muddying up the waters.
[+] [-] itsautomatisch|2 years ago|reply