Feature Lead Engineers ship better products, faster 🚀

At Nested, we’ve seen a step-change in product quality and output over the past couple of years, and one of the key reasons for this is “feature leading”. Engineers from outside Nested are fascinated by the concept, so I’m sharing in the hope that it catches on!

Our engineers take turns feature leading, which means taking responsibility for the technical delivery of an epic. The Feature Lead Engineer (FLE) is involved in the initial research and customer interviews, contributes to the ideation and proposed solution, explains the project and options for the technical implementation to the engineering team, writes and prioritises the tickets and communicates the launch to the business.

✨ The result?

• Our engineers gain more context and ownership and make a more significant impact on our products, which tends to lead to happier, more motivated engineers. No one person is required to fill the gap between product and engineering, and engineers at all levels develop a product skillset whilst still spending 90% of their time writing code.
• Our PMs gain an additional high-context collaborator who can foresee technical issues and find better solutions before work starts. PMs spend far less time writing tickets and answering implementation questions from engineers, which means they can spend more time on high-leverage activities like customer interviews, design iteration, product strategy and evolving the roadmap.

Since introducing feature leads, we’ve shipped better quality products, faster, with a happier, more motivated team! 📈

So how does it work?

🔬  Design/research kickoff

Before any research or design kicks off for an epic, we assign the FLE role to an engineer in the squad. We believe every engineer should be a feature lead, so we use a rota and disregard seniority - our entry-level engineers often feature lead on their first project after 3 months or so.

We set up a Slack channel for the project that includes the PM, designer and FLE (and anyone else relevant). All ideas and design iterations are shared here, and the FLE is encouraged to contribute throughout the ideation phase. The FLE will often shadow customer interviews and stakeholder meetings with the PM and designer, giving them first-hand insight into the problem or opportunity.

The engineer’s perspective and understanding of technical constraints can be very useful at this stage - since we introduced the role there have been countless examples where a FLE has pushed the project in a better direction or spotted edge cases before we’ve even finalised a design, saving a lot of engineering time.

As the designs take shape, the FLE will also be collaborating with the PM and Data team to plan out any reporting needed to measure the impact and success of the project. They’ll be starting to consider potential implementations for the epic, scheduling spike tickets for their team and researching the pros and cons of different options as they prepare for the technical kickoff meeting.

Importantly, it’s not on the FLE to necessarily solve all the technical questions themselves. We encourage engineers to consult with others around the team before proposing any technical solutions. This inclusive process allows us to leverage the knowledge and experience of the whole team to find the best solution but also empowers those early in their career to take on the FLE role because they’re not expected to have all the answers themselves.

💡  Technical kickoff

A week or two before engineering work is scheduled to start, the FLE will lead a technical kickoff session with the rest of the engineering team. 

The FLE shares the context they’ve learned about why this is an important feature and what the proposed product solution is. They’ll talk through the tradeoffs of different implementations, present the reasoning behind their choices, and talk the team through how they plan to split the work into parallelisable, vertically-sliced tickets. The rest of the engineering team will provide feedback which helps shape the final proposal.

Before the FLE role, our PMs would plan and spec an epic themselves then work hard to try and explain to an engineering team why it was important. Engineers trusted our PMs to make the right decisions, but they usually only had a surface-level understanding of the context and often just did “what they were told”, which led to a lot of problems. The first time I heard a FLE enthusiastically pitching the merits of their project to the engineering team with the same level of context the PM had, I knew we were on to something special.

Once the team has agreed on an implementation, the FLE is responsible for creating and prioritising all the tickets in the backlog (we use Shortcut) to ensure the project runs efficiently. The PM is responsible for prioritising multiple epics and any features that don’t fall within an epic, but the FLE has ownership over the tickets for their epic. We try to keep epics to 2-3 weeks of work - if a project feels bigger, we’ll try to reduce scope or split into multiple epics. Keeping epics as small as possible means we avoid the need for complex estimation sessions and timeline debates.

🛠   During engineering work

Before we introduced the FLE role, PMs would regularly receive questions from engineers mid-way through a project as they came up against edge cases or needed clarification on something the PM hadn’t considered or documented well enough. With the FLE role, the FLE has usually preempted these questions in the spec, and if not, most of the time they have enough context to solve the problem with the engineer without involving the PM. This is a game-changer for PMs, giving them more confidence in the implementation and freeing up more of their time to figure out the next epic or think about the roadmap.

🚀  Launch

When we launch, the FLE emails a launch announcement to the company and demos the feature in our weekly company All Hands meeting, in collaboration with the designer and PM (though some people prefer not to, and there’s no pressure of course!). Demoing a feature to a flood of excited Zoom comments from around the business is super rewarding for engineers and makes sure they get the recognition they deserve.

🔧  Post-launch

The FLE is responsible for delivering the feature successfully, and that often includes improvements we want to make post-launch after further user testing, watching FullStory videos and monitoring success metrics. The FLE will work with the PM and designer to figure these out for follow-up launches.

Once the epic has concluded, the FLE runs a dedicated retrospective with the whole squad - we talk about what went well, what didn’t, and what actions we can take to improve for next time.

🌟  Feature Leads are the future of engineering

Feature leading is for all engineers, including our juniors. The FLE role provides amazing step-up opportunities for engineers to gain leadership experience, learn faster from senior engineers by being exposed to different ways of thinking, and gain wider technical and business context they just wouldn’t be exposed to elsewhere. We believe it allows them to do their best work.

Our engineers are more motivated and have more impact, our PMs have more capacity for strategy and research, and as a result, we ship better products, faster 💪

At Nested we hire full-stack engineers who are particularly motivated by the impact their products can have on customers and the FLE role helps us find them. You can learn more about our tech team here and if you’re interested in feature leading, we’re hiring.