[HN Gopher] How to build toxic software teams
___________________________________________________________________
How to build toxic software teams
Author : tate
Score : 92 points
Date : 2023-07-26 18:40 UTC (4 hours ago)
(HTM) web link (badsoftwareadvice.substack.com)
(TXT) w3m dump (badsoftwareadvice.substack.com)
| debacle wrote:
| Seems like David Tate has had a rough go.
| gwbas1c wrote:
| Be highly resistant to replacing outdated tools when they fall
| out of favor in the marketplace. If you don't have ADD/ADHD, take
| Adderall or another upper so it makes your personality unstable.
|
| ---
|
| In 2020 I briefly worked for a small company. I should have said
| no, but due to life circumstances, I was uncomfortable passing on
| the job.
|
| When I joined, there were security problems all over the place.
| They were self-hosting a Mercurial server with http, not https. I
| eventually brought up the issue with the (cough) tech lead. (I
| should point out that the lead had been the lead since graduating
| college, for a decade, and generally had little to no mentorship
| in the process.)
|
| First, I asked why they were self-hosting their Mercurial server.
| I got back a wishy-washy "that's how we're used to doing it"
| answer.
|
| Next, I subtly pointed out, "You know, if you were using
| Bitbucket to host source code, you wouldn't have this issue."
|
| The response was, "Oh, don't you remember, Bitbucket dropped
| Mercurial years ago."
|
| My next response was, "Uhm, then do you think we should switch to
| git?" (For context, I used to like Mercurial better than git, but
| years ago moved everything to git when I started using git at a
| prior job and saw "the writing on the wall.")
|
| The (cough) tech lead then went on a tirade about how we just
| couldn't switch to git, because he didn't want to have to
| handhold everyone in figuring out git, and then arguing about
| minutiae regarding minor differences between the two.
|
| I tried to reason with him in pointing out how, if you build a
| business around a technology, and that technology loses in the
| marketplace, you put your business at risk. I mentioned that a
| business that used Betamax would have needed to switch to VHS
| once it became clear that Sony was discontinuing it and VHS was
| winning in the marketplace.
|
| A few weeks later, the (cough) lead mentioned at standup that he
| was having trouble getting his medication, and acted like he was
| going through stimulant withdrawal. He never acted like someone
| with ADD or ADHD off of their meds, though. At that point I put
| two-and-two together and realized that his behavior was textbook
| "too many stimulants."
|
| Shortly before my time with this company ended, they very
| nervously announced they were switching to git. I watched
| everyone on the team, except the leadership, breath a sigh of
| relief.
| LargeTomato wrote:
| I guess I can share my story. It's not as egregious as others but
| it does frustrate me still.
|
| My team went through a lot of instability. We lost 2 devs, a
| manager, a director, and a VP in 2 months. We were the only 4
| software engineers working on the product.
|
| The company worked according to milestones. Every month we'd need
| to meet some arbitrary feature set. We were planning to launch
| every month for 9 months straight. That's right, the entire 800
| person company was aiming to launch in less than 30 ways for 9
| months.
|
| Our product was shit. It was rushed and messy. After we hired a
| new director and hired more devs those original 4 people
| (including me) got yelled at, blamed for the bad product, and
| pushed out of the company.
| ravenstine wrote:
| Always be in hiring mode, and be vocal about it so your employees
| know you're ready to replace them. Mention every day that you are
| interviewing someone, even if you really aren't. It's not like
| anyone is going to prove you didn't.
|
| In a similar vain, try to prevent your team from knowing when
| other members of your organization have quit or been let go.
| Also, do not announce in advance that a new person will be
| joining your team. Remember, you want to keep your team in a
| constant state of disorientation.
|
| Make sure to have at least one subordinate with authority over
| the rest of your team who can be the "good cop" to your "bad
| cop".
|
| Use burndown charts as a way to measure individual performance,
| and immediately point out a team member is "falling behind" when
| their velocity is even a smidge less than it was the last sprint.
|
| Turn your daily standups into status updates that only you are
| allowed to be the master of. Discourage your developers from
| self-organizing and performing standups on their own when you're
| late or not around. If your developers take the initiative to
| give you notes on the standup you were away from, display a
| lukewarm demeanor that tells them that their notes will never be
| read.
|
| Speak as if your team is in competition with other groups in your
| company. After all, why should they be collaborating when they
| should be _working_?
|
| Frequently ask your team whether they know about some new and/or
| obscure tech they problably haven't heard of before. Even better
| if the tech is made up! Your team members must feel
| intellectually inferior to you at all times.
|
| Randomly pull aside individual developers on your team and give
| them a pop quiz on how one of their fellow team members is doing.
| The point of this is not to learn anything about the other
| developer, but to sow distrust and subtly communicate that you
| know everything that's going on.
|
| (^^ Yes, that's based on something I actually experienced)
|
| If one of your devs writes some code that you don't like, subvert
| the team's code review process by insisting they have a one-on-
| one meeting with only _you_. If any of the other devs like the
| code you don 't like, you definitely don't want them around to
| defend them. This is _your_ team, so take full control of it!
|
| When a developer implements something in a way that you don't
| like, compare it to some nebulous standards, guidelines, or
| systems that don't actually exist anywhere on paper. For example,
| you can say that the new UI feature "simply doesn't align with
| our design philosophy." That philosophy doesn't have to exist
| because, hey, you're in meetings all the time, so what difference
| is it to you? Make sure that it never exists because otherwise it
| can be used against you. The point is to look like you're the
| only person who truly knows anything for sure while disarming any
| arguments that will waste your time.
| uncletaco wrote:
| Ah Martha, I see you haven't changed one bit.
| temporallobe wrote:
| On a positive note, we just had a sprint retrospective today and
| the entire team gushed with praises for each other and we all
| agreed that team morale is great, and that we are accomplishing
| great things despite all the challenges we had been facing
| recently. I attribute this to a few things I've observed. First,
| we do have some extremely dedicated engineers who lead by example
| rather than granted authority. This garners huge respect for
| those members and makes everyone work that much harder so that
| they don't disappoint anyone. Second, we have extremely positive
| non-technical members (PO, TL, SM) who are very encouraging,
| respectful, and willing to go to bat for anyone. Thus, we feel
| empowered and trusted. Third, we course correct, a lot. If there
| are problems and/or mistakes, we own up to them and focus on the
| solution. We face problems head-on instead engaging in finger-
| pointing and deflection. It's honestly the best team I've ever
| worked with, and I will be sad when that has to end. I've worked
| on extremely toxic teams where all of the above what the exact
| opposite of what I just described and it usually ends in failure
| (through attrition, project realignment/cancellation, etc.). Oh,
| and the source of the toxicity is usually ONE person, but it
| spreads like a disease.
| duxup wrote:
| My first "real" job the director sat down with me and said
| "Look, everyone fucks up. It's ok, someone just fucked up and
| we are all running around now because of it. Just be honest
| when you do it and everything will be fine."
|
| He was right, his department was great to work in. No
| recrimination for honest fuck ups (I took down a national banks
| ATMs for a few hours once).
|
| It was a great place to work and everyone was better / more
| productive because of it. People were positive, honest, and
| adults!
|
| Years later we joined a larger company. They acquired another
| company who had 3x the people doing half the work.... They were
| all about blame and recrimination. Their productivity was
| absolutely related to their culture. They were so follow the
| process / afraid of getting blamed (and people got blamed for
| no reason) that they were terrible / found the worst ways to
| work.
| peteradio wrote:
| [flagged]
| robertlagrant wrote:
| @dang
| sixstringtheory wrote:
| Doesn't this not work here? Just flag/downvote and move on.
| hack34news wrote:
| Hire some Product Managers. EOM.
| zenolove wrote:
| Awww. As a product manager who hopes to be serving, encouraging
| and fostering his team well, this saddens me to read
| jdlshore wrote:
| I wouldn't worry about it. HN is prone to these sorts of
| thoughtless dismissals.
| eschneider wrote:
| Good PMs are rare, but good PMs are worth their weight in
| gold.
| 3-cheese-sundae wrote:
| I read that response in the inverse (that is, hiring product
| managers is a way to avoid building a toxic software team).
| Why? Because I'm on a team with no product manager, and we
| are expected to all service in that role, at least
| tangentially. Not ideal.
| zenolove wrote:
| Thank you, this is a much more wholesome reading of it. I
| probably misunderstood the tone.
|
| That said, I am actually actively trying to grow my
| engineers into somewhat of mini product managers
| themselves.
|
| It's going quite great so far-- the more they get exposed
| to users and problems, the more they are taking ownership
| of their work.
|
| I don't hear things like "the user doesn't understand"
| anymore, but rather "I tried to make it clear to anyone who
| uses it".
|
| They started coming up with features and changes that were
| way more brilliant than anything I could come up with. And
| also interviewing developers (who are also target users for
| us), performing small tests to validate hypothesis, and so
| on.
|
| And they also started making little jokes in customer calls
| to keep users' mood up! Some users even thanked us for
| letting them test our early "broken" work-in-progress :D
| and apologized for not testing well enough. The first time
| I saw this, it was crazy!
|
| I am so incredibly proud of them!
| fruzz wrote:
| Retain rockstar programmers at all costs, even if they push
| everyone else to quit over being mistreated. Give them fancy job
| titles.
|
| Have upper management crack sexist jokes, and HR laugh with them,
| so that women at the company who are sexually harassed know
| reporting it will do at best nothing, and at worst risk their own
| career.
|
| Only hire young men in their twenties, and praise the idea of
| working long hours. Child care is for their wives to do.
|
| Create artificial deadlines, that have no real-world
| repercussions for missing. But make it an urgency that must be
| done, instilling stress, and causing people to work long hours.
| Then after the deadline passes, note how it was unimportant, and
| repeat.
|
| Have upper management make engineering decisions without
| accepting the input of engineers. Then when things blow up in a
| manner predicted by engineers, blame the engineers.
|
| Pay new grads more than you do women engineers who have been at
| your company for years.
|
| Have interviews that are focused on sports, and how much fun you
| would be at a party.
|
| Praise the management style of Jeff Bezos and Elon Musk.
| BlargMcLarg wrote:
| >so that women
|
| Men aren't impervious to sexism either.
|
| >Only hire young men in their twenties, and praise the idea of
| working long hours
|
| Young women are working ridiculous hours as well.
|
| >Child care is for their wives to do.
|
| What child care, most of the highly educated aren't having kids
| to begin with. (Exaggerating, but it's not the big deal given
| what most career couples in their 30s make.)
|
| >Pay new grads more than you do women engineers
|
| That's universal as well, not specific to women only. Several
| companies are overcorrecting by overpaying younger women
| compared to both the older cohort and their male cohort, too.
| jmye wrote:
| > Men aren't impervious to sexism either.
|
| Given that GP didn't say they were, why is your first
| instinct to assume that anything OP didn't mention, in what
| were fairly obvious examples, was specifically excluded?
|
| > Young women are working ridiculous hours as well.
|
| So are the elderly, why are _you_ excluding them?
|
| And so on.
|
| Come on. There's absolutely no need for the ridiculous
| pedantry, and it adds less than nothing to the comment chain.
| Be better.
| dmvdoug wrote:
| > There's absolutely no need for the ridiculous pedantry,
| and it adds less than nothing to the comment chain. Be
| better.
|
| But it sure does tell us a hell of a lot about the person
| who wrote it.
| [deleted]
| fruzz wrote:
| > Men aren't impervious to sexism either.
|
| Men aren't impervious to sexual harassment, that's true. But
| in my career women have been overwhelmingly on the receiving
| end. I've seen a woman not be hired by a male interviewer
| because she was "too hot", I've had one woman tell me she was
| groped, a number been subject to unwanted sexual advances,
| and I've seen male staff cat call. I've had a manager massage
| me out of the blue. It's a gendered problem, the statistics
| bear this out, and acknowledging that is necessary in order
| to address it.
|
| > Young women are working ridiculous hours as well.
|
| That's not the point I was making.
|
| > What child care, most of the highly educated aren't having
| kids to begin with.
|
| That's not the point I was making.
|
| > That's universal as well, not specific to women only.
|
| Again, yes, Not Only Men, but there is a gender component to
| this that I am acknowledging.
| alexachilles90 wrote:
| Let me add: 1) Always micromanage down to the lines of code
| changes. Have your reports depend so heavily on your next-steps
| that you maintain your influence on them to the point that nobody
| can make strategic decision when you are on vacation. 2)
| Encourage narcissistic, rude, and self-serving behaviors in the
| teams to the point that the other team members would think that
| there is no way ahead other than copying these behaviors.
| Praising one particular toxic dev on a weekly basis (and ignoring
| all the rest) works perfectly well. 3) Say one thing - do
| another. Verbally encourage work-life balance, taking care of own
| family members, creative problem solving, maintaining code-debt,
| good documentation etc but makes sure to praise the one dev who
| burns the candle at both ends to report that a project is "DONE"
| as fast as they are humanly possible (without any detail of what
| is being done). 4) And last but not the least, definitely throw
| devs under the bus when a project failed without mitigation plans
| and definitely do not let the dev amend for their mistake because
| heads need to roll. 5) Extra tip, isolate devs and DO NOT let
| them talk to each other (easy during pandemic) in case they form
| better camaraderie because _shudder_ we definitely do not want
| them working together! They only need to take instructions from
| the manager gosh!!
| seattle_spring wrote:
| > Always micromanage down to the lines of code changes
|
| I'll never forget what one of my directors asked me to do a few
| years ago. I was a first-line eng manager with a handful of
| native mobile engineers. The Android guy had a better
| reputation for coding ability than the iOS guy, which was
| reflected in peer reviews come performance eval time.
|
| Director received this feedback and instructed me to have iOS
| guy write his code exactly like the Android guy, down to
| function and var names, classes, logic, etc. No acknowledgement
| whatsoever that the 2 platforms use different languages, best
| practices, UI flows, etc., just: "Have him write the exact same
| code in his language and he'll learn how to be a good
| engineer!"
| Ensorceled wrote:
| > If something goes wrong, start an investigation. Figure out who
| to blame and do it publically. Raise your voice, send nasty
| emails, mean-mug without delay. Anytime there is a failure, don't
| miss an opportunity to assert your authority.
|
| I've worked at a number of companies with this behaviour. What
| happens is most people in this situation just start keeping their
| head down and not doing anything at all unless specifically
| tasked by the leadership team. Things usually grind to a halt.
| fullstackchris wrote:
| Like the clowns I used to work for, cancelling daily standup with
| 5 minutes notice or just not showing up at all
|
| its really the little things of being professional
| baby wrote:
| I'd also be interested to read about how to build a team that
| can't succeed.
| dangerwill wrote:
| I do wonder if people have any experience around doing root cause
| analysis that doesn't just end up in blame games? I've worked for
| three companies in a row that claim to have blame-free cultures,
| and all of them did put work into it (structuring the documents
| to not assign an individual's name to any given misstep and
| telling people to be kind and understanding). But in every case,
| you can feel it in the air that everyone still understands that
| the RCA is a blame document/process and that management is
| keeping track of the individuals at fault and it still matters on
| their end of year eval.
|
| With the industry wide layoffs this feeling has only gotten worse
| now that there is a decent chance that accepting blame (or your
| manager deciding the blame is on you) will be the difference
| between having a job or not in 6 months.
|
| Maybe this is unavoidable given that these processes only kick in
| when something goes wrong, and you can only screw up at your job
| so much until you get shown the door?
| hecanjog wrote:
| I really don't know either. When it works for me though, I
| think it looks like people going out of their way to point the
| finger at themselves, and nobody going out of their way to wag
| a follow-up finger at them. I'm not sure hiding it would be
| helpful, but I haven't tried that.
| jstarfish wrote:
| > When it works for me though, I think it looks like people
| going out of their way to point the finger at themselves, and
| nobody going out of their way to wag a follow-up finger at
| them.
|
| This is how I prefer it too, but the problem is that honesty
| is a luxury when times are good. When times aren't so good,
| having a self-documented history of failure doesn't help your
| case for retention when the jerk next to you who deflects
| everything appears to be a golden boy.
|
| > I'm not sure hiding it would be helpful, but I haven't
| tried that.
|
| From the police playbook: after raising awareness of a
| problem, proactively make excuses for other teams and/or
| deflect blame to a vendor ("we don't know it's that team's
| fault; they're understaffed and we don't know what they're
| having to deal with over there; give them a break because
| nobody can understand the vendor's fucking incoherent
| documentation and their software is garbage anyway").
| Confusing the issues and misdirecting blame gives the team
| time to address the problem while saving face. Everybody
| hates Microsoft anyway so they're an easy scapegoat. (Sorry,
| Microsoft employees.)
|
| For better or worse, it fosters a culture where people cover
| for each other, not throw each other under the bus. This is
| how you wrangle even the most toxic Narcissists-- they
| recognize and appreciate when someone's doing them a public
| favor, and (IME) this compels them to respond in kind because
| they'll want to one-up you as everyone's savior. (We're
| starting to see this with all the moral crusading and self-
| appointed "safety" workers. All Narcissists.)
| sokoloff wrote:
| I think we ran an effective process to cover the RCA area of
| our operations. Importantly (IMO), we did go to lengths to
| understand and ascribe _actions /activities_ that resulted
| in/contributed to an outage to a specific individual; we were
| just careful to not assign individual _consequences_ to them. I
| think it 's critically important to understand as precisely as
| possible what happened, who did it, what they were looking at
| that caused them to take that action, and which parts of that
| [if any] we'd change with the benefit of hindsight. I ran the
| Ops team at the time and it was easy for me to enforce the lack
| of consequences for anything short of an intentionally
| destructive act.
|
| If "blameless post-mortem" means "we want to make sure that no
| one has any idea who was responsible", you can achieve that but
| you probably won't like the results.
|
| If it instead means "we want to know why it happened, who
| contributed, and why, so that we can not repeat it", you have a
| fighting chance.
|
| I've written and published multiple RCAs that explain in detail
| why /u/sokoloff caused an outage, when it started, when it was
| contained, and how to avoid that mistake in the future. I think
| that trying to obscure who did something is not only not worth
| the effort, but is actively destructive to the learning and
| trust.
|
| If I can't trust that my name can appear next to an honest
| mistake, what else must I be distrustful of? If instead, I see
| respected, senior staff readily taking responsibility and
| sharing their mistakes without fear of consequences, I trust my
| company's leaders more, not less.
| agentultra wrote:
| A gold mine!
|
| Always make sure you sow doubt and confusion in your employees.
| Make sure they question their own lived experiences and wonder if
| there is something inherently wrong with them. If they seek out
| advice and feedback from you about their work make sure you
| respond with vague suggestions, not based on reality and facts,
| and make sure it's about a character flaw you see in them. Never
| use examples or facts to back up your claims and never give
| direct advice about how to address the issue. They will soon
| wonder what it is they have done to become so flawed that no
| amount of therapy will ever undo the damage you have wrought. Do
| this to enough employees and watch as egos and careers are laid
| to waste.
|
| Make sure everyone works alone and never talks to one another. If
| someone asks for advice it's because they're not competent enough
| to have known the answer. Make sure they know that is why they're
| not being promoted. Don't let them talk or share ideas. It's a
| waste of time. Workers who are isolated and silenced are easier
| to manipulate, learn to feel helpless, and depend on you to tell
| them what to do.
| [deleted]
| Kapura wrote:
| Love it when a post crystalizes exactly why you need to leave
| your current job ;)
| hereforthecake2 wrote:
| Something a lot of people miss or don't understand: software
| engineers typically emulate other software engineers, not
| managers.
|
| If you are tech lead you should be keeping this in mind at all
| times - your behavior, attitude, and approach to things gets
| amplified across team members.
|
| If you are a manager you should also be keeping this in mind at
| all times - the values and behaviors want demonstrated on your
| team will need to be cultivated by key devs in your group.
| Working with them to help shape their understanding of how to be
| effective and how to lead others will really help things solidify
| in the group.
| bcbrown wrote:
| This is something I didn't fully understand until I was hired
| into a position of a formal role model - principal engineer on
| a new team of fairly junior engineers. My manager had several
| conversations with me to drill into me that I now had to keep
| in mind the power of my example in behavior for the team. It's
| not that I was a bad role model, just that it wasn't always
| front-of-mind for me.
|
| I think it's easy-ish to get promoted to Senior based on your
| personality and inclinations that lend themselves to being a
| "natural" role model; moderate deficiencies can easily be
| glossed over as long as there's enough compensatory strengths,
| and you aren't expected to be perfect. But once you start to
| become a role model - formal or informal - you gain a new job
| responsibility: _consistently_ demonstrate the culture of
| professionalism and courtesy the company wishes to inculcate.
| Because your actions will be emulated, for better or worse.
| l0b0 wrote:
| OP, don't you mean "Most people" rather than "Few people" in the
| first paragraph?
| minorinscrum wrote:
| _Do a daily stand-up_
|
| Make sure to monitor your team every day and force their
| performance first thing in the morning. Focus on the daily grind
| to ensure meaningful change can never occur.
|
| _Hire randomly_
|
| Never put in the work to identify potential candidates based on
| their contribution to the industry or relevant projects. Always
| rely on blind applications to a job ad then make the applicants
| perform grueling and humiliating coding tests until they've
| successfully demonstrated their pain tolerance and allegiance.
|
| _RTO_
|
| Make your developers as uncomfortable as possible and force them
| to move to the most expensive real-estate market possible. It's
| important to remind individual contributors of their position on
| the social hierarchy. Home ownership and starting a family is for
| execs only.
| dudul wrote:
| I would bet a lot that there is probably very little difference
| in outcome between hiring randomly and hiring with these
| complicated, disconnected, grueling interview processes that
| every company seems to be doing now.
| chaosharmonic wrote:
| _Pay quietly_
|
| Don't pay your staff consistently for the same work. Refuse to
| advertise your budgets, and loosen your "ranges" to get people
| in the door when they push you about it, but then use those
| same targets to hand-wave away people already inside -- who
| come to you after comparing notes or observing the impact of
| broader market conditions like inflation. Also, stop them from
| comparing notes or doing fifth-grade level math like
| compounding effects. That education is there to help _you_ ,
| not _them_ - and speaking of which, it taught them better than
| to talk out of turn, let alone to question the people they work
| for.
|
| (...satire aside though, you do know standups can be done in
| the afternoons, right?)
| mrguyorama wrote:
| Don't forget having HR regularly discourage sharing salary
| for some bullshit reason in flagrant disregard of labor laws.
| ryandrake wrote:
| > Hire randomly
|
| > Never put in the work to identify potential candidates based
| on their contribution to the industry or relevant projects.
|
| Corollary: _Never promote internally_
|
| If there is someone on the team interested in and capable of
| stepping up to become a team lead or manager, ignore him or
| her, and instead hire someone externally for the leadership
| role. Bonus: Always use the excuse "Gosh, we can't find any
| good internal candidates, so we grudgingly need to look outside
| the company for leaders!"
| superfrank wrote:
| > Do a daily stand-up
|
| I absolutely disagree with this one. Both the best and worst
| teams I worked on as a developer both had daily stand ups and
| the frequency, length, and process was nearly identical. If
| daily stand ups are a problem for your team, it's usually a
| symptom of a bigger problem, not a cause.
|
| I'm a manager now and I have multiple teams who report up to
| me. Personally, I hate daily stand ups so when I took over a
| new team last year, I floated the idea of switching them from 5
| stand ups a week to 3 a week and they unanimously vetoed it. Of
| all the teams who report to me, they're actually the one that
| does the best work and are the most independent.
|
| If you feel like your manager or PM is micromanaging, removing
| your daily stand up isn't going to fix that. They're just going
| to micromanage you though a different medium.
| neilv wrote:
| > _If daily stand ups are a problem for your team, it 's
| usually a symptom of a bigger problem, not a cause._
|
| I'm sure that's true for some teams, but daily standups can
| also be a problem for teams that are functioning well.
|
| What if the daily standup routine isn't highlighting problems
| (nor otherwise helping), but it's just wasting time, throwing
| off flow, or frontloading a bunch of distractions into
| people's brains first thing in the morning?
|
| What if people have to contort their schedules to do it
| (either starting before they're woken up or done their
| morning exercise, or interrupting the flow of early-risers
| who'd already dug into their work)?
|
| What if the team members are good at async collaboration, and
| have a good sense when on-demand real-time is worthwhile, so
| daily synchronous standups seem like someone else needs
| help/nudge to learn the skills of the other team members, to
| avoid sabotaging a high-performing team's effectiveness and
| morale?
| CSMastermind wrote:
| Daily stand-ups are a problem when people don't understand
| the purpose of the meeting.
|
| Social bonds are built through repeated casual social
| interactions. Standups are a mechanism for building social
| bonds within the team by creating an environment where they
| take place.
|
| If you think that standups are about status updates or
| resolving blockers than you're being led astray.
| go_discover wrote:
| A stand up is fine if the team wants to do it. Once it's
| dictated from above and run by a manager it's lost all worth
| KerryJones wrote:
| I enjoy the sentiment of Charlie Munger of "invert, always
| invert" or "All I want to know is where I'm going to die, so I'll
| never go there."
|
| I wish there was more to this list? There's so many more things
| that can go wrong, a short list: - Asking for input from the
| team, then ignore it - Gaslight engineers to thinking that other
| people think they are "bad at X" - Set out clear expectations,
| and then change them - Forget about previous conversations and
| insist they didn't happen
|
| etc. etc.
| arc9693 wrote:
| And when devs come asking for leaves, show authority by asking
| them to reschedule their leave plans for later dates and attend
| to current priority- making better soup.
| fidotron wrote:
| "Happy development teams are all alike; every unhappy development
| team is unhappy in their own unique way."
|
| Tolstoy was right. There are infinitely many ways for a team to
| be toxic and only one way for them to be happy.
|
| A shared sense of a common goal, knowing how each member uniquely
| contributes to that goal, and a common respect for the value of
| those contributions. Deviate from that and you get in trouble.
| CoastalCoder wrote:
| Never require the documentation to be complete and accurate!
| Neither as a gating criterion for merge requests, nor even as
| part of a larger effort!
|
| This ensures job security for the in-crowd who already knows the
| code base, and ensures only super-geniuses can later join their
| ranks.
| mgkimsal wrote:
| If someone _does_ contribute tests, nit pick the format and
| style of the test, vs what the test exercises. Formatting and
| style and variable naming are the truest ways to ensure project
| success.
|
| Also, if someone contributes tests, never run them yourself.
|
| Bonus points for making changes in other peoples' code without
| even running it locally before committing and pushing up.
| teeray wrote:
| Remember that if one of your team members has a good idea about
| how to improve the codebase or the process that you should
| acknowledge that it's a good idea and tell them how much you like
| it. Then you should always remember to tell them that it's "not
| the right time" so you can then move on to demand status updates
| on features.
| dxdenton wrote:
| If said teammate decides to follow through on his idea without
| your explicit permission, transfer him to another team ASAP
| (without his approval). No teammate can show initiative, self-
| direction, or autonomy. Furthermore, every piece of work must
| be represented in JIRA and every team member must report on it
| --- daily.
|
| This happened to me recently. Yes, I'm a little salty about it.
| Although it's probably for the better, as this guy is no longer
| my manager. For the record, my super-great-idea was upgrading
| some 5+ year old software that was giving us and the devs a lot
| of headaches. I was told it could not be done, and it would be
| replaced by The Next Great Thing, which would take 6-8 months
| of engineering. I upgraded the thing in a day (in dev) just to
| prove that it could be done. Despite praises from my teammates
| (and devs) I had undermined The Manager. Although I know he
| wanted to, he could not berate or yell or force me to rollback
| --- imagine telling dev we are rolling back to a five year old
| version. In any case, ten years in and I've learned that the
| manager is a hard cap on the productivity of a team. The most
| productive team I've been on did not have a manager. We didn't
| need a JIRA board or a roadmap or someone to help us plan or
| prioritize. We simply got our work done. Imagine that.
| robertlagrant wrote:
| > We didn't need a JIRA board or a roadmap or someone to help
| us plan or prioritize. We simply got our work done. Imagine
| that.
|
| How did you prioritise?
| jcon321 wrote:
| In reality I know what you mean, but not a good look for you
| imo. Imagine that upgrade causes an issue upstream and
| someone has to explain who approved it. There's always a way
| to get housekeeping items approved, sneaking it in isn't it.
| peteradio wrote:
| It was in dev environment which I doubt in his world
| required any sort of management approval.
| peteradio wrote:
| > We simply got our work done. Imagine that.
|
| Well what happened? Why did you leave? It sounds great!
| Swizec wrote:
| My favorite tool when someone suggests a code improvement is to
| say _"Cool! Love that. Make it so"_
|
| Then usually nothing happens. They didn't think it was good or
| important enough to use _their_ time, they just wanted others
| to Do Better. Oh well
| bombela wrote:
| Or they were actually asking for time to officially work on
| it. Thinking their superior must have a good view of the big
| picture. Waiting confirmation that their idea made sense in
| the grand scheme of things.
| Swizec wrote:
| In that case giving them permission does the trick and the
| improvements happen. Huzzah!
|
| The other side is making sure to always plan for enough
| slack in the system so people have time for these things,
| if they choose to use it.
| ianmcgowan wrote:
| AKA "The Wally Reflector" from Dilbert :_)
| Swizec wrote:
| Looked that up thinking I'll disagree, but actually yes. As
| you grow in your role, you get to a point where the number
| of incoming "quick requests" outpaces your ability to keep
| up.
|
| To most people they're just asking for a quick 10 minutes
| of your time, what's the big deal. But they don't see the
| other 20 people doing the same thing. If you devote 200min+
| of every day to fulfilling others' requests, when will you
| have time to do your own work?
|
| The problem grows only worse the higher in the org chart
| (formal or informal) you get.
|
| Someone like a VPofEng may have 100 people asking "quick
| questions" all the time. Without the Wally Deflector,
| there's literally not enough time in the day to even have
| all these conversations, let alone do anything about 'em.
| nineplay wrote:
| I have a feeling you're being sarcastic but this isn't terrible
| advice. I've seen a lot of dysfunction caused by that one
| engineer who constantly complains about the current code base
| and tell everyone how it should be done. If a tech lead can get
| them to quiet down and move on it will do the whole team a lot
| of good.
| dhbanes wrote:
| I always immediately approve implementation of any good idea
| regardless of roadmap or resource availability.
| AceJohnny2 wrote:
| Ah, the luxury of no deadlines...
| marcosdumay wrote:
| Looks like good long-term project stewardship.
|
| If somebody just improved _all_ future deadlines at the
| expense of a delay in one, isn 't it great? (Yeah, there
| are a few times when it isn't; but if those are not few
| enough to be clearly communicated, your management is a
| bunch of dummies.)
| LargeTomato wrote:
| YES. Fake praise and empty, kind words will get you far.
| Unfortunately I learned this far too late. To me it feels gross
| and manipulative but that's what people want.
| pydry wrote:
| The non dysfunctional way to deal with this is to allocate
| between 20% of dev time to process improvements and vote on
| large scale changes.
| CoastalCoder wrote:
| Ensure you use the dysfunctional version of that, where some
| individuals are always outvoted.
|
| Over time, they'll become some of your favorite object
| lessons about employee engagement!
| seattle_spring wrote:
| Every place I've worked has had a "20% tech debt" time.
| Universally, it's used as a reason to _not_ fix technical
| debt as opposed to enabling engineers to fix long-standing
| problems. "Oh you need to re-write such and such? Well
| that'll take 40% of your time for 3 weeks and the max time we
| can allocate is 20% so..."
| Scubabear68 wrote:
| I would add "make toxic competition among team mates mandatory,
| and make it clear the winner will be well treated". Then step
| back and watch the vicious infighting begin.
|
| Double points if you tie this to financial reward like bonuses.
| [deleted]
| ourmandave wrote:
| Reminds me of the book _How to Make Yourself Miserable_ by
| Greenburg and Jacobs.
|
| They don't care _why_ you want to be miserable, ( "Perhaps you
| thought of spraying Black Flag on your father's Cheerios."), they
| just tell you how.
| PeterStuer wrote:
| It's easy. Hire one bad narcissist. Keep praising and promoting
| them.
| Moto7451 wrote:
| Not so fast, it's easy to start but you really need to invest
| in a long term plan to hire their poorly behaving friends from
| past jobs too. They'll never let you forget that they are all
| high performers, how bad everyone else that works there is, and
| how lucky you are to have them save you from yourself.
| mrguyorama wrote:
| Don't worry, every narcissist's first step when gaining power
| is to build a powerbase of controllable, weak, assholes who
| put loyalty to them above all else.
| fredley wrote:
| Better if they're the CEO in my experience. Then it trickles
| down the whole org.
| refulgentis wrote:
| Narcissist has become exponentially more abused over the past
| couple years.
|
| I've ended up leaving it for people who are attention-seeking,
| in common culture it is reduced to "people I have conflict with
| who I don't think care about other people", which has some
| irony, that's how a narcissist would perceive many
| interactions.
| samtho wrote:
| From Mayo Clinic:
|
| > Personality qualities include thinking very highly of
| oneself, needing admiration, believing others are inferior,
| and lacking empathy for others.
| [deleted]
| wahnfrieden wrote:
| Achieve massive profits through a team's output, then thank and
| congratulate the team by informing them their reward for their
| performance is to revisit their wages next year and update it to
| your own index of current wage market averages
| 23B1 wrote:
| One of the worst aspects of specialization of the workforce (hard
| skills) has been the complete lack of focus on developing
| management and leadership (soft skills).
| blueridge wrote:
| Take everything your senior but not executive direct reports
| write up at your request, make a copy of the docs, then share the
| copies with your executive peers as if they are your own words
| and ideas. When your direct reports ask for an update on the
| project, or want to know why no one has commented or engaged on
| the write-ups they created, ignore them.
|
| Ask your direct report to do all of the prep work for a critical
| project that they are most qualified to run and oversee, ask them
| to share the pre-reads with a decision making group, invite them
| to the kick-off meeting, tell them five minutes before the
| meeting starts not to say a word during the meeting, or else.
|
| Show up 20 minutes late to a 30 minute meeting, then spend the
| next 20 minute talking at the group, allow for no interruptions,
| keep everyone over time.
___________________________________________________________________
(page generated 2023-07-26 23:02 UTC)