You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 9: Transitions — First 90 Days and the New Lead's Surface #

Start with the cold-start problem, and start earlier than you think it starts: if a new role arrives through an interview process, the interview itself is already a political moment, not just a technical one. The question on the other side of the screen is never only "can this person do the work" — it is "what kind of operator is this person." How you handle being stuck, how you respond to pushback, whether you ask clarifying questions or barrel into a wrong implementation, whether you can be wrong gracefully: all of it is co-evaluated alongside the code, and most engineers walk in optimizing only for the first axis. Then, if the offer lands, the same miscalibration repeats at larger scale. Your reflex in a new role will be to over-rotate on technical onboarding — read the codebase, learn the architecture, ship a small PR in week one to establish credibility. None of that is wrong. All of it is incomplete, and Watkins' frame is the corrective: the political onboarding has a tighter clock than the technical onboarding, because the relationship-formation window closes around week four, and reopening it costs double. Your week-one move is not just the architecture diagram; it is the 1:1 schedule with every adjacent stakeholder, the question "what's hard about working here right now" asked of three different people (the triangulation across their three answers will tell you more than any single conversation), and the deliberate decision not to ship a PR in week one even when you could — because shipping early signals "I'm here to prove something," and the signal you want is "I'm here to learn the system before changing it."

Write the first-90-days plan even if no transition is currently live, because the plan is more useful written before the role than after, and the pre-mortem is the part most engineers skip. The three reliable political failure modes for a senior engineer joining an established team: over-claiming expertise in week one and under-delivering in week three when complexity catches up; becoming the coded outsider in a team with insider/outsider dynamics you haven't read yet — a risk that doubles if you join remotely or through a contracting boundary; and optimizing visibility so aggressively that you produce a "trying too hard" read. Write the most likely version of each failure. Then write the prevention. The plan will need revising at week four against actual data; the revision is part of the plan, not evidence it failed.

The second transition is the phase shift: the lead promotion. The single most operationally important concept here is the credibility paradox, and it deserves plain statement: your technical credibility was the input to the lead role; maintaining it is now the output of deliberate practice rather than the byproduct of doing IC work. As an IC, credibility was a side effect of writing code well. As a lead, it has to be engineered — depth kept deliberately in one or two domains, PR-reading discipline that buys broad context at thirty minutes a day, architectural work done personally while implementation is delegated. Without that engineering, the team's trust in your technical judgment erodes, and once eroded it does not come back through any amount of management skill. Around the paradox, a ratio pattern so reliable I'd pre-commit against it in writing: you will under-do the people work in months 1-2 (the technical work is more comfortable and more legible), over-correct in month 3 when you notice, and find a sustainable balance around months 5-6. The pre-commitment in your Operating Stance doesn't prevent the pattern; it makes the pattern visible in real time, which lets you correct faster.

Two harder truths about the lead role that the formal curriculum can only half-say. First, the role amplifies both your virtues and your shortcomings, visibly to others before visibly to you: the patient teaching that made you a good mentor becomes the most respected part of your leadership, and the conflict-avoidance that was your private IC default becomes a team that takes too long to surface its own disagreements, because they inherited your avoidance. Both amplifications happen simultaneously, and the Operating Stance document is the instrument that lets you see them deliberately rather than in the dark. Second, deference can mask disagreement. In many team cultures — hierarchical ones especially, and several national workplace cultures train deference explicitly — your new title means people will stop telling you things unless you engineer the telling: explicitly inviting disagreement in 1:1s ("I want to try this approach but I'm uncertain — what am I missing?"), narrating delegation as growth rather than offload, asking for feedback rather than expecting it to surface. And if you lead from inside a contractor configuration, note that the standard literature assumes FTE-grade scaffolding — HR partnership for hard conversations, calendared review cycles, manager continuity — that you may not have. The work the FTE lead outsources to organizational structure is work you carry explicitly. Not unmanageable; just demanding, and better absorbed deliberately than discovered by surprise.

Conclusion #

Two transitions, one discipline: the windows are short, the topology you build in them determines what is possible for months afterward, and improvisation wastes them. The first-90-days plan spends the cold-start window deliberately — stakeholder map, win sequence, what-not-to-do list, pre-mortem. The Operating Stance resolves the credibility paradox in writing — the ratio, the kept domains, the political work only you can do. Build both even if neither transition is live; port them when one becomes real, which it will.

Predictions #

  • If a new role lands, your week-one instinct will be to ship a PR. Don't. Ship in week three; spend weeks one and two on stakeholder mapping and 1:1s.
  • You will under-budget relationship-building time in the new-role plan. Senior engineers consistently do. The honest budget is roughly 30% of week-one time, not 10%.
  • The "what's hard about working here right now" question, asked of three people, will produce three different answers, and the triangulation will be worth more than any onboarding document.
  • Within the first month at any new team, you will observe a political dynamic that no interview surfaced. One screen does not reveal team politics; plan for the unknown explicitly.
  • If you lead: the IC-ratio will drift toward more IC work than your Operating Stance specifies. The drift will recur; correcting it repeatedly is the discipline, not a sign the stance failed.
  • If you lead: somewhere around month two or three, you will discover a team member has been suppressing a disagreement with you for weeks, and the suppression caused a real problem. That discovery is what converts "invite disagreement explicitly" from aphorism into practice.
  • Sponsorship-of-team work will not happen reliably in your first lead year unless it is calendared. Calendar it.
  • By month six of a deliberately-run lead transition, your team will be able to articulate, specifically and accurately, what you are like to work with. That articulation does not happen for leads who run on improvisation. It is the marker of having done the political work of the role.
  • The first-90-days plan will feel premature when you write it without a live transition. It is not; the plan is more useful written before the role than after, and the pre-mortem will surface a failure mode you carry from your current configuration that does not apply to the next one. Notice the carry-over and adjust.
  • Reading Fournier's tech-lead chapter, you will find at least three observations that describe behavior you have already exhibited in a lead or lead-adjacent role. The recognition is the calibration point, not an indictment.