Should devs make pull request to other teams repos?

Summary

In large organizations, allowing software engineers to create pull requests across teams' repositories can significantly improve development velocity. The key to success lies in shifting from service ownership to feature ownership, fostering cross-team collaboration, and ensuring standardized practices. By building a culture of shared ownership and trust, and streamlining onboarding processes, teams can break down silos, avoid bottlenecks, and better utilize resources. The approach mirrors auto-scaling in infrastructure, enabling engineers to dynamically contribute to multiple systems and reducing dependency delays, ultimately leading to faster product delivery.

Takeaways

• 😀 Large organizations should enable cross-team pull requests to allow software engineers to work more efficiently across multiple repos and tackle capacity issues.
• 😀 Achieving cross-team pull requests is not just about technical feasibility but also about creating a secure and accepted practice within the organization.
• 😀 Developers can become emotionally attached to their code, which can create reluctance to allow others to make changes to their repositories.
• 😀 Many organizations struggle with dependencies between different teams and services, making it hard to divide features and avoid bottlenecks in product development.
• 😀 Shifting from ownership of individual services to ownership of features across teams can help reduce dependencies and improve product velocity.
• 😀 To facilitate this change, teams need to follow consistent conventions for code structure, onboarding, and pull requests, similar to the standardization seen in McDonald's operations.
• 😀 Teams should focus on feature ownership instead of service ownership, allowing faster changes across multiple systems and reducing resource waste in development.
• 😀 Standardized onboarding processes are essential for making cross-team pull requests feasible, as it ensures developers are familiar with the project setups.
• 😀 Security and comfort are key to making developers feel confident about making changes to other teams' repositories without causing regressions.
• 😀 Effective cross-team collaboration requires the breakdown of siloed thinking, where developers can contribute across various systems as needed, ensuring efficiency and resource allocation.
• 😀 Adopting an open-source mindset within organizations can foster collaboration, increase developer engagement, and reduce dependency bottlenecks, allowing teams to work more dynamically.

Q & A

Why does the speaker argue that large companies should allow software engineers to create pull requests in other teams' repositories?

The speaker believes that enabling cross-team pull requests allows teams to move faster, overcome capacity issues, and avoid bottlenecks caused by rigid team ownership over codebases. It enables a more dynamic workflow where developers can contribute to features across various services.

What is the main challenge in enabling cross-team pull requests according to the speaker?

The main challenge is overcoming the emotional attachment developers have to their own code and ensuring that both the teams owning the code and the developers making changes feel comfortable and secure with the process.

What is meant by 'feature ownership' as proposed by the speaker?

Feature ownership refers to the idea that teams should focus on owning a complete feature, rather than just the services or codebases that belong to a specific part of the system. This allows them to work across different repositories and systems to implement features more efficiently.

How does the speaker compare the development process to McDonald's system?

The speaker compares the development process to McDonald's in the sense that both require clear and standardized conventions. Just as McDonald's restaurants around the world operate in a similar way, development teams should follow standardized practices that make it easy for anyone to onboard, contribute to, and maintain different repositories.

What does the speaker mean by 'system architecture' in the context of cross-team pull requests?

System architecture refers to how the software and its components are structured. A well-structured system, with clear conventions and practices, allows teams to work across multiple codebases more easily. A poorly structured or legacy system, however, may make it too difficult or risky to contribute to other teams' repositories.

What is the significance of 'onboarding' in enabling cross-team pull requests?

Onboarding is crucial because it ensures that new developers can easily understand and work with the codebases, regardless of the repository they are contributing to. If onboarding is inefficient or difficult, it can create roadblocks in the ability of teams to collaborate across repositories.

What role does 'community-driven development' play in the speaker's argument?

Community-driven development fosters collaboration across teams, allowing developers to contribute to each other's codebases in a more open and transparent way. This can improve communication and help reduce bottlenecks in the development process by making it easier for teams to ask for and provide help across the organization.

How does the speaker suggest solving the problem of developers only working within their own team’s code?

The speaker suggests that organizations need to build a culture and environment where developers feel comfortable working across multiple teams' codebases. This can be achieved through clear conventions, secure practices, and fostering a sense of ownership over features rather than just specific services.

What is the impact of 'technical and social shifts' in organizations trying to implement cross-team pull requests?

Technical shifts involve creating standardized practices for writing and maintaining code, ensuring that all repositories follow similar conventions. Social shifts are needed to change the mindset of developers and teams so that they no longer feel overly protective of their code, but instead are open to collaboration across repositories.

Why does the speaker believe resource allocation becomes inefficient in teams that don't allow cross-team pull requests?

The speaker argues that when developers are confined to working on only their own code, it leads to inefficient use of resources. Developers could contribute to other teams' code and help alleviate bottlenecks, but instead, their time is wasted on limited tasks within their own team, which is a self-inflicted resource bottleneck.