Likeable leaders go further

Estimated reading time: 7 minutes

Being a leader who engineers enjoy working with can open doors and improve team performance. 

Early on in a software engineer’s career, the main focus and gauge of productivity is raw output. How many pull requests do you average per week? How many bugs do you fix a year? And what is your track record at implementing features on time?

This is a sensible focus as you begin your journey, but as people progress from individual contributors (ICs) through to technical leads (TLs), it begins to cause a conflict in your day-to-day.

Suddenly, as a TL, you find yourself tasked with facilitating and optimizing for the entire team’s output, not just your own. In fact, your individual output is directly linked to the team’s success. 

Because of the word technical in the job title, many TLs continue to prioritize technical expertise, but what they often miss is that TLs are the face of a team and will have to spend a large amount of time looking outward and talking to other cross-functional team members.

The best TLs adapt their role into two to become an engaging presence that people actively seek out:

1. A trusted, wise head internally to their team who can unblock and guide them through challenges and complexities.
2. A trusted, calm authority externally to the business who is the port of call for questions and ideas.

In addition to this, a good TL recognizes that their technical expertise is almost secondary to their approachability. If your teammates enjoy working with you and respect your leadership, and no one outside of your team fears having to engage with you, you’ll find that your job becomes a lot easier and your team’s performance increases.

Stay calm and prioritize

Being in a position of authority on a technical team is as much about saying “no” as it is about pushing new features through to delivery.

You will be overwhelmed by inputs and ideas from your team, your immediate cross-functional colleagues (product managers, UX designers), and others in other parts of the business. It is crucial that you manage your workload to avoid being drained by overcommitting and failing to deliver.

The way you engage and decline ideas is vitally important for cultivating relationships. I’ve been a TL for many years now, but early on, I made the mistake of rejecting a conversation with a product manager with a dismissive, “Sorry, I’m too busy and we have too much to do.” I didn’t even give them time to tell me their ideas! This approach hurt me in a number of ways:

• This person is now far less likely to approach me in the future to suggest an idea.
• Their idea might have been amazing, and I’ve missed the chance to own the technical direction.
• It could have been an idea ripe for delegation to someone on my team, giving them an opportunity for career growth.
• That person also gave (very justifiable!) feedback to my manager, suggesting I work on being more open to collaboration.

The one positive to come from this experience was that I could reflect and adjust my approach.  Now, I have a few strategies in place that I recommend:

1. Always accept an invite for a discussion. If you’re really busy, defer it a week, or ask if they can share it over email first, but never outright decline.
2. Keep a list of all the ideas or projects you could do, even if there are far too many for you to conceivably pursue. You never know when priorities change or a project that was high effort a year ago suddenly becomes much easier due to some other technical work.
3. Try to avoid “I’m too busy” as a phrase. That’s never the real reason that something can’t get done. The reality is that someone else’s idea is likely a lower priority than other projects on your lap.  Be honest about that and remember that everyone is busy!
4. Be flexible but clear with management on workloads and prioritization. If my manager asks me to prioritize a new project, I can explain that I can, but he will need to help me identify which existing projects are now lower priority and can be put on hold.
5. Put your own team first, every time. Their questions, 1:1s, code reviews, design docs, and so on are my top priority every day. My number one objective is to minimize the time my team is blocked by me and empower them to make decisions without me if necessary.

Increase trust with clear communication

Building good software products means collaborating with people across teams and departments. Often, these people are spread across different locations and time zones, making it difficult to ensure everyone stays up to date. 

As a TL, you have an opportunity here to set the standard by ensuring crystal-clear written communication to keep everyone aligned. If a decision is made in a meeting – either physical or over video call – write it down as soon as possible.

In doing so, people will come to trust that if you’re involved, things will be run smoothly and that you have your finger on the pulse. Here are some ways you can achieve this:

1. End each meeting with a recap. My favourite strategy is to send an email to the attendees (and anyone who couldn’t join) with all the key takeaways and next steps. By proactively doing this, you are taking ownership of the decisions while also giving people a chance to flag if they disagree and uncover any misunderstandings. Trust me, it’s much better to find this out now than ship a feature and have a product manager question its functionality!
2. Get every decision in writing. You want to make sure that if your manager or another team asks how you arrived at a decision that you can point to the notes. If you take notes and recap on each meeting, this will happen naturally, but I’ve found it’s also useful to capture any decisions taken in less formal scenarios – perhaps a coffee with a colleague or a 1:1 with a manager where you would typically take fewer notes.
3. Proactively communicate when things change. No one likes having the rug pulled from them as they are working on something, but sometimes it is necessary to shift priorities unexpectedly. If you find yourself having to pivot, own the situation and be transparent. Explain the decision and why it’s been made, and offer to chat further if anyone wants to. This will be a slightly awkward situation to approach, but it’s better than people wondering why it changed and coming to the wrong conclusions.

Attribute everything to the team and praise in public

As you become the figurehead for your team, it becomes easy to inadvertently take all the credit. It will be you who sends the email that announces a new feature being shipped or the quarterly summary to leadership. Phrasing these sorts of announcements becomes incredibly important to avoid the faux pas of taking all the glory:

1. Focus on what “we” shipped. Avoid saying “my team” or “me and my team,” and simply use “we.” Make sure you proportion credit correctly to everyone. 
2. Praise your team members often and pass credit on to them if it’s given to you. As an example, a senior director in another team recently thanked me for my work on a feature, but 95% of the work was done by one of my team members. I replied to their email, looping that person in, and was clear that the praise was theirs to take, not mine.
3. When there are bugs, keep it blameless. Although one person will have shipped the faulty code, there are other members to consider as well, like the engineer who reviewed the code. In most cases, multiple people were involved in the design stage. So, focus on fixing the bug and any process improvements, and never make a deal out of the individual whose code change was the cause.
4. Praise publicly, and provide feedback privately. People like being thanked and receiving praise. Doing so in a public forum is a nice way to show gratitude. If you have any constructive criticism, share it privately, either directly with the person or through their manager, depending on the feedback and what the person prefers.
5. Avoid venting in a public forum. It is not a good look for a senior person on the team to vent. If I reach the point where I cannot be constructive, that’s usually my signal to go for a walk, or make a coffee and take a breather. In meetings, you want to be productive and present solutions to problems.

Deadline: January 4, 2026

Call for Proposals for London 2026 is open!

Submit your talk idea

Final thoughts

Never forget that being a good TL is as much about your outward appearance and communication as it is about your deep technical expertise. Focus on being:

1. A crystal clear communicator who values clarity and team alignment.
2. A fair team lead who shares praise and owns problems.
3. A person who cross-functional team members enjoy working with, who is open to new ideas and finding solutions to problems.

In doing so, you establish yourself as a “go-to” engineering leader, enhancing your career prospects and those of your team.