My Journey as Tech Lead : Lesson Learned (Final Part)
This article is part of my series “My Journey as Tech Lead” where I share my experience as Tech Lead on creating technical foundation for my team. What kind of challenge I have to solve and my thought process to solve them.
You can follow this series from the start by going into the link below.
My Journey as Tech Lead (Part 1)
Every ending of a journey is a beginning of a new one
Along my journey as Tech Lead, I have learned a lot of invaluable lessons that shapes me into a better person.
I have the opportunity to sharpen my technical skills. But more importantly, I learnt a lot of non-technical skills such as Leadership, Management, Communication, Team Growth.
It has been 2 year since I start this journey. And now the journey ends and a new journey is a bout to begin. I am taking a new role with more responsibility and more challenge.
I will conclude this series by elaborating some of the most insightful lesson I have learned, and how to use that lesson to better myself.
Use Written over Verbal Communication
One of my biggest failure during the journey is my inability to transfer knowledge that I have into team member.
In retrospect, I realize the reason for it is because I rely more on verbal communication over written communication.
Verbal communication is fast, but highly subjective and prone to human error. Human memory is a fragile thing, we forgot thing easily.
Written communication takes more effort to do, but is more resilient to miscommunication.
I consider chatting online as a form of verbal communication. Because we cannot revisit chat log easily compared to accessing written documentation.
In my new role, I choose to write all of my though process and knowledge before discussing it verbally.
Multitasking is bad, but sometime necessary
One of the challenge during the journey is running multiple product line at the same time.
In retrospect, it was a bad decision because it prevents us to focus and put more attention into detail. In later phase, we decided to merge the team to focus only on one product.
Multitasking is generally bad, but there are times when it was truly necessary. And I experienced one of the extreme case for this.
On my busiest day, I have to manage 14 responsibilities at the same time.
- Supervise 3 product line development
- Supervise tech integration for 3 different business partner
- Supervise gauntlet team development
- Supervise 3 intern crew for gauntlet
- Supervise gauntlet porting to ios
- Support automation test research
- Supervise analytic tool research
- Be presenter for programmer knowledge sharing
It was the craziest time that forces me to push myself above my limit.
I am happy to experience those kind of moment when my productivity goes through the roof. But it was also the moment that scrape away my sanity and creates tremendous pressure.
In my new role, I create a centralized of To Do list and limit myself to only focus only on one task per hour, and at most 3 task per day. So I can be productive while also keep my sanity during busiest time.
Learning is Never Ending
When I join Agate, I have confidence that I know everything about game development.
I know exactly what to do and how to do it. However, after discussing with other people in Agate, it turns out some of my assumption are wrong.
So I have to understand other people approach and adapt what is good from their approach into my work. It was a very important lesson for me. To always learn from other people, even if you think you already know it.
In my new role, I always start asking people opinion of a problem that I encounter when I am not sure of what I should do.
Leadership is about Delegation
Leadership is hard, very hard. You are expected to be reliable on solving every problem.
Before starting the journey, I prefer to solve the challenge by myself. Mostly because I think other people cannot do it better than I can. It was based on arrogance.
Those thought are unhealthy and dangerous. Because you will get overwhelmed very quickly. No matter how good you are, you have limited time and energy.
And so, I realize that the most important part of being a leader, is to be able to delegate responsibility to other people and accept any consequence from it.
Delegation looks simple on paper, but it is very hard in reality. To be able to delegate, you must be able to communicate your Goal. That requires good communication skill.
You also need to check it periodically to make sure it goes into the right direction.
Most importantly, you have to accept if the result is not as good as you expect. It contradict my idealist ego, and force me to have a balanced weight of idealism vs pragmatism.
Because of that, I always think how I will delegate a work whenever I receive a new goal.
There is a cost to everything
Most of the responsibility as a Tech Lead is to take a decision and be responsible for that decision. Being a decision maker is hard. It creates a lot of burden to made the correct decision.
You need to be able to really understand your purpose and understand that every decision have a cost. Every decision have a downside and upside. And we have to assess which one is more preferable to our situation.
There is one case when I decide something, and believe it was the correct decision. Suddenly, there is a technical issue that make us failed our target. This caused the team to assume the decision is incorrect. But I stick to the decision, and explained why it was the correct decision, and why we should stick to it. It only require one week to turn the table and give solid proof that the decision is indeed correct.
The tricky part is to communicate the impact and the cost of your decision to the team, so they can also understand that the downside is expected and not an error in decision making.
Thank you for reading the series until the end. I appreciate anyone who have followed this series. Hopefully this series can provide insight and help you in your work too.
