Introduction
A feature lead refers to a person in a team responsible for the technical planning and delivery of a new feature or long-running project.
It’s common for individual engineers to lead projects at high-growth start-ups or big tech companies. Feature leads are the go-to person for planning, implementing, and delivering that project or feature.
Taking on the responsibility of a feature lead is one of the best ways to level up to gain more experience and seniority. For those entirely new to feature leading, it can be a source of confusion and stress, as your primary focus expands from specific coding tasks to being responsible for the delivery of a project, often involving many non-coding related tasks.
So what do those non-coding-related things involve?
The goal of this post is to try and distill all those fuzzy parts, some may call “soft skills”, into a few fundamental principles.
These principles come from observations when working with other great feature leads. While trying to understand what they actually do, that lead a project to success. And also from my experience acting as a frontend technical lead on various teams.
Despite the title, these principles transcend specific domains like the front end and apply more generally to large software engineering projects.
This post aims to arm up-and-coming feature leads with a framework to make sense of those fuzzy parts when leading a team to deliver a feature.
These are the fundamental principles you can always rely on. Do each of these well, and you’ll have a pretty good time. On flip the side, in my experience, if I’ve started neglecting one of these, it usually doesn’t end up great.
So let’s dig in and understand each one in turn.
Discover
Product managers and designers typically know the value they want to ship to users before a project starts. This is where you come in as the team’s feature lead. You’ll need to discover what needs to be done at a technical level to make that a reality.
There are three main aspects to the process of discovery:
- Understanding the problem you are solving. Looking at this another way, what new value will be created when everything is shipped to users?
- Understanding the current technical terrain.
- Charting a clear path forward for the team to get to where you need to go.
What discovery looks like in practice
What concrete tasks will a feature lead do when they are in the discovery phase?
Generally at the start of a project:
- Researching similar prior art from other teams.
- Searching for similar problems that have been solved before. You should avoid re-inventing the wheel if you can.
- Reading through any existing relevant documentation if it exists.
- Speaking with other relevant teams and feature leads.
Gathering the high-level details
- Discuss your project with relevant subject matter experts.
- Getting the high-level architectural details. And identifying potential dragons before digging into the low-level details is helpful.
Gathering the low-level details
- Reading through existing code and making notes.
- Doing this first without having a picture of the higher level makes it much harder.
Ball parking high-level estimates
- I always try to remember to add an extra buffer. This helps to set correct expectations, which is critical at the beginning of a project. It’s better to under promise and over-deliver.
The hard parts of discovery
”No plan survives first contact with the enemy”
In the early stages of a project, you’ll spend a lot of time in discovery mode. But it’s also an ongoing process throughout the lifecycle of a project. In practice, unknown things will come up halfway and even towards the end of a project.
In fast-paced environments, things often change — especially requirements. You’ll find yourself cycling back to this phase often for various sub-streams of the project. This can make it hard to stick to detailed plans up front.
This phase is about working towards a completed view of the project, and what that looks like. On the one hand, you need to understand the core parts so the project can begin. Conversely, you’ll need to be okay moving things forward often with incomplete information.
You’ll also want to understand the things that have the potential to go wrong or slow things down. Both at a technical level and also at an organizational level. There will likely be many questions that come up during this phase.
For example, “does this feature depend on other teams?"
"It will be much faster to ship this in the existing tech stack, but we want to move to the new stack. How should we balance this?"
"The platform doesn’t currently support X. Do we build something bespoke, wait for support, or build it ourselves into the platform first?”
In practice, some of these questions may be answered quickly. While others may be more open-ended, leading to further questions and exploration.
Keep in mind your goal here is to understand the current technical reality as much as possible.
This happens through asking the right questions and seeking their answers. So it’s expected to have a bunch of unanswered questions in this phase. It’s a good sign you are starting to develop a clearer picture of what needs to happen. And also what further discovery is necessary.
Practical tips for discovery
Validate early
After you have an initial idea of your approach, you’ll want to confirm you are on the right track. Organizations sometimes have architectural sparring sessions or dedicated office hours with architects and principal engineers that you can utilize.
If there is no formal process for this, you can try reaching out to other senior engineers to bounce ideas off. This helps you get early feedback. And also spread awareness across the organization of upcoming changes and features.
Technical spiking
If you’re making a change to an existing system. It’s often super insightful to do 1-2 day time-boxed spikes to get a sense of the actual work involved.
As you hard code values, mock out data, comment out code, and generally leave a trail of destruction on a spike branch. You’ll end up with a useful set of to-do tasks like “TODO: need to get the data here somehow”, “TODO: we’ll need to refactor and extend this” etc.
Translating an idea into code tends to reveal the hidden technical decisions you need to make that simply having a high-level conceptual understanding won’t reveal. So this is a useful starting point for breaking down concrete tasks that developers can pick up and work on.
Communicating progress
Sometimes in the discovery phase it’s hard to show progress is being made. It can be useful to create tasks in whatever issue tracker you use, dedicated to investigations. This is both to show progress externally and also to help keep track of all the investigations that often go on in parallel so you can refer to them later. As mentioned before time-boxing can help avoid getting lost in rabbit holes, and allow you to provide regular updates on your findings.
Things to watch out for
Breaking down tasks too early
Sometimes a developer will pick up a task and discover that the approach outlined is much more complicated than originally thought. Or not currently possible. This can lead to confusion and increased context switching, and if it happens too regularly, it can reduce team morale.
The Dunning-Kruger effect
This is a kind of cognitive bias we all have that leads to underestimating things. Or, put differently, overestimating our ability to do something. We often feel certain about many things we don’t have direct experience with.
This is often true when planning work. It can bite you if you have a high-level conceptual understanding of something and think it “should be pretty straightforward”.
The devil is always in the details:
- This is often the cause for overly optimistic estimates, which can lead to setting the wrong expectations early on.
- These overly optimistic estimates can also contribute to a sense of time pressure for developers who pick up stories that have these estimates. Especially in scrum environments, there is an unspoken sense of “the story is estimated as a 1. I will just merge now and do all the extra X in a follow-up later”.
- This can lead to a pile of tech debt over time. The thing to watch out here is that there is also a kind of Lindy effect for stuffed chucked in the backlog. In my experience the longer something is put off in the backlog, the longer it is likely to be continued to be put off or forgotten about.
- It’s also useful to understand this bias in external stakeholders. It’s the classic “why does it take 2 weeks to make that button work?“.
- You don’t want to bombard stakeholders with all the technical limitations and challenges. In fact, you want to shield them from this to some extent. Communicating the technical landscape in a language external stakeholders can understand is a valuable skill to develop on its own.
A critical part of being a feature lead is a clear understanding of what the team is building and how it will be built.
As part of this process, you are likely to discover multiple possible approaches. Each with their own trade-offs and open-ended questions that need to be answered. As a feature lead, you’ll want to continually push to keep forward momentum without getting blocked.
The next step is taking this context and making decisions that allow you to move things forward.
Decide
This is all about building consensus.
Building products is said to be a series of trade-offs. As a feature lead, you will be the key person driving these decisions along with design, product managers, and other teams your project or feature may impact.
In an ideal world, everything is discovered, and all decisions around the user experience and implementation details have been decided. As a team, that’s a good state to be in. Assuming solid discovery and no spanners are thrown in the mix, from there it’s a straightforward matter of execution.
It’s unlikely you’ll get to this state early on for every aspect of the feature. So you’ll want to work towards this state for the various sub-streams.
The hard parts of deciding
”Things that matter most should never be at the mercy of things that matter least."
"Deciding what not to do is as important as deciding what to do”
There is a bit of a balancing act here.
While you want to have clarity on what needs to happen, deciding too early means you could be building the wrong thing, the wrong way. This can result in your decisions being undone down the road, leading to re-work and loss of team morale and momentum.
This can be especially painful if you decide on a course of action that affects other teams unknowingly.
Often times it is best to defer making engineering decisions until all information is available if it ever comes at all. There really is no silver bullet here. The best you can do is break things down and start building consensus on the smaller independent sub-streams. So you can get started while more information is then gathered.
Often times what is proposed is not workable in the time frames given. Speed, quality and scope - you can usually pick 2. In the majority of cases picking speed and quality is the right move. This follows the principle that it is generally better to do less work to a high standard rather than to try and do everything at once poorly. At a higher level, this maps to the lean way of incremental delivery.
Sometimes you’ll find yourself between two or more competing interests across teams. It’ll be your job as the feature lead to offer multiple solutions or ways forward. Ideally, with high-level estimates, that many balance sides. And then to ensure you’re driving those decisions to an outcome one way or another.
Your ability to come up with a good set of options comes back to knowing the why behind the feature, and understanding the customer pain, you are solving. Knowing this allows you to focus on what matters most.
What driving decisions looks like in practice
- Creating, updating and driving decision register documents. These are documents that capture the problem statement, propose a bunch of solutions, and provide a format for building consensus in writing.
- Collaborating with product managers to understand what is in scope and by when.
- Updating and driving smaller, less impact decisions and updating decision registers.
- Talking with other teams and people to engage in the decision-making process and garner alignment.
- Communicate your decisions’ outcome via whatever status reporting format your team uses, weekly syncs, stand-ups, async posts, etc.
Practical tips
Run a project kick-off
A project kick-off is used to build an initial consensus on what a successful outcome looks like. These are helpful for aligning everyone involved on the value you plan to ship and roughly by when.
It’s useful to get everyone on the same page early on in this regard. Because as you make trade-offs down the line, you can optimize and generate solutions based on what the customer truly cares about in the feature being delivered. Establishing what that is as a group before work begins is very useful.
Keep track of your decisions and the reasons why they were made
It’s useful to record each decision and why it was made. This helps you own the decisions you make and move forward with confidence. People will question some decisions (not necessarily maliciously but out of curiosity). Having a decision register helps you come back to the why as time passes.
Quantify decisions if you can
By passing through the discovery phase, it’s likely you would have encountered some issues that need extra work to be done. There will come the point where you will need to convince others that some action needs to be made or avoided.
It’s helpful to articulate the value something will provide whenever you put forward a proposal. Or alternatively, the issues you won’t have to deal with down the line if you do the work now.
Strive to get metrics if you can. For example, refactoring something to make it faster. How much faster? By what percent? Are you able to correlate it to existing support tickets? Sometimes even having a ballpark estimate is useful for making a stronger case.
Things to watch out for
Not being explicit about the trade offs you’re making
At some point, you will need to decide between a trade off. When recording decisions, it’s useful to be explicit about the trade off you are making. This serves as a way to leave a paper trail for your work and as documentation for the future.
Decisions leading to rapid accumulation of tech debt
Depending on the project, you’ll likely find situations where you simply have to cut corners and introduce tech debt due to time constraints. Avoid this if you can, but in my experience, it’s quite hard to completely avoid.
In these situations it’s useful to make this clear to external people “we are borrowing time from the future” so we can provide customer value faster, but at some point this will come back to bite us.
Own this as your responsibility as the person closest to the implementation. Communicate this back out to the team and relevant stakeholders, and ideally, get commitment to cleaning things up in a following iteration if possible.
Having your decisions undone
This leads to re-work and inefficiency. Also loss of momentum and morale. In practice, usually this will come from not assessing the impact on other teams and other dependencies. Or from not understanding the current technical landscape in detail enough and having to back-track out of a particular approach. When locking in decisions, make sure to include every relevant party. Good discovery is key in avoiding this situation.
Delegate
This is all about not trying to play what is a team sport, solo.
As you discover what needs to be done and decide how you will do it, as feature lead you’ll need to delegate. As you discover and decide, you’ll need to regularly download what’s in your brain to the rest of the team.
Delegation is not about palming off work to others. It comes back again to consensus building. It’s also about creating a sense of ownership in the rest of your team. And as much as possible, having each member “act as a principle” by having clear areas of responsibility. You want to eliminate as many single points of failure in the team as possible - aka the “bus factor”.
The hard parts of delegating
”If you want to go fast, go alone. If you want to go far, go together.”
Sometimes you might find that there aren’t enough people to delegate to, depending on your team size and composition. In these cases, it’s best to speak to your manager or project sponsor to get more help or reduce the scope / increase the timeline.
Often it will be faster for you to “just do it” rather than share the context and delegate it to someone else. There is a trade-off to balance here. In most cases, it’s better to share whatever is in your brain with the team and delegate as needed.
If you’re new to feature leading, it can sometimes be difficult to feel comfortable delegating to others. This is a pattern to identify and break as early as possible to avoid piling everything on yourself and burning out.
What delegating looks like in practice
Breaking down tasks and fleshing them out with all the necessary information
This also means delegating to your future self. Providing all the context needed and links to files in source code where you need to make changes. As with all the context switching it’s so easy to lose or forget the context where you need to make the changes.
Running estimation meetings
Or any meeting where the engineers sync up to talk about the work they are going to do. This involves walking other engineers through tasks to provide technical context. So the others are on the same page and are in a position to work on them independently. It also includes regularly organizing the backlog based on priorities. And being available for ad-hoc meetings and answering questions for those taking on the work.
Practical tips for delegating
Have developers work and own small subsets of the feature
This makes development more efficient and creates a sense of ownership. Pieces are ideally small enough not to create knowledge silos.
Delegation can apply to more areas than coding
It’s not just about delegating the development work. You’ll likely need to delegate the work related to discovery for larger projects. This also applies to driving decisions to a decided state when multiple decisions are needed.
Things to watch out for
Trying to take everything on yourself
You have all the context, and it often feels like it will be quicker and easier to do it yourself. On large projects, you’ll likely just put yourself on the path toward burnout, and it’s also inefficient to try and do everything yourself. Remember, it’s a team sport.
Not shielding the team
Ideally, when you download your brain to the team, it is with information that won’t later become irrelevant. As you go through the process of discovering and driving decisions, there may be a churn in the technical direction.
It’s useful to be mindful of this as you share the context with the team. You’ll want to strike a balance between shielding them from that versus bombarding them with details at every step of the way, which usually leads to confusion.
Over delegating
Sometimes over-delegation can happen. It’s much rarer compared to feature leads piling everything on top of themselves, but something to watch out for nonetheless.
The most important D
Chances are at some point you will be called upon to lead a project as a technical feature lead. To take what is just an idea, and drive that through to something concrete that provides value for other people.
When this happens, don’t panic!
Remember the 3 Ds, and you’ll do fine.
Good luck.