Why is it important to say no as a leader

From the very beginning of our life, we have learn that the word ‘no’ is negative. But learning when to say it to be focused in what is important can be very positive in our life, specially if you are a programmer and have to be in constant communication with your clients or your team leader ask you to develop a feature.

As a software developer, we face not only syntax and logic challenges but client communication. This is crucial because some times, your client will ask you for features that will take a lot of time and will not add value to the final product or are not the aim of the application.

If you face a situation similar to the mentioned above, you have 2 options.

Develop the feature. Say no.

Why should you say no? Isn’t it what my client wants? Isn’t it his/her software?

Of course it is. But there is also time and money through.

Your client is investing resources in something you determinate will not add value to the product and even knowing that, you proceeded with the task.

So, how should you manage situations like these? We are going to say no, but arguing why.

As a software apprentice in Pernix, we have to develop applications in a period of 6 weeks. These applications are called MVP (minimum viable products). As the name suggest, these applications are meant to do the minimum but with a special feature that will give a big value to the final product.

6 weeks is a very short period of time, we have to be agile and very focused in what is important. Sometimes the client wants features that will take a lot of time to be developed and will not add a real value at the end of the period.

This is why we have to identify what is the aim of the application and put our efforts in this features.

In one of the project I was, a client asked for a chatbot implementation that would take the entire 6 weeks if we have agreed to develop. The main feature of the project was to develop a CRM with social network implementation.

So we put on the table 2 options. We develop the chatbot or the CRM.

Fortunately, the client got our point, and decided to implement the chatbot in the future and put our efforts in the CRM.

This would be very different if we would agree in developing the chatbot. We wouldn’t be able to develop chatbot and the CRM neither.

At the end, we managed to develop the CRM functionality and the client was happy with the final result. We learned to focus on 2 main functionalities and develop them as good and fast as possible.

This method would sound familiar if you use Scrum as your development methodology. In Scrum you have to take a task and accomplish it on a sprint period. If you find out that your task will take longer than you thought or you realized you are developing a completely different feature, always keep in mind, what was the task? What was the aim?

In short, identify what is important in your project and learn to say no to those features that will take a lot of time to be developed and will not add value to the final product.

Happy coding :)

References

This story is published on Data Driven Investor, Medium’s fastest growing publication followed by entrepreneurs, investors, and curious intellectuals.

Join Us. Stay alert of Top Stories Here.