An engineer with manager potential needs honest, bounded practice rather than an invisible promotion. A staff engineer who mentors peers or runs standup while you are away may be ready to test parts of management, but remains an individual contributor. Name what they may decide, what stays with you, how long the practice lasts, and how the rest of the team can question the arrangement.
How do you learn whether they want management?
Ask directly and leave room for uncertainty. An engineer may enjoy mentoring, planning, or resolving disagreement without wanting performance responsibility, hiring accountability, and less coding time. Do not treat helpful behavior as consent to a career change.
Discuss the actual job, including difficult conversations, organizational tradeoffs, repeated context switching, and responsibility without complete control. Avoid presenting management as the natural reward for technical strength. A senior individual contributor path should remain credible, visible, and valued.
Let the answer change. Someone can be curious now and decide against the role after practice. That outcome is useful career information, not a failed audition. Promise that a fair experiment will not damage their standing as an engineer.
What practice is real but safely bounded?
Choose one responsibility with a clear beginning and end. Leading a project, facilitating a hiring loop, coordinating an incident review, or running planning for six weeks can reveal relevant behavior. The assignment should create actual decisions and relationships, not merely extra administration.
State the learning question. A project lead might practice aligning owners and surfacing disagreement. A hiring lead might practice consistent evidence and timely decisions. If the assignment is only deliver this project, success will measure delivery again and teach little about whether the engineer wants or can grow into management.
Keep employment authority with you. The engineer should not handle performance cases, compensation, leave approval, private manager notes, or promises about promotion. Practice does not justify exposing peer information or turning a temporary lead into an unannounced supervisor.
How do you tell the team who decides?
| Decision | Practicing engineer | Manager |
|---|---|---|
| Project sequence | Decides within scope | Sets outcome and constraints |
| Technical proposal | Facilitates and recommends | Names final technical owner |
| Peer feedback | Gives work feedback | Owns performance action |
| Work allocation | Suggests project tasks | Resolves people concerns |
| Time off and review | No authority | Owns decision |
Share the boundary at kickoff and repeat it when the assignment changes. Team members should know whether a direction is a project decision, a recommendation, or a managerial expectation. Ambiguity gives the practicing engineer power without accountability and makes disagreement feel risky.
Provide a route around them. A teammate must be able to raise concerns with you without it becoming evidence that the practice failed. The engineer also needs a route to you when a peer issue exceeds the assignment. Clear escalation protects everyone and keeps the exercise honest.
How do you avoid creating a shadow manager?
A shadow manager assigns work, represents performance, and carries sensitive context without title, support, or explicit consent from the team. This often begins because a capable staff engineer already answers questions when you are away. Stop the drift by turning any practice into a named, time limited assignment.
Do not ask them to monitor peers for you. They can give direct feedback about shared work, as any strong teammate should. They should not collect private evidence, report attitudes, or enforce expectations that you avoid discussing yourself. You remain responsible for management conversations.
Watch how others respond. If teammates seek approval from the practicing engineer for leave, career choices, or ordinary technical disagreement, restate the boundary. If you start relying on them to carry messages you should deliver, reduce the assignment and repair the manager relationship.
What practice sequence should you use?
- Ask whether the engineer wants to explore management.
- Choose one time boxed responsibility.
- Name the decisions and limits publicly.
- Define the behavior you will observe.
- Meet regularly to reflect on real moments.
- Collect team impact without running a popularity vote.
- End the assignment and discuss what they learned.
- Choose a next step without promising promotion.
A time box creates a genuine ending. Six to ten weeks is often enough for a project leadership experiment, though the work should determine the duration. Put the review date on the calendar before starting, so the temporary role does not quietly become permanent unpaid labor.
At the end, discuss energy as well as competence. Which conversations did they seek or avoid? What work did they miss? Did responsibility feel meaningful or draining? Career choice should reflect the job they experienced, not only praise for the result.
How do you keep glue work fair?
Potential managers are often the people who already onboard others, take notes, chase owners, and smooth conflict. Those contributions matter, but piling on more coordination can reduce their technical growth and make the team dependent on unpaid labor. List the added work and remove something of comparable weight.
Rotate routine glue work that belongs to a healthy team. The practice assignment should focus on deliberate learning, not every neglected task. Leading a difficult project decision can be useful practice. Becoming the permanent meeting scheduler because they are reliable is exploitation, not development.
Credit the work in current evaluation even if the engineer never becomes a manager. Project leadership, mentoring, and coordination can demonstrate impact in an individual contributor role. Do not make recognition conditional on accepting a future promotion.
What feedback reveals management readiness?
Comment on listening, clarity, judgment, and response to disagreement, not only whether the project shipped. Did the engineer seek context before deciding? Could they state a decision that disappointed a peer without becoming defensive? Did they notice when one voice dominated? These moments are closer to management work than task throughput.
Use specific examples. Say that during design conflict they summarized both constraints and asked the quietest domain owner to test the proposed tradeoff. Or say that they privately changed task ownership without explaining why, leaving two peers unsure who could decide. Concrete feedback gives them something to repeat or repair.
Distinguish a skill gap from lack of desire. Listening can improve with practice. Dreading every people conversation may indicate that the job itself is not attractive. Neither conclusion should be made from one event, especially under unfamiliar authority.
What should happen after the experiment?
End the temporary authority clearly. Tell the team which decisions return to normal owners and thank them for participating. Leaving the boundary vague forces peers to guess whether the engineer still speaks for management.
Discuss several paths. The engineer may try a different practice, seek formal manager training, continue as a project lead, or return fully to individual contribution. A formal promotion depends on organizational need and a fair process, not simply successful completion of one assignment.
Record what support made the practice possible and what the team experienced. If the engineer proceeds toward management, use the evidence to shape development in listening, feedback, and disagreement. If they do not, preserve the useful leadership behaviors without maintaining a secret boss role.
How can a project lead practice disagreement?
Give the engineer a project where reasonable people hold competing constraints, not a task where leadership means distributing tickets. For example, a platform change may improve reliability while forcing product teams to alter release plans. The practicing lead can gather concerns, frame options, and facilitate a decision by the named technical owner.
Before the meeting, ask what each person is protecting and where authority sits. The engineer should prepare questions rather than a speech that proves their preferred design. This reveals whether they can remain curious while accountable for movement, a common tension in management.
Observe the room without rescuing too quickly. Do they let one senior voice close discussion before key evidence appears? Do they restate disagreement accurately? Can they separate a person's frustration from the technical choice? Take notes on behavior and consequence, then discuss one or two moments privately.
If the lead makes a weak decision, preserve the boundary. The actual owner can correct material risk, but avoid taking over every imperfect exchange. Explain what required intervention and what remained acceptable learning. Practice becomes meaningless when the manager silently controls every result.
Ask affected teammates about process, not whether they like the aspiring manager. Did they understand who decided? Could they raise contrary evidence? Did the final explanation reflect the tradeoff? This feedback protects the team without turning the experiment into a popularity contest.
Finally, ask the engineer how disagreement affected them. Some enjoy finding a workable choice but dislike carrying other people's disappointment. Others discover they rushed consensus to escape tension. That reflection can guide another practice assignment or support an informed return to the individual contributor path.
How do you protect peers during the experiment?
Tell peers the duration, scope, and feedback route before the assignment starts. They should not discover new authority when a colleague redirects their work. Make clear that respectful disagreement will not be treated as resistance to the engineer's career.
Check for uneven cost. The practicing engineer may delegate unpleasant tasks, overuse familiar collaborators, or consume meeting time while learning. These mistakes can be coached, but teammates should not carry them indefinitely for someone else's development. Adjust the exercise when impact becomes excessive.
Close the loop with the group at the end. State what authority ends, what useful practices continue, and who owns unresolved decisions. This restores ordinary peer relationships and demonstrates that experiments have real boundaries.
What are common questions?
Should a strong mentor become a manager?
Not automatically. Ask whether they want the full job and give bounded practice before either person assumes the answer.
What is a good first management practice?
Use a time boxed project or hiring responsibility with real decisions, explicit limits, regular reflection, and a clear end.
Can they assign work to peers?
They may sequence project tasks when that authority is public, but the manager must handle people concerns and broader allocation.
How do you prevent a shadow manager?
Name temporary authority, keep employment decisions with the manager, provide escalation routes, and end the assignment explicitly.
What feedback matters most?
Focus on listening, fair decisions, handling disagreement, clear boundaries, and team impact rather than delivery alone.
Related: working with people who are not your reports, working with a dotted line engineer, working with a people partner.
Prefer prepared conversations over memory alone? Explore iSilta features or try the product demo.