Everywhere, but never deep
Useful work can spread so widely that it never develops a center.
Small tasks move quickly across the board. Bugs are repaired, neglected code is cleaned up, reviews receive attention, and gaps rarely remain unattended for long. The activity reaches many parts of the system and keeps the team moving.
Over time, the work adds up to less than expected. Many tasks are finished, but the team develops little deeper understanding of any one area, and no one becomes responsible for what happens there next.
This is the pattern once described as the busy body: an engineer who moves rapidly across the codebase, completing useful pieces of work without staying long enough to develop depth, continuity, or responsibility for what happens next.
The name can make the behavior sound frivolous. Usually it is anything but. These engineers are often capable, curious, and responsive. They know enough about many parts of the system to become useful quickly. When a small problem appears, they are willing to pick it up. Their pull requests are easy to review, their queue stays active, and their contribution graph fills with evidence of steady work.
The risk appears over time. Each task ends near the point where deeper ownership would begin.
They add the endpoint but do not operate the service. They fix the visible bug but do not investigate why that class of bug keeps returning. They create the first version while later versions move to somebody else. Their work touches many domains without building a durable relationship with any of them.
Breadth is valuable in software teams. A senior engineer may move across boundaries because a problem genuinely spans them. A new team member may sample several areas while learning the system. A support rotation can produce a week of small, scattered changes. A staff engineer may make precise interventions across teams while other people retain local ownership.
Healthy breadth creates connections. The engineer carries knowledge between areas, recognizes recurring constraints, and helps decisions made in one system account for another. Their range gives the organization a wider view.
Fragmented work creates a different shape. The engineer changes contexts frequently, selects work with a short path to completion, and leaves before consequences return. Their range becomes a way to avoid the uncertainty, coordination, and sustained judgment that larger ownership requires.
The distinction lies in what accumulates.
After several months of healthy breadth, the engineer understands how important parts of the system fit together. Colleagues seek their help with cross-boundary decisions. They can explain the history behind a service, the tradeoffs in its current design, and the changes likely to affect it next.
After several months of fragmented work, the engineer has a long list of completed tasks and little that has become more clearly theirs. They can find their way around the codebase, but rarely carry the richest context in a room. Activity accumulates while judgment resets with each assignment.
Repository history can reveal part of this pattern. Look for many small pull requests spread across unrelated directories, high participation in reviews, and frequent new work with relatively little return to earlier changes. The engineer may appear in many projects while remaining central to none. Their changes often solve contained problems and attract little debate.
Those signals deserve context. A release engineer, developer-experience specialist, or production responder may naturally work across the repository. So may someone maintaining shared libraries. Their ownership exists at another level: the delivery path, development environment, incident process, or quality of an interface used throughout the system.
Job design therefore matters more than the distribution of changed files. Ask whether the movement serves a coherent responsibility. A scattered diff can still belong to a focused outcome. A localization project may touch every screen. A security improvement may cross every service. A performance investigation may follow one request through the entire stack.
The more useful questions concern continuity. Does the engineer help define the work, or mainly collect ready-made tasks? Do they remain involved when the first approach encounters resistance? Do they see the results in production? Do they return for maintenance, feedback, and the next version? Can they name an outcome whose quality they feel responsible for over time?
A pattern of shallow movement can originate with the engineer.
Small tasks provide frequent completion. The requirements are usually clearer, the review is lighter, and the emotional risk is limited. A person who feels uncertain about their ability can build a reassuring sequence of wins by staying close to work they already know how to finish. Their busyness is real. It also protects them from situations where progress becomes ambiguous and expertise has to be earned in public.
Curiosity can produce the same trail. Some engineers love the first encounter with a problem: discovering the area, finding an opening, and making the first useful change. Familiarity reduces the novelty that supplied their energy. As maintenance, edge cases, and operational details arrive, their attention moves toward the next unexplored problem.
The person may also equate responsiveness with value. Teams often reward the colleague who answers quickly, clears an easy ticket, or steps into an unattended gap. Every request feels like a chance to help. Enough requests can divide a week into pieces too small for sustained thought, while the resulting visible activity still earns appreciation.
Organizational design frequently produces the pattern before personality does.
A manager may give important work to the same established owners and use a versatile engineer to absorb everything left over. Sprint planning distributes a UI fix, a flaky test, and a data cleanup to the person known for being flexible. Each assignment makes sense alone. Together they form a role with no center.
A team may break work into pieces so small that nobody experiences an outcome from beginning to end. One engineer implements an endpoint, another handles deployment, and a third responds when it fails. Ownership belongs to the workflow in theory and evaporates between its stages in practice.
Urgency creates fragmentation too. Interruptions repeatedly pull the most responsive engineer toward whatever is currently loudest. Priorities change before deeper work reaches its difficult middle. The engineer learns that commitment has a short half-life, so choosing small tasks becomes a rational response to the environment.
Access can be another cause. The team says it wants people to take ownership, while architectural decisions happen in private meetings, product context stays with senior staff, and production permissions arrive only after long negotiation. Small code changes remain the only work a less-established engineer can complete independently. Their shallow trail reflects the boundary around them.
Sometimes the missing depth is a sponsorship problem. Larger work rarely begins as a perfectly bounded ticket. Someone must trust an engineer with an incomplete problem, help them find the right people, and allow their understanding to grow before visible output appears. Engineers already seen as owners receive those opportunities. Engineers seen as useful helpers receive another set of small tasks, reinforcing the original judgment.
This cycle can last for years while performance reviews continue to ask for greater impact.
Managers should begin by reconstructing the system around the work. Look at several months rather than one sprint. Group the engineer's contributions by outcome, domain, and type of responsibility. Include incident response, reviews, design discussions, support, mentoring, and maintenance. Code changes alone can make connective work look scattered even when it has a clear purpose.
Then ask the engineer what the period felt like. Which work held their attention? Where did they want to stay longer? What kept interrupting them? Which system would they like to understand well enough to make harder decisions about it? Which completed change do they still think about?
The conversation may reveal an emerging specialty the task list obscures. Several unrelated fixes may all concern observability, accessibility, reliability, or the experience of other engineers. That thread can become a legitimate area of ownership when the team names it, gives it outcomes, and makes space for its continued development.
The conversation may instead reveal avoidance. The engineer enjoys the clean finish of a small ticket and feels exposed when work requires a design proposal, coordination with another team, or responsibility after release. Treat that discomfort as a development edge. Shame makes the safe work even more attractive; a supported stretch creates evidence that the person can operate at greater depth.
Give them something with a horizon.
That might be a feature whose first release is small but whose next two versions are already imaginable. It might be a service that needs an operational owner, a recurring class of support issue, a neglected internal tool, or a quality concern that crosses the product. The best starting point has genuine value, bounded risk, and enough duration for decisions to return with consequences.
Ownership should include more than implementation. Invite the engineer into discovery. Have them clarify the desired outcome, identify constraints, and choose what belongs in the first release. Keep them connected through deployment, measurement, support, and iteration. Let them write the documentation, handle early defects, explain the work to colleagues, and propose what happens next.
This complete loop turns code knowledge into judgment.
The first version teaches how the system is supposed to work. Production teaches how it actually behaves. User feedback reveals which assumptions mattered. Maintenance exposes the costs hidden by the initial design. A second version asks the engineer to use all of that evidence rather than begin again from zero.
Depth develops through these returns.
Give the assignment enough protection to survive the next interruption. A manager who names an ownership area and then redirects its owner whenever a small request appears has created a label rather than a responsibility. Decide which incoming work can wait, rotate, or move elsewhere. Make the trade visible when urgent work truly requires a change of focus.
Support should remain available without replacing the ownership. A more experienced engineer can review a design, introduce a domain expert, or help plan an unfamiliar rollout. They should leave the important decisions legible to the developing owner. Quietly taking over the difficult middle preserves delivery while removing the exact experience the assignment was meant to create.
Progress will look slower at first.
One sustained problem produces fewer closed tickets than six small ones. Time spent reading history, speaking with users, or understanding operational behavior may produce no immediate diff. The engineer is building a model that will make later decisions faster and safer. Managers need measures broad enough to recognize that investment.
Look for changes in the questions people bring them. Notice whether they can anticipate second-order effects, explain tradeoffs, and identify which apparent problems share a cause. Watch whether their reviews in the area become more specific and whether other engineers can learn from the context they have organized. Ownership becomes visible through the quality of decisions as much as through the quantity of code.
Keep breadth alive around the deeper responsibility. The goal is a home base rather than a fence.
An engineer with wide interests may thrive with one sustained area and a deliberate allowance for smaller work elsewhere. A support rotation can preserve their view across the system. Cross-team reviews can let them carry lessons outward. Short explorations may continue to supply energy, provided their primary commitment has enough uninterrupted attention to mature.
Teams benefit from people who cross boundaries. They notice seams specialists learn to ignore, connect colleagues who would otherwise work apart, and adapt when priorities change. Depth should add weight to that range, giving the engineer a body of evidence from which to act.
Managers also need to examine the portfolio of ownership across the whole team. If one person holds every important system while another receives miscellaneous work, coaching the second person addresses only half the problem. Rebalance access to consequential work. Let established owners teach, delegate, and eventually step back from parts of their domain. Make room for new ownership before asking someone to demonstrate it.
Clear expectations help. Define what ownership means for the chosen area: the decisions the engineer can make, the outcomes they should watch, the people they need to involve, and the conditions that call for escalation. Vague ownership can feel like unlimited liability. A workable boundary gives the engineer authority alongside responsibility.
Revisit the arrangement after enough time for a full loop. Ask what they now understand that was invisible at the start. Which decision would they make differently? Where does the area still depend on someone else's memory? What should another engineer be able to learn from them?
Ownership has matured when the engineer can improve the area and make it easier for others to enter. Hoarding knowledge would merely replace one unhealthy shape with another. The strongest owner develops expertise, documents judgment, welcomes review, and creates paths for shared responsibility.
A team needs explorers and stewards. Sometimes those roles belong to different people. Sometimes a versatile engineer becomes unusually effective by learning to do both: exploring widely enough to see connections, then staying with an important problem long enough to understand what those connections mean.
The scattered trail is a signal to investigate, not a verdict on commitment.
Find the curiosity, incentives, interruptions, and access behind it. Then give the engineer a meaningful outcome, the authority to shape it, and the time to meet the consequences of their choices.
Breadth shows how many places someone can contribute. Depth begins when one of those places can change because they stayed.