There is some truth to the idea that some programmers are more productive than others. In practice, this is mainly a function of the breadth and depth of their experience, rather than an expression of innate talent. Under the right circumstances, the difference between two programmers can be significant, though a single programmer who is 10× more productive than the average is quite rare.
There does exist, however, a means of substantially improving productivity without relying on superstars: good leadership.
The difference between a one-person project which takes 5 years to complete, and a 10-person project which takes 2 years, is nine people. The ability for a maintainer to sell their project to potential contributors and inspire people to get involved is a major productivity hack. With 10 more years of experience, you may find yourself a 10× better programmer, but with 10 more programmers, you can get results today. This is especially true in FOSS, where attracting volunteers is often a key competency of successful projects.
Organizing the work is the most important task in this role. You need to hold a vision of the project in your head, and an actionable plan for executing it. This need only have enough detail to ensure that (1) you know what needs to be done, and in what order, and (2) you have enough work to keep everyone busy.
In my workflow, I aim to identify the most difficult problems first (those with the most unknowns), then have senior engineers address them upfront. This tends to create a lot of ancillary tasks which can be taken on by contributors at a broad range of skill levels, keeping a healthy pool of tasks ready for everyone who wants something to work on. It also makes the difficulty of the work trend towards zero, which helps a lot with planning, since you get a firmer and firmer picture of the remaining work over time. The goal is to quickly create a thin skeleton which can support work on the project’s largest challenges, allowing senior engineers to focus on the core problems while others put meat on those bones, planning out junior- to mid-level problems as they become apparent.
Working with the contributors on an individual basis is the next matter of concern. It’s up to the leaders to understand the interests and capabilities of each contributor, and help line up impactful work which they will find rewarding. Furthermore, you need to help them lay down a path of experience in which they can grow to understand more of the project’s scope, approach it with greater skill and confidence, and fill an empty niche in the team. This extends more to simple coding skills also: contributors can also be involved in planning, design, testing, research, code review, mentorship, and even leadership, taking some of the burden from your own shoulders. A good leader sees the potential in each contributor to grow in these domains, and figures out how to help them achieve that growth.
As software engineers, we’re used to applying our skills to technical problems, writing code, designing systems, and so on; but applying our problem-solving mindset to other domains as well will often yield surprisingly powerful results. When applied to the project’s social problems, leadership emerges. Success in this respect allows you to scale your engineering output exponentially.
Advertisement: SourceHut’s free and open-source software consultancy specializes in this kind of work. We provide not only talented engineers, but talented leaders. As the maintainers of dozens of FOSS projects, we are used to bringing out the best in ad-hoc teams of mixed experience, and our skills in mentorship and project management leaves that team stronger than it was when we started. Our work with upstream FOSS projects also has us constantly introducing ourselves to new projects and teams, and that experience has enabled us to execute on unfamiliar projects faster than anyone else. If that sounds like something that you need, get in touch.