An introduction to feature leading

This was originally posted on the SafetyCulture Medium blog here.

Software engineering is about more than programming. Programming is important, but so is understanding how your software works, how it gets deployed and the machines it runs on. Equally important is successfully leading a feature from an idea to being in your customers hands. Overseeing the delivery of a feature helps you grow as an engineer, gives you a better understanding of the software development lifecycle and helps you grow your impact beyond the code you write. This is often done by a tech lead, but can also be done by a feature lead. A feature lead is an individual who is responsible for managing a feature, and helping the team work towards its completion. Feature leading is a great way to develop new skills, but can be quite challenging to get started with. I have been the feature lead on a number of projects, and have helped others on my team feature lead as well. Feature leading is a great opportunity to learn, but can be very daunting at first. In this article, I’ll give you an overview of how to lead a feature, including strategies some of our teams use at SafetyCulture.

First steps

Think

Feature leading has two goals. The first, and most obvious, being to get the feature over the line. The second being to develop a really deep understanding of the feature. Ask lots of questions, write everything down, go for a walk, and then come back to ask more questions. Try to understand the big picture goals and low level minutia of the feature. Think about questions that your teammates might ask to be better prepared to answer them. Try and understand the feature deeply, and cover as many scenarios as possible.

Plan

When I first started programming, I’d always jump right into a problem; I’d start hacking something together, only to realise that my initial attempt wasn’t quite right. As I gained more experience, I learned to stop and form a plan before making any large code changes. It’s the same with feature leading. Jumping in without a plan will lead to edge cases, and make completing the work much harder. Time spent in planning is never wasted, and leads to better outcomes.

Find the why

An important question to figure out for this feature is ‘why are we building this?‘. Growing as an engineer involves lifting your focus from only code, to thinking about what you’re building and why. Code is a tool used to solve a problem, and that problem is the one solved by the product. Thinking about the why ensures that the solution solves the problem. Finding the why, and lifting your focus beyond code makes a better engineer, and will make you a more effective feature lead.

What do you need?

Before you start planning, do you have everything you need? Do you have all the required designs? What do the different user flows look like, including error states? What are the required changes? When is the projected release date? Make sure you have everything you need before you start planning. This ensures you haven’t missed something critical that could put the feature at risk.

Who needs to know?

This feature may interest different people or departments; find out who they are. Think about the different people usually involved in new product releases. Does the customer support team have enough lead time to write customer documentation? Are marketing running a new campaign? Will any of the code changes have an impact on other parts of the platform? Part of the role of a feature lead keeping everybody in the loop about the feature. When you’ve thought about who needs to know, this becomes much easier.

Measuring success and determining scope

What’s the goal of this feature, and how will the team know when they’ve achieved it? If you’ve set out to do one thing but do another, the feature may not have achieved its goal. With a goal in mind, it’s the priority of a requirement can be identified. Knowing the goal helps to determine the scope of the feature.

The requirements of the feature make up its scope. If a requirement is “In scope”, it must be completed. Similarly, “out of scope”, means the requirement won’t be completed. Some requirements will be neither in or out of scope, and are “nice to have”. Scope is important because the team will only have limited time to deliver this feature.

Time, scope and cost are the three parts of the project management triangle. This says that the competing demands of scope, time and cost determine the total quality of a project. For example, cutting scope could lead to an earlier completion date, but may lead to an incomplete feature that doesn’t achieve the set goals.

Therefore, a feature lead’s job is to maximise quality, while managing scope, time and cost. One of the most powerful ways to do this is by changing and negotiating which requirements are in scope. This also means that some requirements will be left out. This is necessary to ensure the product is of high quality, and completed within a reasonable timeframe. Cutting scope can help to focus a feature. If a feature is too large and there isn’t enough time to complete it, this will often lead to a rushed and buggy product.

For example, these hypothetical requirements are to add some new functionality to a form.

Requirement: Update the form with a new redesign. Response: This will add an extra two weeks, so this is out of scope. Maybe we can do it as a separate feature, because the work is complex.

Requirement: Update the colours to fit the new brand theme. Response: This will only take an extra two days, so this should be possible. Because it’s not completely necessary, this work is nice to have. We’ll try and fit this in if we have time.

Requirement: Add the new form field and connect it to the back end. Response: This is in scope, because without it the feature doesn’t achieve its goals.

If a feature is too large and there isn’t enough time to complete it, this can lead to a rushed and buggy product. Therefore, managing what will and will not get completed in a given timeframe is critical. Some requirements can be rejected during planning, and your team can help reject others later on when your estimates are firmer. It sounds scary to push back during planning, but this is expected of a feature lead. The feature lead has the most context on the technical side of things, and is in charge of the feature. They are therefore best positioned to help steer the feature in the right direction. If the feature lead doesn’t push back where appropriate, they’ll be under pressure to get the feature back on track if it starts to fall behind. It’s easy to add extra requirements if there’s spare time, but much harder to remove them if the timeline gets tight and promises have been made. The team will be grateful if unnecessary requirements can be trimmed early. Once this information has been finalised, add it to a product page in Confluence or somewhere similar. This will be the source of truth going forward, and will be often referred to during the course of the feature.

Communicate to the team

Once the engineering manager and product manager agree on the requirements, bring in the team who will be doing the work.

At SafetyCulture, we do this in a Product Kickoff meeting. This meeting brings in product, design and engineering to align everybody on the goals and outcome of the feature. During this session, the team will ask questions that might not have been covered yet. This is a great chance to make sure that any questions are answered and all requirements are documented. Make sure to document anything new in your product page.

Design the technical implementation

Next, you’ll need to plan the system design for the implementation. It’s important that the implementation is sensible, performant and scalable. This is important, because changing the implementation before anybody has begun coding is much easier than changing it after.

System design is a large topic that’s out of scope (get it?) of this article. There’s many resources out there that focus on it, so check those out to learn more. This article will instead discuss how to present your design.

At SafetyCulture we write about the design in a Confluence document. This way, your team and other teams can reference this page as required. It’s also useful as a historical document for the engineering team’s reference in the future. When you’re writing a design out, think about these points:

1. Outline the problem. Your technical solution exists to solve a problem. Ensure that whoever is reading this document knows what that problem is. Write this for an audience that’s broader than your team. Your team may know the problem in depth, but others may not.
2. Write for a particular audience. I try to keep my CTO in mind when I’m writing up a design. They understand technology and the business, but may not have a deep understanding of implementation specific details. This helps me think about what’s relevant, what to expand on and what doesn’t need as many details.
3. Start broad and narrow down. Start with the big picture, and then separate out larger portions into their own section. Don’t start from a narrow context, as this makes it harder for you to communicate the complete picture.
4. Keep details relevant. Only include relevant details. Specifying that the feature is using Postgres and then doing a deep dive into Postgres itself isn’t helpful. However, outlining a new database table and its columns and indexes would be very helpful.
5. Discuss any alternatives. During the design process, there may have been some alternatives that weren’t chosen. Mention these, as someone else may think about this solution too. It’s helpful for them to know that these possibilities have been thought about and disqualified. This also gives the team confidence that the proposed solution is the best way forward, and not the first idea you came up with.

After you’ve done this, get feedback on your design. Start with your team, and then open it up to a wider audience. SafetyCulture runs a design review session where teams present their designs to collect feedback from engineers outside of their immediate team. This session helps to refine a design, and helps shape them into better solutions. If your organisation doesn’t do this yet, organise it for your next design. Others within engineering will benefit from this as well.

Figure out and plan tasks

After you’ve incorporated any feedback into the design, break the requirements down into stories. At the outset, be super granular with the aim of combining some tickets later on. I do this in a rough document before moving the tickets to Jira. It’s easier to get feedback on the tasks, as well as consolidating them if needed. Doing this in Jira means a lot more clicks to change or combine a task.

Think about this in broad tasks like, “Set up new microservice”, or “Show new information to customers”. These broad tasks can now be broken down into the specific changes that they need. “Display new information to customers” might include updating your web, iOS and Android clients, updating the endpoint to return new data and adding end-to-end tests. These five tasks are easier to communicate, assign and parallelize between the right people, as opposed to the one big task.

Work vertically instead of horizontally. It’s easy to think about tasks as “backend” tasks, or “mobile” tasks. A better approach is to split the work up so that smaller pieces of work can be tested and verified early. Let’s say we are creating a new endpoint and modifying an existing one. A horizontal approach would be to work on all of the backend tickets for each endpoint, then mobile tickets to support these changes, and so on. The problem is that it becomes harder to test a set of changes until the feature is close to completion. By working to finish one endpoint before the other, it’s easier to de-risk the feature and build confidence in the testing plan as early as possible. This means less testing at the end because large portions have already been tested.

Sequence the work to make things smoother. When looking at the work involved, the order that functionality is completed can make a huge difference. For example, part of a new feature work involves adding a new data type to an existing data structure. If the vertical slice that allows that data to be added via the UI is done first, it’s much easier to work on the slice that focuses on fetching and displaying that data because the team can add the data in the same way a real customer would. If this was done the other way around, the team will probably be adding data manually to the database. This works, but is slow, error prone, and much harder to find edge cases. By figuring out the correct sequence of work the implementation of the entire feature is much simpler.

Next, go through the tasks and make sure that the implementation works if the tasks are executed as outlined. Try to find any gaps, missed areas or flaws. Do this with a teammate to ensure it makes sense, and make sure that nothing has been missed. Add any missed tasks in, or tweak the design if needed.

Add some estimates to the tickets to get a rough feel for how much time this work will take. Bring this to your engineering manager and get their feedback. If the estimates are higher than the allotted time, you might need to work together to cut some scope or revise the target delivery date. With these estimates in hand, I’d recommend visually planing out the tasks. I’m a big fan of Jira’s planner functionality. It includes functionality to assign tasks to people, add blockers and visualise the flow of the feature. This way the work can be spread evenly amongst the team so that nobody is stretched too thin. Visualising the tasks is optional, but it’s a helpful way to see how the feature is going, and correct course if it begins to to slip behind schedule.

Align your team and start

With your plan and tickets, it’s time to bring your team together and get the feature underway. At SafetyCulture we do this as part of an engineering kickoff. The purpose of this session is to make sure the team is ready to start working on the feature. The team should have already read through the implementation, but go through it with them to ensure that everyone is on the same page. When everybody understands the big picture, go through the tasks and get the team’s estimates. Hopefully the estimates are similar, but if your teammates have different estimates, add theirs to the ticket. Their estimates should give good insight into how long this feature will take.

From here, you and your team can start working on this feature. During the course of the feature you may find some problems or gaps. This is okay! Your job is to facilitate fixing these problems, and finding ways to plug any gaps. Provide solutions to these problems and be open and communicative to your stakeholders.

The bottom line is to be honest and as communicative as possible. If the feature is slipping behind schedule, talk about it. Your manager and team want to know when things are going off course so that they can help you fix it. Hiding information only make things worse, even if being outspoken feels difficult.

Test and deploy

Once the work is complete, run a testing session to ensure that everything works as expected. Come up with scenarios that cover happy paths, and various edge cases. This will give you confidence that when your customers are using it, you won’t get any nasty surprises. You’ll only be able to test the whole thing when the work is complete, but you can still test the feature while your team is working on it, especially if you’ve broken the work into testable vertical slices. This will help you find bugs and missed edge cases before your customers do.

Once you’re confident with your testing, switch on the feature flags and progressively roll it out. Keep an eye on alarms, logs and performance metrics, and don’t be afraid to halt deployment if you find something.

Reflect and retro

Congratulations! That’s your first successful feature completed. Schedule a feature retro, and find out how your team felt about it. Take any feedback on board and work on their suggestions next time. Find some time to self reflect and give yourself some feedback too. You’ll have learnt a lot, and now is a great time to consolidate these learnings.

Make sure to document any cut scope. Your team may be able to work on this as a quick win sometime now that most of the hard work is out of the way. If the cut scope was a bit larger, it might be an additional feature that needs more work and planning.

Finally, give yourself a huge pat on the back. Leading your first feature is incredibly challenging, but very rewarding. You’ll have levelled up a lot in your product knowledge, technical expertise and understanding of the software lifecycle. Plus, the greatest reward of all, you’ll be a better engineer afterwards.

TL;DR

1. Think and determine scope
2. Product kickoff
3. Technical design/implementation and feedback
4. Task breakdown
5. Engineering kickoff with the team
6. Plan things out visually
7. Test, deploy, retro
8. Congratulate self, rest