This year was outstanding for me. Not just because of the pandemic, but also because even before that I decided to take a new challenge in my career (more on this later). After coding for quite some time I decided to try my luck as a Tech Lead at Mimic.
It was the biggest challenge I ever took: I never tried it before, I was deeply afraid, and being the first tech lead hired in a new startup wasn’t helping either. I had to learn and I had to do it fast. Thankfully I had the opportunity to make all possible mistakes (yes, all of them!) and a mentor (Thank you David!) to guide and correct me as I failed across the path.
As I progressed leading 2 teams, I collected several “rules” or as I prefer: principles that worked out for me in handling some situations. I’m going to share them right now, so hopefully, you can skip some pains and absorb some learnings from my experiences.
💬 1. Never open the meeting talking, Ask first
We don’t know everything, it’s impossible to. Ask your team! Ask for updates, problems, and risks.
I remember on my first day it was very frustrating to be in front of a project without knowing anything. I felt that if I didn’t come up with a clear plan/solution (yes, on my first day) I would fail. Turns out that leading is more about relying on your team, than knowing everything.
It’s completely fine to not know everything, instead: Ask your team!
👶 2. People are like babies
They feel what you transmit to them. You laugh, they laugh. You cry, they cry — They don’t even know why.
The first week was terrible, I was nervous, I was anxious, you could see clearly through me that I was panicking!. As I asked questions and talked about the next steps with my team, they responded in the same way: worried, nervous, feeling sad. Clearly I made them feel that way! You can unmotivate your whole team because of your own internal feelings.
I remember months later after I absorbed the technique of being positive and optimistic. We were trying to replace our old KDS software for the new version my team worked so hard to develop, the only issue was that we had 2 hours to test and the third party team responsible for the integration didn’t finish their part. My whole team got stuck in the meeting for 1 hour and a half while waiting for the other team. Can you imagine how frustrating it is to run things in production that can affect our operation just a few minutes before the opening hours? But there was nothing on my plate that I could do to solve, the real best I could do was to encourage the team to finish and believing they would be able to finish it in time for our test and before the kitchen opening hours.
Guess what? Yes, we got it. 30 minutes was risky but enough. If I had yelled at them complaining about some lack of responsibility or any other bullshit do you think the result would be different? Probably not better. Always, under any circumstance: Be tough, but also positive and optimistic. Always believe your team will handle it, what you don’t know you will find out, and somehow things will work out.
🖼️ 3. Don’t get involved with details
Have the big picture in mind. Always keep your discussion at the intended level, don’t get lost.
That’s a hard one. Coming from a developer world I was eager to understand every damn line of code, every minimal decision regarding tools and frameworks and I felt that if I didn’t I would be failing as a leader. At the end of the day, this stuff doesn’t even matter. You should just ensure the right projects are progressing and that it solves the problem.
It’s tempting to start discussing how many classes/functions would be implemented to solve the problem. I wouldn’t ever succeed as a leader if I’ve focused on the details. Instead, I relied on and trained my team so I could trust them to manage and handle such details.
(Worth mentioning this principle is easier said than done, I often need to remind myself to focus on the big picture).
👂 4. Never interrupt people, they need to feel they’re heard
If you need to change the topic, ask questions instead or reschedule a better time to make it happen
As the team grows it’s very easy for people to start adding details that don’t add any value to the discussion or talk about something else related to the main topic that is getting them anxious.
Well, interrupting them is the worst thing you could ever do. It just makes them feel even more anxious, but now ignored as a bonus. If for any reason people are getting off track start asking questions: Do we really need to handle this right now?, Do you think that topic X deserves to be decided before Y? and always be open. Remember you don’t know everything, if it’s something important, you can always schedule a proper call to address it specifically without losing the meeting goal.
🕹️ 5. Don’t act like willing people to obey right now just because you want it
Hear their ideas, make them suggest! No one likes to be controlled, they want to feel they’re free
As a new leader, I was always anxious to ensure my team would be able to deliver everything under time. It’s easy to start giving orders and directions willing them to do exactly what you want right now. Don’t be like that. People are not machines, you can’t run a function and expect them to give the expected output.
Hold your anxieties, ensure they understand the problem and ask them for ideas. Again, maybe their ideas are better than yours. Who knows?
🧾 6. Make sure everyone knows what they should do and what’s the deadline
Ensure your team is on the same page you are
I learned this straight from watching my CTO doing it over and over again and ensuring everyone understood his goals and next steps.
As soon as a long meeting ends it’s very easy to forget part of the discussion and feel lost, you can’t guarantee everybody paid attention, but you can ensure they know the next steps. After every meeting with required action is over, write a message (through slack, email, whatever) to everybody involved. Outline the next steps discussed and tag people to these steps. Even those who got lost in the meeting can easily catch up and understand what they missed.
🏋️ 7. Don’t tell, train
Your team should be able to conduct every process in your absence
It’s very easy to just give orders and instructions: Change this variable, update that config, etc. If you keep doing it, you’re not really sharing knowledge, you’re just giving orders.
Instead, make questions and talk about issues. If you realize something broke in production, instead of jumping in to fix it yourself, ask someone: Why did it break?, How can we avoid this from happening again?, What would you do to solve that? and finally ask them to handle that for you. Yes, let them do it, there’s no better way to learn.
Remember, your team should be able to understand and solve everything in your absence. You shouldn’t know more than your team.
🧠 8. Show you’re open to ideas, make your team comfortable telling you’re wrong
Everybody loves idea’s meritocracy, but just a few enjoy knowing they’re wrong
This is analogous to Ray Dalio’s principle: “Be radically open-minded”.
When I got my first shot to refactor a whole microservice in a month I got overconfident. I thought I would be able to deliver the whole system in a week. Ha poor me. It was shocking to hear from my team that my goals were way off and it would be impossible to deliver in time.
It took a while for them to realize they could tell me and as soon as they dared to tell me and I heard it my posture changed: We together outlined every risk and I came up with a plan the next day, it was a map with all features we could push to deliver and the ones that would be ok if we delivered later.
We were able to focus and my whole team got motivated because they believed in the plan we built together. If you have your team trust, you guys can make miracles. After that episode, it became a habit to tell when we disagreed about anything, and I must assume I was wrong several times and we always could recognize it before it was too late.
🤯 9. Do a favor for your team and criticize them!
Work with people that enjoy criticism, if they don’t make them used to it!
Dale Carnegie got a point when he says to “do not ever criticize” someone. I got him, but this is not true when you’re building a team that wishes to grow. It’s impossible to grow without pain in any area. Why it would be different in your profession?
As soon as I started leading, I made the stupid mistake of never criticizing directly a team member which I regret today.
It took me a while to understand that I was actually stealing them the opportunity of growing at the same time I was hiding myself from conflicts.
I remember in the first months of my job the thing I most desired was feedback: constant and tough feedback — not cheap praise. I’m passionate about these feedbacks that hurt you deeply but that you know it’s true. I prefer to hear a hard truth that will make me grow than to hear a pretty lie that will keep me comfortable.
If I deeply want to improve through honest feedback, why my team would want anything different? If they do it to me, how I will pay them back? By just saying nice things?
NO! If you have something to say, SAY IT. You don’t have to be right, you just have to be honest.
In the end, did it pay off?
I still remember 2020 March: I sitting at my Kitchen table crying with my wife telling her it was the worst idea I ever had. I was doing terrible and got bad results so far. It was just a matter of time to get fired, I’ve lost all faith that I could ever become a leader.
What I was thinking? Leaving a good company to venture myself doing something totally different? And for what? For boredom?
Turns out although I initially failed, I was able to learn and grow fast. All my previous mistakes got so clear to me, every bad decision seemed easy to solve and as a result, I started delivering everything in time and got promoted to repeat the recipe with a whole new team.
Yes, instead of getting fired I improved and got promoted. Sometimes fear is the best urge to be humble and grow.
The incredible pain of failing made me learn tons of things by experience (which worths more than books and articles on leadership because you live and feel every decision consequence).
It made me understand that (sometimes) boredom is the signal you’re done with learning in the current position you are. It means you desire some good fight. Thus you should follow that urge.
Worth saying that without my wife and God to support me emotionally and without my CTO to support me at my work — I would have failed for good. Be surrounded by people who support your growth and by those who want you to strive for growth.
So I don’t regret it at all. I chose the best place to start and to fail because my CTO allowed me to try, learn, and recognize all my mistakes which made me succeed as a leader in the following months and delivering 3 projects with 2 teams of around three developers each. Always work with people you respect and that are better than you.
Originally published at https://blog.guilatrova.dev/what-i-learned-as-a-leader-in-2020/