Programmer Collaboration Styles
Programmer Collaboration Styles
In software development, two collaboration styles have proven to be most effective. Both are widely used today, but are quite different from each other.
Most people don’t think much about their collaboration style—or if they’re applying it correctly. Usually, they default to an unspoken set of norms or habits they assume everyone follows.
But this is unwise, because healthy collaboration sits at the core of developer productivity and engagement. When you know the right style for your situation and use it intentionally, work flows smoothly, and everyone’s more engaged.
So, what are these two collaboration styles? Individual stewardship and shared stewardship.
Individual Stewardship
Open source software development is the best example of individual stewardship. In an open source project, there’s typically one central figure: the benevolent dictator. This individual controls the project’s direction and has the authority to make changes directly to the source code. Others who want to contribute do so by submitting pull requests, each of which must pass through the benevolent dictator.
In individual stewardship, one person owns both the vision and the means to achieve it. They decide on the language, coding style, release schedule, collaboration tools, and integration approach. In a corporate setting—more common in the 90s—individual stewards would report to a supervisor who assigns them clear responsibilities, expected outcomes, general constraints, and a reporting structure but leaves the rest to them. This was often referred to as delegation.
Don’t be confused; individual stewards aren’t isolated islands. Collaboration still occurs, particularly in two areas: (1) interactions with other stewards and (2) coordination around volunteer code submissions.
In a corporate setting, teams consist of several individuals with distinct stewardship. While they stay out of each other’s domains, they spend considerable time defining boundaries and interfaces. They negotiate what they’ll deliver to each other and when, and they’re expected to meet these commitments.
A great corporate example of individual stewardship is the Morning Star Company, the world’s largest tomato processor. At Morning Star, workers organize themselves annually by drafting contracts called colleague letters of understanding. Each steward identifies key points of interaction with others and sets expectations around them. Later, their performance reviews will reflect how well they’ve honored these agreements.
In open source, collaboration among stewards is limited, while interaction with volunteers is extensive. Volunteers submit contributions through pull requests, which stewards review and integrate. The process is less about daily involvement between stewards and more about actively managing and incorporating volunteer efforts.
Shared Stewardship
The shared stewardship collaboration style is more common in today’s corporate environments. It requires developers to be in frequent contact with one another. In shared stewardship, the whole team shares responsibility for the project’s direction and quality. Team members have equal permissions to modify a common set of source repositories, and they seek consensus on major decisions related to the work.
Unlike individual stewardship, where a single owner sets the project vision and standards, shared stewardship relies on a collective vision. Team members align on coding standards, integration strategies, release schedules, and all other project aspects. They work together to ensure everyone’s contributions meet these shared standards and aim to produce a steady flow of cohesive work.
Even though many corporate environments today aspire to this collaborative style, they often fall short by blending in practices from individual stewardship. Specific details of these common missteps follow below.
Notably, certain practices have emerged, mostly from prominent voices in the agile movement, that make shared stewardship particularly effective. These practices include:
Releasing in small batches
Test-driven development
Continuous integration
Pair (or even mob) programming
Refactoring
While any of these can be useful in individual stewardship as well, they fit especially well with the shared stewardship mentality and help team members stay aligned, energized, adaptable and productive.
A Cooking Analogy
Imagine cooking as an analogy to understand these collaborative styles. I had the opportunity to live in Italy for a while when I was younger with a roommate who loved to cook (and was incredible good at it) but hated the cleanup. I didn’t mind the cleanup and didn’t have any particular inclination for cooking. So we struck a deal: he handled the cooking for both us, and I handled all the dishes. He had total control over the kitchen—ingredients, methods, timing—while I had complete ownership of cleaning. We were both thrilled with the arrangement, as each of us fully controlled our “stewardship.” He could cook to his hearts content, and I reaped the benefit of being able to eat his delicious creations. He was in heaven because he didn’t have to wash a single dish.
In contrast, my college cooking nights were a shared stewardship experience. My friends and I would shop together, brainstorm a menu, and then divvy up the cooking tasks—one person chopped vegetables, another prepped the sauce, someone else set the table. It was a shared effort with constant communication to keep everything coordinated. In addition to creating a meal, it was a satisfying social experience.
These cooking experiences reveal some key trade-offs. Individual stewardship, like my roommate’s cooking, allows mastery and personal style to develop, fostering ownership and high-quality results. However, it also depends on the skills of the individual and can be risky if they don’t deliver. Shared stewardship, like my college cooking experiments, allows for easier learning and less risk but can lead to a “lowest common denominator” effect, where quality may be steady but rarely exceptional.
In software, both approaches have their place. Individual stewardship provides ownership and depth, allowing developers to refine their skills within their domain. Shared stewardship, on the other hand, distributes work across a team, focusing on rapid completion and shared responsibility. Just like in cooking, choosing the right model for your team can make a big difference.
Remote Work
A fundamental difference between individual and shared stewardship is the frequency of communication they require. Individual stewardship requires far less interaction due to the larger responsibilities assigned to each person. In the open source world, for example, collaborators rarely interact beyond submitting feature requests and code improvements. They almost never meet or do video calls.
In a fully remote work culture, communication naturally becomes less frequent and more challenging, which aligns well with the individual stewardship model. I’d wager that many companies now calling employees back to the office are doing so because they struggled to make shared stewardship effective within the communication limits of remote work. They might have seen far better results by adopting an individual stewardship model. But since individual stewardship has fallen out of favor in corporate settings, few, if any, companies have tried this approach.
For companies committed to remote work while still pursuing shared stewardship, nearly constant video communication is essential. Pair programming or even mob programming should be the norm—I can’t imagine any other way to make it work. Without an “always-on” communication structure, shared stewardship is unlikely to succeed.
Some Things in Common
Both collaborative models share some important similarities. Both approaches are forms of self-management. In the individual stewardship style, individuals self-organize their collaborations with others and manage their own volunteer contributions. In the shared stewardship style, teams operate with a flat, self-organizing structure, coming to mutual understandings and making collective decisions.
Another area of commonality is their capacity to embrace Agile principles. Many Agile principles are applicable to both styles of collaboration, with the primary difference being how these principles are enforced. In the shared stewardship style, Agile practices are implemented and maintained at the team level, with everyone aligning to shared goals. In individual stewardship, Agile principles are adopted voluntarily by each steward, who applies them in their own domain.
Both models emphasize frequent releases—shared stewardship teams often release in small batches, while individual stewards in open source projects are known to “release early and often.” Additionally, both styles can prioritize customer collaboration, value individuals and interactions over processes and tools, and respond to change rather than following a rigid plan. Again, the main distinction lies in who applies these values: in shared stewardship, it’s the team; in individual stewardship, it’s the individual.
Code Reviews
Code reviews associated with pull requests became popular in open source projects because they serve as a convenient gating mechanism for external contributions. They allow code owners—the “benevolent dictators”—to review and, if necessary, reject code submissions. If owners were to skip this step and allow contributions to go directly into the source repository, it would lead to chaos and errors. In this context, pull requests serve a vital purpose. Additionally, in individual stewardship, pull requests can be processed asynchronously. Code owners can address them at their convenience without interrupting their workflow.
In a shared stewardship environment, however, pull request style code reviews can be excessive. When your team already collaborates closely, works in small batches, integrates continuously, and uses practices like pair programming, there is less need for an extensive review step. Code should go into the main branch immediately. Direct integration is a key part of what makes shared stewardship work effectively. Introducing gating mechanisms like pull request reviews disrupts the flow of work. If compliance requires code reviews before deployment, consider adding a gating review step in your release pipeline—but put it after code integration.
This is a common pitfall for teams attempting shared stewardship: they retain the pull request style code reviews of individual stewardship, which block progress rather than support it. In shared stewardship, the goal is a seamless flow of work with close, continuous collaboration. Pull request reviews create interruptions that counter this goal. Unlike individual stewardship, where owners can address reviews when convenient, shared stewardship relies on immediacy to maintain its momentum. As a result, pull requests require immediate attention, and are therefore more obstructive.
Specialization
When work requires highly specialized skills—perhaps advanced degrees or extensive experience—and many tasks can only be tackled by one person on the team, individual stewardship is an ideal choice. It allows programmers to become deeply immersed in their unique domains, giving them time to study and connect with other specialists. With more flexibility to tailor their workflow, individual stewards can better handle the unpredictable, often “bursty” nature of experimental work. The more exploratory the work, the better it aligns with individual stewardship.
In contrast, shared stewardship assumes a steady flow of tasks that any engineer on the team can handle. In a shared model, the work is generally accessible enough that pairing is sufficient to spread the knowledge, allowing all team members to get up to speed in the domain. However, if the work requires a high degree of specialization, shared stewardship may struggle with inefficiencies, as it’s harder to ensure that everyone can contribute effectively.
Quality
As shown in my cooking examples, there is a noticeable difference in quality between individual stewardship and shared stewardship collaboration. When focused on a single stewardship—ideally one that aligns with your passion—your skill and mastery deepen over time. The autonomy granted by individual stewardship allows for experimentation and customization of your process. Over time, my roommate in Italy perfected his skills and developed a style that was distinctly his own. The quality of his cooking was consistently excellent.
In contrast, the group cooking of my college days produced mixed results. With everyone contributing in a fragmented way, it was challenging to reach the same level of quality. The food was never bad, but it didn’t reach the culinary heights of my Italian roommate’s meals.
One advantage of group cooking, however, was that it was less prone to major mishaps. With many cooks in the kitchen, there was enough oversight to catch mistakes before they spiraled out of control. In Italy, if my roommate took a wrong turn in the recipe, the entire meal could be botched. Had he been a poor cook, our arrangement of divided stewardship would have been a risky choice.
Similarly, in software development, the highest quality results often come from skilled individual stewards. However, this approach carries greater risk, as misguided efforts can drag on and lead to costly setbacks.
Shared stewardship, on the other hand, is a safer, more predictably average option. While it reduces the risk of catastrophic failure, it also limits opportunities for breakthrough innovations. Ideas are often watered down or sidelined in favor of the perspectives of more senior or vocal engineers.
Notably, research from Harvard Business School supports these observations. In a study on collaboration, researchers found that infrequent collaboration (akin to individual stewardship) produced both the highest and the lowest-quality outcomes, while frequent collaboration (similar to shared stewardship) resulted in consistently average results.
Interestingly, the study also suggests that a balanced approach—collaborating intermittently—can yield results that, while not quite reaching the peaks of infrequent collaboration, offer higher quality than frequent collaboration with more consistency than infrequent collaboration. For individual stewardship, open source projects offer a straightforward way to implement a balanced approach: regular community (or coworker) collaboration through pull requests or feature suggestions. For shared stewardship, a corresponding adjustment would be to give team members occasional time for private experimentation, allowing space for fresh ideas and personal innovation.
Knowledge Transfer
For sharing knowledge among team members, shared stewardship is the clear winner. With its emphasis on frequent communication and pair programming, it’s ideal for on-boarding new team members, mentoring, and distributing tribal knowledge across the team.
Individual stewardship, on the other hand, can easily lead to knowledge silos. Deliberate attention is required to prevent knowledge from accumulating with one person. If you’re using an individual stewardship approach, consider having each code owner designate a “second-in-command”—ideally a trusted and prolific project contributor—to be trained as a backup. This ensures continuity when the code owner is unavailable, whether due to vacation, illness, or departure. Additionally, strong documentation practices are essential in individual stewardship, helping capture and share critical knowledge.
Collaborative Energy
One important distinction between the two collaboration styles lies in collaborative energy. In a shared stewardship model, much is gained through solidarity. Working closely together allows team members to encourage and motivate each other, leading to significant productivity benefits.
Individual stewardship, on the other hand, can feel isolating, especially in the early stages of a project before broader community or coworker collaboration is established. Thriving in this model requires self-motivated individuals.
However, because of their personality, some individuals prefer one style of collaboration over the other, making it essential to consider personal preferences in team assignments.
Difficult Personalities
An often-overlooked benefit of individual stewardship is its ability to shield against challenging personalities. With clear authority established, collaborators with abrasive personalities have limited influence; they can only affect interactions around project edges. While meetings might still be tense, difficult personalities can’t interfere with project internals or the day-to-day progress of others’ stewardship.
In shared stewardship, difficult personalities can be highly disruptive. Because the team must collaborate closely on all aspects of the work, there’s no escape from challenging dynamics. For example, if someone tends to dominate conversations in team meetings or pressures others to follow their personal preferences, the result is often a steep decline in both productivity and morale. Addressing these dynamics promptly is essential for maintaining a healthy, productive team environment.
Assessment
It’s important to recognize that your collaboration style significantly impacts how work is assessed. In individual stewardship, evaluating performance is straightforward: you can assess individuals by looking at the quality and quantity of their contributions within their specific domains.
In shared stewardship, however, where work is a collective effort, it’s more appropriate to evaluate the team as a whole. Individual contributions are harder to isolate, which generally isn’t a problem—unless there’s a particularly unhelpful team member. In such cases, peer reviews can be a useful tool for addressing individual performance within the group.
Collaboration Styles at a Glance
Individual Stewardship
Important Figures: Linus Torvalds, Guido van Rossum, Dennis Ritchie
Units of Work: Projects and outcomes
Examples: Open Source, Morning Star
Communication frequency: Occasional
Role Models: Howard Roark, Tony Stark, Sherlock Holmes, Einstein
CPU analogy: Separate Parallel CPUs
Assessment: Individual, based on their stewardship
Keys Strengths: high autonomy/ownership, potential for exceptional results, low communication requirements, ideal for specialized work, supports remote work, fosters individuality
Key Weaknesses: less consistency, potentially isolating, risks of knowledge silos, challenges with on-boarding and mentoring
Shared Stewardship
Important Figures: Kent Beck, Martin Fowler, Ron Jeffries
Units of Work: Tasks
Examples: Valve, Spotify
Communication Frequency: Frequent
Role Models: Captain Jean-Luc Picard, Samwise Gamgee, Captain America
CPU analogy: Multitasking Single CPU
Assessment: Team, based on collective stewardship
Key Strengths: consistency, solidarity, collaborative energy, well-suited for general tasks, excellent for on-boarding, mentoring and knowledge sharing.
Key Weaknesses: limited potential for exceptional results, high communication demands, less ideal for remote work, can consolidate around dominant personalities
Conclusion
Both individual and shared stewardship bring unique strengths to the table. Understanding the nuances of these collaboration styles enables teams to leverage each approach more effectively, maximizing productivity and morale. By applying the right model to the right situation—and keeping the strengths and weaknesses of each in mind—teams can create a more adaptable, dynamic working environment that meets the needs of their members and projects alike.