I never considered becoming a manager.

When fantasizing about the future, I’d think of working as a programmer until I had enough money to switch to something different. I even considered completely unrelated things like opening my own restaurant (you get a little carried away when you start cooking J. Kenji López-Alt‘s recipes). Or maybe buying a farm and living off the land (honestly, I was just playing too much Stardew Valley).

This means I was absolutely unprepared for the whole journey ahead of me when my former boss messaged me in Slack saying “hey Thiago, can we have a chat?”

A Brand New Challenge

It was November 2017 when Andrin, the aforementioned boss, told me during a video call he had been chosen for another position in the company. He wanted to know if I’d like to replace him as the Frontend team lead (at Toggl, that’s we call a manager).

I asked for some time to think about it. A move to management made sense: I had been writing code professionally for almost 13 years and wasn’t exactly excited about programming anymore, or at least not in the same way my coworkers were. As somebody who loves to prove myself I can learn anything, a brand new challenge would be a massive motivation for me.

I accepted the promotion, but not without dealing with my doubts. Could I really do the job? Would the extra responsibility be a burden too heavy for me? Would my coworkers accept me as their manager? Would I become the company’s most recent example of the Peter Principle?

First Failure: An Important Lesson

January of 2018 was intense.

A nasty, very hard to find bug that affected many users was introduced in our web application. Each incoming complaint made me feel physically sick.

Rather than assembling a task force to deal with the problem, I tried to solve it myself. I didn’t feel like I had earned the boss title from the team yet, so it felt weird telling them what to do. I thought, to gain respect from them, I’d have to find and fix that bug. I was sure Andrin would have found and fixed the bug.

That strategy failed horribly. Two weeks had passed since first discovering the bug and complaints were piling up. I was losing sleep. I started feeling dizzy throughout the day. One of the problems of working remotely is people won’t notice your despair if you don’t speak up.

I realized I was on the verge of burnout when I burst into tears for tipping over an empty glass (it didn’t even break 🙈). That’s when I finally swallowed my pride and asked for help:

With the whole team working on the problem, we fixed the bug before the end of the next workday. Out of the many lessons I learned from those two horrible weeks, the most important was that I had to learn how to delegate and trust the team.

Your Own Style of Team Leading

Shortly after accepting the promotion, I scheduled a chat with Krister, Toggl’s CEO. “You have to find your own style of team leading,” he said. It was good advice, good advice that went entirely over my head.

I initially tried to do things exactly like I thought Andrin did. After all, he was a pretty good boss, and I didn’t have a clue what I was doing.

Imitating someone else’s style of leadership isn’t always a good idea. First, I haven’t been through the same experiences that shaped Andrin’s style, so there’s no guarantee I actually understand it. Second, this strategy would only work if both of us were good at the same things.

The first step in finding my own style of leadership was the realization that I would never be as technically good as Andrin. He excelled at many things I don’t do as well, like code reviews, for example. His ability to stay on top of technical details across many different projects had frequently impressed me. How was I supposed to do that?

That realization, along with January’s fiasco, made me consider different ways of leading a team. And then it hit me: I like talking to people, and I have excellent social skills. What if I just took a leap and gave up on technical work? I wouldn’t have any other option rather than learning how to delegate and trust the team.

I vaguely recalled a quote I had read somewhere: “time invested in people is a manager’s best time investment.” It felt like a powerful idea. I embraced it and decided to make my job about people.

Self-Sufficient Team

Another piece of advice I got from Toggl’s CEO during one of our 1:1 meetings was “make yourself redundant.” Unlike the previous advice, I understood this one immediately and translated it into a more practical objective: “I should be able to go on vacations at any moment without worrying.”

To make the team self-sufficient, I needed to eliminate myself as the single point of failure. For example, if every time a part of the code breaks and I jump in to fix it myself, I’m preventing the team from learning how to fix it. Or, if I’m the only person who can do a production deploy, the team won’t be able to fix a critical bug when I’m not around.

Stepping away from these doesn’t mean as a boss I’m not willing to get my hands dirty when needed. Instead, it means I’m delegating tasks more wisely.

I chose this approach for two main reasons: the altruistic one, empowering the team, so each person has more room for growth, and the selfish one, being able to delete Slack from my phone when I take time off so I can finally enjoy my Negroni on the beach.

I know this might sound like an excuse for slacking, but it takes hard work to make this happen. Every time I start getting too comfortable, something spins out of control and reminds me of that.

There’s a catch though: when you delegate one of your responsibilities to someone else, you might actually be turning that person into the new single point of failure. One solution for this is introducing a rotation. For example, Toggl’s backend team has a rotating “Batman” role. Whoever is wearing the Dark Knight’s cape is responsible for answering any technical questions our user support team has when helping the users.

The idea of a redundant manager perfectly fits our remote working culture at Toggl. We choose to trust people rather than micromanage. People are free to choose their working schedule, do things in their own way and, in a way, be their own boss. Micromanagement is a dirty word for us!

A Relationship-based Approach to Leadership

1:1 meetings are an essential part of Toggl’s work culture. Everybody in the company is required to have recurring 1:1s with their team lead.

I used to think the only reasons for those meetings were to check people’s temperatures and remove roadblocks. Then I was introduced to the Leader-Member Exchange Theory in an online course for novice managers. The theory explains how building a strong relationship with your subordinates will increase their levels of productivity and happiness.

In possession of that new knowledge, I ditched my old 1:1 format (basically a boring list of questions) and chose a more casual approach: a quick retrospective mixed with some basic structure to cover problems, actions, and goals. But 1:1s are just a part of a relationship-based approach to leadership.

It takes constant effort to build trust and maintain any kind of relationship. It’s no different when you’re talking about boss and employee. A good leader must step into uncomfortable terrain and learn how to be more open and honest with their team. I consider this the most important part of my job and, honestly, I still suck at it. But hey, at least there’s a lot of room to improve!

As a Manager, You Need to Take Care of Yourself Too

In November 2018, I had the first anxiety attack of my life.

In prior weeks, the pre-burnout signs from when I first started in January came back but even stronger: dizziness, faintness, irritation. Stress. But why? This time there wasn’t an external trigger. The web application was stable, I was getting good feedback from many people, and the team was productive and happy. I realized it was mostly me demanding too much from myself.

I’d start my work days by immediately grabbing my smartphone to check Slack and reply to new messages. I’d then check my calendar and frequently feel overwhelmed by the number of meetings awaiting me later in the day.

My to-do list constantly had 30+ items scheduled as “Today.” And even though I was tracking around 8 hours of work every day (which means more than 10 hours in “work mode”), it felt like I was working 16 hours.

After coming back from a mini-vacation prompted by the anxiety attack, I started to rethink my work routine. I fixed it by doing four things:

I deleted Slack from my phone, so I could have my mornings back. I cleaned up my to-do list. Todoist is a great app, but I was clearly using it wrong. I moved many tasks to a new to-do list and shared that list with the team, so the responsibility was now also shared. I also restructured my task priority system, in a way that there was rarely a high priority item in the list. I regained control over my calendar. I stopped attending some recurring meetings and delegated others. For the busiest days, I used time blocking . I embraced a better work/life balance. As our CEO told me many times, “staying fresh and sharp is part of a team lead’s job.”

It only took me a couple days to organize everything and get back to a healthier working routine. I suddenly felt happy and motivated again. It’s amazing how easy it is to fix a problem once you admit you have one.

Final notes

After working one year in management, I know I’m still at the beginning of this journey and have a lot to learn.

One thing that helped me a lot throughout this first year was Marcus Blankenship’s online course about team leading (you might actually know him from this Medium article). In his course, he discusses many of the topics I’ve mentioned in this article. I strongly recommend it to anybody who is starting as a manager or just wants to be a better boss.

I still miss some things from the technical days, like the meetingless, flexible calendar I had as a remote developer. But I couldn’t be happier about my decision to accept the team lead job. I do not see myself going back anymore.