How the Feature Lead role finally helped me grow

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:

1. Plan and deliver the feature well i.e using the time and resources effectively
2. Consider the business impact (success criteria) and validate it (report on it via metrics)
3. 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:

1. 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.
2. 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.

So you as a Feature Lead are thinking about delivery and validation earlier, as well as having a more proactive part in decisions across the entire process.

This might also involve more managerial tasks such as:

• Regularly reviewing the success criteria with stakeholders and communicating these to the team.
• Collaborating with all disciplines across the business, from marketing to legal. Are the problems and your take on the solution all understood?
• Communicating with stakeholders and (for the bigger features) sending out weekly update emails as well as release emails. This has proved very useful at sharing project information with the right people.

It’s worth noting you can be an engineer in 1 project, then a Feature Lead in another. It is a temporary role in that it will only last as long as the project.

However if it takes weeks or months to prove the success or learnings then it is the Lead’s responsibility to keep track of this. Essentially all the hard work was for this, so in many ways it is the most crucial part.

Caveats about this role 

It is important to remember that it is not about the process, it is a series of considerations.

People have varying degrees of interest in following it which is fine, it should empower engineers not control them. We are not replacing one process with another. Encourage people to practice it and see the results themselves.

It has been very obvious how much having leaders who have bought into this has helped. They have pushed it from the top, which has had an incredibly positive effect on its adoption.

The results 

Having done it several times now, I can honestly say it has changed my life (I’m not being over dramatic).

Before this started I had very little opinions about what was going on outside the code, but not anymore.

Each time I have led, I have found new challenges from which I learn a huge amount from. This is likely because they are not the typical problems facing an engineer. I am now aware of problems from well outside my normal domain. Not to mention knowing the first names of people outside engineering.

I now have a big passion for understanding and utilising analytics data and also it’s setup. The considerations for this might include:

• Which tool can I use to answer our questions? Understanding what each tool does (e.g Google Analytics vs Mixpanel vs Server-side tool) and their limitations.
• How long will this metric need to exist for? Do we need it to still be available in 6 months or can we get our answer via a 15 minute hack (e.g a spreadsheet) and then not worry about it ever again?

Focusing on the ROI of any work really changes how you view the work. You consider all the time spent on each part of it from a business perspective. No longer wanting to write code for the sake of it, you want it to have a purpose. I have a deeper appreciation for questioning and understanding the value a piece of work actually delivers. I think this might be the part which has helped change me more than any other. I might spend slightly less time coding but the time I do spend is much more productive.

“No longer wanting to write code for the sake of it, you want it to have a purpose”

My efficiency at helping to deliver a project has improved as I fully consider the heavier details at the beginning, so the delivery process is more streamlined. I never cease to appreciate the lack of stress had at the end of a project well planned. Not to mention the pleasure in meeting expectations.

I have learnt I can offer value to different areas of the company, as I have a better understanding how they work as well as their pain points. This not only has a positive effect on myself but also on the business. Knowledge sharing has been a pleasant unexpected side-effect of this role.

For me personally it has helped identify (substantial) gaps in the business that I never would have been able to find previously. For example we had issues with analytics discrepancies (tools producing different results for reasons unknown). I was able to get involved fixing them, which was hugely valuable across the business. The result of this are learnings which are useful to me, to engineering but also to the wider business.

Summary

I do my best to try and use the skills I have acquired to add value where I can, not just where I am Feature Leading. This typically surfaces in suggesting things and proactively seeking to ask or answer questions for any feature currently in progress. I am only able to do this as I am more knowledgeable in diverse areas. My actions also include spreading awareness and encouraging others to partake in this practice.

One of the best developers I ever knew said

“Engineers should deliver software not develop software”.

At the time I did not know what this meant (should we focus on deployment perhaps?), but now I feel I have my own strong ideas. For me delivering software is more about the value it brings than the way it’s built.

I need to thank my company Nested for the culture that they have pushed to adopt. For empowering and not controlling their employees. Without this we would not have had space to experiment and learn, and I certainly would not have gone on this journey.

Please feel free to get in touch about your experiences, we would love to hear about them.