Introduction

Honestly, being a tech lead is not easy. You not only have to do your own work well, but also manage people, plan projects, and work on those projects. You wear multiple hats, and like being the middle of a sandwich, you can easily get squeezed from both sides if you're not careful.

During work hours, you spend time on communication, coordination, and handling emergencies. After work and on weekends, you still have to spend time planning work and maintaining your professional skills.

So, I've taken some time to organize and reflect on the things I've done.

Facing 'Meteor' Crises

When I joined the company two and a half years ago, it was right after the previous manager had retired and a group of engineers had also left. Everything was like a storm; new, urgent problems would pop up every week. Often, the work goals on Monday would be different from those on Friday. A super-high-priority project would appear out of nowhere every so often. To let others focus on their work, I always had to be on the front line, intercepting this storm of incidents. Since there was no one to coordinate, I had to negotiate with others on behalf of the team, even for unreasonable requests. Things got much better after I suggested adopting Agile development and helped my US colleagues implement Jira. At least our two-week goals became stable, and unless there was an urgent need, everything else was scheduled for the next Sprint.

Improving Recruitment Bottlenecks

To address the recruitment bottleneck, we didn't have a dedicated HR person at the time; an assistant handled HR duties part-time. I pulled them in to work on improvements with me, which included revising the company introduction and job descriptions on the 104 job board, replacing unclear images, and optimizing the recruitment copy and process.

Improving the Developer Experience

Since there's a lot to cover, I wrote a separate article about it+

Work Coordination

Often, users from different departments would request that we work on their tasks simultaneously. But with just a few of us, working on everything at once would slow us down. The constant context switching was painful, and everything felt rushed. For smaller tasks, if I could resolve them during my workday, I would help take care of them or find someone to assist. But when faced with larger projects, I would create a WBS (Work Breakdown Structure) to show stakeholders how long development would take, explaining that we couldn't do everything at once in a short period, and negotiated more reasonable delivery timelines.

Filling in the Gaps

To ensure projects went live smoothly, I helped clarify and break down unclear tasks or requirements. When tasks were left undone or dropped, I stepped in to fill the gaps because I cared about the outcome.

Recommending New Hires

In the past, it was common for one person to hold multiple roles in the organization. But as the scale of our work grew, one person, especially in a part-time capacity, could no longer handle all the responsibilities. Therefore, based on the workload and bottlenecks, I continuously recommended to management that we hire more staff: Engineers, an HR professional, a PM, and an MIS specialist.

Technical Initiatives

My regular workload was already heavy, and on top of that, I often received urgent technical requests. I had to use my own time to do some preliminary research on the general approach and execution plan before delegating them to interested colleagues. Examples include: the architecture for the German website, marketing automation, GA4, AI, and 3D.

Holding the Line

Along the way, I encountered some tricky situations. Many were small things I didn't really want to get involved in. But many small problems, if left unaddressed for too long, spread like the broken windows effect. In those moments, I would have a one-on-one conversation. For example: repeatedly breaking the checkout system, work output not meeting expectations, being unreachable during work hours, taking leave on a deadline and dropping work on others, issues with abnormal leave patterns, and arriving late or leaving early without reason.

Code Reviews / Work Reviews

When reviewing work, I had to find different ways to phrase feedback to avoid making team members feel uncomfortable.

Ad-hoc 1-on-1s

I would periodically take colleagues out for a meal or to a coffee shop to chat, to understand what they cared about, what difficulties they were facing, and where they wanted to go in their careers. I'd find areas of alignment between the organization's needs and the member's goals, and then coordinate with my own manager. For example: when someone got married and moved farther away, I helped negotiate one WFH day per week for them. If someone wanted to work on a specific project, I did my best to assign them that work.

Planning Career Paths

The new generation of developers needs a career Roadmap. This was something I proactively suggested to my boss after seeing examples online.

Recommending Salary Increases

For team members with excellent performance or outstanding contributions, I proactively fought for their raises and promotions.

• Probationary period salary adjustments
• Year-end salary reviews
• Positional promotions

Advocating for Team Benefits

• Secured extra perks, like attending a computer expo, which also served as a team-building activity.
• Arranged for extra vacation days for colleagues who successfully mentored new hires, based on results.
• Negotiated for additional WFH days based on a member's special contributions or performance.

Managing Up

• Proactively syncing on work progress. I believe every manager has information anxiety; if a long time passes without an update, they might start wondering what we're doing all day.
• For cross-departmental issues, resource shortages during execution, or feedback from team members, I would discuss them with my superior to seek help.
• Often, the new generation of employees cares about different things. In the past, we would just do what we were told. Now, it takes a lot of time to communicate, clarify goals, and translate them into a language that younger team members understand.

Areas Where I Feel I Fell Short

• When communicating with others, I sometimes replied too hastily. In reality, it would have been better to slow down, let things settle, and think a bit more.
• I was too protective of my team members. If I thought they couldn't do something, wouldn't do it well, or wouldn't like it, I might not assign it to them. Looking back, even failing is a form of growth, and I deprived them of opportunities for self-breakthrough.
• Taking on poorly done work that wasn't my responsibility. This is actually detrimental to the organization in the long run, as it allows the gaps to widen.
• I overlooked the influence of the environment. But perhaps due to my personality, there are some things I should have just turned a blind eye to.