- In an external service integration feature, one team owned requirements definition and the neighboring team owned implementation. The author explains that no one was positioned to judge whether the requirements were feasible and how much effort they would take, so work kept going back and forth between the two teams.
- The author says that abstract requests to change how work is divided between teams always ended with the claim that it was practically difficult. In response, they created a one-page responsibility boundary map showing the owner of each stage and brought it to a meeting.
- In the diagram, engineers gather materials for preliminary research and pass them to a product manager (PdM, the role that sets a feature's direction and priorities). The PdM decides the requirements definition, and engineers take charge of design. The author states that after this diagram was used, the meeting shifted to concrete revision discussion. The source does not state that the effect was measured numerically.
- Two objections came up in the meeting. One was that the receiving team had no spare staff. The other was that the knowledge needed for research and requirements remained with the former team. The author says they handled these separately from the discussion about responsibility division.
O: This is useful for an engineering manager who has been handed an external integration feature with unclear responsibility boundaries. Before the next planning meeting, they can draw a table of owners for each step and work with the team to check whether each row's owner is right.
X: The case comes from the author's own organization. The source gives no evidence that the effect was measured numerically, and the author admits that staffing shortages and priority conflicts cannot be solved by a diagram alone, so you need to weigh your organization's conditions before copying it.