Being a good software engineer depends not only on your ability to write good code, but even more on your ability to deliver features and add business value to the product. At different stages of our professional development, we do it differently: we may contribute to feature delivery; we may deliver it solo; we may help a team to deliver a feature, or we can even coordinate multiple teams in their effort to deliver a big feature.
You do not need a certain rank (junior, senior, staff+) to be part of feature delivery. You are already doing that during your day-to-day job, but there might be room for growth — taking accountability. Accountability is one of the most important skills when somebody wants to grow professionally. Being a feature lead is the safest way to take responsibility during your software engineering path, one that may be a solid stepping stone in your career development.
This article will set clear boundaries for the feature lead role and teach you how to navigate it efficiently. You will learn what areas you, as a feature lead, may impact in feature development and which tools you can use during your journey. Using this information, you will be able to confidently execute the feature lead role and make it a big win for you, your career and the company.
🗺️ How to read this article
The article is quite big, I know it, but I decided to publish it as a whole, to show case the feature leading process from the beginning to the very end. I advice you to dedicate about 25 minutes to read it completely (just one 🍅, you can afford it). Later you can return to the specific topics, here is the table of content to help you to navigate:
What does it mean to be a feature lead?
Let’s set up the stage. Imagine you are working for a company that sells hugging pillows online, let’s call it HUGPILL. For convenience, I will also mark the paragraphs related to the story with 🛏️. HUGPILL is a high-tech company with a complex information system. Customers can order and customize their pillows, and this information is passed directly to the factory where the pillows are made. You work on the team responsible for payment processing. Currently, HUGPILL only accepts wire transfers and cash payments on delivery. But this is going to change because your team wants to integrate Stripe as a payment provider.
You volunteered to be the feature lead. That’s great! Your manager cheers you on and says “You can do it!” You are energized, but what does it mean for you? What does it mean to be a feature lead?
Feature lead is a role, not a rank; anybody can be a feature lead. Team may have multiple feature leads at the same time. You play this role throughout the feature development process, and then it’s gone. You may have already started ideating the meaning of the role:
When I’m a feature lead, I’m responsible for ensuring that our feature has the best possible architecture!
When I’m a feature lead, I’m responsible for ensuring that the code that implements the feature is clear and antifragile!
When I’m a feature lead, my goal is to make sure this feature generates revenue for the company!
When I’m a feature lead, my goal is to make my manager happy!
These efforts are all admirable, but they are all WRONG. As a feature lead, you have one goal: to deliver the feature. In our case, “delivered” means that HUGPILL customers can pay for their orders using Stripe.
All of the other aspects of feature delivery, such as those described above, may also be important, but they are side dishes. Your goal is to deliver the feature. Understanding this single, but very important goal makes your life in this role much easier because you can assess every aspect of the process through this filter. If we do X during feature development, will it bring us closer to delivering the feature? If the answer is YES, then do it. If the answer is NO, make an informed decision and evaluate if it really needs to be done right now.
You may still ask: “But what about the code, architecture, profitability, and maybe other cross-functional requirements?” Yes, they are all important, but establishing them is the responsibility of the team or engineering as a whole. This is done on a daily basis. Ideally, when you start developing any feature, these processes are already established and you just need to follow them. If not, your team is on their journey of establishing them, and this is great. However, these questions are not your main concern as a feature lead.
Areas of impact
Alright, you now know what you are accountable for — your goal is to deliver the feature. Since you are not likely to work alone, that also means that you need to lead everyone who is involved towards the feature delivery. Let’s now explore the areas of impact that may help you go through this journey efficiently.
🔮 Feature scope. That’s first. Usually, when we start to work on the feature, we know at least something. The product owner has thought it through, ideally they have done it together with the team, and it’s clear what has to be developed. But, in 100% of cases, you cannot plan everything upfront. There will be open questions and new ideas that may improve your feature. These ideas can come from different sides — the product owner, your team, the CEO, or someone who was passing by and decided to give their valuable input.
Your role as a feature lead is to critically assess the feature scope and these “new” suggestions. Your goal is to avoid feature creeping. Why? It’s easy — the smaller the scope, the faster you will deliver the feature to production.
We will review which tools you can use in the scope of this area of impact in the sections below.
⚙️ Development. Now let’s talk about the development part. After all, we are still software engineers and not some random business people — we write code! And your team writes code! Again, your role requires you to be critical, and your focus needs to be present on the feature delivery. Ideally, each line of code that we add to the project(s) shall bring us closer to the feature delivery. This is impossible to achieve, but this mindset shall be your mindset.
Your feature development shall not cut corners or make your overall code or architecture less maintainable. We shall keep things as good as they were or even improve them. But we do it alongside feature development; this shall not slow us down.
Luckily, there are simple tools that help you. We will review them later.
💬 Aligning with 3rd parties. Being a feature lead means being a good communicator. Don’t worry, it doesn’t require you to be a Steve Jobs of presentations or “The Wolf of Wall Street” in motivation. You just need to communicate and over-communicate to keep everyone involved in feature development aligned.
This starts with your own team but also includes every 3rd party who is involved. In HUPILL’s case, it’s the accounting team. Don’t wait or assume that it’s the product owner’s role to coordinate teams. Yes, they can do that, but you can also make their and your life easier by doing that on your own. This will speed up the process.
You are responsible for enabling people. When you see that some part of the feature is stuck because X is waiting for an answer from Y, it’s your responsibility to make sure that they get this answer. Don’t read this as micromanagement, but just keep an eye on the things that happen or don’t happen, make sure you all have transparent communication, and act if you think you can help and speed up the process.
🏋️ Last 20% push. It’s great that this feature has you because you will make sure that the last 20% is completed. We can apply the Pareto Principle to feature development and say that you will most likely develop 80% of the feature quite fast. But the most important part, the last 20%, will take longer. This is not a linear process.
This feature needs you to lead all the involved parties through this 20%. Usually, most of the functionality is done, nothing major blocks you, but there are lots of loose ends: missing translations, waiting for a sign-off, which color should that button be at the end? You are the one who will help your team to make sure they are not stuck and all of these questions will be answered. Let’s do that push and celebrate the feature release together!
🔥 Promoting your feature. Okay, now it’s finally delivered and you can even see it on the dashboard. Have customers done what you expected them to do (almost ;))? Is your job over? Not really. If you want to efficiently close this feature-leading cycle, then you need to promote it.
I’m sure you, your product owner, and your peers know that your feature is great. But does the company know? Or maybe even the internet community? You did a great job and I’m sure you learned a lot during this feature development. Give back — share your learnings, measure numbers, find interesting statistics, say “thank you” to everyone who was involved, make them feel important. Do it publicly, do it in a way that more people know that you did a great job.
Tools to help
We know where you can make an impact and help deliver features. Now, let’s explore what you can specifically do to achieve that. In the following sections we will closely look at each impact area and explore tools which will help you to make that impact.
🛏️ Let’s add more context to the HUGPILL’s case. Usually, when feature development requires or assumes the role of a dedicated feature lead, it also means that more than one person will be involved in delivering the feature. In HUGPILL’s case, this includes you, software engineers from your team, your product owner, and the accounting team, which is responsible for the bookkeeping of HUGPILL.
🔮 Feature scope
First thing you need to do is to understand the feature yourself and confirm that you understand it the same way as your product owner (or other stakeholder with a similar role) understands it. Now you have two people thinking alike. Believe me, this should not be taken for granted. Now you can start your work on feature scoping.
Phase II. Phase II is a magical place, which we also often use in software development, by putting there things, which we want to do later. When we develop any feature, we assume that it will bring good to the customer and, consequently, bring good to the business. We might want to do as much as we can and then release it. But everything we have before it’s delivered is an assumption. We assume that when we allow customers to pay through Stripe, then sales will increase by 15% and the number of payments resulting in problems will decrease by 40%. Will the real numbers be higher or lower than expected? We will only know after the delivery. This allows us to say that our business is interested in case we deliver it sooner. What can help us deliver it sooner? The less we have to implement, the sooner we will deliver.
It is more important to launch the feature and start measuring whether our idea was right or not than to delay the product launch in favor of perfectionism.
The Phase II trick allows you to deliver faster. If your team has good ideas but you think that the current scope will already help the customer or business, suggest putting these ideas into the epic called “Phase II”. This decreases the cognitive load and keeps everyone happy.
Constraints. The more constraints you have, the better it is for your feature. Having constraints makes it easier to say NO to something and to make decisions about how something needs to be implemented. These constraints can be both technical and non-technical.
The most common architecture constraints are:
Cost
Quality
Time
Scope
Technology
Risk
Resources
Compliance
For example, at HUGPILL we have a technical constraint that requires us to use PostgreSQL as our main database engine. This makes it easy to decide which database we will set up for our feature.
Critically assess the scope. What is the reasonable functionality that still brings benefits to the customer but allows us to receive feedback sooner? Let’s focus on that. It’s your job to challenge your stakeholders and convince them to move something to Phase II. This way, we can deliver faster and learn from the data. It’s their right to reject your offer, but at least they are informed of what it means.
🛏️ In HUGPILL’s case, there is a requirement to provide real-time information about orders to the accounting team. They say they need it to keep their bookkeeping up to date. But you know that they only do it at the end of the month. After you’ve confirmed this with them, they said that the described thing is an ideal solution. And they are fine if you just provide the export of the orders for the last month once a month. This makes your feature scope smaller and allows you to deliver faster.
You need to keep doing that for each suggestion that is on the table for the feature, whether at the beginning, midway, or end of the feature development.
⚙️ Development
We analyzed the feature scope and are quite sure that we understand what needs to be developed. It’s fine if we do not have a complete understanding, but we know where to start and what our target is. This is enough to start developing the feature.
At this moment, we already know that development itself is not the most complex part of feature building. It is an important part, and without development, there will be no feature, but it’s only one variable of the complex equation. Our strategic goal, as a feature lead, is to make sure the software implementation of our feature will a) help our feature to go live; b) will not make our overall software realm worse than it was before we implemented our feature.
Here are the tools that might help us.
Stability & Throughput. Stability and throughput are two metrics that help you measure the health of your software engineering. Your software engineering process should be organized in a way that you often release software that does not fail. These metrics can be further decomposed into the Four Key Metrics (or DORA metrics).
What does it mean for you and your feature? As a feature lead, you need to make sure that any software or architecture decision you make during feature development will not negatively affect these metrics. Otherwise, it should be an informed decision that you should not make alone. It’s better to have a consensus within the team or engineering.
Does your team want to try out a new framework for this feature? Okay, will it boost your speed or slow you down? Will it increase stability and throughput in the long run? You need to have these questions answered.
Incremental architecture. Do not expect to solve all major engineering or technical debt issues together with feature development. Yes, they still might need to be solved, but as standalone stories or projects. It makes no sense to try to kill two birds with one stone in this case; you won’t kill either of them. Focus on the feature and remember about the boy scout rule.
It also doesn’t make much sense to try to foresee how your solution can be extended in the future and, because of this, set up the most abstract architecture you can think of. Be practical, build things that are easy to maintain and extend. Make many small decisions rather than a few big decisions. This way, you reduce the blast radius of the one that you might take wrong.
This is the concept of incremental architecture. Do not try to make radical changes; take small but confident steps, and this way, you will drastically increase your chances of success.
Be prepared to measure. I bet that the feature you develop is designed to improve things. But how would you know if it did or not? It’s not always obvious. In the end, your feature is an experiment, and the results can validate the initial assumption or prove it wrong. As a feature lead, you are interested in knowing the results of this experiment because it will provide you with more information, and with more information, you may make new decisions.
Be sure to integrate feature telemetry measurement into the software solution part. Define business metrics and track them. Write logs with the information needed to measure, make these metrics available for your Prometheus scraper or else. Prepare dashboards or reports. This is something that should be done during the development stage and should be ready before your release. Take accountability that you will make sure this part of the feature development is present; this is your job.
🛏️ In HUGPILL’s case, your team member suggested using Go lang to create a new microservice. You had a meeting with your team where you discussed this suggestion. The fact was that all 10 microservices were developed with Kotlin, and there was no unique problem in the feature that might have been solved with Go. So you decided to keep using Kotlin and talk about the Go topic again when there is an appropriate problem.
During development, you oversaw that the most important business metrics (for example, each order paid with Stripe) were logged. You prepared a Kibana dashboard where these metrics are displayed in real-time. On the dashboard, you were able to see the percentage of orders paid with Stripe compared to other payment methods.
💬 Aligning with 3rd parties
Remember, at the beginning of the feature leading journey, I said that you and your product owner should make sure you both understand the feature the same way. It seems obvious, but in fact, this should not be taken for granted. People may not always understand things the same way. As a feature lead, you should ensure that everyone involved in the project understands things the same way. This will help the feature to be delivered in different ways, such as increasing people’s commitment, fostering collaboration, and speeding up feature delivery. Let’s see how you can do that.
Leaving the artifacts behind. It’s important that at any point in time, people who work on the feature can open a document/issue/slack message and confirm that the idea they have in their head is true or false. When you start working on the feature, there will be some documentation, but definitely, during the work, you and your team will come to new conclusions. These conclusions need to be recorded.
Whenever you have a meeting or a dialogue and make a decision, make sure to inform other people about it. This can be a message in Slack with the meeting notes or the decision’s log page in Confluence. Just make sure it’s present, and all involved parties know where to search for such stuff. Also, be proactive and point people to such artifacts when they ask something. This way, your group will naturally learn to be independent.
Overcommunicate. Communication is hard. It’s often not enough to tell somebody something and consider that they understand it in the way you expect them to understand. But it’s also quite simple. If you want somebody to understand something, you just need to tell them the idea more times than the times they do not understand.
Overcommunication does not mean repeating the same message again and again. Good overcommunication means communication over different channels. Let’s say you discussed the feature architecture with your team, and everyone said that they are fine with it. What can you do more? Draw this architecture, put it into Confluence, and share it in Slack. Ask your peers if they have any objections.
Make people feel heard. It is important to give people a feeling that they are heard. For the persons themselves, it is actually even more important than seeing that their ideas are accepted. If people are heard, they have a much higher commitment to the project.
How can you do this? Easy, you just need to validate their thoughts from time to time, show them that their suggestions are valuable. When somebody says something, you can repeat it or write it down. Sometimes there will be something more out of it. The idea can influence the feature building or may not. Both are fine.
All of these tools lead to good, established, and transparent communication, which strengthens collaborative work.
🛏️ In HUGPILL’s case, as you remember, there is your team and the accounting team. In order to facilitate communication, you may organize a meeting with the accounting team where you discuss all their expectations (write them down, so they see it). Then, you, together with your team, initiate the solution, one that covers most of the accounting team’s expectations. You put that suggested solution into Confluence and ask your team to check it. After you see that there are no complaints, you present it to the accounting team and receive their feedback. This cycle continues until both parties agree on the solution, which is meant to be implemented.
One more thing — do not be afraid to reach out to people. Everyone loves when they see someone who takes responsibility and tries to solve something. They will be happy to help you on your journey. If somebody does not respond to you, there is a magic phrase “Hello, friendly reminder, can you please have a look at…”. Communication is the key to any problem resolution.
🏋️ Last 20% push
When people work on something, there will be progress. You will see things moving forward and there will be more and more substance to the new feature you are working on. However, reality shows that this process can also go on almost indefinitely. Eventually, things need to be finished, and the skill of finishing things is not something that everyone has from birth. It needs to be developed.
Your feature will most likely not be an exception to the 80/20 rule. You will quickly reach the point where most of the work is done, there are no blockers, but there are still loose ends, and everything needs to be put together. Let’s see what can help you do this right.
Checklist. Checklists are a great invention of mankind and are already used in different areas, from something as simple as grocery shopping to something as complex as surgeries. They can also help us in feature leadership.
When you see that you are relatively close to finishing the project, but there are still loose ends, you can gather a meeting and help your team align on what needs to be done. Ask everyone what they think needs to be done, usually these tasks will be quite small, write them down, and together decide who is responsible for each task. Assign responsibility. This is very important, as collective responsibility is the responsibility of no one. Put this information on Confluence as a “Pre-release activities” page and make all of these tasks into a checklist. That’s it. Now your team knows what to do and who is responsible for what. You can still add things to that list as soon as you discover more.
Release roadmap. A release may be as simple as deploying to production, but it can also be a more complex procedure where you need to coordinate the release of your feature with other teams or real-world activities (for example, sending out an email).
It is important to write down the specific sequence of steps that you and your team are going to implement in order to release the feature. Again, you can call a meeting and brainstorm what it should be, who does what, and when. Put it on Confluence and follow it on the day of release. This will make everyone, including you, more confident in the security of your feature release.
When working on the release roadmap, it will also be helpful to do a risk assessment. What could go wrong and what will you do if it does? Being prepared for the worst does not mean it will happen, but it will make your life much easier when it does.
🛏️ In HUGPILL’s case, you saw that there is a working prototype on the integration environment where customers can indeed pay for their order using Stripe. But there were some things missing. You gathered a meeting and identified that you are missing Stripe production account credentials and translations for some locales on the website. You formed a checklist and assigned people to resolve these issues.
Then you worked on the release roadmap. First, you drafted it yourself and put it on Confluence. Then you presented it to the team and received valuable input that it would still be worth checking if it works on production by doing an actual payment on the prod environment — a good idea. You added it to the roadmap as a QA gateway. First, you will deploy it to prod under the feature flag, and this feature will only be available for certain cases.
It’s 11:00, and you start your final prod deployment. By 11:05, everything is live. Your QA team does the prod purchase, and you see it on your Stripe dashboard. The QA gateway has passed. You enable the feature for every customer. By 11:30, you see that there are already five purchases through Stripe. You smile. You did it. Your feature is live 🎉
🔥 Promoting your feature
It is live! You can even see that customers have started to use it. Isn’t that great? Yes, it is, but do you know what can bring you and your team even more positive emotions? Appreciation. Appreciation is one of the motivational factors that keeps most of us fulfilled. Yes, we can understand ourselves that we did our job well, we can even back this feeling up with numbers, but it’s still satisfying when others tell you that what you did was important. Promoting your feature helps you and your team get more appreciation. But it also has another effect — it increases your visibility.
Working on your visibility is a safe investment for your career development. We cannot say that modern career development in IT is completely based on meritocracy principles. And I like that. I think it’s healthy to expect that it’s a good software engineer’s job to make their work visible. Let’s see which tools can help us achieve this.
Demo. I believe most companies are already working using agile practices, and sprint review is one of them. Take the time to prepare a demo of your feature. It can be live or it can be recorded. It’s up to you to decide. Nowadays, I prefer the recorded ones because, in a remote setup, our work life shifts more and more to asynchronous communication. Record an end-to-end video of the thing you’ve deployed, add some energizing background music, and share it within your company. People love to consume information this way and will pay you back with useful feedback and appreciation.
Make other people visible. Say thank you to everyone who participated in the feature development. Make it public, make your thank you specific. I bet you had cases where somebody walked an extra mile — appreciate that. Write a message to the public channel, telling that you have released your feature and these people or teams were working hard to make this happen. Everybody loves to be noticed, saying “thank you” is a super healthy habit.
You can also do it in private. We, at SHARE NOW, are using Officevibe to facilitate connection between employees and the company, and there is a tool called “Good vibes.” There you can send a card to your colleague, telling them what you appreciate.
Collect fun numbers. As good engineers, we aim for anything we release to be measurable. I’m sure that at the moment of the release, you already have your dashboards prepared, and you can see in real-time how the feature is performing. Having numbers allows us to make both direct and indirect conclusions. Does our feature perform the way we expected it to? But we also may have fun with numbers by collecting data that looks interesting but does not necessarily mean anything by itself. For example:
The most expensive and least expensive order paid by Stripe
In which city people are paying through Stripe the most
During which hours the number of payments peaks
These are the numbers that you can share with anybody within your company, and they will cause some positive emotions. People who have received these positive emotions will tie them to you as well.
🛏️ In HUGPILL’s case, on the next day of the release, you posted a Slack message to the #general channel, telling that the long-awaited feature was released. You provided a quick summary of what is covered and thanked Sebastian from the accounting team for their effort in the team’s alignment.
As well, in the regular weekly meetings your product creation department has, you demoed a recording of your feature usage. So that the whole company saw how convenient it is now to pay through Stripe. You also presented the numbers for the first week of the feature usage and confirmed that your initial estimations regarding the performance are so far right. The cost of the most expensive order was €2,000, and it was a lady from Bremen.
Post release activities
Ok, now you think you’ve done everything, but what about post-release activities? The feature is there, so let’s relax! You’re right, but only partially. Let’s think about how else you can benefit from being a feature lead.
As we’ve discussed before, being a feature lead can be a stepping stone in your career development. Regardless of your current plans, it’s better to have facts that may help your career development, rather than just fond memories of executing the feature lead role. Let’s leave artifacts behind.
Ask for feedback. You did your job, took accountability, and released your feature. That’s a fact. But you can ask for more facts. Ask your peers how you performed. The simplest questionnaire may look like this:
Rate from 0 to 10 how I performed while leading the feature development.
What did you like about what I was doing?
Where can I improve? What could have been done better?
Field for any additional feedback.
You can create a Google form and send it out to the people who were involved. It makes sense to do it no longer than two weeks after the feature release. You might also remind people that you would appreciate their response, so you can get more feedback.
First of all, these answers will show that people recognize that you did a great job. They might also provide some food for thought regarding your own growth. With artifacts like this, it is much easier to negotiate a salary increase, promotion, or, in general, speak about your performance with your manager. And not only that, you can also use this information as proof of your achievements when you look for career opportunities outside of your company.
Conclusion
I hope I have shown you how fun, challenging, and useful (both for you and the company) the role of the feature lead can be. I strongly advise you to try it once or, for more senior engineers, to regularly perform it. Together with your professional development, this role will become more and more natural for you, but its importance will never diminish. Taking accountability is the most important skill one can possess, so it will never lose its value.
When you are trying to remember one thing from this article, I would love it if you choose the following: the main task of the feature lead is to deliver the feature to the end customer and nothing else!
Please share in the comments which other traits a good feature lead should possess.
Follow me on Twitter if you want to read more stuff like this and more.
Top comments (0)