It’s easy for teams to find themselves only working on large projects. Large projects are easier to sell (“this will generate millions of dollars of revenue for our company!”) and easier to deflect when things get behind schedule (“we’re behind on this milestone, but that’s okay because this project is fundamentally hard”). They come with more opportunities to impress people and tend to be the projects people find themselves getting promoted because of.
Sure, that’s all fine, I get it. I just want to tell you that it’s okay to work on tiny projects, too.
If the most important thing to be working on is actually just a laundry list of tasks, that’s okay! You don’t need to come up with some “overarching narrative” for your glorified list of tasks, complete with a project brief, key deliverables, architecture review, yada yada yada. Just sit down, fix the task, and move onto the next one.
As long as the tiny projects are as important as you think, you don’t need to kick them down the road in search of a big project.
Graydon Hoare writes about this in his post Let Maintainers Be Maintainers:
[Corporate-employed FOSS maintainers are] in a position where their job performance is very likely to be evaluated in terms of visible growth and novelty (it might be dressed up in more abstract terms like “real-world impact” or “visibility” but it still means the same thing) even though that is exactly the wrong thing for the health of the project they’re maintaining. The incentives are bad. If they do the best thing for the project as infrastructure – triage and fix bugs from the backlog, optimize performance, increase security and reliability, pay down tech debt, simplify and automate ongoing maintenance – the bias of their organization is likely to view them as “doing nothing”, or at best doing “low-value work” that only counts as “reducing fixed costs”, not leading the way towards new growth.
The only thing I’d add: this doesn’t just apply to FOSS maintainers! All infrastructure teams, even internal ones, benefit from focusing on the small tasks, the tiny projects, etc.
On a more personal note, I’ve noticed that the parts of my career where it seemed like we were pursuing novelty for novelty’s sake were also the times when I felt the least fulfilled and the least energized in my work. On the other hand, when I’m working rapid-fire on lots of tiny projects, I find myself building up momentum and staying “in the zone” far more easily than when I’m only carving out time for one tiny project in the gap between large projects.
I will say: I happen to work on a product where the small projects are also very user-visible—that’s not always the case. It means that the tiny projects going undone are often the bulk of the requests from users, making it easier to point to “we’re just doing what they’re asking for” when it comes time to defend our roadmap. Being user-visible also makes it easy to rack up goodwill from checking them off. It’s not going to shake out like that for all teams nor all products.
But it’s worth at least thinking about it. You don’t always have to chase novelty: it’s okay to work on tiny projects too.