Turn vague feedback into a practice plan

Feedback such as “show more leadership” may point to something important, but it leaves too much unspecified. It could mean asking a question earlier, helping another engineer, making a decision, or speaking more often. Trying to satisfy all those interpretations at once is not a development plan.

Ask for the example behind the label

Start with curiosity rather than immediate agreement or defence: “Can we look at a recent situation where that showed up?” Then ask which action the person observed and what consequence mattered. A useful answer should move from an adjective towards a situation you both recognise.

In an illustrative example, a developer receives “you need to be more strategic.” The manager points to a proposed rewrite that ignored another team’s planned replacement. The actionable issue is not a mysterious shortage of strategic personality. It is that the developer recommended an investment before checking a relevant dependency.

Ask what a better action would have been: “Would you have expected me to ask about adjacent plans before comparing solutions?” That question tests an interpretation. It does not mean accepting every conclusion in the original feedback.

Marshall Goldsmith’s What Got You Here Won’t Get You There provides a useful prompt to examine behaviours that may no longer help. His public discussion of adding too much value gives a concrete example of how apparently helpful input can interfere with another person’s ownership. The useful lesson here is to examine the action and its effect, not repeat an untested label.

Try the decision

The feedback is “be more strategic.” What should the developer ask next?

Guess what the label means and work longer hoursRequest an example, observable action and review point

Extra effort does not identify the missing behaviour or necessary support.

Next step: Ask for a recent situation in which a different action would help.

This is an illustrative decision with stated assumptions. It cannot establish your employer’s policy or predict an individual career outcome.

Separate behaviour, information, and authority

Before prescribing practice, check whether the expected action was possible. Did the developer know the other team existed? Could they access its plans? Were they allowed to contact its decision-maker? A person cannot improve a missing permission by trying harder.

The example may reveal two changes: the developer should check dependencies before recommending work, and the manager should introduce them to the relevant owner. Keeping both visible avoids an unfair plan in which only the employee has actions.

Also separate development feedback from an evaluation decision. “Here is something to practise” and “this is why your rating changed” are related but different claims. Ask which one is being discussed and what standard applies. The changing scope of engineering judgement can help frame the conversation, but your own role expectations must be explicit.

Design one attempt you can review

Our proposed practice note has four parts: situation, action, support, and review. In the example, the situation is the next bounded design choice. The action is to identify affected teams and check their relevant plans. The support is an introduction to the owner. The review is a short discussion of the resulting options note.

Do not make the success condition “everyone agrees with me.” You cannot control that, and agreement does not prove the reasoning was good. A better condition is whether the recommendation includes the relevant dependency, explains uncertainty, and gives the decision-maker enough information to choose.

For a communication issue, the practice might be an earlier risk message rather than more frequent status updates. For a review issue, it might be distinguishing a correctness concern from a preference. The code-review guide explains that distinction in its actual working context.

Choose a manageable number of changes. A long list of personality improvements makes it difficult to tell which action helped. One visible attempt creates something concrete to discuss and revise.

Challenge feedback that stays unfair or untestable

Some feedback remains inconsistent, biased, or impossible to act on. If “be more confident” means behaving like a particular colleague regardless of your results, ask for job-relevant behaviours and consistent criteria. You do not need to adopt a stereotype to demonstrate competence.

If examples contradict each other, put them side by side and ask what determines the right action. Perhaps the distinction is urgency, decision authority, or who is affected. If no distinction can be given, record the unresolved expectation instead of pretending the instruction is clear.

Do not repeatedly expose yourself to humiliating or threatening treatment in pursuit of a perfect feedback conversation. Seek appropriate organisational support where needed. This method helps clarify genuine feedback; it is not a cure for an unsafe or unfair workplace.

Check the next attempt, not your personality

After trying the new action, ask the observer what was different and what remains unclear. Bring the actual work. If the result did not improve, investigate whether the action was wrong, the opportunity was unsuitable, or the review criteria were incomplete.

Keep the conclusion bounded: “I now check this dependency before recommending a rewrite” is more useful than “I have become strategic.” The first statement describes a capability you can repeat and test.

Use a development one-to-one to agree the next opportunity. Over time, the aim is not a longer list of feedback received. It is a clearer account of what you can do, under which conditions, and where you still need help.