Set Your Coaching Priorities

Use this skill when a technology leader wants to figure out what to coach their team on next, run an honest perception audit of their own leadership (how the C-suite, their own team, and people outside their reporting chain actually experience them), or…

This skill is Labor as Code™ for the opening chapters of The Code Takes Care of Itself: "The CTO Is a Coach First." Read that chapter for the argument behind every step here — the book's own case studies (the CTO who spent Fridays fixing a race condition, the platform lead who shipped a Friday migration nobody knew about) are the specific examples this skill generalizes. This skill runs the audit and, from the named events (Step 3) and the real perception-audit answers (Step 4), drafts candidate priorities and commitments with its reasoning for the user to accept, sharpen, or replace. What it does not do is decide whether the feedback the user hears is fair, or soften a blunt answer into something more comfortable — assessing your own conduct against what people actually said about you is a judgment only you can make honestly, and this skill supplying that judgment instead would just replace one kind of self-flattery with another.

Before running

Confirm three things with the user before starting:

1. This is a two-quarter commitment exercise, not a five-minute brainstorm. The book is explicit: pick exactly three priorities. More than three produces a list, and "teams do not execute lists with discipline." If the user wants to write down ten things they could improve, that's a different, looser exercise — say so, and offer to run this one on the three that matter most instead.
2. Real feedback has to come from real people. Step 4 below asks three direct reports and one person outside the reporting chain to describe the user's leadership in one sentence, in their own words. This skill cannot generate those sentences for the user — doing so would be inventing the finding the whole exercise exists to surface honestly. If the user hasn't gathered that feedback yet, help them draft the ask (see Step 4), then pause the exercise until they come back with real answers.
3. Which seat, and how much runway. A full-time CTO, a fractional CTO compressing this into weeks instead of a year, and a player-coach still shipping code all face this differently — ask which applies before drafting priorities, since it changes how much the user should expect to change personally versus structurally.

Steps

1. Identify three coaching priorities — not technical priorities

A coaching priority is a specific change in how the team operates, communicates, or grows — one the user owns personally over the next two quarters. Not "migrate to the new event bus." Examples from the book: make code review consistent; build a career ladder for mid-level engineers; close the communication gap between engineering and customer-facing teams.

Write down exactly three. Apply one filter before finalizing: prefer priorities that build on something this specific team already does unusually well. A priority generic enough to fit any engineering organization is rarely the best use of two quarters — if a candidate priority would read the same at a different company, push for a sharper, more specific one. If the user has real events to point to (a complaint, an incident, someone who left) but hasn't yet named three priorities, draft candidates from those events and say why each one earned a slot over the others - the user still picks the final three, but from a reasoned starting set instead of a blank page.

2. Write one coaching goal per priority, with a checkable test

One sentence each, with a test that shows when the goal is met. Not "improve collaboration." This: "Every pull request gets a substantive review within one business day, measured by our existing tooling, for eight consecutive weeks." If you can't state the test, the goal isn't defined yet — go back and sharpen it before moving on.

3. Name the real event behind each priority

Connect each priority to something that actually happened: a complaint you heard, an incident, a person who left or almost left. If you can't name the event, look at the priority again — it may be an abstraction borrowed from a book, a conference talk, or a video, rather than something this team's own history actually calls for.

4. Run the perception audit

Ask three people who work for the user, and one who doesn't, to describe their leadership in one sentence. Ask in those exact words — "describe my leadership in one sentence" — not a softened version. If the user hasn't done this yet, hand them this draft ask to send verbatim or adapt:

I'm working on becoming a better [CTO/engineering leader] and I want
an honest read, not a diplomatic one. In one sentence, how would you
describe my leadership right now? Please don't soften it for me —
the blunt version is more useful than the kind one.

Once real answers come back:

• Write down each answer exactly, without editing it into something more agreeable.
• Compare the answers against the three constituency gaps the book documents (adapt the ones that fit this org, don't force all of them):
  • The C-suite's complaint: jargon that never gets translated, technology spend nobody can connect to a business outcome, slow to read market signals, resistance to change.
  • The team's complaint: feels out of touch with current reality, inconsistent (either hovering over every decision or vanishing into meetings for weeks), career development treated as an afterthought, priorities that are unclear because everything is labeled urgent.
  • The complaint from outside the reporting chain (sales, support, other functions): engineering as a bottleneck, a product that doesn't reflect what customers actually ask for, inconsistent communication that reads as evasion.
• Turn what you heard into a single dated commitment you can be held to. If the answers surprised the user, that surprise is itself the most useful result of this step — don't explain it away before writing it down.

5. Close the loop

Restate the three priorities from Step 1 in light of what Step 4 surfaced, and state this skill's own read: does the perception-audit evidence support keeping all three as-is, or does it point to replacing one of them? Name the specific verbatim answer driving that read. If the perception audit revealed something none of the three priorities addresses, that's a finding worth sitting with, not a reason to silently add a fourth priority — go back to Step 1 and decide, on purpose, whether one of the three gets replaced. The read is this skill's recommendation; whether to act on it is the user's call, since it's their two quarters and their commitment to keep.

The check that catches this book's own failure mode

Before calling this done, confirm:

• Exactly three priorities, not a list. If there are four or more, cut, don't append a caveat.
• Every goal has a stated test, not an adjective like "better" or "stronger."
• The perception-audit answers are verbatim, not paraphrased into something more comfortable to hear. A softened quote defeats the point of asking.
• At least one priority ties to real perception-audit evidence, not only to the user's own instinct about what needs fixing. The book's own research citation matters here: what separates leaders who improve after feedback from leaders who don't is what they do with the feedback, not merely whether they collected it. A priorities list drafted before Step 4 and never revisited afterward hasn't actually used the audit — it decorated a plan that was already made.