In my experience retrospectives are just lip service. Managers who attend use them as an opportunity to make excuses for the company and focus on what’s wrong with you, the employee, and what you can do better. People eventually realize that the smart thing to do is to stop making yourself an easy target for down-sizing by not speaking up. Then when someone has a complaint about the development process a manager can say, “If you had such a problem with it you should have mentioned it in the retro.”
Employers who want to hear from you will foster an environment that is open to discussion and even polite dissent. When an employer formalizes that mentality and slaps a label on it you can be sure that it’s a managerial con.
One point of the post is that if you do constant retros (say every 2 weeks), within teams with the engineering manager, you can help foster an "an environment that is open to discussion and even polite dissent" (as you put it).
As a VP Eng, I've found that it can definitely hurt for upper management to get involved in retros. I try really hard to create bottom-up empowerment where individuals and teams can solve problems and improve their processes independently. That kind of ownership is really powerful. Retros really help with that. Plus, from my perspective, I can just read retro-notes to find common threads across teams that may require my help to improve or fix (e.g., if we're consistently underinvesting on testing or if aren't providing enough avenues for career growth or ...).
I obviously can't speak to your experiences, but what you're describing sounds really dark: management "conning" management. I hope you've been able to get away from such places!
This is literally what I did as a VP Eng. I let the teams drive the improvements and kept my role to a) ask questions to help the team identify areas of improvement and b) help implement the changes when necessary. The result was that I had many teams with fairly different processes, definitions of ready & done, etc. but that was the whole point. It's all about what helps the team work best, and ownership of the process along with the result goes a long way.
When there are actual management problems happening, probably it's also not so comfortable for the manager to get criticised as a single person, no matter how polite it is. So jointly discussing topics should probably happen regularly.
Comments
In my experience retrospectives are just lip service. Managers who attend use them as an opportunity to make excuses for the company and focus on what’s wrong with you, the employee, and what you can do better. People eventually realize that the smart thing to do is to stop making yourself an easy target for down-sizing by not speaking up. Then when someone has a complaint about the development process a manager can say, “If you had such a problem with it you should have mentioned it in the retro.”
Employers who want to hear from you will foster an environment that is open to discussion and even polite dissent. When an employer formalizes that mentality and slaps a label on it you can be sure that it’s a managerial con.
One point of the post is that if you do constant retros (say every 2 weeks), within teams with the engineering manager, you can help foster an "an environment that is open to discussion and even polite dissent" (as you put it).
As a VP Eng, I've found that it can definitely hurt for upper management to get involved in retros. I try really hard to create bottom-up empowerment where individuals and teams can solve problems and improve their processes independently. That kind of ownership is really powerful. Retros really help with that. Plus, from my perspective, I can just read retro-notes to find common threads across teams that may require my help to improve or fix (e.g., if we're consistently underinvesting on testing or if aren't providing enough avenues for career growth or ...).
I obviously can't speak to your experiences, but what you're describing sounds really dark: management "conning" management. I hope you've been able to get away from such places!
This is literally what I did as a VP Eng. I let the teams drive the improvements and kept my role to a) ask questions to help the team identify areas of improvement and b) help implement the changes when necessary. The result was that I had many teams with fairly different processes, definitions of ready & done, etc. but that was the whole point. It's all about what helps the team work best, and ownership of the process along with the result goes a long way.
When there are actual management problems happening, probably it's also not so comfortable for the manager to get criticised as a single person, no matter how polite it is. So jointly discussing topics should probably happen regularly.