liveBook · Manning

Continuous improvement

As explained in Think Like a Software Engineering Manager

A feedback loop is a recurring process in which information about results or behavior informs subsequent actions or adjustments.

A cross-functional project can be on schedule while partners still struggle with unclear decisions or competing priorities. Continuous improvement means regularly gathering information about what is happening, using it to make an adjustment, and checking the results again. Feedback only becomes a useful loop when it informs what happens next. section 9.2.5 section 13.2.6

A practical loop has four parts:

  • Gather perspectives. Use stakeholder one-on-ones, team retrospectives, input from other managers, or an anonymous survey when people may be reluctant to speak openly. section 9.2.5
  • Look for patterns. Compare successes, gaps, concerns, and trends rather than treating one response as the whole picture. section 13.2.6 section 9.3.1
  • Choose an action. Address concerns through conversation; if an organizational change needs a different direction, revise its strategy and road map. section 9.2.5 section 13.2.6
  • Measure and revisit. Check whether the adjustment helped, then use the next round of feedback to continue or pivot. section 13.2.6 section 9.5

The loop works at different scales. During project execution, check-ins help a team respond while work is underway; afterward, success metrics and a retrospective inform the next project. In change management, monitoring may reveal a gap that calls for another pass at the strategy. Neither setting requires treating the first plan as final. section 10.3 section 13.2.6

Learning from a departure

When an employee leaves, debrief them and follow up with an HR exit interview. If departures repeatedly point to compensation, bring that trend to HR and company-wide discussions rather than treating each departure as an isolated event. Talk with remaining employees about their concerns, too. The aim is to turn a difficult event into better retention decisions without assuming that one person can simply be replaced by another. section 8.4.3

Keep the loop open and transparent, especially when responses conflict or become emotional. Inviting people into decisions, explaining the reasoning, and discussing concerns can build trust; making decisions without relevant team feedback can undermine it. Ask: what have we learned, what will we change, and how will we tell whether it helped? section 9.3.1 section 9.2.5

How Think Like a Software Engineering Manager covers it

How deep it goes
Lays out feedback channels and a monitor-evaluate-adjust cycle, without prescribing a fixed cadence or measurement method.
Examples
Illustrates improvement through stakeholder one-on-ones, anonymous surveys, exit interviews, and iterative cloud migration.
What it assumes
Assumes a team or workplace decision to improve; introduces practical feedback activities without requiring a formal method.
What you can do after
Practice/perform it by collecting feedback, identifying trends, adjusting plans, and checking results again.
How it connects
Connects feedback loops with retrospectives, trust and transparency, success metrics, and change management.

Also explained in

Compare how 30 books explain continuous improvement →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a Software Engineering Manager. The section links point to the parts of the book it draws on.