Case study: two coaching challenges

At a mid sized product company two experienced engineers reached a career inflection point. Maya is a senior engineer who writes excellent code and owns complex components. She struggles to scale her work through others and frequently becomes the bottleneck for related projects. Raj is a staff level engineer responsible for cross team architecture. He produces high quality designs but finds it hard to get stakeholder buy in and to prioritize competing requests.

What the manager needed

Their manager wanted both engineers to increase impact without losing technical quality. That required different coaching approaches. For Maya the goal was to convert individual delivery into team leverage. For Raj the goal was to convert technical clarity into organizational alignment. The manager used a structured coaching plan built around short experiments, specific signals of progress, and check in routines that preserved autonomy.

Initial assessment and agreed outcomes

Start by diagnosing skills and constraints. The manager ran two 45 minute assessment conversations with each engineer. The agenda covered current responsibilities, recent decisions that went well, repeated blockers, and whom they needed to influence to be more effective. Each engineer left the conversation with a clear outcome for the next three months and one measurable signal of progress.

Maya agreed to double the number of tasks she could enable through others by delegating two recurring work items and mentoring a peer. Her primary signal was a reduction in her own pull request work time for related areas and two completed feature stories where she acted as reviewer and coach rather than implementer. Raj agreed to get formal stakeholder endorsement for one cross team technical decision and to run a design review that resulted in a documented integration plan. His signal was a recorded decision and a stakeholder sign off.

Coaching framework used

The manager combined a few well known practices into a lightweight routine that fits engineering contexts. Use these elements rather than memorizing each name.

• Goal focus Clarify a single outcome for the coaching period that links to team objectives.
• Small experiments Break progress into one to three week experiments that are easy to try and easy to stop.
• Evidence oriented checks Define concrete signals that show progress and that can be observed by others.
• Role play and scripts Prepare short conversational scripts and run role plays for difficult influence moments.
• Documentation as leverage Encourage concise artifacts that convert tacit reasoning into shareable evidence.

Practical coaching roadmap for Maya

Week one to two

Identify two recurring engineering tasks that Maya performs where a peer could learn to do the work. Co author a step by step checklist or a short how to guide. Run a paired session focused on transfer of context and decision rules. Follow up with a short retrospective one week after transfer to capture where the checklist missed steps.

Week three to six

Ask Maya to act as reviewer and coach on two feature stories owned by others. Coach her on review style that focuses on learning and constraints rather than rewriting. Use three minute feedback scripts that make expectations explicit. Track the time she spends writing code in those areas compared to reviewing and mentoring.

Week seven to twelve

Have Maya mentor a junior or mid level engineer through an entire feature cycle. She should lead design critique meetings and own a knowledge transfer artifact such as a one page component design. Measure success by the feature delivery quality and whether she can handle at least two parallel mentoring relationships without quality regressions.

Practical coaching roadmap for Raj

Week one to two

Map stakeholders and their primary concerns for the project Raj owns. Identify the decision makers, their timelines, and the information each needs to say yes. Convert that map into a one page influence plan that lists the next three stakeholders to talk with and the outcomes for each conversation.

Week three to six

Run two short design reviews with targeted audiences. Start each review with a 90 second problem statement and a one page decision trade off table that shows alternatives and risks. After each review capture feedback in a single summary and update the integration plan accordingly.

Week seven to twelve

Organize a cross team design workshop where Raj facilitates alignment on concrete integration steps. Use a pre read to set context and close the workshop with explicit commitments assigned to owners. Record the decision as a documented architecture decision record so future teams can understand the rationale.

Coaching conversation scripts and micro prompts

Coaching works better when conversations are predictable and concise. Use short prompts the engineer can practice.

• For delegation Try this prompt during a transfer pairing. Say to your peer I will explain the three constraints you should check when making this change and then I want you to write the change while I watch. This sets the expectation that the peer will act not just listen.
• For reviews When reviewing code start with What trade offs did you consider here and which one did you pick. That invites explicit reasoning rather than incremental edits.
• For influence Before a stakeholder meeting open with Here is the problem we must solve, the options I considered, and the decision I would find easiest to support. Then pause and ask for their main concern. That framing shortens alignment time.

Measuring progress with observable signals

Pick signals that are simple to measure and that others can verify. Examples used in the case study included these.

• Number of feature stories delivered where the engineer acted as reviewer and coach rather than main implementer.
• Time spent per week on direct code changes in the component area versus time on mentoring and review.
• Stakeholder sign off recorded in a meeting note or decision document.
• Number of times architecture or integration plans were reused by other teams.

Do not confuse activity with impact. A single high quality decision that reduces duplicated work across teams is worth more than many small delegated tasks.

When coaching needs escalating or changing

If progress stalls, first check for organization level blockers. Examples include unclear product priorities, lack of permission to make certain decisions, or overloaded peers who cannot accept delegated work. If blockers are structural, the manager must remove them rather than double down on coaching tactics.

If an individual shows repeated difficulty with a skill after multiple short experiments then narrow the goal and increase practice frequency. For example if delegation fails because the peer lacks context, convert the goal into creating a richer context artifact and run five short context transfer sessions rather than a single handoff.

Practical tips for managers who coach senior and staff engineers

Keep coaching time focused and scheduled. Engineers at this level prefer predictable short interactions to open ended meetings. Favor single outcome coaching periods that last three months or less. Keep written artifacts concise and actionable so they serve as leverage. Finally, treat coaching as experiments. Change one variable at a time and use the signals to decide whether to iterate, scale, or stop the experiment.

The two engineers in this case study achieved the agreed outcomes over a twelve week period. Maya completed three successful transfers and shifted to a reviewer first role for her main component. Raj secured stakeholder sign off for the integration plan and documented the decision in a public architecture record. Both outcomes improved team throughput and reduced the number of last minute escalations.