Side Quests for Junior Developers — A Lightweight Path to Growth

In 2024, I was leading a small tech team at Harvy, an early-stage startup in the agricultural sector, based at Station F in Paris. Our tech team was tiny — two junior developers and myself as CTO — and our main mission was to build a flexible invoicing system. Think Amazon-style consolidated billing: one invoice for multiple providers. Technically demanding, requiring precision and coordination.

To deliver on time, we adopted a fairly top-down organization: I wrote most user stories as “recipes” to minimize friction and ensure alignment. This approach worked — we shipped a full-featured billing system by October — but left little room for initiative or creativity on the dev side.

That’s when I introduced what we called the Harvy developer side quest.

What’s a Side Quest?

A side quest is a small personal project, carried out within regular sprint work. The only rule? It must bring value to the team. Beyond that, the developer is free to explore. Once the scope is agreed on, side quest tasks are treated like any others: they can be estimated, prioritized, added to the board, and reviewed just like sprint stories.

At Harvy, we formalized this concept as part of our semi-annual reviews. Each developer chose a side quest in collaboration with the leadership team. The scope was co-defined during the review, and progress was checked informally during regular 1:1s. It wasn’t just a hobby project — it was an intentional step toward autonomy and technical maturity.

We outlined three common types of side quests:

• Self-learning — for example, diving into advanced Git techniques and producing a workflow note, a synthesis, or a cheatsheet for the rest of the team.
• Refactoring — tackling a piece of tech debt identified with the CTO (e.g., restructuring a controller, improving data models, or cleaning up a legacy view).
• Developer tooling — optimizing build speed, improving Docker reliability, setting up Storybook, or building internal dashboards like Datadog panels.

Once launched, the side quest belonged to the developer. They could write stories or documentation if they wanted to, but the key was: they drove it.

Why It Worked

Side quests are low-cost, but high-impact. In an environment where sprint tasks are tightly scoped, they offer:

• Autonomy — a rare chance to explore, tinker, and make decisions.
• Motivation — devs are more engaged when they own what they build.
• Learning — side quests often lead devs to touch areas they’d never reach through sprint work alone.

But for this to work smoothly, I found that a well-framed launch makes all the difference. Freedom without structure can lead to inertia. The best way to kick off is:

1. Set the frame early — within the first few days.
2. Help define the first milestones — even if roughly.
3. Then step back — and let ownership grow.

Final Thoughts

Not every dev will seize the opportunity. But when they do, the payoff is real — in confidence, in skills, and in team culture. In tightly managed teams, especially those with junior profiles, side quests offer a breath of fresh air and a path to real growth.