The 'Delayed Opinion Givers': Prioritizing Cross-Team Collaboration in Engineering

When another engineering team requires work on your team's domain, their success often hinges on your cooperation. Faced with such requests while managing your own workload, teams typically choose one of three paths:

1. Disengagement: Provide no attention, allowing the other team to proceed as they deem best.
2. Delayed Engagement: Offer attention only after persistent follow-ups, leading to late PR reviews and consultations.
3. Prioritized Support: Actively help them achieve great work on time, even if it means adjusting your own immediate priorities.

The core principle is that effective engineering teams prioritize cross-team needs—addressing questions, requests for help, and consultations—approximately 90% of the time. While teams solely focused on their internal objectives might see short-term success, they often become difficult to work with, leading to long-term negative consequences. This mindset, though carrying inherent risks, is a strong belief.

A personal experience highlighted the importance of this approach. Working on a project outside the team's primary domain revealed the chaos of inter-team collaboration. Untracked requests often devolved into "Slack nagging," causing constant distractions and missed tasks. Even organizations like OpenAI faced similar challenges before adopting more streamlined tools, noting that "If you went and assigned an issue to another team, things would get lost." Asking teams to "just open a ticket" with cumbersome issue reporting tools often creates more friction than solutions. To effectively prioritize external requests, visibility is key. Tools that simplify issue tracking empower teams to respond faster, not because engineers suddenly care more, but because the tools facilitate, rather than hinder, the process.

Recalling a specific incident, a mid-sized feature requiring work in another team's critical codebase led to significant frustration. Despite attempts to consult, the other team's Engineering Manager, citing busyness, funneled all communication through himself. He opted for delayed attention, reviewing the initial pull request after a two-week chase. Although the feedback was meaningful, the pressure and frustration led to a hurried merge, with the intention of addressing misgivings retroactively—an action that, in retrospect, never truly occurred.

Let's explore the three options in detail:

Option #1 - Not Giving Any Attention

With modern tools simplifying codebase understanding, this option can be valid if your team is genuinely overwhelmed and the external feature is low-risk or peripheral to your domain. If chosen, it's crucial to empower the other team by stating, "You have my blessing to complete this feature as you see fit," and crucially, not to block them or change your mind later.

However, this approach comes with significant downsides:

• Loss of Context: Much valuable context—decisions made, their rationale, and potential pitfalls—resides within people's heads. Even minimal involvement from the "hosting" team can provide crucial insights.
• Unforeseen Complications: Requirements change, scope expands, and what seemed "harmless" can evolve into a significant feature with quality compromises if no one from your team is involved.

Option #2 - Giving Delayed Attention

This is widely considered the most detrimental approach. Deciding to be involved but failing to provide timely input creates a cascade of problems:

• Planning Disruptions: Answering planning questions days later means the other team has likely moved forward with partial assumptions, necessitating rework.
• Design Stalls: Providing technical design feedback a week after implementation has begun causes significant delays and frustration.
• PR Backlogs: Waiting a week to review pull requests creates dependencies, accumulating a "PR mess" and wasting considerable time on reconciliation.

This option incurs substantial costs. The perceived saving of a few hours of focused work can result in engineer-weeks of degraded productivity for the company, compounded by technical debt from messy merges and demoralized engineers. If the intent is to participate, delaying engagement offers no tangible benefit. This mirrors healthy code review practices, where guidelines often suggest reviewing code shortly after it arrives, unless engaged in a focused task. This principle applies even more critically to unblocking other teams.

Option #3 - Prioritizing Unblocking Other Teams

A common concern with this approach is the potential for one's own team to develop a reputation for being late. Consider an extreme scenario: two critical initiatives need launching on the last day of the quarter. Your engineer needs a few hours to wrap up their task, but another team needs that same engineer for a small, critical change in your domain. In such a case, the default mindset should be to unblock the other team.

Assuming both deadlines primarily impact team reputation rather than hard business requirements:

• Finishing Your Own Task: Your team meets its deadline, but the other team is late, potentially citing your team as the cause.
• Helping the Other Team: Your team is late, but the other team meets its deadline, crediting your team for saving them.

Consistently choosing to help builds a reputation as a supportive and collaborative team, even if it occasionally means adjusting your own timelines. This positive reputation can even aid in recruitment. Furthermore, this fosters reciprocity, making other teams more inclined to assist you when circumstances reverse.

Setting Boundaries

In an ideal world, teams would anticipate dependencies and plan for cross-team support. However, this isn't always the reality; dependencies are often discovered late, or their scope is underestimated. While advocating for prioritized help in these situations, it's also important to recognize that some teams or individuals may exploit this generosity by not completing their own preliminary work.

Such behavior cannot be treated the same way, as it can lead to your team becoming underperforming. The recommendation is to err on the side of helping the first and second time, while clearly explaining how they could have better prepared. If the pattern persists, it becomes the Engineering Manager's responsibility to set clear standards and, if necessary, block further requests until appropriate pre-work is done.

Conclusion

Effective inter-team involvement spans a wide spectrum, and the goal isn't deep involvement every time. It's perfectly acceptable to decide to be available only for critical questions, provided clear expectations are set. However, once a decision to engage is made, it must be executed in a timely and helpful manner, prioritizing the needs of the requesting team.

As Adam Grant highlighted in "Give and Take," "givers"—individuals who unconditionally help others without expecting immediate reciprocation—are often the most productive people. This powerful concept extends equally to engineering teams.