liveBook · Manning

Feedback

As explained in Think Like a Software Engineering Manager

A feedback mechanism is a process or structure for collecting information about experiences, performance, or conditions.

An engineering manager hears that a new working-hours policy is making it harder for teammates to manage personal obligations. Feedback is the information that makes the problem visible—and creates a chance to change course. It can also show what is working, reveal a skill gap, or help someone recognize a strength. Treat it as guidance for a next step, not simply as criticism. section 3.3.1 section 15.3.6

Keep feedback useful by making it a two-way, ongoing practice:

  • Ask for it. Use one-on-ones, regular check-ins, and, when candid input is hard to obtain, anonymous surveys. Ask about concerns early enough to act on them. section 3.3.1 section 8.4.1
  • Give it with care. Connect specific, data-backed observations to expectations and individual goals. Recognize strengths as well as areas for improvement; offer resources and follow up. section 2.5.9 section 4.3.4
  • Make room for a response. Listen before addressing pushback, invite questions, and avoid surprises in performance reviews by discussing concerns in earlier one-on-ones. Share feedback without unnecessarily identifying its source. section 4.3.4 section 4.2.1
  • Receive it without defensiveness. Request specific instances, look for blind spots, and turn what you learn into a development plan or a change in practice. section 15.3.6 section 3.3.1

Choose the channel to fit the purpose. A check-in can clarify a delegated task before work begins; peer input can inform coaching; a prepared performance review can bring together achievements and team feedback. Periodic surveys can surface broader concerns about tools, processes, career growth, or leadership. Collecting input is only the start: discuss it, decide what support or change is needed, and check whether it helped. section 5.4.1 section 4.3.3 section 8.4.1

From peer feedback to support

An engineer misses a project milestone. Peers report difficulty taking ownership and responding to technical discussion. In a one-on-one, the manager shares the feedback and learns that the engineer is struggling with the service codebase. They arrange mentoring, document skill gaps, and review progress. Two months later, another round of peer feedback shows improvement. The manager also revisits onboarding documentation so the next engineer has better support. section 3.2.6

Feedback can guide decisions beyond individual performance. During an organizational change, seek early reactions and adjust execution where warranted; expect some friction and keep discussions open. When feedback is difficult to hear, ask what it tells you and what you can do next. section 13.2.4 section 15.3.6

How Think Like a Software Engineering Manager covers it

How deep it goes
Develops practical channels and conversation habits, from check-ins and surveys to data-backed reviews and follow-up, without prescribing one universal script.
Examples
Uses a working-hours policy, a missed project milestone, and periodic employee surveys to show different feedback loops.
What it assumes
Assumes an engineering-team workplace, while explaining feedback through everyday management situations rather than requiring prior management experience.
What you can do after
Practice/perform two-way feedback by gathering specific input, discussing it constructively, acting on it, and checking progress.
How it connects
Links feedback to psychological safety, one-on-one meetings, performance reviews, coaching, delegation, and organizational change.

Also explained in

Compare how 18 books explain feedback →

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.