From developer to team lead: re-engineering a mindset
Berlin. Autumn 2017. I wake up feeling pretty good! The sky is blue outside. Even though it’s not warm enough lo leave the jacket in the wardrobe, the sun is shining, making this a glorious morning in Berlin.
On the U-Bahn, I have the head full of ideas I want to put in practice today. I can barely wait to open my IDE and do some coding.
I get to work. As I open my computer and look at my calendar, I can feel all of that energy being drained out of my body. My hands pull my hair backwards as I realize I have the worst kind of day ahead of me: a day full of interruptions.
That was when I realized I needed to do something about the organization of my work.
I enjoy working as a team lead. There are many things I like about it. But let’s face it: interruptions are part of the job description. You need to attend meetings, do one-on-one’s with your team, jump onto production bugs. On other hand, deep in my soul I’m a programmer. I love coding. I can’t focus on a complex topic if I know I’ll need to stop in 10 minutes.
My work life couldn’t be only about attending meetings and reacting to things all the time. I needed to respect myself and reserve time to work on the things that make me tick. And I made it happen by focusing on 4 topics.
Time
Being a team lead means dealing with complex and time consuming topics on a daily basis. And I need time to think about all the angles to be covered before responding. How to achieve that in a calendar made of 30 minutes free slots in between meetings?
First thing I did, blunt and simple: I blocked my calendar during the most critical portion of my day.
For instance, lunch is crucial for me. I don’t care how cold it is outside, I need to go out, stretch my legs, talk to my friends in Brazil, have a look at the memes my dad sends me. If I don’t do that, I’ll be stressed out during the rest of the day and won’t deliver anything. So, during lunch time, no one can book a meeting with me. Simple.
Same for afternoons. My most productive part of the day is the afternoon. That’s when I like to code or jump onto issues that need attention. So, Monday to Wednesday, from 13:30h to 17:00h, if you need me, come and talk to me. It’s my time, I guess it's fair for me to decide what to do about it. Any other day, morning or afternoon, if you need me, I’ll be there.
Second step: bouncing meetings. Every time I realized an e-mail could replace 5 people sitting in a room, I’d just write the e-mail and reject the invite. If I had nothing to contribute to a meeting, I’d skip it. And for every meeting I really needed to attend, I’d fiercely try to make the group stick to the agenda and be the first one to ask “are we done here?”, instead of watching 30 minutes being filled with random topics. Save chit chat for after work.
Third: delegating.
I don’t believe that being a team lead means stopping everything you’re doing every time someone pops up with a question. Neither it means being the single source of truth in the team. If someone from the team can contribute to a topic, I encourage them to take ownership of it. The more people are able to answer questions or attending meetings on my behalf, the better. It means when I’m away, work won’t stop, the team continues to deliver. Of course, this doesn’t work for every topic, but it covers most of them.
Fun
I’m a developer. I’m addicted to solving different puzzles every day and having fun with new frameworks I read about in the interwebs.
I’m also a team lead. I love watching people develop and becoming great professionals. I feel good when I look at our board and see the team moving forward without me needing to interfere with anything.
But I know from one week to another my schedule might change from a sea of calmness to a Tetris board made of meetings. How could I have fun on both ends while coping with my unstable schedule?
Staying out of the team’s way was a great idea, as a matter of fact. I’d let them take care of the things that couldn’t be late and grab a non-critical coding task every once in a while. Or instead pick a super critical task that needed to beat the regular process and be released as soon as possible (in which case I’d skip even more meetings).
Another approach was putting in place something the team asked for: free time for experimentation and learning. After agreeing with our PO, we established that every Friday afternoon everybody was free to do whatever they wanted, as long as it was work related. Refactor code, learn something, try out a new framework, you name it. Everybody was entitled, myself included, and I’d use that time to improve our codebase, fix some code smells reported on SonarQube, improve our test coverage, whatever had been on my TODO list for longer.
This was essential for me to keep my sanity in this last year as a team lead. But nothing made feel better than what comes next.
The good things in life
Alessandro was the best developer in my team. His brain could accumulate unbelievable loads of information. He knew business rules that lied under other teams' umbrellas. He’d tell you where to look for a given piece of code without even looking at the computer. He quite often was the first one to get to the office and also the one to shut the lights.
Alessandro was responsible for a business critical project. For several reasons, we couldn’t make it go live before the first week of November. Guess when had he booked a week of vacations to spend with his family at his home country? The worst thing is he was so committed to that project that he was willingfully offering to work remotely for the first two days of his vacations just to monitor how everything went.
I’ve done that in the past. I’d forget so much about myself that I’d offer to do the same, just to, later on, regret not having spent more time with my family. And now I had the chance to do something good for someone else. I mean, he wouldn’t let go, he was decided to monitor it remotely and I wouldn’t try to change his mind. But, as a team lead, I had the resources to at least do it right by him. And so we agreed he’d get paid for those two days of remote work and have those two vacation days whenever would suit him best.
Doing right by others. Giving a raise to someone who works hard. Watching people jump with their teeth on new responsibilities. Those things are priceless, and you only get to experience those as a team lead.
I still remember how bad I felt, back in Brazil, when I’d spend a year working my ass off, just to have my manager say: “as much as you deserve it, unfortunately we can’t afford a salary raise for you at this moment”. The first time I had the opportunity to do the opposite and give a raise to people that had worked just as hard, to see the smile on their faces, I gotta tell you, that felt good. And again, I could only experience that as a team lead.
But still, even with all of these tricks, even with all that satisfaction, I always had this question in the back of my head, nagging me every now and then…
How do I measure my success?
When I’m wearing the developer hat, it’s quite easy to measure success. I have feedback in pull requests telling me how good is my solution. I have unit tests making it clear whether my proposal works or not. I have logs unambigously stating my new feature has seamlessly integrated with the rest of the code.
But how could I measure my success as a team lead? Effectively, the answers were already there, I just had to listen to them.
From my very first month on the job, we agreed to do one-on-one’s with everyone in the team on a monthly basis to discuss what could be improved. On my first round, I’d walk out of the room overwhelmed most of the times, there was a lot to be fixed. On my third round, most people had zero complaints. From code red to code blue in 3 months. How could I have not paid attention to that before? That was a major success!
After 6 months at Outfittery, Jesper and Luca, our CTO and Head of Product, respectively, wanted to introduce the concept of end to end teams. Business and Tech working more closely together, massive cultural change for everyone. Of course that brought some concerns to the team. The question I heard more often on the next round of one-on-one’s was: “Am I going to have a different team lead?”. Those people have no idea how big a gift they were giving me by subtly expressing they were happy to stick with me. I know, it sounds cheesy and vain, but if that won’t represent success, I don’t know what else would.
Yes, I could have measured my own success by more objective ways, that’s for sure. I could have checked our employee satisfaction survey to see how the team felt about my work. I could definitely have used the feedback from our 360 feedback process. But tools and numbers sometimes are too cold. As a team lead, my main goal is to take care of our people, and there’s nothing like looking in their eyes and hearing it directly from them.
It’s tough but it pays off
Bouncing meetings, focusing on the good news, setting time aside for fun, all of this required discipline from me. It took my chaotic mind a long time to realize I needed to organize my schedule if I wanted our team to deliver while also having fun. And it took me months to reengineer my mindset as to ignore the need for hard and fast numbers and focus on implicit good news. But it paid off.
I’m much more relaxed nowadays than I’ve ever been as a team lead. Even with business critical projects being worked on every single day, everybody on the team goes home whenever they want, everybody enjoys their vacation time and I have time to blog about it. That's being successful to me.
What about you? I’m curious about you. Are you a team lead as well? Have you been through the same struggle to adapt your mindset? Care to share your experiences and ideas here? Let’s talk about them!
