On increasing contributions

On teams building software, a common question is posed: "how can we get more contributions".

Putting aside that contributions are not the most relevant metric for a team (but perhaps the easiest measured), some form of this question is relevant to most teams ("how can we increase our velocity", "how can we improve our quality", "how can we increase our impact", etc).

For the sake of this post, we'll assume a few things:

• Your product has market fit (users want it)
• Your team is capable of delivering value (you can build it)
• Your team is motivated (you want to build it)
• Your management or sponsors have the resources to support you (incentives)

... and if any of these are not true, you should probably address them first.

Once you have these in place, the number one thing you can do to increase contributions is to make it easier to contribute, and the number one way to do that is to provide the right kind of work for the right kind of contributor, henceforth referred to as problems, projects, and tasks.

Tasks

The most straightforward way to increase contributions is to provide tasks which are:

• Vetted: tasks are things your team already wants to do, and that you know will be valuable to your users - the only limiting factor is the time and effort required to complete them.
• Explicit: the contributor knows what is expected of them, and likely even has examples such as existing checked-in code, a draft PR with clear TODOs, and/or fast test cases that currently fail and would pass upon completion.
• Small: the contributor can complete the task in anything from a few hours to a few days. The exact amount of time is not critical, but the contributor should be able to see the end of the tunnel at all times.

I notice that tasks are the number one things most teams get wrong. They either provide tasks that are too big, too vague, or too unimportant. This leads to contributors getting stuck, losing interest, or feeling like they are not making a difference. Failure modes include:

• Only junior or newer contributors are expected to work on tasks, while senior contributors almost exclusively work on projects or problems. This leads to a lack of mentorship and growth opportunities for junior contributors (doing cookie-cutter tasks is not the same as learning from someone more experienced), and feelings of imposter syndrome for senior contributors (if they are not contributing to the most important work, what are they doing?).

  Fix: ensure there is a range of work available for all levels of contributors, and that the work is distributed evenly across the team. If there is particularly important work that only senior contributors can complete, ensure that there is a clear path for junior contributors to grow into that role.

• Tasks are poorly triaged, often aspirational ideas (i.e. from a brainstorm or TODO) that have not been vetted by the team, which leads to contributors spending time on work that is not a priority or that will never be merged.

  Fix: don't use an issue tracker as a TODO list. Ensure that all tasks are vetted by the team, and that they are prioritized, estimated, and well-understood before being assigned to a contributor, particularly someone new or with less influence on the team. Tasks should be "if there was a PR that did X, observable by Y, we would merge it" - not "it would be nice if we had X".

• Tasks are too big or speculative, leading to contributors getting stuck or losing interest. This is particularly common when the team is not sure what the right solution is, or when the task is part of a larger project that is not yet well-defined.

  Fix: break down tasks into smaller, more manageable pieces. It is OK for a task to have some "discovery" or "research" component, but the contributor should have a clear path (documented tools, test cases, sample applications, etc) to follow, and a clear deliverable (a PR, a brief document, a prototype, etc) to produce.

It's worth noting that creating the tasks is valuable work in itself, and should be done by the team as a whole, not just the person who is responsible for the work. This is particularly important for tasks that are not directly related to the product, such as documentation, testing, or community engagement.

A maturing contributor will start to move from working on tasks to defining some tasks for themselves, and eventually to defining tasks for others. This is a natural progression, and should be encouraged by the team, but it is important that the team as a whole is responsible for the work.

Projects

Projects are defining and completing (though not necessarily by the same person) a set of tasks that accomplish a specific goal. Projects are larger than tasks, but smaller than problems, and are often used to group related tasks together, or to provide a clear path for a contributor to follow. They should be:

• Scoped: projects should have a clear goal, a set of tasks that will accomplish that goal (or a clear path to discovering them), and a set of criteria that will determine when the project is complete.
• Resourced: a clear owner, a regular cadence of check-ins, and a set of resources (time, money, people) that are dedicated to the project. This is particularly important for projects that are cross-cutting or that require coordination between multiple teams.
• Noisy: projects should be visible to the team, and should be regularly updated with progress, blockers, and next steps. This is particularly important for projects that are long-running or that require coordination between multiple teams.

Failure modes include:

• Projects have no centralized ownership or accountable person, leading to newer contributors churning without sufficient guidance, or to senior contributors feeling like they are doing "busy work" that is not directly contributing to the team's goals.

  Fix: ensure that every project has a clear owner, and that the owner is responsible for ensuring that the project is completed on time, on budget, and to the team's satisfaction. This does not mean that the owner has to do all the work, but they should be responsible for ensuring that the work gets done.

• Projects are vague, often originating from a top-down mandate or suggestion by an influential member of the team, but without a clear goal, set of tasks, or criteria for completion. This leads to projects that are never completed, or that are completed but do not provide value to the team or the users.

  Fix: projects should be carefully considered (beyond a short prototyping phase), and be explicitly accepted by the team, and by other teams or dependencies that are likely to be needed.

Projects are a natural progression from tasks, and should be used to group related tasks together, or to provide a clear path for a more experienced contributor to follow. Often your team's velocity will be determined by the number of projects you can complete in a given time period, and the quality of those projects.

Problems

Problems are the highest level of work, and are often used to describe a user need, a business goal, or a technical challenge that the team is facing. Problems are too large to be completed by a single person, and often too complex to be fully understood at the outset. They should be:

• Challenging: problems should be difficult, but not impossible. They could require the team to stretch (i.e. learn new skills or technologies), but should not require the team to break (i.e. work nights and weekends, or sacrifice quality or safety).
• Important: problems should be valuable to the team or the users, and should be aligned with the team's goals and values. They should be worth the time and effort required to complete them.
• Limited: it is dangerous to have too many problems open at once, as this can lead to a lack of focus, or to the team feeling overwhelmed. Problems should be carefully considered, and only opened when the team is ready to commit to solving them.

Failure modes include:

• Problems are seen as something to be "claimed" rather than "solved", leading to a lack of ownership or accountability, or to a lack of collaboration or coordination between team members.

  Fix: reward the team for solving problems and collaborating across teams and disciplines.

• Problems are seen as "too big" or "too vague" to be solved, leading to the team feeling overwhelmed or paralyzed, or to the team feeling like they are not making progress.

  Fix: ensure appropriate stakeholders are intimately involved in defining the problem, and that the team has the autonomy and resources to solve it.

Conclusions

In conclusion, the number one thing you can do to increase contributions is to make it easier to contribute, and the number one way to do that is to provide the right kind of work for the right kind of contributor. This means providing tasks that are vetted, explicit, and small, projects that are scoped, resourced, and noisy, and problems that are challenging, important, and limited.