Internal Transfers and Promotions

The internal loop has a memory

An external interviewer knows only the evidence you bring into the room. An internal decision maker can read the design review, ask the product lead what happened, compare your account with an incident timeline, and remember the feedback you received last year. Internal transfers and promotions are not easier versions of external interviews. They are decisions made in the presence of partial organizational memory.

That memory is uneven. Your manager may know that you rescued a migration. A staff engineer may remember that your design arrived late. Support may know that you stayed with the rollout until the operating path worked. A promotion panel may know none of this and see only a packet assembled from those views. “They know my work” usually means that several people know different fragments.

Consider a modeled case. A product engineer wants to move to a platform team. Two checkout incidents led her to redesign retry handling, coordinate a rollout with SRE and support, and improve the service runbook. The platform manager values that work but doubts that she has owned an API used by several teams over its full lifecycle. Her current team still depends on her for an unfinished schema migration.

There is a plausible mobility case here. There is not yet a clear decision.

Name the decision before assembling the evidence

“I want to grow” describes a motive, not the choice the organization must make. The modeled candidate could be asking for any of three decisions:

• A promotion in place asks whether she already performs at the next level often enough for the formal level to change. One unusually visible rescue is not enough; the burden is repeated next-level behavior.
• A lateral transfer asks whether her judgment will create value in the target team, whether the remaining domain gap is manageable, and whether she can leave her current responsibilities safely.
• A transfer with a level change asks both questions at once. Interest from the platform team does not prove the higher level, and promotion evidence does not by itself make platform fit credible.

Combining these cases into a general appeal makes each one harder to assess. Tenure, restlessness, a friendly target manager, and strong performance reviews may all be relevant context, but none states the required scope or the risk of the move. A useful opening makes the decision explicit:

I am asking for a lateral move to the platform reliability team. The team needs
an owner for retry safety across checkout-adjacent services. My evidence is the
checkout redesign and its rollout; my unproved area is long-term ownership of a
multi-client platform API. I have a bounded first assignment for that gap and a
handoff plan for the schema migration I would leave behind.

That claim can be challenged. This is a virtue. An internal case becomes stronger when a manager can identify the precise evidence that would change the decision.

Build a case that can survive a phone call

The checkout redesign sounds impressive until someone asks what the candidate actually did. “Led reliability work” could mean diagnosing the failure, coordinating other people’s decisions, writing one implementation task, or giving the final presentation. Internal shorthand invites the listener to fill the gap with whatever reputation already exists.

Recover the work as a chain of decisions and effects:

Claim
I can own ambiguous reliability work across team boundaries.

Evidence
After two checkout incidents, I traced duplicate retries to the request path,
proposed moving them behind an idempotent worker, and changed the rollout when
support volume showed that the original sequence would overload triage.

Record
Incident review, design decision, replay tests, rollout notes, alert changes,
support runbook, and the next traffic-spike review.

Other views
The SRE partner observed the failure analysis and alert work. Product observed
the scope decision. Support can speak to the revised rollout and runbook.

Limit
This does not prove that I have managed a platform interface with several
independent clients through adoption and compatibility changes.

The record matters because it constrains a polished story. The other views matter because senior work is rarely visible from one reporting line. Neither is a hunt for endorsements. A validator who likes you but cannot cite the work is weak evidence; a colleague who can explain both your judgment and its limits is much more useful.

Ask people who observed the work questions they can answer honestly:

1. If you had to cite one example for this level or role, which would you use?
2. What decision or behavior in that example was actually mine?
3. What concern would a panel or target manager reasonably raise?
4. Who saw a different part of the work closely enough to confirm or challenge the account?

The answers may reveal that the evidence does not travel. Perhaps the manager remembers reliable delivery but not problem framing. Perhaps SRE credits the technical diagnosis to another engineer. Perhaps support experienced the runbook as an improvement while product remembers the rollout as late. Resolve those differences before the formal loop. Do not average them into a flattering sentence.

For a promotion, repeat this exercise across more than one piece of work. The question is not whether the checkout redesign reached senior scope once, but whether similar judgment appears when the system, phase, and relationships change. Look for repeated ownership of ambiguity, decisions that survived challenge, influence beyond assigned implementation, operational follow-through, and mechanisms that made other engineers more effective.

Let known feedback into the case

Internal candidates do not receive a clean slate. Avoiding known feedback only makes the listener supply it.

Suppose the candidate’s earlier design reviews were technically accurate but abrupt with teams that lacked her context. A defensive answer turns the project pressure into an excuse. A vague answer—“I have worked on communication”—cannot be checked. A serious answer preserves the full sequence:

In Q1 I received feedback that I mixed blocking risks with preferences in design
reviews, which made partner teams unsure what they had to resolve. I began
labeling those separately and closing each review with the decision, rationale,
owner, and open questions. The payments and support teams stayed engaged through
the later rollout, and both challenged the plan before it closed. I still watch
for abruptness when timelines compress.

This does not claim a personality transformation. It names the observed problem, the changed behavior, the resulting evidence, and the condition under which the weakness may return.

Positive reputation can be equally narrowing. The engineer known for rescuing late projects may need evidence that she prevents the need for rescue. The deep checkout expert must show which judgment travels outside checkout. The reliable implementer must show where she framed the problem and changed the course of other people’s work. The internal loop is often deciding whether a familiar strength has become a ceiling.

Manager alignment belongs here, but not as a lesson in office politics. A manager may affect timing, calibration, and the account of the work. When it is safe and practical, avoid making the first serious transfer conversation a surprise. If that alignment is unsafe, learn the formal mobility process and protect the necessary confidentiality. The governing principle is to understand how the decision is made without surrendering control of your career to an informal veto.

The gap needs an assignment, not optimism

The platform manager’s concern is legitimate. Retry work adjacent to a platform does not establish full platform ownership. The candidate weakens her case if she denies the distinction or promises to “ramp quickly.”

Instead, turn the gap into a bounded first proof:

First 30 days
Map the client services, compatibility promises, incident history, and current
owners. Shadow one API review and one operational review.

By day 60
Own the design for one reliability slice touching services I already understand.
The platform lead reviews interface and adoption risk; client teams challenge
the migration assumptions.

By day 90
Roll out that slice to a named client cohort, reconcile the expected behavior,
and own the operational review. The evidence is one design, one adoption path,
and one production result—not completion of the whole platform roadmap.

This plan separates transferable judgment from missing domain experience. It also gives the target manager milestones at which confidence can rise or fall. The candidate is not claiming to be a complete platform engineer; she is showing that the organization can test the remaining risk without gambling an entire roadmap.

The same method applies after a “not yet” promotion decision. Ask what scope or behavior remains unproved, what assignment could generate the evidence, who will calibrate it, and when the decision will be revisited. “Be more strategic” is not a development plan. “Own the next cross-team reliability proposal from problem framing through adoption, with the staff group reviewing the decision boundary before implementation” is at least observable.

What you leave behind is part of the evidence

An internal transfer creates two risks: whether the engineer will succeed in the new team and what happens to the work she leaves. Treating the second as a manager’s inconvenience contradicts the ownership the candidate is trying to prove.

In the modeled case, “finish the migration first” is too blunt. It may delay the move indefinitely, and it does not reveal which risks actually require the candidate. A responsible transition would identify:

• the current schema phase and the decision still open;
• a named owner for the cutover and dashboard, with authority to change the plan;
• the design history, rollback conditions, runbook, and operational context that must be transferred;
• one rehearsal in which the new owner leads while the candidate observes;
• two scheduled support reviews after the move, followed by a clear end to the old ownership.

The rehearsal is more revealing than a folder of handoff documents. If the new owner cannot make the next decision without private context, the transfer is not ready. If every question still routes to the candidate three months later, the organization has moved her seat but not her responsibility.

In a transfer conversation, answer “What will your current team lose?” without pretending the answer is nothing. Name the knowledge, relationship, or decision capacity that will leave. Then show how the risk is reduced, accepted, or escalated. A person who can leave a team cleanly demonstrates the same ownership judgment the target team hopes to gain.

How an internal loop may examine the case

The process may be a formal promotion panel, a set of target-team conversations, or something less visible. The names of the rounds matter less than the views they add.

A manager conversation usually tests the decision itself: why this team or level, why now, what the company gains, and what risk comes with the move. A project deep dive can compare the candidate’s account with known artifacts and separate personal contribution from team output. Stakeholder conversations can test whether influence and operational follow-through were visible outside the reporting line. A technical discussion may deliberately leave the familiar checkout domain to see whether the candidate’s reasoning transfers. A promotion panel may have only the packet and must decide whether the behavior is repeated and level-calibrated.

Prepare the same evidence for all of them, but do not give the same speech. Explain the failure mechanism and design choice in the technical discussion. Explain the changed rollout and customer consequence with product. Explain decision rights and runbook use with support. Consistency does not require flattening each observer’s contribution.

Internal familiarity raises the standard for precision. “You remember the checkout migration” is not an answer. State the constraint, your decision, the people affected, the result, and the limit. Likewise, do not borrow confidential documents for preparation outside the company or bring material into a process that is not authorized to receive it. Reconstruct the reasoning in neutral terms when the audience changes.

Rehearse the decision, including the uncomfortable line

Write the internal case on one page. It needs only the target decision, two or three evidence claims, the records and people who can verify them, known feedback, the important gap, and the transition risk. If it becomes a catalogue of everything you have shipped, the decision has disappeared again.

Give the page to someone who understands the target level or team but was not inside every project. Ask what they believe is proved, what is merely asserted, and what concern they would investigate first. Revise the evidence, not the volume.

Then rehearse the questions that make internal answers evasive:

• Why should this be a promotion rather than a growth assignment at the current level?
• Which part of the target role have you not demonstrated?
• What would your manager or peers name as your main risk?
• What will your current team lose if you move?
• What evidence would make “not yet” the right decision?

The chapter’s modeled engineer has a credible lateral-transfer case because the checkout work shows relevant reliability judgment, the platform gap is bounded, and the migration handoff can be tested. Whether she also has a promotion case cannot be inferred from that one project. She would need repeated next-level evidence against the company’s level expectations.

That may feel less satisfying than ending with a universal readiness checklist. It is also the judgment the internal loop requires. Organizational memory is useful only when you turn its fragments into a decision that other people can inspect—and leave room for the evidence to say no.

Related links

• Level Calibration
• The Project Dossier
• Personal Contribution Without Erasing the Team
• Feedback and Difficult Working Relationships