Dysfunctional Engineering Teams
Comments discuss frustrations with poor code quality, untested code, bad leadership, and team dysfunction, offering advice on communicating issues to managers, building consensus, or leaving for a better job.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Have you tried talking to the tech lead and asking him what gives? There is a very high chance that he doesn't even realize what he's doing. Be charitable - give him the benefit of the doubt and be non confrontational.
Probably they resent you. What feels like a good solution is discussing this in the retrospective or have an informal discussion about this. Then again, team members need to be open to discussing this and viewing it from another angle.Also, by discussing the issue you might discover others feel the same way and are open to changing the process.
For a person of many years of experience your friend is the problem. He has agreed to push untested code which is his responsibility, enabled other teams to work out of schedule and him producing dangerous results. All these without any indication that he sought approval from upper management. Why would you use the word "complaining" when communicating an issue? State the facts and how they diverge from the formal process, flag parts of the process that are problematic due to lack of r
hey, not an engineer but this could happen to any teams.If you are doing this two things, you should do well.1. Take care of yourself first. It is easier to act the right way and manage any situation when you are mentally and physically fit.2. Take a step back and count your breath before reacting. Always assume the other person is hungry, stressed, have family issues, anything. Do not take any thing personally. Give yourself space and address this later.Also show an effort in your q
It appears the team lead is the problem. Explain the situation to the team leadβs supervisor / the founders.
It sounds like your org is lacking in some basic leadership. If issues are brought up in the code it either needs to be corrected or justified with the team.
People don't pay you for your (team's) code, people pay you to solve their problemsLearn to listen & talk to your managerLearn to listen & talk to your userLearn to be a bad cop, stay away or even fire those who negatively impact the team ASAPI'm not writing to you, I'm writing to myself :p
It has nothing to do with "BigCo" or not.If you work in a small company, pretty much any boss will be happy to hear feedback like "Hey, it looks like there's an impediment to smooth work, and the team has gotten used to it, but it's costing us". Bonus points if you propose a solution.(If your manager isn't happy to hear that, it's time to leave, because small companies closing their eyes to this have a tendency to go down in flames)But you
Please sign me up!I had at least a dozen projects in as many months started, reach a completed state, then canceled.I'm on a very small team, I am the only expert in infrastructure, but all infrastructure code is reviewed by the lead engineer who is a complete novice at AWS/GCP. I've written thousands of words of documentation and had entire weeks of phone calls to explain what is going on and the rationale behind decisions. Those efforts have thus far been in vain, and larg
Sounds like the team you were in back then was a bit dysfunctional but if you feel rage and shame over SW bugs in your codebase you need to address that first as it's a disproportional reaction to normal things happening in programming. Speaking up immediately but calmly when you get blamed for something you didn't do would be a good skill to acquire.