article > tech
I've Never Seen "Contribution" Work Well in a Development Team
But it should be made to work.
The “Contribution Model” described in this article is an engineering team management strategy that encourages engineers to actively contribute beyond their immediate work domain, particularly to common engineering areas.
Having a functioning contribution system unequivocally benefits the team. Contribution multiplies engineering capabilities across the team. Sharing best practices elevates not just individual engineers but the entire team’s engineering standards. Contributing to common modules or automation increases the team’s collective velocity and shares achievements.
As a development platform engineer, I’ve stated before that we should strive to build teams where contribution functions smoothly. Yet, simultaneously, I’ve admitted I’ve never actually witnessed this contribution model functioning effectively throughout my career.
Reflecting on this, I’ve identified several reasons below and considered what conditions are necessary for a contribution model to thrive.
Because the Engineering Platform Is Poor
When an engineering team sharing similar codebases reaches about 10 people, it becomes challenging to expect contributions to happen organically. Ownership is crucial for maintaining code quality. Unclear ownership in shared code areas significantly decreases engineering stability. In an already demanding environment where ensuring code quality responsibly is difficult, contributions might be perceived (quite negatively, admittedly) as saying, “I won’t take ultimate responsibility.”
A robust engineering platform is essential to enable safe contributions. It must include mechanisms and processes that quickly isolate issues if they occur, ensuring stable contributions to common modules.
Documentation, testing, and the tracking and management of exported interfaces are non-negotiable. All implementations exported by a package (in JavaScript modules, those that are exported) should be version-controlled and capable of being deprecated if unused. If implementations are exported blindly just for sharing, future management complexity increases exponentially.
Every exported implementation must be documented clearly in package READMEs, and forgetting documentation should cause the CI pipeline to fail. Hosting documentation with tools like Docusaurus can be beneficial, but documentation should always be close to the code. Additionally, test coverage for every package must never be zero.
Without ensuring these standards, contributions risk frequently introducing problems, creating a negative cycle where engineers feel unsafe contributing. About three years ago, a colleague who maintained and improved a shared layer of a large legacy codebase strongly recommended, “Always have extensive unit tests for common modules.” Now, I deeply understand why.
Because the Contribution Difficulty Is Too High
If the responsibilities tied to contributions are excessively high, contributions become extremely difficult. Consequently, no one will contribute. Imagine adding functionality to a shared module that’s used in over 1000 places, requiring regression testing for all connected apps. No engineer wants to shoulder such risks, especially for tasks unrelated to their immediate work.
A dynamic codebase full of implicit knowledge, historical complexities, neglected features, and increasing coupling over time makes “small contributions” nearly impossible. Engineers become solely responsible for verifying and maintaining the functionality, making contributions rare and substantial rather than small and varied.
Occasionally, tech conferences feature sessions like, “We created this small but valuable code into a common module, and people love it.” Watching these, I often think such contributions would be impossible in highly coupled, debt-ridden codebases. In short, overly complex codebases eliminate small joys or utilities that come from diverse, minor contributions.
The contribution difficulty must be lowered. Beyond having a solid engineering platform, contributions must be facilitated through properly isolated codebases. It should be easy to incrementally adopt contributions and see their benefits. If achieved, small ideas or contributions can safely propagate from a single product or team to multiple products and teams, gradually increasing contributors’ satisfaction.
Because Organizational Culture Isn’t Contribution-Friendly
The heart of contribution lies in “wanting to help.” Contributors willingly do tasks outside their designated responsibilities because they genuinely want to help. This mindset must never be discouraged.
Throughout my career, I’ve frequently observed criticism of people labeled as “raising issues without proposing solutions.” While raising concerns without accountability can feel empty in execution-focused startups, it’s vital that teams support those who have the willingness to contribute, enabling them to pursue improvements. People who highlight problems may genuinely not know how to fix them yet.
Creating a culture conducive to contributions involves guiding and actively encouraging potential contributors. Teams should provide good tools and keep them accessible so potential contributors can easily find solutions. A contribution-friendly engineering platform plays a significant role here, and team members should readily offer consultation.
Criticizing engineers who only identify problems without immediate solutions stifles their desire to contribute. Next time they see a problem, they might remain silent, ultimately harming the team.
Organizationally, companies can support contribution by promoting study groups on topics of interest. However, more beneficial activities involve collectively addressing shared product or code issues. Ideally, the team organically creates cycles where people study to solve product issues, make small contributions, discuss improvements, gather feedback, and continually refine their work.
Conclusion
Though each section offers slightly different perspectives, a strong engineering platform solves many issues. Platform engineers should work hard to enable diverse and valuable contributions and continuously seek ways to support and appreciate their colleagues’ desire to contribute.
In the three years at my current company, I’ve seen contributions worsen but also observed moments of incremental improvement. It’s still early to judge outcomes fully, but we’ve removed many blockers hindering contribution. There remains considerable potential for further improvement.