3 Things I Learnt Feature Leading for the First Time

When my team starts work on a new feature, a developer is nominated on the team to act as the feature lead. This person is responsible for keeping others up-to-date on the feature’s progress, any communications with stakeholders, and creating/managing the backlog of Jira tickets for the feature (which can at times feel never-ending!)

Over the last few months I got the chance to feature lead the conversion of a pre-existing Backbone.js front-end into a shiny new React app, and I picked up a couple of learnings along the way.

Get feedback on your implementation

While creating the tickets for your feature, you’ll probably come across a few tasks that you’re a bit iffy on the implementation details of. Maybe there might be a few ways that you can approach it, or you’re unsure of all the edge cases involved. In this situation, it’s worth putting together a quick page describing some of the different approaches and its pros and cons, and share it with the rest of the developers on your team.

The other devs can then provide their feedback on the approach they think should be taken and raise any other risks they have thought of, and you can settle on a solution together. Doing this in advance makes life much easier for the developer who picks up the ticket, as they know exactly what they need to do. It also creates a much smoother pull request process, as everyone will already be on the same page in terms of the implementation.

It’s probably going to take longer than you think

I thought I was being generous when I estimated the time it would take to finish the feature - but I ended up being more than a month off. There’s all sorts of things that can cut into developer time like team events, 20% time and other initiatives or features that can take priority in certain weeks, and before you know it you’ve hit the week that you were supposed to be finished and there’s so much left to do! We can’t always account for these things in advance, so the important thing here to stay on top of knowing what might cause delays, so you can communicate with your stakeholders as soon as possible when your feature’s launch date changes.

Small things add up

What I didn’t realise was that coding the main functionality of the page isn’t the hard bit - it’s all the small things that create this long tail of things left to do. Handling certain error cases, form validation rules, fixing a pesky UI bug… It’s your job as a feature lead in this scenario to make sure that you’ve made tickets for all these things that need to be complete, and be ruthless about deciding whether it’s actually within the scope of the feature. It may be that it’s not necessary for the release of the feature, but it’s still a “nice to have” that you can come back to do afterwards.

I’ve learnt a lot from my first feature leading experience, and I hope I can apply them to the next time I feature lead!