Delegation, One-on-Ones, and Feedback

A fictional engineering manager told an engineer that a broker migration was fully delegated. The engineer planned the technical work and made commitments to partner teams, but the manager had not explained a business freeze or agreed which decisions the promise covered. In week six, she reversed the proposed timing in a hallway conversation. The engineer had to revise the partner commitments, and the reversal damaged trust in the promise.

The manager had been told to avoid interference, but that instruction did not explain how to set expectations, delegate a decision, or notice a problem early. Clear expectations, continuing conversations, and timely feedback give both parties a way to find such gaps before commitments become difficult to change.

What a manager is for

Google’s people research began, by its own account, from the hypothesis that “Managers don’t actually matter.” The multi-year study that followed, Project Oxygen, analyzed performance reviews, feedback surveys, and interviews and found the opposite: “Teams with highly effective managers were more likely to achieve better results, be happier, and experience lower turnover.” The ten behaviors it identified start with the two this article is about. The first is “Be a good coach” and the second is “Empower the team without micromanaging”. Google later distilled its research into three manager responsibilities, and the second of them reads like a syllabus for what follows: “Develop People involves setting clear expectations, providing relevant feedback and coaching, engaging in meaningful career conversations, and supporting team members’ growth by exploring development opportunities.” That is Google’s data about Google’s managers, and the page is careful to say so. The reason to quote it is not that it transfers automatically but that a large organization with a strong bias against management looked hard and found that the job is real and consists of nameable behaviors.

The UK Civil Service reached a similar list from the other direction, by writing down what it requires of every line manager. Its Line Management Standards state the core of the people-facing job in one sentence: “I set clear expectations for my team(s), using feedback and coaching techniques as part of regular performance conversations, providing honest feedback, recognising good performance and promptly addressing both poor performance and poor behaviours.” Expectations, feedback, coaching, regular conversations, honesty, promptness. The fictional manager had done none of these with the broker decision, and the reason was not that she did not care. It was that each of them is a specific practice with a specific failure mode, and she had been told only what not to do.

Expectations: write down what good looks like

The US Office of Personnel Management begins its performance-management cycle with planning: agreeing expectations and goals alongside the evidence used to assess them. Its standards emphasize clarity, measurability, verification, fairness, and attainability. Evidence need not always be a numeric target; it can include an observable result or a demonstrated practice. OPM also treats a performance plan as a document to discuss during the work, rather than something consulted only at rating time. Where it is stored matters less than whether the manager and employee use it.

For the migration, own the broker migration leaves too much unspecified. A useful expectation describes the intended result and constraints: no message loss during cutover, partner teams informed before their integrations change, a tested rollback path, and a release outside the freeze unless the authorized business owner grants an exception. Agree how each will be checked. The engineer should help develop the plan, while the manager supplies the business constraints the engineer does not yet know. OPM recommends involving employees in planning; Google’s team research separately identifies clarity about expectations and how to meet them as a relevant team dynamic.

Set outcomes, constraints, and required practices while leaving meaningful room to choose how to work. Delegation specifies which choices have actually been handed over. Evidence about the work can inform a performance discussion, but a delivery metric alone is not a complete evaluation of a person. The article on measuring friction rather than people explains the different purposes and evidence requirements.

Delegation is a degree, not a switch

Management 3.0’s Delegation Poker describes delegation as contextual and gradual rather than all-or-nothing. Its seven levels make the manager’s involvement in a defined decision explicit. In the list below, the manager is the delegating party and the engineer or team receives the authority. These levels describe an agreed relationship; a label cannot confer powers the manager does not hold.

1. Tell: The manager decides and communicates the decision.
2. Sell: The manager decides and explains the reasoning to seek support.
3. Consult: The manager seeks the team’s input, then decides.
4. Agree: The manager and team make the decision together.
5. Advise: The manager offers advice; the team decides.
6. Inquire: The team decides; the manager asks about the decision afterward.
7. Delegate: The team handles the decision without the manager participating in that individual choice, within the delegated scope.

If the manager wants the engineer’s input but retains the decision, that is level three. If she offers advice and the engineer decides, it is level five. If both must agree, it is level four. In the original broker conversation, neither the authority nor the scope was clear enough to assign one level to the whole migration. The engineer had reason to expect autonomy, but the promise did not establish permission to override a business freeze. A newly discovered constraint can justify reconsideration; a manager’s preference alone is a different reason for taking back a delegated choice. Explain the reason, who is authorized to decide, and how the team will repair commitments already made. The glossary entry develops these distinctions.

A delegation board records an agreement for a decision area and the parties involved, rather than assigning one permanent level to a person. Valid authorization establishes a decision right; the board makes it visible. As responsibility and accountability explains, doing the work does not itself grant release authority. An advice process can be adopted alongside delegation, but its requirement to consult affected people and experts is a separate rule, not something implied by levels five or six. Such consultation can expose a calendar constraint only if someone with the relevant information is involved and communicates it.

For the redesigned fictional team, leadership explicitly authorizes the manager to select cutover dates within approved business windows and to select candidates for already approved positions within compensation limits. The business owner retains freeze exceptions, and the budget owner retains headcount approval. The board below governs the manager-engineer relationship. A migration is split into several decisions: the tooling choice does not also authorize a shared-contract change or a release date. The corresponding decisions and any partner approvals must all be settled; unclear overlaps are escalated before commitments are made.

Decision area (fictional team)	Level	Authority and boundary
Local library or tool choice within approved standards and budget	7 Delegate	The engineer decides; this excludes shared-contract changes and production timing
Internal service design, excluding shared interface contracts	5 Advise	The manager offers advice before the engineer decides; advice is not an approval requirement
The team’s proposed shared-interface migration plan	4 Agree	The manager and engineer agree on their proposal; affected partners separately approve changes to their commitments
Cutover date within approved business windows	3 Consult	The manager seeks team input and decides; a freeze exception requires the authorized business owner
Candidate selection for an approved position within compensation limits	3 Consult	The manager consults the team and decides within the assigned hiring authority; new headcount or budget remains with its owner

Review the board as capability, risk, reversibility, constraints, and willingness to take responsibility change. Good decisions at the current level are evidence to consider, not an automatic reason to move right. Maintaining an appropriate level can be sound management even while the team develops; new risk can also require a revised scope or less delegation. Agree the review point, information needed, and escalation triggers. In particular, level six specifies inquiry after a decision, not a universal reporting deadline.

The one-on-one is not a status report

The manager had been skipping one-on-ones because the migration seemed on track. Michael Lopp’s essay argues for protecting a regular slot, suggesting weekly meetings of at least thirty minutes, and using them for more than facts already available in a project report. Those are his practical recommendations, not universal thresholds for a useful conversation. Agree a cadence and duration that leave room for the report’s concerns. When an urgent conflict makes a meeting impractical, explain and reschedule it rather than quietly dropping it.

Lopp describes three possible conversations: an update, a vent, or a disaster. His aim is to find what deserves exploration beneath a routine update, using an open question and prepared topics. A one-on-one can surface uncertainty, development needs, or concerns that are awkward in a project meeting, but it should not be the only route for urgent questions. In this fictional case, the engineer did not know the freeze constraint until week six. An earlier discussion of the proposed window might have exposed that information gap; the absence of a question does not by itself establish fear of speaking.

Lara Hogan’s first-one-on-one questions ask about preferred feedback medium, timing, recognition, goals, and support. Learn these preferences before a difficult conversation and revisit them as needed. Knowing that one person prefers written preparation and another prefers a conversation can remove a delivery obstacle. It does not eliminate other causes of delay, such as missing evidence, uncertainty, workload, or the manager’s reluctance to address an issue. Urgent operational information still needs the appropriate immediate route.

OPM’s playbook recommends frequent check-ins, including a biweekly example, to assess progress and offer support. It also calls for recording key discussion points. The UK standards require regular development discussions. These sources support a continuing conversation; the local arrangement should make individual concerns, progress, support, and follow-up possible without making a meeting format the measure of success.

Feedback while it can still change something

OPM’s monitoring stage combines continuing assessment with feedback so that problems can be identified and addressed during the work. Its playbook calls for timely, actionable feedback after tasks, including both poor outcomes and work that exceeds expectations. Vague praise gives little information, but specific positive feedback can show which behavior helped and should be repeated. Corrective feedback is also necessary. Its fairness and delivery matter; correction alone does not establish punishment or predict that someone will hide a problem.

Discuss the behavior, the outcome, and the evidence connecting them. A good result can owe much to favorable conditions, while a sound decision can still have an adverse outcome. OPM’s Start, Stop, Continue structure gives three practical directions: introduce an action, discontinue one, or retain one that works. Explain why, invite the person’s account, and agree the next step. The UK standards’ emphasis on honest, prompt conversations supports addressing a problem clearly without turning the discussion into a judgment about the person’s character.

In the broker case, the late discovery forced the engineer to revise commitments to partners and damaged trust in the manager’s promise. Agree decision checks and feedback timing before work begins, based on risk and the time available to change course. For level six, specify when and how the manager will ask about a completed decision and what events need earlier notification. A production failure needs immediate operational communication and mitigation; a private discussion of the behavior can follow once the facts are sufficiently clear. Neither should wait automatically for a performance review or a weekly meeting.

Choosing between coaching, teaching, and direction

Feedback provides observations and an interpretation of work; coaching helps a person examine their reasoning and develop their own next steps. Questions can be useful for that purpose. The UK standards support development conversations, and Google’s guide recommends approaching uncertain work as an opportunity to learn. Those recommendations do not establish that asking questions is always more effective than giving an answer. The practical choice here is the author’s judgment: consider what information and skill are missing, how urgent the decision is, and who holds the authority.

The engineer knew the technical system but did not know the business calendar. The manager needed to provide that information, not ask questions until he guessed it. Later, with the constraints understood, the engineer could compare a pause with a narrower migration scope. A useful coaching question was what would need to be true for the narrower plan to be safe? The manager could help test the reasoning while still giving missing information or stating a required limit. Coaching, teaching, and direct instruction can all contribute; the aim is to develop judgment while making a decision appropriate to the situation.

The GOV.UK Service Manual assigns delivery managers responsibility for removing obstacles and helping teams organize their work more autonomously. That role includes providing support, not just reducing requests for it. Assess whether the team makes sound decisions, achieves its commitments, and receives useful help when needed. Development may support broader delegation, but the decision level also depends on risk and authority. Fewer conversations with the manager, or movement to the right on a board, is not by itself evidence of better management.

Trust, and why accountability needs it

The hallway reversal damaged the engineer’s trust because the manager’s action contradicted what he reasonably understood her promise to mean. Predictable follow-through can help rebuild trust, alongside competence, honesty, and a clear account of actual authority. Keep ordinary commitments and explain necessary changes, including their consequences for the person doing the work. That provides evidence of reliability; it does not guarantee that trust in a larger or different decision will follow automatically.

Team Topologies links low trust with defensive documentation and process. An unexplained reversal can similarly encourage engineers to seek approval before choices they thought were delegated, adding avoidable coordination. That is a risk to investigate rather than a prediction about every decision. Ask whether people understand the boundary, whether the manager honors it, and what happens when a genuine exception arises.

Google’s account of Project Aristotle identifies psychological safety as a shared perception that taking interpersonal risks in the team is safe. Its examples concern raising questions, admitting mistakes, and proposing ideas without humiliation or retaliation. The guide presents a survey item about whether mistakes are held against the respondent as an example, not a complete description of the survey instrument. Combine members’ perceptions with evidence about how the team responds to concerns. A quiet engineer, or one incident, cannot establish the whole team’s level of safety; investigate the circumstances before interpreting silence.

Safety is compatible with standards and accountability. Google’s findings include dependability, and the UK standards pair supportive discussion with addressing performance and behavior problems. Fear of punishment can discourage disclosure and reduce the information available for fair judgment and timely correction. It is not the only reason a problem goes unreported, and people sometimes speak despite fear. Google’s guide recommends treating uncertainty as a learning problem, acknowledging fallibility, and asking curious questions. The entry on blameless postmortems applies a related reporting and learning principle to incidents, while retaining responsibility for follow-up work.

The manager, six months later

The fictional manager then wrote an expectations note with each report, including results, constraints, and evidence to review. She confirmed her authority with the director and separated the recurring decisions as shown in the board: local tools, internal design, the team’s shared-interface proposal, approved-window scheduling, and authorized candidate selection. Freeze exceptions and headcount increases remained outside her authority. She agreed a weekly one-on-one with each report, protected the time, and rescheduled unavoidable conflicts. Each person could add topics, and she recorded feedback and recognition preferences alongside agreed follow-up.

For the resumed migration, the manager and engineer jointly agreed on the team’s proposed shared-interface plan at level four before the engineer presented it to the partner teams. Each partner then agreed to the changes affecting its own commitments. After consulting the team, the manager chose a date within the approved post-peak window at level three. The engineer retained the scoped technical decisions assigned to him. After a clean cutover, the manager recognized the tested rollback preparation and advance partner coordination, explaining how they supported the result. When a later unannounced change broke a partner integration, they notified the partner and coordinated a safe mitigation immediately. After confirming the facts, the manager gave specific private feedback promptly. That week’s one-on-one revisited the agreed communication change and whether it was working; it was not the first response to the incident.

She did not set every decision to level seven. She agreed what was delegated, what remained constrained, and how a decision could be reconsidered when evidence changed. The team’s boundary with its partner teams, recorded in a Team API, clarified services and interactions between teams. The delegation board separately recorded decision authority between the manager and engineer. Neither document implemented the agreements on its own; the manager and teams had to follow them, resolve exceptions, and check the results.

What a reviewer should ask

A manager’s practice, or a manager’s own manager, can be reviewed with a short list, each item tracing to something above.

• For each report, are results, constraints, and required practices clear? What evidence will be reviewed, and when was the agreement last discussed or updated? Check its use rather than the system where it is stored.
• For each decision, who advises, who decides, and who grants any separate approval? Does actual behavior match the delegated scope? When a decision is reconsidered, are the reason, authority, and consequences explained?
• Do one-on-ones give the report room for concerns, development, and support, with follow-up on agreed actions? Is repeated status reporting crowding out that purpose, and are unavoidable cancellations rescheduled?
• How soon does useful feedback arrive relative to the opportunity to act? Are urgent operational messages sent through the response route rather than held for a scheduled conversation?
• Does the manager know the report’s current feedback and recognition preferences? If feedback is delayed, also examine evidence, preparation, workload, and reluctance to address the issue.
• How have concerns been received, and how do team members describe the experience? Treat a recent response or a period of silence as evidence to investigate, alongside perceptions and circumstances, rather than a complete safety score.
• When was each delegation area reviewed against capability, risk, constraints, and the responsibility people want to take? A justified decision to maintain a level can be appropriate; movement itself is not the objective.

These practices make expectations and decisions easier to inspect, but they do not eliminate urgent work or interpersonal difficulty. The redesigned arrangement gives the manager and reports a way to notice a gap, discuss it, and revise what they do. Whether it helps should be judged through decisions carried through, useful feedback, manageable support needs, and the experiences of the people involved.

References

• Google re:Work, Following the data: The research behind great managers, August 2025.
• Google re:Work, Understand team effectiveness, originally published 2015.
• UK Civil Service, The Line Management Standards: Core stage, April 2025, V1.2 (Open Government Licence).
• US Office of Personnel Management, Performance Management Cycle.
• Performance Management and Accountability Playbook: Monitoring and Developing.
• Management 3.0, Delegation Poker and Delegation Board.
• Michael Lopp (Rands), The Update, The Vent, and The Disaster.
• Lara Hogan, Questions for our first 1:1, 2016.
• Matthew Skelton and Manuel Pais, Team Topologies: Key Concepts.
• GOV.UK Service Manual, What each role does in a service team, updated 6 November 2023.