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.
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:
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.
Let’s break down what is involved and at what point of a project.
By that I mean 2 things:
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.
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.
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 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:
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.
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.
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:
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.
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, I would love to hear about them. Also comments or feedback are always welcomed and appreciated.