Things that I’ve learned after 3 months as the technical leader of a project

4 min readDec 18, 2020

Enjoy the journey while going to your destinations

3 months ago, I have taken the role of Technical Leader of a new and important project for my company. This is the first time for me and I very appreciate the journey that I have had with my team as well as with the product, even it just the beginning of the road. And today, we had the first demonstration of a product to stakeholders as the proof of concept for an important project of my company, the demo was good when it has achieved the required functionalities and designs.

From the start, I’m really confident about the team because we have the best people. But due to some unexpected missions, people temporarily have left us, the architect, the developer, and then DevOps. 4 days ago, I cannot imagine that we can deliver the demonstration on time, there are many things to do, from the programming to DevOps tasks to configure and deploy the product to the sandbox environment. Let me share with you some lessons that I’ve luckily had a chance to experience.

1. Teamwork is a very important skill

Yes, this term has been mentioned many times. But depending on each specific context, applying it is not easy. For my international team, we are trying our best to make it works. We need to coordinate smoothly among members: PO, BA, Designer, and developers. By doing daily or weekly meetings, or documenting as much as possible, pair programming, etc.

Delegation is one of the keys, giving the chance to the right people at the right time can bring awesome result. So, give the land for people to show their abilities and you will see the miracle.

2. See problems as challenges and solutions will come obviously

As I mentioned above, we have encountered a lack of people in the team, and with 2 developers, we need to do architect and DevOps tasks to build the development environment. But we have seen them as the challenges and the opportunities to do more things than only programming. The keys are communicating and studying. We need to ask and exchange with experienced people in other teams and self-taught the new knowledge to do the software architecture and Ops tasks. And the positive result has come with us, we success to do things, not the perfect ones but they good enough for the project requirements. IT WORKS!

3. Choose a good enough solution

There is a regret thing that I have figured out that we have chosen the technologies too earlier when doing architecture for the software. And the reason was we want to use the new technologies for the new project. Of course, applying modern materials is good but depends on the priorities. We have only 2 months to ship the MVP version and with new technologies, we lose time to learn and not sure that we are doing the right practices the tools.

Moreover, when designing the software, I’ve learned that we should leave the choices for detailed technologies as delay as possible, that we can focus on implementing business and have more inputs for these choices later.

4. Prioritizing works is really important

There are many things that need to do when building software from scratch: coding conventions, document, development tools, etc. But with the teamwork, we need to have a plan that lists all the TODO tasks and prioritize them, then people in a team can understand clearly the roadmap, why they need to do things, and have better organization for their work as well. Otherwise, the team will become a mess step by step.

And scoping the result of tasks is important too. As developers, sometimes, an issue requires just 1 but we do 2 or even more. So, as the technical leader, I need to define explicitly the context, inputs, and outputs of a task. And exchange usually to be sure that we do not lose time for the fewer priority things.

So, keep the focus on what we need to do and ask your question every day that is your team doing the TODO tasks.

5. Keep learning and sharing

The more you know, the you will see yourself as smaller. So, keep learning from the colleagues, by reading books (I’ve read Clean Architecture from Uncle Bob while doing architecture), by the internet, etc. We are in the digital generosity, we have many resources to learn, the point is you need to define what you want and pay focus on it.

And keep sharing, of course, a strong team is made from strong members. The knowledge of the project needs the be shared across the team, everyone in a team needs to be able to explain or handle any specific part of the software. If not, your team will face the Bus factor issue.

I’ve just shared with you some bullet points that I’ve learned. Again, keep learning and experimenting. The project is still in the MVP phase, there are many challenges for us ahead. See you in months later. I hope I can share with you the road to success of the project at that time.

Keep calm and enjoy your journey!

You can reach me at: