The Senior Engineer Who Came Back Cautious

Diagnose D3: moderate-to-high competence, variable commitment. Competence evidence: she has seven years of engineering experience, her code is careful, and her questions are technically sound. The new stack lowers task-specific competence somewhat, but she is not a beginner; she can reason about the service and is choosing caution rather than showing inability. Commitment evidence: she is quiet in stand-ups, asks for reviews on changes she once shipped alone, rewrites the same service, and says 'I don't want to break anything.' That is variable commitment expressed as anxiety and caution, not D2 disillusionment or D1 enthusiasm. D4 would require confidence and sustained performance on this architecture; she is not there yet. D2 would require low competence plus low commitment; she has transferable competence and is still engaged, just hesitant. To confirm D3, look for whether her questions are about unfamiliar platform details versus basic design ability. If she cannot explain event flows or repeatedly misses Kubernetes fundamentals, the competence gap is larger and S2 may be needed. If she can explain the design but doubts her judgment, D3 holds.

Lead with S3 supporting: lower direction, high support, with targeted direction where the new stack genuinely requires it. Support behaviors: ask what would help her rebuild confidence, explicitly state that you are not reducing her role, pair her with a Kubernetes buddy for two weeks, and make design reviews opt-in but set a clear rule for when to escalate. Direction behaviors: agree on a bounded first release scope, name the two or three architecture decisions she must review with the team, and set 30-day checkpoints. Avoid abandonment by not saying 'you're senior, figure it out'; avoid over-supervision by not requiring approval on every pull request. A useful conversation: 'Your judgment is not in question. The platform is new, so let's bound the first release and use a buddy for two weeks. After that, I expect you back on full releases.' That is S3 because it shares decision-making and rebuilds confidence. If her pull requests show actual skill gaps, add temporary instruction, which is an S2 element, not a permanent demotion.

Contract three things: scope, support, and evidence of readiness. Scope: she owns two services in the release, with a written boundary on what she can change without review. Support: a named Kubernetes buddy for two weeks, one architecture review per service, and a weekly 20-minute check-in focused on decisions rather than code. Evidence: she runs a release readiness review, explains the event flow and rollback plan without prompting, and ships at least one non-trivial change without asking for pre-approval. Return to S4 delegating when she demonstrates both competence and confidence on the new architecture across a full release cycle, not just one clean pull request. Tell her that explicitly: 'When you've run one release and walked the team through the rollback plan, I'll hand releases back to you fully.' That prevents S3 from becoming permanent. If she meets the evidence earlier, move earlier. If she does not, reassess whether the issue is skill, confidence, or something outside work, and adjust the contract rather than silently keeping her on a short leash.