# How do you work with a dotted line engineer?

**A dotted line engineer** can belong in your daily work without entering your reporting line. They may sit in standup, own tickets on your board, and know your release better than people who formally report to you. Their actual manager still owns career decisions, leave, and long term allocation. A clear three way agreement keeps useful local direction from turning into accidental people management.

        
## What does the dotted line actually mean?

        
Treat dotted line as a prompt for specifics, not a universal job design. In one company, a security engineer spends four days with a product squad and one day with security. In another, a data engineer joins planning but receives all assignments from a central group. Ask what authority was delegated to you, what remained with the home manager, and how the engineer understands the arrangement.

        
The engineer should not have to infer which manager matters on a given day. Write the local outcome, expected capacity, duration, and the name of the person who breaks ties. If you can sequence agreed work but cannot add new scope, state that boundary. If the home manager can recall the engineer for urgent work, define urgent and require a direct manager conversation.

        
Explain the model to your team. People may otherwise treat the engineer as spare capacity or exclude them from decisions because they are not a real member. Neither response fits. They are a full participant in the work that was assigned, with a second organizational home that remains legitimate.

        
## Who should assign the engineer's work?

        
Use one local backlog and one named daily work owner. Multiple teammates can discuss needs, but the engineer should not receive competing private assignments. The home manager confirms how much capacity is available and which categories of work fit the placement. You then sequence work inside that envelope with the engineer and the team.

        
For example, a security engineer embedded in a product squad might own threat modeling and remediation support for a new payments flow. That does not make every old security task their responsibility. When a teammate asks for an unrelated access review, route it through the agreed intake rather than rewarding whoever asks in Slack first.

        
Check capacity with evidence. Tickets alone may miss design reviews, consultations, and work for the home team. Ask the engineer to describe the whole load, then resolve conflicts with their manager. Do not praise them for quietly working evenings to make two managers' plans appear compatible.

        
## Who writes the review and approves time off?

        
The actual manager should own the formal review, compensation input, promotion case, and leave approval unless company policy explicitly says otherwise. Your role is to provide timely examples from work you directly observed. A dotted line does not give you permission to promise a rating, a promotion, or an exception to policy.

        
Agree on a feedback rhythm before review season. A monthly note with outcome, behavior, impact, and context is more useful than a rushed summary at the end. Include strengths and gaps. Share material feedback with the engineer first, so your input to their manager does not reveal a private judgment they never had a chance to use.

        
When the engineer requests time off, direct the approval to their manager and immediately adjust your local plan. Avoid making the person collect separate emotional permissions. You may explain delivery impact and offer timing choices, but the formal decision belongs to the stated owner.

        
## How should three way feedback work?

        
- Agree which work outcomes you will observe.
- Give the engineer direct feedback near the event.
- Record specific behavior and work impact.
- Let the engineer add context or correction.
- Share the agreed facts with the home manager.
- Ask what coaching each manager will own.
- Review whether the pattern changed.

        
This sequence prevents two common failures. In the first, you send criticism to the home manager but remain pleasant with the engineer, creating surprise and distrust. In the second, both managers coach the same problem differently, leaving the engineer to reconcile incompatible advice. Directness plus coordination is kinder and more effective.

        
Not every observation needs a three person meeting. Routine feedback should stay lightweight. Bring the home manager in when a pattern affects evaluation, when priorities contribute to the behavior, or when support requires authority you do not have. The engineer should know why the conversation expanded.

        
## Which decisions belong to each manager?

        
| Decision | Host manager | Home manager |
| --- | --- | --- |
| Daily sequence | Owns within scope | Consulted if capacity changes |
| Work feedback | Gives observed examples | Uses full context |
| Review rating | Provides input | Owns decision |
| Time off | Adjusts plan | Approves request |
| Recall to home team | Explains impact | Negotiates timing |

        
A table cannot resolve every local policy, but it exposes missing decisions. Replace titles with names and link to the agreement where the team can find it. If your organization delegates a different authority, document the exception rather than assuming everyone knows it.

        
The engineer should be consulted on changes that affect their work, but consultation is not the same as making them decide between managers. Let them explain technical consequences and personal preferences. Then the managers should own the resource decision and communicate one answer.

        
## What happens when the home team pulls them back?

        
Assume recall is possible and plan for it before urgency. Keep designs, runbooks, and open decisions in shared systems. Pair another engineer on critical areas. Avoid giving the dotted line engineer sole ownership of a service simply because they have the strongest specialty. Resilience is part of the host manager's job.

        
When the request arrives, ask for reason, timing, and expected duration. Explain product impact in concrete terms, such as a delayed security review or an unsupported launch. Offer options rather than resisting on identity grounds. Perhaps the engineer finishes one critical review, transfers another task, and returns to the home team by a named date.

        
Tell your team what changed without blaming the engineer. The allocation agreement changed at manager level. Present the new plan, owners, and risks. Public frustration aimed at the person teaches future guests to hide requests from their home group.

        
## How do you include both organizational homes?

        
Invite the engineer to local planning, retrospectives, and technical decisions that affect their work. Give them the same context and review bar as other contributors. Do not reserve meaningful ownership for formal reports while assigning only cleanup to the embedded specialist.

        
Protect connection with the home team. Keep their home planning block or community meeting visible on the calendar. Encourage them to bring reusable learning back, such as a threat model pattern discovered in the product squad. Their second home is a source of expertise, not a loyalty problem.

        
When recognition is due, name both contexts. Tell your team how the engineer changed the product outcome, and tell the home manager how that work advanced the specialty. This helps the person receive fair credit without requiring them to market the same contribution twice.

        
## How do you prevent a permanent ambiguity?

        
Set a date to decide whether the placement ends, renews, or becomes a formal transfer. Long running dotted lines can work, but they need renewed consent and current boundaries. Capacity often drifts while the written agreement remains frozen. The engineer then carries the gap.

        
Ask separately about delivery, development, and belonging. The work may be successful while the engineer receives weak career support or feels absent from both teams. Their home manager should still understand goals and growth. You should still provide meaningful work and direct feedback. Neither manager may assume the other covers everything.

        
If a formal transfer becomes likely, do not behave as though it already happened. Use the real process, clarify timing, and let the engineer choose where policy allows. Until the transfer is complete, honor the current reporting line and avoid promises about title, pay, or review outcomes.

        
## What does a healthy week look like?

        
A healthy week has one visible plan that respects both homes. The engineer knows which product outcome matters, which security or platform obligations continue, and where questions belong. Meetings fit inside the capacity agreement. Unexpected work is traded against something else rather than added through private urgency.

        
Imagine the embedded security engineer joins product planning on Monday. They identify two reviews needed before launch and reserve time for the security community on Wednesday. On Thursday, the central team requests help with an audit. Instead of accepting silently, the engineer flags the conflict. You and the security manager decide that one product review moves to another specialist while the engineer completes the higher risk review and supports the audit.

        
The key signal is not perfect schedule stability. It is that changes travel through the agreed route and produce a new plan. The engineer does not work two full jobs, teammates do not compete through direct messages, and neither manager learns about overload after a missed commitment.

        
Use the weekly 1 on 1 or work check to ask three practical questions. What changed in either home? Which commitment now competes with another? What decision requires the managers rather than the engineer? These questions uncover allocation problems without turning every conversation into status reporting.

        
Also preserve development. The home manager may own career goals, but you control many daily opportunities. If the engineer wants deeper product context or design leadership, choose suitable work and send evidence back. If local work offers no learning for months, say so. A dotted line should not make career growth invisible simply because no single manager sees the entire week.

## What are common questions?

### Can a host manager assign tickets to a dotted line engineer?

Yes, when the agreed placement delegates daily sequencing and the tickets fit the outcome and capacity approved by the home manager.

### Who writes a dotted line engineer's review?

The actual manager normally owns the review, using specific and timely evidence supplied by the host manager.

### Who approves time off?

The actual manager approves it under company policy, while the host manager adjusts local commitments and communicates delivery impact.

### Can the home team take the engineer back?

Yes, if the allocation permits it, but the managers should negotiate timing and impact directly rather than pressure the engineer.

### Should the engineer attend both teams' rituals?

They should attend the rituals needed for each responsibility, with an explicit schedule that does not silently exceed their capacity.

Related: [working with people who are not your reports](https://isilta.com/blog/how-to-work-with-people-who-are-not-your-reports/), [working with a forward deployed engineer](https://isilta.com/blog/how-to-work-with-a-forward-deployed-engineer/), [working with an engineer who has manager potential](https://isilta.com/blog/how-to-work-with-an-engineer-who-has-manager-potential/).