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.
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.
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.
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.
Yeah, I was almost afraid to post my comment because it could indeed seem sarcastic to someone not in the situation, but I assure you it was genuine. We’ve had sprints where everyone was frustrated, exhausted, and morale was low, and they made it known, so I trust that they’re being honest. That being said, I also don’t think that gushing with meaningless praise all the time is necessarily good either.
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.
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.
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!
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.
>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.
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.
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.
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!!
> 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!”
> 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.
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?
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.
> 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.)
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.
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.
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.
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.
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.
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.
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?)
> 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!"
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.
> 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?
> 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?
Why don't you change the format of the meeting in a way to make it helpful?
> 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)?
Why don't you talk to your team to move the stand up to a time that's convenient to everyone?
> 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?
Then why are you having stand ups at all?
==========
(I don't know if you are the one who has those issues, but I'm going to use "you" in my response just because it's easier)
None of the things you listed are problems with a daily stand up. Almost all of them seem to be communication issues within your team where you can't or won't communicate your needs to the rest of the team. You're an adult (I assume). If something isn't working for you, speak up, take some ownership of the problem, and work with your team or your manager to find a solution that works for everyone.
Maybe everyone else on the team is getting a ton of value out of the meeting and you are not. If that's the case then it seems like the problem isn't stand up, it's you. Remember, not every meeting you attend is there to give you value. Some meetings exist for other people to get value from you. Just because you're not getting something from it doesn't mean it's a bad meeting.
On the other end of the spectrum, if you talk to your team and no one is getting any value out of the meeting, then the problem isn't the meeting, it's that your team leadership sucks and they're making everyone go to meetings that no one is getting value out of.
Daily stand ups are just a tool. Saying daily stand ups suck would be like saying hammers suck. Your may not need a daily stand up, but that doesn't mean they're bad.
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.
I've become more or less convinced that having a positive environment takes a lot of work and it's easy to go wrong - regardless of whether someone is being a bit malicious, or just makes it worse unknowingly.
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
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.
“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.
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.
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.
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.
> The most productive team I’ve been on did not have a manager.
Ive been in the weird scenario of not having a real manager a couple times. One time it was how you described. Another was pretty bad, we basically became the dumping ground for unwanted projects and tedious work because we didn't have authority to say no.
Yes, a good manager shields the team from distractions and lets them focus. I know I sound anti-mgr but I’m not. I’ve had some rly good one who gave us autonomy, trusted us, but also held us accountable. It seems most managers don’t subscribe to the servant leadership philosophy, but are prone to the dictator style (ie team members are subordinates whose role is to implement the (not shared) vision.
When there is a lot to do and you are understaffed the highest priority things are usually obvious. For instance, we keep getting repeated requests for X from dev, let’s automate it or make it self-service. Software X is severely out of date and preventing us (or dev) from implementing X, let’s upgrade it.
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.
I agree, it was a calculated risk. Without getting into the deets I was confident it wouldn’t introduce any major issues. In fact NOT upgrading had resulted in problems that affected production a few weeks prior. Would I recommend a junior engineer yolo it? Of course not. But I’d also warn junior engineers to always keep a healthy skepticism when they are told “No, this cannot be done.”
> There’s always a way to get housekeeping items approved…
Yes, at a functional software shop, upgrades and maintenance are not considered stretch items. I did my best to make the case from a technical (bug fixes and features), business (vendor X won’t support us on this version), and customer (customer wouldn’t be happy if they knew we were running version X) standpoint. However, at a dysfunctional software shop, none of those factors matter (or they don’t matter as much).
We were assigned a manager. Who immediately tried to bring in his folks from a prior job (they weren’t a good fit), force us to adopt his preferred tools (with no consideration for our skills and tech stack investment), and took over daily standup, which exceeded 30 minutes in the regular for a four person team.
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.
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.
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.
Even worse, someone actually listens to that guy, they go implement something “cool” or “elegant” that actually makes things worse, then they leave and people hate the thing even more.
I’ve seen one costly example in the wild - a problem domain was wildly oversimplified at an early stage of a project so one component was coded as a state machine. However, there were a bunch of background threads running independently of the state machine doing stuff and passing messages. And tracing code execution even within the state machine was a nightmare because a lot of what you’d think of as “call stacks” were coordinated by messaging passing between threads (mediated by the state machine controller) in a way that required you to do like 8 “find references” each time you wanted to see which function was actually getting called when a message was passed. Literally the entire thing could have just been a regular old init call making the same background threads, a regular request handler, and a regular handful of functions called if an error occurred but it was such a fucking mess we just started over in a new binary rather than trying to fix the existing one.
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.)
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.
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…”
There should absolutely be separate meetings for new idea separate status updates, and ideally status update meetings should only be for chatting about what digital updates can’t handle.
Creating useful digital over-communication in the right way can go a long way to establish the “what do you need from me so I can get out of your way culture”.
If you are getting told to ignore it by people who can’t even evaluate how bad the problem is (because they’re nontechnical or just too lazy to dig into it technically) that’s a problem.
But as a technical person who has heard this a lot and been the person complaint before too, IMO people are too eager to make these complaints (if nobody in the current team understands why something was done, that doesn’t mean it’s tech debt) or have poor ideas (more READMEs! That in 1y will go out of date and just confuse people or be deleted because the person pushing for it left. And that was the only person actively reading them) or don’t actually have a way to solve it because there isn’t one (solving bugs often involves increasing cyclomatic complexity or adding some ugly code somewhere - there may not be an elegant way to avoid that. Same with having to do something hacky with a library or framework because it imposes constraints on some edge case).
If poor codebase quality can be linked to a more tangible problem like reliability, bugs, high engineering or operational maintenance problems, etc then it should be seen as a feature to improve that. If the only impedance is development speed you really need a decision maker who has a strong understanding of how a proposed improvement would improve development speed to get a good outcome IMO, because a small improvement for a big investment (and potential risks of new bugs, or an outcome that is actually worse after all the edge cases to fix bugs are added back) may not be worth it, but conversely a big improvement for a small engineering investment could be a no brainer. It’s just, a lot of engineers propose improvements that aren’t worth it.
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.
My experience in a super toxic setup was when the ceo had one product in mind, and then task 3 teams with working on a version of the product, and said whichever best team will make one that works. You can imagine the politics that resulted.
Don't listen to engineer estimates. Instead, promise aggressive estimates to your own boss. Artificial urgency is the best because the deadline is only to impress the bosses, not for any real customer.
Later when the deadlines slide by a mere 2 weeks, blame the engineer saying that the time given to them was "generous".
Use performance ratings as a tool to set them up for failure, but only after getting the guarantee of a backfill headcount.
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.
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.
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.
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
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).
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.
debacle | 2 years ago
Seems like David Tate has had a rough go.
gwbas1c | 2 years ago
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 | 2 years ago
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 | 2 years ago
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 | 2 years ago
Ah Martha, I see you haven’t changed one bit.
temporallobe | 2 years ago
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.
dennis_jeeves1 | 2 years ago
>and the entire team gushed with praises for each other
Lol, you should add that this is a sarcasm.
temporallobe | 2 years ago
Yeah, I was almost afraid to post my comment because it could indeed seem sarcastic to someone not in the situation, but I assure you it was genuine. We’ve had sprints where everyone was frustrated, exhausted, and morale was low, and they made it known, so I trust that they’re being honest. That being said, I also don’t think that gushing with meaningless praise all the time is necessarily good either.
duxup | 2 years ago
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 | 2 years ago
[flagged]
robertlagrant | 2 years ago
@dang
dennis_jeeves1 | 2 years ago
robert, grow a pair...
sixstringtheory | 2 years ago
Doesn't this not work here? Just flag/downvote and move on.
hack34news | 2 years ago
Hire some Product Managers. EOM.
zenolove | 2 years ago
Awww. As a product manager who hopes to be serving, encouraging and fostering his team well, this saddens me to read
jdlshore | 2 years ago
I wouldn’t worry about it. HN is prone to these sorts of thoughtless dismissals.
eschneider | 2 years ago
Good PMs are rare, but good PMs are worth their weight in gold.
3-cheese-sundae | 2 years ago
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 | 2 years ago
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 | 2 years ago
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 | 2 years ago
>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 | 2 years ago
> 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 | 2 years ago
> 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] | 2 years ago
fruzz | 2 years ago
> 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 | 2 years ago
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 | 2 years ago
> 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 | 2 years ago
> 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 | 2 years ago
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 | 2 years ago
I’d also be interested to read about how to build a team that can’t succeed.
dangerwill | 2 years ago
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 | 2 years ago
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 | 2 years ago
> 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 | 2 years ago
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 | 2 years ago
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] | 2 years ago
Kapura | 2 years ago
Love it when a post crystalizes exactly why you need to leave your current job ;)
hereforthecake2 | 2 years ago
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 | 2 years ago
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 | 2 years ago
OP, don't you mean "Most people" rather than "Few people" in the first paragraph?
minorinscrum | 2 years ago
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 | 2 years ago
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 | 2 years ago
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 | 2 years ago
Don't forget having HR regularly discourage sharing salary for some bullshit reason in flagrant disregard of labor laws.
ryandrake | 2 years ago
> 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 | 2 years ago
> 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 | 2 years ago
> 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?
superfrank | 2 years ago
> 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?
Why don't you change the format of the meeting in a way to make it helpful?
> 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)?
Why don't you talk to your team to move the stand up to a time that's convenient to everyone?
> 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?
Then why are you having stand ups at all?
==========
(I don't know if you are the one who has those issues, but I'm going to use "you" in my response just because it's easier)
None of the things you listed are problems with a daily stand up. Almost all of them seem to be communication issues within your team where you can't or won't communicate your needs to the rest of the team. You're an adult (I assume). If something isn't working for you, speak up, take some ownership of the problem, and work with your team or your manager to find a solution that works for everyone.
Maybe everyone else on the team is getting a ton of value out of the meeting and you are not. If that's the case then it seems like the problem isn't stand up, it's you. Remember, not every meeting you attend is there to give you value. Some meetings exist for other people to get value from you. Just because you're not getting something from it doesn't mean it's a bad meeting.
On the other end of the spectrum, if you talk to your team and no one is getting any value out of the meeting, then the problem isn't the meeting, it's that your team leadership sucks and they're making everyone go to meetings that no one is getting value out of.
Daily stand ups are just a tool. Saying daily stand ups suck would be like saying hammers suck. Your may not need a daily stand up, but that doesn't mean they're bad.
CSMastermind | 2 years ago
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 | 2 years ago
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
KronisLV | 2 years ago
I actually wrote a similarly tongue in cheek post a while ago, called "The Unethical Developer's Guide to Personal Success": https://blog.kronis.dev/articles/the-unethical-developers-gu...
I've become more or less convinced that having a positive environment takes a lot of work and it's easy to go wrong - regardless of whether someone is being a bit malicious, or just makes it worse unknowingly.
KerryJones | 2 years ago
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 | 2 years ago
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 | 2 years ago
“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 | 2 years ago
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 | 2 years ago
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 | 2 years ago
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 | 2 years ago
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.
tayo42 | 2 years ago
> The most productive team I’ve been on did not have a manager.
Ive been in the weird scenario of not having a real manager a couple times. One time it was how you described. Another was pretty bad, we basically became the dumping ground for unwanted projects and tedious work because we didn't have authority to say no.
dxdenton | 2 years ago
Yes, a good manager shields the team from distractions and lets them focus. I know I sound anti-mgr but I’m not. I’ve had some rly good one who gave us autonomy, trusted us, but also held us accountable. It seems most managers don’t subscribe to the servant leadership philosophy, but are prone to the dictator style (ie team members are subordinates whose role is to implement the (not shared) vision.
robertlagrant | 2 years ago
> 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?
dxdenton | 2 years ago
When there is a lot to do and you are understaffed the highest priority things are usually obvious. For instance, we keep getting repeated requests for X from dev, let’s automate it or make it self-service. Software X is severely out of date and preventing us (or dev) from implementing X, let’s upgrade it.
robertlagrant | 2 years ago
Ah, gotcha. Single internal customer. Makes sense you wouldn't need much structure around this.
jcon321 | 2 years ago
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.
dxdenton | 2 years ago
I agree, it was a calculated risk. Without getting into the deets I was confident it wouldn’t introduce any major issues. In fact NOT upgrading had resulted in problems that affected production a few weeks prior. Would I recommend a junior engineer yolo it? Of course not. But I’d also warn junior engineers to always keep a healthy skepticism when they are told “No, this cannot be done.”
> There’s always a way to get housekeeping items approved…
Yes, at a functional software shop, upgrades and maintenance are not considered stretch items. I did my best to make the case from a technical (bug fixes and features), business (vendor X won’t support us on this version), and customer (customer wouldn’t be happy if they knew we were running version X) standpoint. However, at a dysfunctional software shop, none of those factors matter (or they don’t matter as much).
peteradio | 2 years ago
It was in dev environment which I doubt in his world required any sort of management approval.
peteradio | 2 years ago
> We simply got our work done. Imagine that.
Well what happened? Why did you leave? It sounds great!
dxdenton | 2 years ago
We were assigned a manager. Who immediately tried to bring in his folks from a prior job (they weren’t a good fit), force us to adopt his preferred tools (with no consideration for our skills and tech stack investment), and took over daily standup, which exceeded 30 minutes in the regular for a four person team.
jasmer | 2 years ago
[dead]
Swizec | 2 years ago
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 | 2 years ago
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 | 2 years ago
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 | 2 years ago
AKA "The Wally Reflector" from Dilbert :_)
Swizec | 2 years ago
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 | 2 years ago
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.
opportune | 2 years ago
Even worse, someone actually listens to that guy, they go implement something “cool” or “elegant” that actually makes things worse, then they leave and people hate the thing even more.
I’ve seen one costly example in the wild - a problem domain was wildly oversimplified at an early stage of a project so one component was coded as a state machine. However, there were a bunch of background threads running independently of the state machine doing stuff and passing messages. And tracing code execution even within the state machine was a nightmare because a lot of what you’d think of as “call stacks” were coordinated by messaging passing between threads (mediated by the state machine controller) in a way that required you to do like 8 “find references” each time you wanted to see which function was actually getting called when a message was passed. Literally the entire thing could have just been a regular old init call making the same background threads, a regular request handler, and a regular handful of functions called if an error occurred but it was such a fucking mess we just started over in a new binary rather than trying to fix the existing one.
dhbanes | 2 years ago
I always immediately approve implementation of any good idea regardless of roadmap or resource availability.
AceJohnny2 | 2 years ago
Ah, the luxury of no deadlines...
marcosdumay | 2 years ago
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 | 2 years ago
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 | 2 years ago
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 | 2 years ago
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 | 2 years ago
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…”
j45 | 2 years ago
There should absolutely be separate meetings for new idea separate status updates, and ideally status update meetings should only be for chatting about what digital updates can’t handle.
Creating useful digital over-communication in the right way can go a long way to establish the “what do you need from me so I can get out of your way culture”.
opportune | 2 years ago
If you are getting told to ignore it by people who can’t even evaluate how bad the problem is (because they’re nontechnical or just too lazy to dig into it technically) that’s a problem.
But as a technical person who has heard this a lot and been the person complaint before too, IMO people are too eager to make these complaints (if nobody in the current team understands why something was done, that doesn’t mean it’s tech debt) or have poor ideas (more READMEs! That in 1y will go out of date and just confuse people or be deleted because the person pushing for it left. And that was the only person actively reading them) or don’t actually have a way to solve it because there isn’t one (solving bugs often involves increasing cyclomatic complexity or adding some ugly code somewhere - there may not be an elegant way to avoid that. Same with having to do something hacky with a library or framework because it imposes constraints on some edge case).
If poor codebase quality can be linked to a more tangible problem like reliability, bugs, high engineering or operational maintenance problems, etc then it should be seen as a feature to improve that. If the only impedance is development speed you really need a decision maker who has a strong understanding of how a proposed improvement would improve development speed to get a good outcome IMO, because a small improvement for a big investment (and potential risks of new bugs, or an outcome that is actually worse after all the edge cases to fix bugs are added back) may not be worth it, but conversely a big improvement for a small engineering investment could be a no brainer. It’s just, a lot of engineers propose improvements that aren’t worth it.
Scubabear68 | 2 years ago
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] | 2 years ago
ourmandave | 2 years ago
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.
leshokunin | 2 years ago
My experience in a super toxic setup was when the ceo had one product in mind, and then task 3 teams with working on a version of the product, and said whichever best team will make one that works. You can imagine the politics that resulted.
nine_zeros | 2 years ago
Don't listen to engineer estimates. Instead, promise aggressive estimates to your own boss. Artificial urgency is the best because the deadline is only to impress the bosses, not for any real customer.
Later when the deadlines slide by a mere 2 weeks, blame the engineer saying that the time given to them was "generous".
Use performance ratings as a tool to set them up for failure, but only after getting the guarantee of a backfill headcount.
PeterStuer | 2 years ago
It's easy. Hire one bad narcissist. Keep praising and promoting them.
Moto7451 | 2 years ago
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 | 2 years ago
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 | 2 years ago
Better if they're the CEO in my experience. Then it trickles down the whole org.
refulgentis | 2 years ago
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 | 2 years ago
From Mayo Clinic:
> Personality qualities include thinking very highly of oneself, needing admiration, believing others are inferior, and lacking empathy for others.
[Deleted] | 2 years ago
wahnfrieden | 2 years ago
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 | 2 years ago
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 | 2 years ago
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.