From Developer to Technical Lead: Introspection and Lessons Learned
I have been a technical lead on a complex multi-team project with another co-worker for the past year and a half. Typical days range from calm sailing to absolute chaos, with multiple fires burning simultaneously. Below are some lessons I learned and some tips that kept me sane and helped us deliver on time.
Architecture and Code will be Imperfect
One of my struggles was getting stuck in thinking about how I could improve our codebase and application architecture. As a developer, I take pride in software craftsmanship and quality. I constantly measured the quality of work against my standard and forgot the evaluation came from years of design and development background. Insights that naturally come with experience are not always intuitive for a team of young developers. As a result, I lost sight of the remarkable improvements that my team had been making.
Requirements and priorities change. Today’s “perfect” architecture and code might not be relevant next week. These artifacts are a means to achieve organizational goals, so they should be evolvable. As long as they maintain some modularity and are mostly loosely coupled and reusable, it is okay if the solutions do not have the exact shape we have in mind to be able to deliver. Instead of dwelling on quality in less critical areas, it is more scalable to guide and trust the team to figure out the how.
As an individual contributor, I have no official management authority but am still responsible for the output of the people I work with and the successful delivery of a project. Meanwhile, my personal output, if measured by merged pull requests, had been the lowest since I’d become a developer. It took me a while to realize that saying, “You got this. Here are the resources and information you need. I’m going to be here if you need help.” empowers others to learn and take action. When things finally start going in the right direction to align with our technical vision, it is kind of heartwarming.
Autonomy Is a Perk, But Overcommitting Is Not
Being trusted to create my magical backlog of work based on the current product priorities is satisfying. But knowing what is impactful and choosing the proper scope and granularity to focus on is tough.
My archetype in the current team that I work with is a mix of tech lead, architect, and solver. The project team comprises two two-pizza teams, both relatively unfamiliar with the tech stack. Some members were new to the organization. The legacy membership system we are modernizing manages a core part of the business at AMA. Many applications spanning multiple domains within the department integrate with it for specific business operations.
With such an intricate problem space, I get pulled in a million directions daily. Everything has an opportunity cost—spending time preparing a proposal about improving the robustness and scalability of our software architecture takes time away from PR reviews and unblocking the team. But if I became overzealous with technical direction and gatekeeping, my team would miss out on valuable learning experiences.
Sometimes it is a struggle to decide when to step in or to stay above the water.
As a veteran individual contributor, I stay aware of suboptimal things around me: architectures that will not scale, processes that are detrimental to the team’s health, opportunities to try something new etc. However, doing everything is not sustainable. Hat tip to my manager for reminding me that my time is valuable—it does wonders for my health to delegate when appropriate and focus on things I am uniquely positioned to work on. Delegation is hard because powering through any problem has been my default tool. So this is one of my career goals for the year.
Technical Challenges Are Far from Being the Only Problem
My consulting years have taught me one concept well: nothing is ever only an IT project. Consultants often wear many hats to help clients succeed, and being a technical lead amplifies that notion. Contrary to consulting gigs, projects or initiatives do not “end.” There is always more maintenance work, more big-picture context to absorb, and even more rough terrain to navigate.
Writing code and creating brilliant solutions are only part of the success story of a long-running cross-disciplinary project.
Additional concerns include ensuring user stories have the right level of technical detail, explaining how certain architectural decisions fit into the overall vision, convincing other groups with competing goals of our priorities, or collaborating with team leads to identify necessary processes and cultural changes.
Alas, unlike debugging, getting feedback about whether my work has any effect can take weeks or months. Nonetheless, I am responsible for the final result as a technical lead. That means I need to consider the entire problem and do other tasks that will drive things forward but fall through the cracks if no one steps up to bring attention to them.
Final Thoughts
My journey to becoming a tech lead has been filled with exciting challenges, and I am blessed to have a great support system of leaders and peers at work. Besides, seeing a team flourish and be recognized for reaching vital milestones is incredibly uplifting, as it shows my perseverance and the grey hairs on my head have genuinely paid off.
Winnie Ho is a Senior Software Developer @ Alberta Motor Association who has an insatiable desire to learn, read and write about all the things AWS and the web.
