Keep a Living Plan for Every Relationship You Manage

This is the full playbook from “A CTO Manages Up, Down, and Sideways at Once.” The book prints a shorter version at the end of that chapter, and this page keeps every step and every example.

Build the Multi-Level Management Plan as a living document. The relationships it maps change as roles change, and trust with a specific person either accumulates or erodes.

1. Map your three directions by name, not by function. For managing up, list the people: your CEO, each board member who engages with technology decisions, each executive peer whose support you need for budget or prioritization. For managing sideways, list every peer executive whose function touches engineering output. For managing down, list your direct reports, and in a large organization, the layer below them separately. A vague category produces a vague plan. A named person produces a specific plan.
2. Write the current state of each relationship in one honest sentence: what it is now, not what you want it to be. “Trusts my judgment on technical timelines and doesn’t ask for detail.” “Sees engineering as a bottleneck because of the CRM integration delay.” “Has no relationship with me outside the quarterly all-hands.” The step works only if you refuse to describe a relationship as better than it is.
3. For each relationship that is less than trusted, name one deposit you can make in the next thirty days. It must have no connection to a current request, and it isn’t a favor that sets up a future one. Attend a planning meeting you weren’t required to attend. Report a risk to that person’s function before it becomes their problem. If you can’t think of a deposit without an attached ask, you’ve just learned how the relationship has worked so far.
4. For every initiative in flight that needs cross-functional cooperation, name the person whose informal agreement you need, and get it before the formal decision meeting rather than during it. If you can’t name that person, you don’t yet understand who controls the outcome. Find out before the initiative goes further.
5. For every major technology commitment to leadership, write two dates: when the capability will exist, and when the organization will get value from it. Note which parts of the second depend on functions outside engineering. Present both, every time. Never let one date do the work of two.
6. Review the document at the end of every quarter. For each relationship, ask one question: has the balance moved up or down since the last review, and why? A relationship that erodes without a visible incident is more dangerous than one that breaks in public, because nobody repairs it until a request fails. And once a year, check the up direction against the standard “Translate Technical Work into Each Audience’s Terms” set: can you still say, in one sentence, which advantage the technology story is compounding?

The exercise feels like overhead the first time through. It stops feeling that way the first time a cross-functional initiative moves faster than it should have, for reasons nobody in the room can quite articulate, because the reason was built two quarters earlier, in a deposit nobody was tracking.

All of the playbooks are listed on the playbooks page.