Thoughts on moving to a leadership role

Moving to a leadership role does not mean you will need to check every line of each PR, tearing your hair and hoping it will be not that bad day.

When I started the role of Technical Lead (feel free to replace it with any other variation of the role) I had a strong craving to control everything around me. This is not anything strange for tech people new to this kind of role.

Therefore it’s easy to feel overwhelmed, sad, or lost at times. This already happens in the early stages, when your team is small and the concurrent tasks are still manageable.
An example of this behavior is the attempt to perform every code review.
Probably you’re concerned that something will break if you don’t pay the necessary focus.
You won’t say anything new but, listen to me, it isn’t feasible and it does not scale.

But what you can do instead?
Some people hates code reviews but they’re an awesome opportunity to explore how someone solved a problem in their unique way and to have discussions on the programming craft.

Before anything else…
Before any automated tools, before linters and formatters you need to focus on two fundamentals activities:

• Teach your team to review effectively Emphasize the scope of a review the kindness, clarity and throughness. You can’t write and review all the code for your team, neither you can hire for people for this job. Put your team in position to handle them effectively.
• Establish Paradigms Setting a few paradigms and rules during product development will save your life. Once you’ve set clear boundaries, reviews become laser-focused. Reviewers can focus on the specific features and they don’t get distracted by accessory elements. A shared structure is one of the best things to invest in; others can leverage and build on top of it. Define how different parts must communicate, the overall architecture, and general approach to UI development leaving the opportunity to evolve and change it over time (gradually).

Once you have consolidated these changes you can build at the top of it:

• Document processes Team members should be aware of the scope and structure of each PR. Using PR templates allows people to correctly explain what have they done and offer a clear overview to any reviewer.
• Integrate Automated Tools Linters, formatters & automated tests release people from the burdens of the boring parts of a review (yeah, I know, some people are human linters but, okay). Strengthen your release pipelines with tests, monitoring, and rollback. This will help to prevent, detect and mitigate defects.