Not having high trust in people (either because you can’t give it or because someone doesn’t deserve it) is a more fundamental problem that can’t really be solved with process so I don’t think it’s a reason to avoid or discount shape up. If anything, Shape Up would give individuals a chance to grow in those areas that require giving/getting high trust.
I’ve distinctly seen two buckets when initially implementing, those that try to adapt Shape Up into past ways of thinking and those that adopt their own approach to fit with Shape Up. I honestly think the people who actually read Shape Up cover to cover are the ones who can shed the past more easily. It becomes easier once you get a few cycles with successful hill charts, scopes, etc. and can use them as examples for others.
If previous processes requires the people now called “Shapers” to be fully engaged in execution, and now they’re completely hands off, yes it will be impacted if others depended on them. We haven’t found any way around product managers being completely hands off during the cycle. It doesn’t really seem practical and it also doesn’t really seem to be a fundamental principle of Shape Up. I might be biased though because I don’t want to be completely hands off but I’m also not being pushy or just checking status, actually solving problems with the team is where I want to get involved. Shapers also have to be involved when it comes to making trade offs unless they’re crystal clear about must haves and nice to haves which is never the case.
We don’t find larger cycles being too much risk, what we find more often is that we need to weave small batch projects between larger batch so that we can focus on either customer-specific requirements or small refinements that we consider to be blocking larger progress. I think this will smooth out over time and we’ll do more big batch cycles than small with some mind set changes - for example, if something is working but engineering thinks it needs to be refactored, then make sure that’s being taken into account when de-risking a project that touches that part of the code base, so they can leave it better than they found it, rather than dedicating a project to black-box changes.