Beyond 1:1s: Building Multiple Feedback Loops That Actually Work

Manager talks to report and report listens. Maybe they push back a little. Maybe they nod and ignore it later. Then everyone wonders why improvement is slow.

I used to think the 1:1 was the primary lever for growth. If I could just have better conversations, ask better questions, give better feedback, everything would improve. But here's what I learned: single-channel feedback creates a bottleneck. You become the constraint. Your visibility becomes the ceiling. Your time becomes the limiting factor. The teams that actually improve are running multiple feedback loops at the same time.

The Problem With Manager-Only Feedback

I spend maybe 5-10 hours a week directly observing my team's work. The rest of the time, I'm in meetings about the work, not doing the work. My team members spend 40 hours a week together. They see things I don't see. They know who struggles with code reviews. They know who writes unclear tickets. They know who disappears when things get hard.

Research shows peer feedback can boost performance by 14% because team members have direct visibility into the day-to-day work. They're not guessing based on status updates. Most teams don't have a system for peer feedback. They have hallway conversations and Slack complaints.

What Multiple Feedback Loops Actually Look Like

Here's what I've built over the last few years.

Monthly Anonymous Survey

I send a survey every month. It's truly anonymous. I don't track emails or try to figure out who said what.

The questions are specific:

  • Am I helping you remove blockers or creating them?

  • Do we have too many meetings? Not enough?

  • What's one thing I should start doing?

  • What's one thing I should stop doing?

Then there's a blank section for anything else. I take the feedback and slowly work it into 1:1s. Not to figure out who said what, but to get more context. Once psychological safety is established, I bring it to the team meeting to discuss openly. This creates upward feedback without the political risk of saying it directly to your manager's face.

Code Reviews as Feedback Infrastructure

Code reviews are a feedback loop most teams already have. But they treat it like a quality gate instead of a learning system. I watch how code reviews change over time. Are people still getting tons of feedback on basic stuff? That means trust hasn't been built yet. Are reviews getting shorter and more focused? That means learning is happening. The pattern tells me more than any 1:1 conversation about growth.

Retros That Actually Surface Problems

Real psychological safety isn't when everyone is nice to each other. It's when the team can call each other out. Direct and kind. I had a team that agreed to put acceptance criteria in every ticket. They all nodded. They all agreed it was important. Then nobody did it. Nobody called anyone out for it in retro. I had to be the one to bring it up. That's when I knew psychological safety was broken. The team didn't trust each other enough to hold each other accountable. A working feedback loop means the team corrects itself without waiting for the manager.

Cross-Functional Feedback From Outside the Team

Your team works with other teams. Product managers. Designers. Other engineering teams. Those people see things you don't see. They know if your team is easy to work with or a pain. They know if communication is clear or confusing. They know if commitments are kept or broken. I ask those stakeholders directly: "How's it going working with my team? What could we do better?" Then I bring that feedback back. Not as blame, but a way for us all to grow and learn. This creates a loop that catches problems I'd never see from inside the team.

The Self-Assessment Loop

The most overlooked feedback loop is self-assessment. I give my team work that challenges them. Then I watch how they react. Do they push back because they're afraid? Or because it's genuinely out of scope? Are they implementing feedback I gave them three months ago? Or are they still making the same mistakes?

If someone wants to move up and the next level requires public speaking, are they finding opportunities to speak? Are they asking for feedback on their presentations?

Behavior tells me if learning is happening. Research suggests that observing peer work and then self-evaluating produces better outcomes than just receiving feedback passively. The loop works like this: You watch how others do it. You try it yourself. You compare. You adjust.

Most teams skip the observation and comparison steps. They just wait for the manager to tell them what to do differently.

Why This Matters More Than You Think

Here's the retention math that most managers miss. 67% of employees cite poor management as their reason for leaving. Not compensation. Not benefits. Management. 62% of workers want more frequent feedback and recognition. Single-channel feedback can't deliver that. You don't have enough time. You don't have enough visibility. But multiple feedback loops can. When someone gets useful feedback from a peer, that's recognition. When the team holds itself accountable in retro, that's feedback. When cross-functional partners say "your team is great to work with," that's recognition.

You stop being the bottleneck. Growth happens without you.

The Mistakes I Made Building This

I tried tracking velocity metrics early on. I thought if I could measure output, I could help people increase it. It became a weird hindrance. People started gaming the numbers instead of focusing on actual work. I learned that feedback loops need to serve learning, not measurement.

I also learned that you can't force feedback loops into existence. You have to build psychological safety first. When I had two team members who developed a toxic relationship, knowledge sharing stopped. They used vulgar language in public channels. They stopped helping each other.

No amount of process would fix that. I had to address the relationship directly. Feedback loops only work when people trust each other enough to be honest.

How to Start

You don't need to build all of this at once. Start with one additional feedback channel beyond your 1:1s. If you don't have upward feedback, start there. Monthly anonymous survey. Three questions. See what you learn.

If your team doesn't hold each other accountable in retros, focus there. Ask them directly: "Why didn't anyone bring up the acceptance criteria problem?"

If you're not getting feedback from other teams, schedule 30 minutes with a product manager or designer who works with your team regularly. Ask what could be better.

The goal isn't perfection. The goal is creating multiple sources of truth so you're not flying blind. 80% of employees who receive meaningful feedback weekly are fully engaged. But that feedback doesn't all have to come from you. In fact, it works better when it doesn't.

What This Actually Produces

When feedback loops are working, you notice a shift. People stop waiting for you to tell them what to do. They start asking each other. Problems get surfaced earlier. In retros, not in 1:1s three weeks later.

Growth becomes visible. You see someone implement feedback without being reminded. You see trust build through code reviews getting cleaner. You stop being the constraint.

Your job changes from "person who has all the answers" to "person who built a system where answers emerge." That's what multiple feedback loops actually do. They distribute the work of improvement across the entire team. They make your 1:1s better, because you're not trying to do everything in that one conversation.

The Question That Matters

What feedback channel are you missing right now? If you're the only source of feedback for your team, you're the bottleneck. And bottlenecks eventually break. Build one more loop. See what changes.

Next
Next

Post-Mortems That Don't Kill Trust