So you're giving your team space to innovate, and together you've identified an area in your process that could be improved.
But no one has any idea how to fix it.
For instance, let's say you've clearly identified that the number of bugs and regressions getting into production has risen sharply in the last few weeks.
The naive way to deal with a problem like this is to say "Hey everyone, there have been a lot of regressions lately. We need to be on our toes and more careful about our code." A slightly more effective thing to do is to then start measuring the number of regressions over time and checking in periodically to see if it's improving.
The more solution-oriented approach is to start asking why, and not stop until you get to a root cause with a concrete behavior that can be addressed at an organizational level. For instance:
Problem: Lots of bugs and regressions getting into production lately
Q: Why are bugs getting into production lately?
A: Because some PRs don't include unit tests
We could stop here and say "Everyone write unit tests". Instead, we ask again:
Q: Why do some PRs not include unit tests?
A: Your newest developer speaks up and says he didn't know he was supposed to be writing them (gasp!).
We could stop here and say "Well now you know. Please write unit tests." Instead, we ask again:
Q: Why did he not know he was supposed to be writing unit tests?
A: Because it's not written down anywhere, and everyone assumed he knew.
We could stop here and say: "Someone write that down somewhere." Instead, we ask again:
Q: Why is it not written down anywhere?
A: Because we have no system or precedent for documenting our operating procedures, or for peer code review.
That one feels good and actionable. Now you can figure out the places in your process to start introducing some low-maintenance documentation of operating procedures. Along the way we've also clarified for our newest developer that he should be writing unit tests. Much more importantly, we've improved a foundational way that we operate as a team, which will pay off on other fronts.
Treat your processes like you treat your software. When you find a bug in the system, don't stop investigating until you find the root cause. You'll create a positive feedback loop that strengthens your team, establishes a strong culture of ownership and improvement, and most importantly, prepares you to you grow.