iTranslated by AI
The Day My Peer Became My Subordinate: The Reality of My First 90 Days as a Tech Lead
I was appointed right after the system launch.
The vendor completed the handover with a comment implying, "From now on, you're the tech lead." Internally, I thought, "Well, that figures, there's no one else." I accepted it coolly. I didn't let it show on the outside.
From that day on, I put on an iron mask.
The Discomfort of Moving from Peers to a Hierarchical Relationship
When I first joined the company, there were three of us, all peers: myself, a junior member, and a very junior member. We were all receiving training from the vendor.
After we became independent, I ended up taking on the roles of both Tech Lead and supervisor. The junior member took on operations management, and the very junior member focused on training—a clear division of roles.
The person who was a peer yesterday became my subordinate today.
What was difficult was that even though the roles changed, the "personal relationship" remained the same. It is not easy to suddenly become strict. But as the "Tech Lead" position carried responsibility, I had to do it. It was something I wanted, and I decided to do it.
That was the beginning of the iron mask.
The Inverted Requirement Flow
Once the structure was set, I noticed a structural oddity.
Usually, requirements come down from the top. The business side or a manager says, "We want this feature," and development implements it.
But my environment was different. The junior member performed requirement definitions as the business contact, which then came down to me, and I would implement them. Even though I was supposed to be the technical lead, in terms of the workflow, the junior member was upstream.
I think it was awkward for both of us. Even I wasn't used to it at first. The relationship where "the other person hands requirements to me" was established with someone who had been my peer just yesterday. It took a while for that to become the new normal.
Nobody Taught Me
There were no seniors who told me, "For the first month, focus on understanding rather than changing things."
There was no guidebook either. While there are books and articles about how a tech lead should operate, whether they apply to "my team's current situation" is a different story.
In the end, I had to do it myself.
What I Did First: Read Code, Scanned for Vulnerabilities
Technically, the first things I tackled were code comprehension and vulnerability assessment.
I read the code extensively. The system handed over by the vendor was not designed by us. If I didn't commit to memory what was doing what and where, I couldn't make any decisions. Reading code was the bulk of my work during this period.
In parallel, I performed vulnerability assessments. npm audit, dependency package vulnerability checks, and configuration reviews. Since we were handling a system in a regulated industry, I felt that grasping the security status could not be put off.
The diagnostics revealed several issues. Whatever was found, I fixed. This was the first time I executed the cycle of "grasp the problem, fix it, and move on."
I didn't do anything dramatic. But this was my first job.
Understanding "What is a Tech Lead" While Doing It
Three months in, I have come to understand things little by little.
The job of a Tech Lead is not "being the person who can write the most code." But it is also not "not writing any code for the sake of the team." At least in my environment, it was a role where I created a state where the team could move forward while writing code myself.
It was tough not having a guidebook, but I don't think I could have done it the same way even if I had one. With only three people, a system just handed over from a vendor, and an inverted requirement flow—that combination was unique to me.
I had to come up with the answers myself. That hasn't changed even now.
Read other articles → taka-techblog.com
Also active on X → @_taka_tech
Discussion