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.

I've worked at a place where all that IS often the case: retrospectives surface issues, those issues typically get resolved, managers attend, etc.

Even at one point when we felt like retrospectives were getting less effective we actually retro'd that and made a bunch of changes to the process (namely, checking in a set number of weeks after each retro to follow-up and see whether action items were indeed followed through on)

+1 to meta-retros (or retros on retros). Once you have a group with a ton of trust, you can retro all of the things.

(and hi Ozzie)

The whole idea of retros rests on the people in the meeting having the power to change the things under discussion.

If that's not the case, it's not really a retro.

I make great efforts to make sure we follow through on action items on my team, and strong top level support has indeed transformed our entire organization and consistently makes Plaid a better place to work. Retrospectives without follow through can become very frustrating that's why action items and owners are a key component.

“why action items and owners are a key component.”

We have that too. The only thing that’s missing is follow through :)

Maybe you can discuss follow through in your retros and come up with a plan to increase that sense of ownership from the bottom up :) I know depending on your org that isn't always possible, but it's an idea!

I've been in retrospectives with middling managers and diddling directors, it's all part of the agile theatre being put on by erstwhile high schoolers