4 ms·
> Having high aspirations for yourself is great. Helping raise the bar through leading by example and mentoring your peers is great. > Running to your manager
by BeetleB 5y ago
> Having high aspirations for yourself is great. Helping raise the bar through leading by example and mentoring your peers is great.
> Running to your manager every time you feel dissatisfied with someone else's performance and arriving with only complaints is, however, not great.
There's a problem with this framing. The two are not exclusive. Complaining to your manager doesn't mean you are not leading by example and mentoring. The other problem is assuming the person complaining to the manager fits this profile:
"Running to your manager every time you feel dissatisfied"
While I'm sure such folks exist, most people who complain do so rarely, and lumping the two together equates to dismissing legitimate concerns.
There are no clear cut rules on what the right answer is. I believe that each person should set standards for work, and stick to them. If a problem arises, there are 3 choices:
1. Try to solve the problem (ideally in a positive manner).
2. Change jobs.
3. Make a compromise and live with it.
In my experience, most people choose 3, and it inevitably just means lowering your standards over and over again. These are the people who complain most about their jobs yet do nothing about it, and will have a lengthy narrative about why that is.
Choice 1 is the highest risk, highest reward scenario. It takes a lot of skill (social, political, etc), so be prepared to learn those skills. But if you succeed, that experience gets you very far and those skills are valuable.
Choice 2 is usually low risk, with medium reward. I've never regretted leaving. Every time I intended to leave, I was told I should suck it up, toughen my skin, and it will be crap everywhere. I always ended up at a better place. Also, see https://xkcd.com/1768/ https://xkcd.com/1768/
From the comments here, I think people are projecting a bit too much. Take some real examples:
You work in a SW team, and a peer who has many more years of experience than you is the lead for a particular project. He doesn't want you making branches for different experiments, as "branches complicates things". Instead, there will be only one development branch and you have to make command line arguments with switches in the code for all the various experiments you need to do.
The customer (also a SW person) was in the meeting and politely points out to the team lead that he thinks SW development would be much easier with branches than with lots of command line options, and the code would be cleaner. The team lead disagrees.
What do you do?
In this case, I didn't complain. But leading by example wouldn't solve the problem as he's the tech lead. Instead, I engaged in some politics to get myself off the project. I was the lead in some other projects and I put my efforts there. Better to work on projects where you can contribute 100% than work on ones where you're hampered.
In a team I was once in, there were a number of "problematic" people, but one of them was particularly a pain - interfered with lots of projects he was not involved in, enforced solutions in those projects without understanding the problem domain, etc. Within a year I could see from the manager's interactions that he very clearly was not willing to address any behavioral issues of any person. And it was evident without me even bringing this up to him.
Folks: Don't lead by example in those situations. The best option is to leave. Such a manager becomes a magnet for problematic people. If you have enough clout, you can go to senior management, but if you're a junior person like me, you won't have that clout, and those who stay long enough to have that clout clearly are OK with the status quo.
Some years after I left the team a former coworker who's still there is having serious issues to the person, and it's becoming borderline harassment. While I didn't witness clear harassment in my time there, I did have the foresight to document everyone's poor behavior - so I got the word out to the former coworker that if he wants to take formal HR action, I can supply them with what I've witnessed.
He did complain to the manager, and as expected, the manager is treating it as merely a relationship issue. The point? Managers who are unwilling to address these issues have a higher chance of getting seriously problematic team members who will exploit the reluctance to their advantage.
- mejutoco 5y ago> You work in a SW team, and a peer who has many more years of experience than you is the lead for a particular project. He doesn't want you making branches for different experiments, as "branches complicates things". Instead, there will be only one development branch and you have to make command line arguments with switches in the code for all the various experiments you need to do. It would not be my first choice, but committing on master and having feature flags can potentially be a good fit if you run tons of experiments. A company I used to work at did this and it ran very well.
- BeetleB 5y agoSome of the flags "interfere" with one another (i.e. are mutually exclusive). So you have to find all the relevant places in the code and put "if" branches. If you have 6 flags, you now have 2^6 = 64 different possible inputs to the program, and your code better handle it well. And these are all temporary. Once an experiment is over, you have to remove the flag and related if conditions. You certainly can design it well this way and abstract out the complexity, but that takes skill, and if the tech lead can't handle branches in version control, it's a good guess they won't be able to handle the abstraction needed to make it a good design either.
- mejutoco 5y agoI agree with you. I am not recommending it. It has all the problems you mentioned. I wanted to share that out there there are some decent companies doing this and it works for them / it does not need to be a red flag.
- BeetleB 5y agoYes, I too have experienced teams that compensate very well for poor SW practices, and even enjoyed some of them. I've even been in teams that didn't use version control and things worked out fine. But frankly, I'd rather not be in a team without version control, and I don't think many would fault me for discouraging others from joining such teams. There's a limited amount of time I have on this Earth, and the less time my brain spends on managing unnecessary complexity, the more time it has to do more useful things. I haven't found a team that's perfect, so there are always some compromises. I treat them as temporary compromises, though. Just because I put up with weird X behavior in a prior job and it worked out doesn't mean I should/would put up with it in future jobs.