In Q1 2026, one of our senior operators handed me a Notion page and said: “I cannot tell if this is mine to own or hers.” The page was a cross-functional handoff from a junior operator on the product side to the ops team. It had task lists, timelines, links to GitHub issues. It had everything except the one thing a senior person actually needs: who owns the decision when it goes sideways.
That exchange was the third conversation like it in two weeks. Three different junior operators. Three different handoffs. Each one technically complete and operationally useless to the person receiving it.
We had a leadership development problem. We had framed it wrong for eleven months.
What we thought the problem was
Our junior operators were sharp. They shipped. They hit deadlines. They documented. In Lattice reviews, their execution scores were high. But when we looked at who was moving into senior and cross-functional roles, none of them were in the pipeline. The people getting promoted were the ones who showed up to ambiguous situations and took a position. The junior operators were waiting to be told what position to take.
We assumed that was a mentorship gap. We had run two mentorship rounds in the prior year. Neither produced a promotion. We had assumed we needed more structured coaching conversations, so we built a coaching cadence in Lattice. That did not move the needle either.
In retrospect, we had not understood that the leadership-skill gap was actually a context-handoff gap. The junior operators were not waiting for mentorship. They were operating in a system that never required them to name who owned a decision, what standard of done applied, or what the non-obvious risk was. They could execute perfectly inside a fully specified task and never once practice the cognitive work that distinguishes a senior IC from a junior one.
The system was protecting them from the work that would have built the skill.
The incident that forced a reframe
The Notion page exchange made that clear in a way the Lattice score history had not. The junior operator who built that page had done her job correctly by every metric we were measuring. The handoff was complete. The problem was that “complete handoff” and “decision-ready handoff” were not the same thing, and we had never built a schema that required her to think about the difference.
We did not understand how to surface that distinction through process design until that page landed in front of us and a senior operator said, plainly, that she could not act on it.
The 4-line packet
We wrote a short schema. It had four fields. Every cross-functional handoff had to include all four, posted in the Slack thread in #ops-handoffs at the moment of transition. No handoff that skipped a field was considered complete.
The four fields were:
Owner: The single person whose calendar and judgment this decision lives on until explicitly transferred. Not a team. Not a function. One name.
Decision frame: The specific call that needs to be made, stated as a question. Not “we need to finalize the onboarding flow.” The question: “Do we gate access behind email verification before the product team’s June release, or after?”
Done standard: What does resolved look like, concretely. Not “when stakeholders are aligned.” A date, a merged pull request, a Slack confirmation from a named person, a state in a Notion database.
Non-obvious risk: The one thing most likely to make this go wrong that is not on the task list. The thing the receiver needs to know that the sender knows from context.
That was it. Four lines. The template lived in a pinned Notion page. Every engineer shipping a cross-team dependency used the same schema in GitHub pull requests. Every ops handoff used it in Slack. The format was the same everywhere so the reading habit could form.
What changed in 14 weekly handoffs
We ran this across 18 operators over 6 weeks. Each operator averaged 14 weekly handoffs during that window. The first two weeks were rough. Several junior operators found the “decision frame” field genuinely hard to write. They would describe work rather than name a decision. They would write “figure out the onboarding timing” and a senior operator would send it back with: “That is not a decision frame. What is the yes/no question?”
That pushback was the coaching. Not a one-on-one session. Not a Lattice goal. A direct, in-the-flow correction that required the junior operator to practice the exact cognitive move that separates a task executor from a decision owner.
By week four, the quality of decision frames in #ops-handoffs was visibly different. By week six, one junior operator who had been stuck in the same IC band for 11 months was writing packets that her senior counterparts were accepting without revision. She had internalized the frame. She was not waiting for someone to hand her ownership. She was naming it, in writing, every week.
Three promotions in one quarter
Within 90 days of launching the packet schema, three junior operators who had each been at the same level for more than 11 months moved onto senior or cross-functional leadership tracks. One moved into a senior ops lead role. One picked up a cross-functional product-ops scope that had previously been handled by a director-level hire. One was put on the shortlist for an engineering lead position based in part on the quality of her GitHub handoffs under the new schema.
We had not changed who they were. We had changed what the system required them to practice every week.
What the tools actually did
The schema lived in Notion because that is where our reference documents live and nobody disputes ownership of what is pinned there. The Slack channel #ops-handoffs was already the place where cross-team transitions happened; the packet gave that channel a consistent shape. GitHub was the right surface for engineering handoffs because pull requests already required a description field, and engineers were already treating that field as a communication mechanism. Lattice reviews started reflecting the packet quality as a signal in performance calibrations, which meant the schema had a feedback loop into the formal promotion process.
The tools did not create the behavior change. The schema created the behavior change. The tools were the surfaces where the schema became visible and verifiable.
The confessional version
We spent eleven months trying to fix a leadership development problem with leadership development programs. Mentorship rounds. Coaching cadences. Structured feedback sessions. None of it moved the needle because none of it addressed the actual constraint.
Turns out the constraint was a process gap, not a skill gap. The junior operators did not lack the capacity to own decisions. They lacked a system that required them to practice naming ownership, on a real handoff, with a real senior person waiting on the other side. When we built that system, the skill appeared in six weeks.
I would not run another leadership cohort without first auditing the handoff system. If your junior operators are technically strong but stuck at the IC ceiling, the mentorship program is probably not the bottleneck. The question to ask is: does your current process ever require them to name, in writing, who owns a decision and what done looks like? If the answer is no, the gap is in the system, and the system is fixable in a weekend.
The packet, reproduced
For anyone who wants to copy the schema directly:
Owner: [single name, not a team] Decision frame: [the specific yes/no or A/B question this handoff resolves] Done standard: [concrete, falsifiable: a date, a merged PR, a named person’s written confirmation] Non-obvious risk: [what you know from context that the receiver does not]
Post it in Slack at handoff. Pin the template in Notion. Wire it into GitHub PR descriptions for engineering. Run it for six weeks across your team and track who starts writing clean decision frames by week four. That is your shortlist for the next senior promotion cycle.
Be the first to comment