“Our most recent survey closed quite a while ago, but I’ve yet to share the actions we’re taking based on it. We don’t want to send people the signal that they filled out the survey for nothing. But I have so many other things to do, and there’s a mental barrier because I need to think of how I am going to analyze it.”

Does this sound familiar? I recently heard it from a Staff Software Engineer who ran a developer experience survey for their 300-person engineering organization.

Fortunately, you don’t have to base your survey follow-up just on a top-down prescription, but you can involve everyone in the process. Letting teams own their improvement not only takes work off your shoulders but puts the engineers' first-hand experience and creativity to use.

Sure, there are some problems teams can’t solve locally, so leaders still have a role to play. Engineering managers should identify gaps, widespread patterns, and impediments flagged by the teams. You get the best results by combining bird’s-eye panorama with ground-level savvy.

Survey retrospectives are one tool in your kit for facilitating those bottom-up insights. These sessions help teams gather the full story behind the responses, identify focus areas, and collaboratively create action plans.

Developer survey retrospective

• Meeting size: up to 10 people
• Preparations: 20 minutes (all participants)
• Meeting duration: 1 hour
• Tools needed: physical or virtual board, sticky notes, note-taking equipment

Before the retrospective

Share survey results: Everyone should come to the meeting with a good understanding of the data and initial thoughts on the most pressing issues. If you have trouble getting people to review the survey results before the session, you can allocate time for self-study at the beginning of the meeting.

Assign roles:

• A facilitator to guide the discussion and keep everyone on track
• A note-taker to document the discussion, decisions, and action items

During the retrospective

Part 1: Topic selection

Start by agreeing on the 2–5 most important topics or questions to discuss. These could be based on various factors from the survey results:

• Questions with exceptionally high or low ratings
• Changes from previous surveys
• Differences to other teams in your organization
• Differences to industry benchmarks
• Questions that got the most comments
• Questions that were skipped the most often

The priority order might emerge naturally, or you could give everyone three votes to help you choose. Ask the team to also select one topic where you did particularly well and would like to praise each other.

Collect the selected topics somewhere where people can see them.

Part 2: Structured discussion

Go through each topic one by one:

1. Review the data: Look at the relevant survey results together, including any open-ended comments.
2. Collect context: Ask team members to provide more background and propose solutions. If you’re faced with silence, you can ask questions like:
   • “Can you share an example of when this happened?”
   • “What would ‘better’ look like for this topic?”
   • “What’s something we’re already doing well in this area?”
   • “If we had unlimited time and resources, how would we tackle this?”
3. Record action items: Before moving to the next topic, agree on actions you’re going to take to address the matter.
4. Identify broader issues: Take note of problems your team can't or shouldn't solve on its own. These might be organization-wide obstacles that require attention from the leadership.

Part 3: Wrap-up

Before ending the session, assign owners to each action item and decide on how you'll follow up on them (e.g., weekly check-ins or the next retrospective).

After the retrospective

• Share notes: Post the retrospective notes to the entire engineering department. This promotes transparency and may help other teams dealing with similar issues.
• Highlight organization-wide problems: In your shared notes, emphasize any issues you identified that seem to be common across teams or require attention at a higher level.
• Escalate appropriately: Reach out to your engineering managers about the topics your team needs outside help with.

Tips for success

• Manage time: Keep discussions on track. If a topic is taking too long, consider creating a separate meeting to dive deeper into it.
• Encourage participation: Ensure everyone has a chance to contribute. Some team members may need gentle encouragement to share their thoughts.
• Follow through: The effectiveness of these retrospectives depends on implementing the agreed-upon actions. Regular follow-ups between retrospectives can help maintain momentum.
• Iterate on the process: After each retrospective, gather feedback from your team on the process itself and improve the format accordingly.

Surveys don’t improve developer experience — action does. If people don’t see meaningful change, they won’t bother filling out the next survey. Running a retrospective is a practical way to turn feedback into progress. The key is making it a habit, not a one-off event. This way, there’s no need to procrastinate with your next survey follow-up.

Run better developer experience surveys

If you’d like to run better developer experience surveys, you can now do that with Swarmia. Get started today.

Learn more