Adapted from Lesson 10, “Ownership Is Not Saying Yes to Everything,” in The Engineer’s Operating System by Abid Jamil, printed pages 38–39 (PDF pages 39–40). First published as this website article on 7 October 2026. Explore the book.
When helpfulness becomes a dependency
Taking responsibility is often how an engineer earns trust. You help a colleague, investigate an unfamiliar problem and step forward when work needs an owner. Those habits create opportunities. As responsibilities grow, however, automatically accepting every request can leave too much of the team’s progress dependent on your time.
The warning sign is not simply a busy calendar. It is a pattern in which decisions wait for you, important context stays in your head and work stops when you are unavailable. The team can appear productive while relying on a fragile arrangement. More effort from the same person may keep that arrangement running without making it healthier.
Care about the outcome; share the execution
Ownership does not require personally completing every action. You can recognize that a problem matters, identify an appropriate implementation owner, help remove obstacles and agree on how the result will be reviewed. Responsibility remains clear, while the work has room to move beyond one person.
This requires judgment about your role. Sometimes direct involvement is necessary; sometimes it prevents another capable person from developing confidence. Before accepting another task, consider whether the team needs your execution, your context or your decision. These are different contributions, and treating them as interchangeable can create unnecessary dependency.
Delegate the context with the task
A useful handover explains why the work matters, what a successful outcome looks like and when you will check in. Without that context, a new owner may have to return for every small decision. The task has moved, but the responsibility has not. Shared understanding is what allows someone to exercise judgment rather than merely follow instructions.
Discuss the constraints that affect the work and make the follow-up point explicit. That creates a place to surface uncertainty without requiring constant approval. Stay available to unblock the owner, but leave enough space for them to make decisions within the agreed scope. Delegation should create another owner, not another route through your inbox.
Treat repeated heroics as a signal
Occasional extra effort and permanent overwork are different situations. If the same person repeatedly has to rescue a workflow, examine the system around it. Missing context, unclear responsibility or concentrated decision-making may be contributing. Celebrating the rescue without addressing the dependency leaves the team exposed to the same difficulty again.
Try this: select one responsibility you are carrying unnecessarily. Hand it over with the relevant context, a clear definition of success and an agreed review point. Observe what still comes back to you. Those questions show where the next improvement in shared understanding is needed.
Key takeaways: ownership includes boundaries, delegation and judgment. A leader helps the team take responsibility for outcomes while developing its ability to act independently. Ask whether people benefit from your leadership or require your continuous availability to make progress.