Tips for Newbie Team Leaders

Stories of failures and lessons learnt from great team leaders I know

Before starting my first lead role at Upflowy a month ago, I wanted to be prepared for it as much as possible. Apart from reading some books suggested by my career coach (thanks, Lucy!) and few random books on leadership from the local library, I contacted the best tech leaders I was lucky to meet in the past.

All of them I asked to answer two questions:

• At your first lead role, what were the main lessons you learnt?
• What was your biggest failure?

Below are their answers, marked with ‘Lessons’ for the first question and ‘Failure’ for the second one.

I also added notes on what makes each of them a great leader, from my point of view.

Miko Ademagic, Design || UI Engineer || Engineering Lead

Miko is a lead who cares and a great mentor. Once I was stuck for hours not being able to construct css media query correctly (I do suck in css). Miko came to my desk, grabbed a texter and drew a simple picture on the wall. Suddenly everything made sense. I was extremely grateful for his help, especially taking into account that a) I didn’t ask for help though must have looked desperate b) he wasn’t my team lead.

Lessons: Your team’s trust in you is now paramount. Trust unifies the team, creates psychological safety, motivation, productivity, and makes a fun team environment. Distrust creates doubt, disengagement, division, and unhappiness. From my then CPTO Joe Waller, “You have a piggybank of trust with your team. You can borrow some, but you always have to pay it back with interest”. Trust is gained through empathy, vulnerability, transparency, and having your team’s best interest at heart. Not through moving the needle for your business, or your technical skill.

Failure: I left an engineer to struggle on a hacky experimental project for too long, only for the project to be cancelled and rewritten by another engineer. This devastated the first engineer and frustrated the second one, and was demotivating for the entire team. As a lead, it can be difficult to decide when to push someone into the deep end of a challenge, and when to help them out of it. I should have put more focus on helping get my team member out early, and rallying the entire team around the problem from the beginning.

Neil McCoy, Founder and CTO

As an Engineering Lead in a company where we worked together, Neil organised effective agile work environment with focus on learning and knowledge share. For one of our weekly Knowledge Share sessions Neil brought a heap of his own books on programming and asked developers to borrow some. My choice, Code Complete, was the most useful book I read that year. Inspired by Neil, I organise regular knowledge share events in all the companies I worked since.

Lessons: There were so many lessons learnt, and I still learn new ones today. One of the main early lessons was that I would try to get the most out of the team by looking for ways to help individuals in the team maximise their output. Standard approaches like removing blocks and automating away waste. Everyone felt productive but we were not actually making better progress. It wasn’t until I researched and discovered “Theory of Constraints” that explained what I had been doing wrong. These days, to get the most out of my teams I will still look to improve individual’s work environment but only for the outcome of improving the person’s happiness and engagement. If I want to increase productivity, I find the bottleneck and focus efforts there.

Another important early learning was to understand that leading a team is a lonely role. When you are in a meeting with other leaders and the next level managers you need to represent your team even if you are the lone voice against an opinion from someone very senior. It is part of your role to ensure your team members’ voices are heard and experiences are known to the decision makers in the business because that could be the only visibility they have of your team members. And the opposite is also true. When in meetings with your team, you are the representative of the business. When a decision comes down from above, even if you didn’t agree, you need to explain to the team why the business made the decision and ensure they come away from that discussion believing that it was the right decision. If you can’t do this, you will create an environment where the team does not trust the business and that will never be a positive working environment.

Failure: Again, there have been many and I still fail these days. The ones that stand out the most to me are when I have been unable to remove a block outside the team or have been unable to influence a business decision that has resulted in the team not being able to deliver something that would have provided business value and a sense of achievement for the team. This failure mode has happened enough times now that it is my number one risk to be alleviated before starting any work. We attack any potential block from outside the team before starting any work. The cost to morale of not being able to deliver work after putting in the effort is too great for the team.

Tom Phan, Lead Developer

Tom is all about learning and sharing knowledge. He shared his habit of morning reading with the whole team. I still read weekly coding digest that he suggested. He contributes to his blog justsimplycode with avid regularity. Out of all our work together, I remember one situation the most: Tom splitting already small task into tiny subtasks so that more junior developer (I) is able to learn and accomplish it more confidently.

Lessons: Main things I learnt are: need to let go and trust the team to get things done. Be patient, and know that sometimes you can’t make everyone happy. Listen to what your team has to say. One example of this is regular one on one. It shows you care and it’ll make your team feels that they can open up to you both professionally and personally.

Failure: My biggest fail would be would be I rush to set the bar too high for the team and sometimes it pushes them too hard. This goes back to my other point around being patient.

Olex Tkachuk, Lead Frontend Developer

Olex’s superpower is empowering people, be it learning new programming language, sharing knowledge or improving table tennis skills. He also inspires others by his own example to take brave steps instead of being afraid of failure.

Lessons: One of the most important thing is getting feedback from developers and your upper management and addressing it. The shorter feedback loop the better result.

Failure: I think it was focusing mostly on technical challenges instead of development processes and the company’s working processes in general.

I hope these reflections will help you to succeed in you lead role. If you have some more advice to share, you are welcome to add it in a comment.

Happy leading!