A brief story of why i’m ended up being a team leader
To be fair, i don’t really know why that happened either. And what i’ve experienced seems to be called an “unintentional situation”. Because at that time, personally, i didn’t really want to get into managerial or leading a team quickly, but after getting challenges from higher-ups and some kind of persuasion, i’ve decided to accept it. Although i’ve still had some considerations about why im hesitant to take it due of i just joined the company less than 3 years and i really don’t understand about nature of how mobile app development work 😅.
If i remember vividly, back then the condition of my team at that time was staggering. After we underwent major migration for our mobile apps and re-wrote to Flutter within just 3 members since last 2022, we still need some time to do some migration for missing features and not to mention that we also need to do feature development, accept ad hoc requests that come from stakeholders, fix all issues based on complaints from users as well as technical debts.
Distinguish between Tech Lead, Team Lead, Product Manager
At first, i was confused about the differences between tech lead, team lead, and product manager roles. Although they do have similarities, in practice, their responsibilities can overlap and it can be hard to tell who is who. However, in my experience, the biggest difference is in the in-person focus (such as being a mentor) and the scope of authority or responsibility. To illustrate this, i like to think of it as:
-
Technical Lead → overall task is to lead the technical aspect when we are going to make a new feature. such as making proposal documents, designing system specifications, code reviewers, mentors as junior developers, or matters related to hands-on code
-
Team lead → responsible for the productivity of the team’s overall performance. Starting from resources or manpower, delivery time and its estimates, standardizing the quality (alongside QA or PM to define it), resolving conflicts between teammates, having an open discussion, and also administrative tasks such as hiring, interviews, and handling user/customer complaints.
-
Product Manager → while the product manager is responsible for the whole product that we make, starting from the strategy for creating new features based on customer needs/demands or stakeholder requests, then transforming them into a task so that they can be developed until the process of the feature is released up to end users.
It’s important to note that the definition and requirements of each role may vary between companies, and there may be instances where a product manager is not necessary if the tech lead or team lead is sufficient, or vice versa. Additionally, in larger companies, there may be additional roles such as Engineering Manager, Delivery / Release Manager, or something else that sit above these positions in the hierarchy.
A lesson learned that was not meant to be
Looking back, i realize that sometimes unexpected moments or either my plan wasn’t according to plan at all. So perhaps through this experience, there are several insights i learned from the hard way.
Lead yourself first, the team will follow
In the first 3 months when i’ve had responsibility to lead my team, i just felt overwhelmed and wanted to blown-up. I don’t have the slightest idea how i am going to manage and navigate the team. Back then, the first thing that i did was all about leading myself first before shifting into a “servant leader”1
I need to know what drives me when accepting this position (for me, i drive by intrinsic motivation2), knowing what the goals and expectations are between me and my team, and starting to set the foundation so all of the other members know about my intentions. What i realized was that when i start made a change, starting with myself, i saw that my team was also slowly following what i was doing too. At this point, i can conclude that change doesn’t always come vertically, but vertical change that’s driven by discipline will grow into a small transformation.
Control things that you can only control
It’s true that when you are given more responsibility, your scope of contribution and control widens. However, it’s important to remember that you can’t control everything, especially when it comes to external factors like unexpected changes or the actions of your teammates. Your first priority should be yourself, your job, and your responsibilities before contributing to the team or the company as a whole.
If you encounter a problem that involves your team, it doesn’t mean that you can immediately overcome it all, and it’s not necessarily your main responsibility to do so. Instead, focus on what you can influence and resolve, and learn to let go of things that are beyond your control. This doesn’t mean that you should ignore the problem, but rather that you should approach it with a realistic perspective and prioritize what you can do within your power. Remember, that being a team player doesn’t mean you have to take on everything yourself, but rather that you work collaboratively with others to achieve a common goal
Over-communication is much better than no communication
Assuming that everyone understands a project or feature can be a reversal, and it’s important to avoid making assumptions in the work context related. From my experience and as a for example, i held a rule of thumb: it’s better to assume that a feature has not been tested, as there’s a good chance that it may have bugs. The relevancy of this analogy is, assuming that someone understands something can lead to ignorance and misunderstandings.
Everyone’s levels of understanding can vary greatly, and it’s our responsibility to ensure that everyone is on the same page and understands what needs to be done in order to deliver a project or product successfully. While it can be frustrating when team members ask repetitive or trivial questions, it’s important to remember that they may be seeking clarification on something. In fact, if my team members don’t ask questions, it can become a problem for me. Therefore, it’s crucial to take the initiative and ask team members for their input and feedback, rather than assuming they will always communicate their concerns to us first.
Don’t just delegate, be observant
The most common mistakes that i’ve seen from product managers/product owners or tech leads as long as i work with them is: they only delegate a task without observing it. I think this is a crucial part foremost, since there’s a huge possibility the person that we are assigned to them may not have fully understood of the requirements, or they didn’t aware of the progress that should be made.
And of course, all these things cost us in many ways: delays in work, release time, overlapping tasks to the next sprint, burdening other people who depend on them, resources, morale, and so on. In the end, you don’t need to observe them daily, just ask them about their progress, what blockers are happening, do they need additional feedback or help from us. After we help and provide them with what is needed, we can just go back to our main responsibility again.
Sometimes, all you can do is trust your teammates
Perhaps this statement might be biased if you got some negligent teammates, but there are times when you can only leave it to your friends and trust them. Maybe, sometimes they having a bad day, their performance is dropping or they are just not in the “zone” and that’s okay. All you need to do is just trust them that they will finish each other’s work. Even though it’s still inconsiderate if some of our coworkers take refuge from something that shouldn’t have happened to them (like self-proclaimed burnout, having a mental illness, and so on), remember what i said before: you can’t and you don’t have to assume in such a way if you yourself have never asked them first.
Having a better perspective on stakeholder requests
Previously, i used to feel frustrated with stakeholder requests that seemed unreasonable and inconsiderate. However, my perspective changed when i started working more closely with stakeholders and communicating with them directly. While there may be some misunderstandings between us, now i realize something that all stakeholder requests, no matter how difficult or confusing, are ultimately aimed at the sustainability of the company. As engineers, it’s our job to use our innovation and products to solve their problems and create value for clients, while stakeholders exist to ensure that the company thrives. In the end, we all have a shared goal of success and growth, and it’s important to work together toward that end
You can’t please everyone
In certain and extended situations, we cannot please both parties. either for stakeholders or your teammates themselves. Personally, for the past few months, my bias have leaned towards my teammates and seemed “humanizing engineers/developers” until i realized that there’s something more important than that: our real users. From there it started, even though it looks very unfair for my teammates (let’s say the deadline is very unacceptable which causes us to work overtime), our first priority is still the customer.
All of us should be aware of this. not just me as a team leader, from here we can also get used to saying “No”-words to things that really have no urgency for us. But it also needs to be noted, we can also say “No” to complaining users for example they only find trivial bugs that don’t happen to other users. Later on, we also seem to get used to and accept that there will be loud or opposing voices against us
The calmer you are, the easier it will be to handle the situation
Sometimes, there was a moment when it was a very overwhelming situation for me, and i felt like i wanted to explode and lose control of myself. Even though my gesture just changed a little bit, all my teammates started to notice this and eventually they also ended up being lost in the transition and composure. Taking a deep breath in a few seconds is indeed powerful rather than we are getting panicked, you are able to see things more clearly even though your thought process is still trying to digest every piece of information.
All you need to do is just ensure that you don’t lose the composure first (i know it’s hard), start picking up and sorting out several things that you can tackle, and if it’s still burdensome: write and write. just write everything or any information that you received. You might take a look at the second brain method for dumping any kind of unnecessary information at the moment. You might not be able to handle the situation quickly but rest assured it was a purpose to organize your thoughts and regain control of the situation.
Being empathetic is everything, but shouldn’t be the one
Being a team leader gives you an unexpected sense of empathy (or you can learn in an unexpected way) because we’re not necessarily able to feel what our teammates are feeling. It’s a hell of a process but the ability to understand each other will give you better communication and trust. That being said, empathy itself is indeed the most important but don’t forget that it’s also not number one on the list.
You should at least be able to analyze and understand situations when you are empathetic and when you have to be firm with others. For instance, you should know when we remind or give feedback to our teammates (do this just two of you, face-to-face) and when we should give them appreciation (in front of your teammates).
Know what things you shouldn’t apply for it
This is exactly what i’ve experienced right now. In the past, in the sake of “learning” and “out of curiosity” or just eager to learn everything, i will try many things without knowing the potential risks first (if we talk about learning in a positive way). However, as i began working with more experienced teammates, i just realized that being a senior or a more seasoned professional isn’t just about having more experience, but also about knowing when it’s appropriate to apply our knowledge. Sometimes it can be risky to apply something we know without fully considering the context and potential consequences rather than keep trying to implement it because we do know or have experienced it.
Wrap-up
At the end of the day, i found myself in a position where i was leading a small team that consists of 5 teammates of people to deliver a targeted goal successfully and being transitioned to lead a more growth team right now that compromised with 9 teammates. It was a challenging experience, but i learned a lot from it, i learned that this “unintentional situation” that give me a new responsibility to lead my teammates is not just about having the skills to lead a team, but also about being able to adapt to changing circumstances, staying calm and composed in a difficult situation, being empathetic towards each other and empowering your team to reach their full potential.
Personally speaking, this is one of the big steps for me. since ever been i working for over 5 years, and i feel like it’s time for me to take on the challenge of leading a larger team or even transitioning to a managerial role. I understand that some might say it’s too soon for such a change (premature transition), but who knows what the future holds right?