The 3 D's of frontend feature leading

Learn the foundational principles of feature leading you can always rely on in the midst of any chaotic project.

Introduction

A feature lead refers to a person in a team that's responsible for the technical planning and delivery of a new feature or project. It's different to the job title "tech lead".

It’s common for individual engineers to lead projects at high growth start-ups or big tech companies. It's one of the best ways to level up and gain more experience and seniority.

Feature leads act as the go to person for everything related to the planning, implementation and delivery of that project or feature. At some point you may find yourself needing to fulfil this role within your team.

For those completely new to feature leading, it can be a source of confusion and stress. As your primary focus expands from specific coding tasks, to also being responsible for the delivery of a project.

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 it is specifically they do that leads a project to success. Also from my own experience acting as a frontend technical lead on a team. Despite the title, these principles transcend specific domains like the frontend and apply more generally to software projects.

The aim of this post is 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. In practice there is much more to be said on the topic of feature leading that is outside the scope of this post.

But 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.

1. Discover

Product managers and designers will typically have a good idea of the value they want to ship to users by the time 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:

1. Understanding the problem you are solving. Looking at this another way, what new value will be created when everything shipped to the end user?
2. Understanding the current technical terrain.
3. Charting a clear path forward for the team on how to get there.

What discovery looks like in practice

What are the concrete tasks a feature lead will be doing 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

• Discussing your project with relevant subject matter experts.
• Getting the high-level architectural details. And identifying potential dragons before digging in 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 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 discovery is also an ongoing process throughout the lifecycle of a project. In practice unknown things will come up half-way and even towards the end of a project.

This is because in a fast paced environments things change often. Especially requirements. You’ll find yourself cycling back to this phase often, for various sub-streams of the feature. This can make it hard to stick to to detailed plans upfront.

This phase is about working towards a completed view of the project. On the one hand you need to understand the core parts, so the project can actually begin. On the other, 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, but 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 easily. While others may be more open ended, leading to further questions and exploration.

Keep in mind your goal here is 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 on what needs to happen. And also what further discovery is needed.

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 principle 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 a 1-2 day time-boxed spike 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 todo tasks like “TODO: need to get the data here somehow”, “TODO: we’ll need to refactor and extend this” etc.

This is a useful starting point for breaking down concrete tasks that developers can pick up and work on. 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.

Communicating progress

Sometimes in the discovery phase it’s hard to show you are making progress. It can be useful to create tasks in whatever issue tracker you use, dedicated to investigations. This is both to show progress externally, and to also help keep track of all the investigations that often go on in parallel so you can refer to them later. It's good to time-box these to 1-2 days and provide regular updates on your findings. This helps avoid spending too much time down rabbit holes.

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 difficult than originally thought. Or not currently possible.
This can lead to confusion and increased context switching, and if it happens often can reduce 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 a number of things we don’t actually 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 “should be pretty straight forward".

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 likely exists 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. Being able to communicate the technical landscape in a language external stakeholders can understand is a useful skill to develop on its own.

Having a clear understanding of what the team is building, and how it will built is a critical part of being a feature lead.
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 be continually pushing to keep a forward momentum without getting blocked.

The next step is taking this context and making decisions that allow you to move things forward.

2. Decide

This is all about building consensus.

Building products is said to be a series of trade-offs. As a feature lead you are going to be the key person driving these decisions. Along with design, product managers and other teams who may be impacted by your project or feature.

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 straight forward 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 effects 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 balance many 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 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.
• Communicating the outcome of your decisions 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 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 a 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 %, or correlate it to existing support tickets if available. 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 both a way to leave a paper trail for your work and serve 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.

3. 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 team composition. In these cases it’s best to speak to your manager or project sponsor to get either get more help, or reduce scope / increase the timeline.

Often times it will be faster for you to "just do it", rather than share the context and delegate to someone else. There is a trade-off to balance here, in the majority of 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 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 to not create knowledge silos.

Delegation can apply to more areas than coding

It’s not just about delegating the development work. For larger projects you’ll likely need to delegate the work related to discovery. 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 just feels like it will be quicker and easier to do it yourself. Most likely you'll just put yourself on the path towards burn out, 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 technical direction.

It’s useful to be mindful of this as you share 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 none the less.

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.