Byte Tank

Pedro Lopes Blog

Learnings as a Software Engineer Techlead

YouTube video with a summary of this article

Life is growth. You grow or you die.

― Phil Knight, Shoe Dog

I’ve had the good fortune of having the opportunity to develop my software engineering work as a tech lead (which is not a fixed role), focusing more of my effort on solving sets of problems, as opposed to individual projects/tasks. While navigating this path, I’ve gathered a set of teachings from my mentors/peers/managers and other personal learnings and observations that I attempted to compile in a condensed list. Hopefully these can be useful in your own journey, just like other people’s learnings were to mine:

  • Planning:
    • Clear planning and prioritization of your projects is essential, especially in the early phases of an initiative. Well defined projects, with solid goaling metrics and well defined ownerships for each project, go a long way towards setting them up for success. These reduce the risk of not meeting goals, and allow for everyone involved to know which areas they need to tackle and own. Another interesting side effect is the value proposition to prospecting new-comers to support your projects, since there is a clear definition of what they can own and how valuable their contribution will be to the team/organization.
    • But don’t plan too much - healthy balance is the secret: if your organization is fast moving and dynamic, excessive planning can have the deleterious effect that little execution is actually done, since most of the time is spent planning.
  • Design Docs, Strategy and Vision:
    • Design Docs are a valuable vehicle to crystalize how a complex system or process can be implemented, they incentivize the owner to structure their thoughts, are made stronger by receiving feedback from peers, and serve as an exceptional piece of documentation that will not only explain how a given system/process works, but also serve a rationale on why they were built that way. Here is an example template from Google
    • Strategy and Vision - This reflection will be mostly based on this great StaffEng article, which I vividly recommend. If you realize that you’ve rehashed the same discussion three or four times, look into your organization’s objectives, find the commonalities from five of your organization’s design docs, combine all of these together, and you have material to write a strategy. When the future’s too hazy to identify investments worth making, grab five strategies, combine them with your organization’s objectives and write a vision for two to three years out.
  • Scaling oneself: The best way to increase impact is by scaling oneself. I’ve personally encountered my speed limit when trying to solve a critical-path project, while at the same attempting to set the direction for the team. As much as I worked, placed hours, or made the process effective, I was the bottleneck. I’ve hit a speed limit, and at the time it was made clear by my manager that in order to increase impact, unblock our team, achieve our objectives and have a balanced workload, I would need to scale myself.
    • Scaling through Delegation - the 75/25 rule:
      • If you are ~75% certain that someone will correctly execute a given project/task, then delegate. The other ~25% is the unknown space that the person needs in order to learn, explore, make errors and innovate. In other words, grow.
      • If you are 100% certain that the delegatee will successfully achieve a given project/task, they will not grow. On the other hand, if the probability of success is too low, then the project/task will be frustrating, probably will not be completed, and will jeopardize the team’s objectives.
    • By default, don’t micromanage:
      • When delegating a task/project, give enough space for the delegatee to own it. In general, the objective is to clearly define expectations, clearly define areas of ownership, and agree upon which details you should be kept up to date, which meetings you should attend, and in which situations you would expect to be pinged for escalations.
      • Micromanaging only makes sense in very specific situations, such as when there is a high possibility of a major failure and help is needed to firefight and course correct.
  • If you are not failing, you’re not pushing hard enough. And probably not growing: Conversely, the 75/25 rule can be applied to oneself. If you find you are easily executing your projects with a high level of predictability, this provides a hint that you should look for bigger challenges and responsibilities. In other words, aim for a growth mindset, rather than a fixed mindset.
    • Errors: Making errors is completely OK and expected. They are part of the ~25% above. Strive for them to happen only once, otherwise they will fail to serve their learning purpose.
  • Mentorship:
    • Give: one of the best ways to learn how to support projects is to mentor a new joiner. This will give you the opportunity to develop your interpersonal and project managing skills as you support/scope/prioritize projects and tasks for your mentee, and will help you consolidate your knowledge about the team and its position in the company as you transmit this knowledge forward. This relationship is especially rewarding in the long term as you work together on other projects down the line.
    • Receive: having good mentors is one of the best ways to quickly grow and learn. I have had the good fortune to learn from specially good mentors throughout my tenure, who apart from sharing their deep technical knowledge about our systems and processes, provided me solid foundations (either directly or by example) on how to navigate ambiguity and tackle challenging projects/situations. Every new mentor will have something novel to share and teach to you, it is an ongoing process. Good mentors provide you a golden path that you can follow to cut through the exhausting search for viable solutions to a given problem.
  • Learn from others:
    • Outside your organization: other people’s experiences are immensely helpful, specially the ones that have been time tested and are well structured. Books are a good source of this knowledge, and I would recommend The Manager’s Path, from which I extracted many of my base understandings of what a techlead should be, do and behave. The book goes straight to the point, gives actionable examples and was written by a very experienced manager.
    • Reach out to your peers: specially in the beginning of my role as techlead, I was struggling to find the right balance between personal impact from my own actions and (the less concrete) directional impact. To resolve my conundrum, I’ve reached out for support from my manager, my original mentor and a fellow experienced techlead. Their experiences and advices helped me to tackle this subject, and other challenges that came along the way.
  • Measure your success:
    • Goaling against quantifiable metrics = solid prioritization and justification: Make sure that all your projects are goaled against an objective, quantifiable metric. Otherwise it will be hard to prioritize between them and justify their value during planning and execution to your peers and external stakeholders.
    • Clear and quantifiable goals = increased motivation: Projects with goals based on solid metrics allow for anyone working on a project to know how valuable their contribution will be. I would claim that working on projects with an ambiguous value proposition is frustrating and will receive less attention and effort from everyone involved, since it will not be clear how impactful their actions will be.
    • Measure your personal progress by asking for candid feedback: if your manager and/peers don’t give you candid feedback on your progress, ask for it explicitly. It is one of the best ways to measure your progress on your role and surfacing any blindspots.
    • No measurement = flying blind
  • Communication - what you transmit, and how, matters:
    • Written and oral communication is essential when explaining the rationale behind an objective/project/task, and when coordinating with your peers and other stakeholders. This is a skill that can be learned, and one that I am still actively evolving. The best way to improve it, as I have found, is to write more, speak more, make more presentations, and study the communication methods from others.
    • As a rule of thumb, most communication styles benefit from a “news article” structure: first a TLDR (Too Long Didn’t Read), then an overall context of the problem in question and its impact, followed by details such as the delineation of a set of solutions, ending with a call to action or further questions.
  • Imposter syndrome: this might stem from a mismatch between your perceived performance and expectations for your role. Work with your manager to explicitly define expectations. Ask your manager and peers for explicit feedback, so you can better calibrate your perceptions. If you feel like an imposter, odds are, you aren’t.
  • Take care of your body and mind, they are your ultimate tools: Last but not least, exercise, eat healthy food, nourish your relationships and strive for quality sleep. These are the essential tenants for the infrastructure (you) that will sustain all of the above points.