# How do you work with people who are not your reports?

**Working with people who are not your reports** requires explicit agreements because proximity can look like authority. Someone may attend your standup, answer in your Slack channel, and move tickets on your board while another manager, employer, or professional role still controls important decisions. Name the shared outcome, the work owner, the people owner, and the route for disagreement before pressure makes those boundaries personal.

        
## Why does proximity create false authority?

        
Engineering managers usually infer responsibility from repeated contact. The person who joins planning every week begins to feel like part of the reporting line. You assign a task, review the result, and answer questions, so it is easy to assume that you also control priorities, time off, career feedback, or continued placement. The other person may make the same assumption until their actual manager makes a conflicting request.

        
The risk is not merely an awkward org chart. False authority produces promises that nobody can keep. A product manager hears that a security engineer will stay through launch, while the security manager expects that engineer back for an audit. A consultant is treated as permanent system ownership even though the contract ends next month. The team plans around availability that was never yours to grant.

        
Use a simple distinction from the first week. Work authority covers the agreed outcome, local practices, and daily coordination. People authority covers employment, compensation, leave, formal evaluation, and long term allocation. Some roles split those areas differently, so confirm rather than guess. Clarity protects the guest and your team from discovering the real contract during a crisis.

        
## What should you agree before work starts?

        
Write a short operating agreement with the person and whoever owns their allocation. Name the outcome, expected duration, weekly capacity, daily work contact, and decisions that require the home manager or vendor owner. Include what happens when priorities conflict. A page is enough if it answers the questions people will otherwise negotiate in private.

        
Describe success in terms that both homes recognize. Your product squad may care about a safe checkout launch, while the security group cares about a reusable threat model. If only your local deliverable appears, the guest will be forced to choose between visible work here and obligations that sustain their standing elsewhere. A shared outcome lets both managers support the same work for different valid reasons.

        
Agree how feedback moves. You should give immediate feedback about work you observed, but formal evaluation may belong elsewhere. Decide whether you send monthly notes, join a review input conversation, or simply provide examples on request. Tell the person what will be shared. Invisible back channels make ordinary coaching feel like surveillance.

        
## Which unusual roles are in this series?

        
- [A dotted line engineer](https://isilta.com/blog/how-to-work-with-a-dotted-line-engineer/)
- [A forward deployed engineer](https://isilta.com/blog/how-to-work-with-a-forward-deployed-engineer/)
- [An embedded consultant](https://isilta.com/blog/how-to-work-with-an-embedded-consultant/)
- [A people partner](https://isilta.com/blog/how-to-work-with-a-people-partner/)
- [An engineer with manager potential](https://isilta.com/blog/how-to-work-with-an-engineer-who-has-manager-potential/)

        
These roles are unusual for different reasons. The dotted line engineer has another manager. The forward deployed engineer moves between customer work and your team. The consultant has a commercial boundary and an end date. The people partner advises management without owning your relationship with the engineer. The rising engineer is still a peer even while practicing parts of management.

        
Choose the guide that matches the actual contract, not the behavior you happen to see. Someone who runs a standup is not automatically a manager. Someone who joins every planning session is not automatically permanent capacity. Correct labels reveal which promises you may make and which conversations require another owner.

        
## How should decision rights travel?

        
List the recurring decisions and assign one clear owner for each. Work sequencing may belong to your tech lead, security exceptions to the security organization, customer commitments to product leadership, and contract scope to a vendor owner. Consultation can be broad, but final authority should not be implied by who speaks most often in the room.

        
When a decision crosses boundaries, make the handoff visible. Suppose an embedded security engineer identifies a launch risk. Your team can choose an implementation, but only the security owner can accept residual risk. Record both choices separately. This avoids asking the guest to carry authority they do not have or letting your team treat their advice as an automatic veto.

        
Escalation is part of the design, not a failure of collaboration. Decide who speaks when the local roadmap conflicts with the person's home obligations. The first conversation should involve the two accountable managers, not force the person to bargain between them. They can provide facts and preferences, but managers should own the organizational tradeoff.

        
## Which boundary questions should you answer?

        
| Question | Local answer | Other owner |
| --- | --- | --- |
| Who assigns daily work? | Named work lead | Confirms capacity |
| Who gives feedback? | Observed work feedback | Formal review |
| Who changes scope? | Proposes tradeoff | Approves commitment |
| Who handles absence? | Adjusts the plan | Approves leave |
| Who ends the placement? | Raises the need | Owns allocation |

        
The answers will differ by role, but ambiguity should not. Put names beside responsibilities. A generic phrase such as leadership will decide is too slow when a release is blocked. The person in the unusual role should know exactly where to take a request and should not become the courier between managers who could speak directly.

        
Review the table whenever scope, staffing, or timing changes. An agreement made for discovery may not fit delivery. A two day customer visit may become a month of field work. Updating the boundary is a normal response to changed conditions, not an admission that the original collaboration failed.

        
## How do you include someone without absorbing them?

        
Invite the person to rituals that help the agreed work. Standup, planning, design review, and incident response may all be useful. Explain which rituals are optional and which carry decisions. Requiring every social and operational ritual can erase their other home and consume capacity that was meant for specialist work.

        
Use inclusive language without inventing permanence. Say our migration team or the people working on this release rather than insisting that everyone has one organizational identity. Ask how the person wants to be introduced. A consultant may want their company and specialty named. A dotted line engineer may want both teams visible so colleagues know where broader requests belong.

        
Make information accessible in the same systems the team uses, subject to access rules. Guests should not rely on private summaries to understand decisions. At the same time, review permissions and confidential channels deliberately. Belonging to daily work does not automatically grant access to compensation notes, customer secrets, or unrelated incidents.

        
## What does useful feedback sound like?

        
Give feedback close to the observed work. Say that the integration review lacked a rollback owner, or that the consultant's pairing session let two internal engineers repeat the procedure. These statements are yours to make because you saw the behavior and its effect. They help the person improve without pretending you control their rating.

        
Separate request, consequence, and formal judgment. You can request a clearer deployment note and explain that the current one leaves support unable to act. If the pattern may affect assignment or performance, involve the actual manager or contract owner according to the agreement. Do not hint at consequences that you have no authority to deliver.

        
Share positive evidence too. Other managers often hear from a host only when something goes wrong. Specific recognition helps the home manager understand the person's contribution and avoids turning the unusual role into a source of risk reports. Tell the person what you shared and invite corrections to factual errors.

        
## How do you close or renew the arrangement?

        
Set a review date before the placement feels permanent. Ask whether the outcome still needs this role, whether knowledge has moved, and whether the capacity bargain remains fair. Continuing by inertia is especially dangerous for specialists, because the team quietly builds dependencies while the home group assumes the work is temporary.

        
Plan the exit as real engineering work. Transfer decisions, access, open risks, and relationships to named owners. A final presentation is not enough if nobody can operate the system on Monday. Use pairing, observed practice, and a short period where the internal owner leads while the departing person watches.

        
Close the people loop as carefully as the technical loop. Thank the person in terms that recognize the unusual contract, send useful feedback to the proper owner, and tell the team what changes after departure. If the role returns later, start a new agreement rather than reviving assumptions from the old one.

        
## How can you repair a boundary that was never stated?

        
Begin by naming the mismatch without blaming the person. You might say that daily coordination made it seem as though you could approve a longer assignment, but their real manager owns allocation. State what you know, what must be confirmed, and when everyone will receive one answer. A prompt correction is more trustworthy than defending an authority you never had.

        
Meet with the other owner and bring the work impact. Do not ask the guest to relay competing positions. Agree on current priorities, the decisions each of you controls, and any commitment that needs correction. Then communicate together or use identical language. The person should not have to compare messages to discover which manager is speaking for the organization.

        
Repair the team plan as well. If colleagues believed the specialist would stay through launch, show which work moves, which risk remains, and who now owns it. Avoid language that presents the other manager as stealing capacity. The original ambiguity was a management problem. Your response should restore predictability rather than recruit the team into an organizational dispute.

        
Finally, update the agreement and ask the person what the ambiguity cost them. They may have postponed home work, avoided leave, or felt unable to refuse requests. Listen without demanding reassurance. A better boundary is demonstrated by future choices that no longer depend on personal courage.

## What are common questions?

### Can you assign work to someone who is not your report?

Yes, when the placement agreement gives you work authority and the assignment fits the capacity and outcome agreed with the real owner.

### Who should give performance feedback?

Give direct feedback on work you observe, while the actual manager or contract owner handles formal evaluation and employment decisions.

### Should guests join every team ritual?

No. Include them in rituals that support the agreed work, and preserve time and identity connected to their other responsibilities.

### What should happen when priorities conflict?

The accountable managers should resolve the organizational tradeoff directly instead of making the person negotiate between competing authorities.

### How often should the arrangement be reviewed?

Set a date at the start and review again whenever scope, capacity, timing, or the person's home obligations change.

Related: [working with a dotted line engineer](https://isilta.com/blog/how-to-work-with-a-dotted-line-engineer/), [working with a forward deployed engineer](https://isilta.com/blog/how-to-work-with-a-forward-deployed-engineer/), [working with an embedded consultant](https://isilta.com/blog/how-to-work-with-an-embedded-consultant/).
