How the Feature Lead role finally helped me grow
By: Craig Taub
Tags: JavaScript, Personal Development, Leadership, Engineering, Analytics

I have been a senior engineer for around 6 years. I definitely was not ready for it when I was hired by the BBC, but it pushed me to grow into the role and I eventually did.

However the past 4 years or so I have really struggled to grow more. My knowledge has improved as the JS ecosystem around me was transformed from one built on jQuery to where we are now. But it has always been clear that this is not the same as genuine growth. By that I mean my role and impact in a given business, what I have to offer besides being told what code to write.

I started working at Nested a year ago and came across this idea of Feature Lead. It is not a new concept (having seen it first mentioned in 2012, but it’s likely older than that) but was the first time I had worked somewhere that was interested in using it.

At Nested we are impact-driven, by that I mean we aim for optimal ROI (return-on-investment). We try to quantifiably demonstrate that we are heading towards our goal by using KPIs (key performance indicators; low-level targets which help achieve a greater goal).

The result is that the leaders all the way up the chain have bought into this role, as the low level metrics now play a huge part in the overall success of the business.

This has really helped push the Feature Lead role to be more prominent and rise within our company.

What is a Feature Lead? 🤔

For those who are not familiar here is my definition. Very early on in a feature’s life, literally when a high-level problem is being discussed, a Feature Lead is selected (or volunteered or whatever) to lead the project. I feel the purpose of the Feature Lead is to;

Plan and deliver the feature with a focus on (business) value

Essentially this involves doing more thinking up-front, and following up. Both are not crazy notions.

The 3 main activities it has to accomplish this are:

Plan and deliver the feature well i.e using the time and resources effectively Consider the business impact (success criteria) and validate it (report on it via metrics) Consider any next steps

The important aspect is that the Lead feels responsible for these activities and has ownership of them. They directly communicate and present on these to the stakeholders/product team/business.

It is less a process to follow and more a series of considerations to review and be mindful of (repeatedly at first).

Smaller features will not require as much following of the practices as larger features. However it’s often unclear beforehand how much value will come from the discovery, planning and thinking up-front.

What does this actually look like? 🎩

Let’s break down what is involved and at what point of a project.

Planning 📝

Directly involved in early phases like inception, ideation/brainstorming, design etc. This should begin with discussing the problem at hand and potential solutions.

Deciding on a v1 i.e the smallest shippable thing bringing the most value (it doesn’t have to be small itself).

Exploring the unknowns as early as possible, validating assumptions before committing to pieces of work. This includes answering (or working with others to answer) any engineering architecture concerns which there might be.

Understand the business objectives the project has. What does success look like? Are you confident on how to report on its success (analytically using metrics if possible)? If not, spike to learn and discover. Ensure you will be able to report how the feature improves the business.

Managing Delivery 👷‍♀️

By that I mean 2 things:

Breaking down the feature into smaller parts i.e ticket spec’ing out. Being able to provide a high level estimate. I.e weeks vs months. If you have answered all the tough assumptions it should be relatively easy to get a rough idea about time-frame. Mediating out the work. Communicating to managers and team members what needs to be done and in what order.

The likelihood is that you will work on at least a couple of the tickets yourself, so you will do some coding in amongst managing the delivery.

Validation ✔️

The after-care is also very important.

What I mean by this is ensuring we follow up and understand its impact.

For example “our new form didn’t do great on mobile, so we will iterate and try variations on mobile only”.

Days or weeks after a launch, review any metrics to learn how it is performing or if any hypothesis were proved.

Here we should consider how we want to surface these results and how long they need to last/be observed for.

Next steps ⏭️

This directly follows on from validation. Any learnings from the first version should be considered and applied to a potential second/next version. For instance:

If we added Y could we improve the engagement by 50%?

If we test different colour or text on the form could we get the conversion rate higher?

If enough value can be gauged from a second iteration of all the steps above, then it starts again.

Theoretically this process can repeat indefinitely as long as it is proving to add value.