I've been working as a Tech Lead in one capacity or another for the better part of the last decade.
The time I've spent advancing from the 'asks good questions' dev, to the 'has the answers' dev, and now what most would define as Senior or Tech Lead has taken longer than those 4 years—it's actually taken my entire career as a developer. (Full disclosure: I still have so much more to learn.)
But in that time, I've noticed that there a few things about 'good' Tech Leads and Seniors that separates them from the rest, and one in particular:
Your communication style matters.
Most developers generally aren't good communicators. And most would immediately disagree; they'd argue that their clear, to-the-point (even blunt) writing style perfectly communicates their point without many issues.
And they'd be wrong.
How you communicate is just as important as what you're communicating.
If that email you're sending is going to be clouded by misinterpretation, you might as well not send that email.
If your code review is overly terse, blunt, and void of empathy, you're wasting time doing reviews at all.
If PMs actively seek to keep communication with you to the absolute minimum, you should consider the value you're providing as a Lead/Senior.
Instead of me droning on about that abstract concept, here's an example:
I've worked in lots of agencies. Some small, some large, and some that had no business at all even calling themselves an agency.
But all of them had a variety of approaches to coding standards, and one in particular had a policy of Code Reviews. Before any code at all could be merged into staging or master, it had to be reviewed and approved by another member of the team.
This in itself is a fantastic policy; in fact I wish more agencies adopted this approach.
However, there was one issue... and that issue was a particular developer on the team.
If you were paired with that developer, you knew things would not be pleasant for the next few months on this project.
Technically he was a Senior Developer, and by all accounts he deserved that title; he's still one of the better developers I've ever had the pleasure of calling a coworker. That should mean that working with him would be a good thing, but everyone else hated being assigned projects with him.
And that was for one reason—he was extremely rough with code reviews.
Whether you were an intern, junior dev, or the most senior developer on the team, he was going to completely destroy your motivation. Compromises be damned; his approach was right, and yours—of course—was wrong.
There was little explanation of why it's wrong, but instead just a reference to the documentation and a few words asking why you thought building it in this fashion was a good idea, and that you've wasted valuable budget doing this wrong.
I can specifically remember conversations with groups of coworkers about reviews they'd received from this developer. The tone of the conversation was... not positive, to say the least.
To be clear, his reviews did have many redeeming qualities—they were prompt, technically insightful, and often revealed significant issues that could arise should this code be used in production for a few months.
But, here's the thing: none of that mattered.
I can hear you now—"Of course that matters, Taylor! Those are incredibly important details!" And you're right, they absolutely are.
But those points were lost in the sea of problems that arose from his communication style. Developers did the exact steps to meet his standards; there was no dissemination of knowledge, no teaching moments, no code improvement—only rigid adherence to this dev's ideals.
Simply put—he might as well have not done the code review at all, because the entire point was completely missed. No benefit was gained by juniors learning from this Senior Dev, no knowledge was spread across the agency, no improvement in coding techniques happened as a result of these reviews.
Aside from code reviews, many awkward conversations were had with coworkers about how to handle his feedback, PMs routinely asked to be reassigned or advised on how to approach him, and basic onboarding questions were simply below his paygrade.
Even though he clearly was extremely adept technically, this developer was eventually asked to seek other employment.
While that example was extreme, similar situations happen all the time in many agencies. A particularly blunt review causes a developer to stop thinking and start simply parroting another dev's requests just to get the PR approved, a series of terse responses to a PM makes it much easier for her to accept an offer with another agency, a junior dev decides after seeing a wall of notifications with nothing but blunt comments on things done wrong that this 'web thing' must not be for him, and the list goes on.
So what can we do about it?
Temper 'negative' feedback with positive. If all your devs ever see is problems and standards corrections, it'll cause 'dread' over reviews, hindering the entire point. When reviewing, don't forget to call out things you've noticed they're doing correctly, such as finding a solution to something you know they struggled with, or praising them for using something they recently learned.
When possible, explain the why behind your requested changes. This is your chance to spread knowledge and context to more locations than just your mind—use it!
The phrase "you are not your code" should be repeated to junior (and senior) devs pretty often, not only to ensure you can actually give the feedback you need to, but also to set them up for a healthy relationship with their projects and career in general. I've seen many developers struggle with feelings of failure because of a desire to excessively 'defend' their code.
In short:
Everyone makes mistakes, and nobody knows everything. If we all kept that in mind, I think we'd have a better industry for it.