41–50 of 102 posts
This ensures job security for the in-crowd who already knows the code base, and ensures only super-geniuses can later join their ranks.
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 humili…
> 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!"
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…
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.
Double points if you tie this to financial reward like bonuses.
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 humili…
> 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 too…
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…
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.
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.
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.
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.