Omid Farhang
Table of Contents
This post starts the Shadow Ownership series (3 posts in total).
On a small development team, one senior developer often becomes the person everyone else knows.
People in product, design, support, and adjacent engineering teams message them directly. They listen well. They notice the rough edge that never became a ticket. They understand why a technically correct interaction still feels wrong to the person using it. When another team is frustrated, they do not reply with a Jira link and disappear.
This is valuable work. It is also how a backdoor can form.
The same developer starts returning from those conversations with changes already in motion. A suggestion has become a promise. A detail outside the sprint has become urgent. Other teams begin treating this person as the owner of the team’s work, even though nobody assigned that role. The team lead learns about a commitment after the work has started.
The conversations are not the bug. Unowned commitments are the bug.
Consider a small example. A designer messages the senior about a confusing flow. The senior agrees that it is poor and says, “We’ll fix it this sprint.” The change is reasonable, but the sprint is already full. The team quietly displaces another planned item—perhaps a defect fix, an accessibility improvement, or a committed integration—to make room.
Now two promises exist: the one the team planned and the one the senior made. At least one stakeholder experiences the team as unreliable, even though everyone involved was trying to improve the product. The hidden cost is not that the lead missed a message. It is that nobody made the trade-off while both obligations were in the open.
The same behavior can be an asset and a liability
There are good reasons to value the cross-team communicator:
- They build trust beyond the team boundary.
- They bring back feedback that a ticket queue does not capture.
- They care about the end-to-end experience, not only acceptance criteria.
- They notice details that protect users from confusion.
- They spend energy on problems that otherwise remain between teams.
There are also good reasons to be concerned:
- Informal requests become hidden commitments.
- Priorities move without the team making a decision.
- The lead is bypassed as the person accountable for delivery.
- Product ownership shifts to an individual without authority or visibility.
- Perfectionist changes create rework and make “done” unstable.
Neither list cancels the other. Calling the developer difficult would throw away useful initiative. Calling every action ownership would ignore the coordination cost imposed on everyone else.
The other developers pay for the ambiguity too. They receive surprise work, review changes against standards that were never agreed, and become uncertain about who owns the final decision. A ticket can pass its acceptance criteria and still feel unfinished because an unofficial reviewer may reopen it. Teammates can also feel bypassed when one senior becomes the only person trusted with product context.
That makes shadow ownership a team-system problem, not a dispute over the lead’s status.
The leadership problem is to preserve the signal while removing the private delivery channel.
This pattern has a name: shadow ownership
Shadow ownership is high-agency influence without clear role authority.
It appears when a person becomes an unofficial product owner, design gatekeeper, or team representative through repeated informal interactions. Their influence is real. Their accountability is ambiguous. Other people route decisions through them because doing so feels faster than using the official process.
This is not simply “too much communication.” Healthy teams need people who cross boundaries. It becomes shadow ownership when communication quietly starts carrying one or more of these:
- Commitment: “We will fix that this sprint.”
- Priority: “This is more important than the work already planned.”
- Authority: “I will make sure the team does it this way.”
- Moral ownership: “I am the person who really cares about this product.”
The first three alter the team’s work. The fourth alters the team’s trust.
What shadow ownership is not
Influence and individual ownership are not inherently suspicious.
A staff engineer who is explicitly assigned a domain, has published decision rights, reports decisions where the team can see them, and is accountable for outcomes is not a shadow owner. Neither is a senior developer who owns an agreed feature and coordinates directly with its stakeholders.
The distinction is not whether one person has influence. It is whether authority, scope, and accountability are explicit and aligned. Delegated ownership has a named boundary and a visible owner. Shadow ownership accumulates through habit, remains ambiguous when challenged, and creates commitments outside the accountability system.
Why small, Jira-driven teams create shadow owners
A ticket system is useful for deciding and tracking work. It is a poor substitute for contact with the people affected by that work.
On a team of two or three senior developers, routine can become very efficient: receive tasks, refine them, implement them, review them, and move on. Meanwhile, users report friction to support, designers observe inconsistencies, and another team discovers an integration problem in a chat channel. That information exists before anyone turns it into a ticket.
If the team’s only legitimate input is the backlog, a vacuum forms between lived product experience and planned delivery. Someone who talks to people will fill it.
Sometimes that person develops a hero story: I am the only one paying attention. Sometimes the process really is too closed and they are the only one receiving the signal. Often both are true. A responsible diagnosis tests both possibilities instead of assuming either disloyalty or heroism.
The organization contributes too. If product ownership is weak, priorities are unclear, or stakeholders cannot get timely answers, they will find the most responsive engineer and treat responsiveness as authority. People follow the fastest reliable path. An organization with no visible owner eventually gets a volunteer.
The answer is not merely to close the backdoor. The official path has to earn its use through clear ownership, a timely response, and a visible decision. Otherwise, stakeholders will continue routing urgent-looking work through the person who answers first.
Keep the communication; stop the private promises
The boundary can be stated simply:
- Talk to anyone.
- Bring feedback back where the team can see it.
- Do not promise scope, priority, or dates alone.
- Separate a user-facing defect from a preference about polish.
- Do not reopen completed work without making the cost visible.
This does not require every conversation to pass through the team lead. That would turn leadership into a communications bottleneck. It requires decisions that change team commitments to return to the team’s decision system.
A senior developer should be free to say:
That sounds important. I will bring it to the team and make sure it is visible.
That sentence is responsive without pretending that one person owns the roadmap.
Match the process to the cost of the decision
Not every cross-team action needs a governance event. Requiring a meeting for every reversible adjustment would make the official path slower than the backdoor.
Within an agreed area, a senior can usually act on a low-cost, reversible decision without creating a new product or delivery commitment: clarify copy, test a hypothesis behind a flag, gather logs, reproduce a defect, or make a local implementation adjustment that does not change external expectations. The team should define that operating space and trust people to use it.
A visible decision path is needed when the action is difficult to reverse or spends shared authority. That includes changes to release timing, promised dates, contractual behavior, data handling, security, accessibility requirements, another team’s work, or the scope already committed for the sprint.
The useful question is not “Did the lead approve this conversation?” It is “What becomes harder to undo, and who bears the cost if this decision is wrong?”
Failure mode one: the lead defends the queue
A threatened lead may respond by restricting contact: direct all requests to me, stop talking to design without me, work only from assigned tickets.
This restores formal authority at the cost of information and trust. It also teaches the team that initiative is dangerous. The cross-team conversations continue, but now they become less visible.
Leadership is not being copied on every message. It is maintaining a process in which useful information can enter freely while commitments remain explicit. If the only way to preserve authority is to become the team’s router, the operating model is already too fragile.
The lead has to ask an uncomfortable question: did this person create a backdoor, or did they reveal that the front door does not work?
Failure mode two: the senior becomes the moral owner
The opposite failure is just as damaging.
A high-agency senior can begin to frame every disagreement as evidence that other people care less. Product accepted a compromise, so product does not understand users. Design allowed an inconsistency, so design lacks standards. The team wants to ship, so the team accepts bad work.
At that point, attention to detail has become moral authority. The product starts to feel like a personal portfolio, and colleagues become obstacles to protecting it.
That posture makes collaboration impossible. Teams regularly choose between good outcomes under real constraints. Caring does not grant one person the right to hide those constraints, replace priorities, or keep work permanently open.
Care has to survive contact with shared decisions.
The real boundary is visibility
Cross-team influence is not a problem to eliminate. It is a capability to govern.
The healthy version is a scout: someone who goes beyond the team’s normal line of sight, gathers useful information, and returns with it. The unhealthy version is a shadow owner: someone who goes out, makes a decision, and returns with an obligation.
That difference is visibility:
- Can the team see the feedback?
- Can the accountable people see the commitment before it is made?
- Can everyone see what will be displaced if the work enters the sprint?
- Can a decision be challenged without challenging one person’s identity as the person who cares?
If the answer is yes, influence strengthens the team. If the answer is no, influence has become a second operating system.
What comes next
The pattern has two seats, and each has work to do.
For the lead, the answer is not to crush the communicator. It is to formalize the useful part of the role, define where commitments are made, and give polish a budget. The next post, Channel the Scout, Keep the Seat, is a practical playbook for doing that, including a copyable operating agreement.
For the senior developer, the challenge is to keep cross-team trust without becoming the unofficial boss. The final post, Have Influence Without Becoming the Backdoor, covers how to bring feedback, protect the user experience, and stay on the team’s side of the board.
If you crush the communicator, you lose the signal. If you ignore the backdoor, you lose the team.