Build a leader habit: learn how to let go

I would like for this post to be addressed to everyone, junior to senior. I believe it will resonate more with senior engineers though. Nonetheless I invite everyone to give it a read!

You can find countless self help books talking about "getting rid of the clutter", "focusing on things that matter" and "keeping things minimal". What you'll read goes in hand with many of these topics. I wanted to go more into specifics, especially for engineers in leading roles. I will split the article into small sections so you know exactly what to let go of. I also touch on other aspects of being a good leader so get ready to take notes!

Projects you started

...that will be passed on to someone else

This applies especially when you join a startup at early stages. You start developing anything, from an internal tool to the backbone of a production app. You get your hands dirty, the team is small and you have to hack it together. But you're proud of what you build, like every engineer. What you thought was a small "internal admin tool" becomes a behemoth. A do-it-all dashboard that holds together all internal data. As the company grows the internal tool grows, up to the point where you can't maintain it alone. At this point a few great opportunities will present themselves:

• Mentoring
• Building Trust
• Letting go

First of all you have the chance to show what you built to a junior. You can mentor them so they can learn their way around the code base. You can teach them about the mistakes you made along the way. It'll help them not having to learn the hard way (mind you, they will learn plenty the hard way so, no need to add more). Then, once they are comfortable, they start adding/removing features, fixing bugs and taking ownership little by little. You can now let go.

Do not obsess over the project because you built it. Do not obsess over the project because you want control. Do not obsess over the project because you want things done "your way". Do not obsess because you want to feel needed. Let go. Let go and trust the coworkers you mentored to take over, they will do just fine. And what if they are completely lost? They can come to you and ask. That easy.

You already gave it your best, you put plenty energy in it. It is time for you to move on and focus on whatever you can bring next to the company. Especially as it grows there will be a ton of new projects, new tools, new apps. Or there can be old projects, old tools, old apps that need help! But remember that clinging onto a project you worked on is not healthy:

• You will always feel like you need to be involved
• You will always feel like you need to keep an eye on it
• You will always feel like you need to be in every meeting about it
• You will take away focus and energy from things you need to work on next
• You will split yourself too thin and burn out

Learning to let go is a beautiful thing. It allows you to focus on what matters. You will avoid wasting mental energy. You will avoid keeping control on things that do not need you. It's not easy, because we all love to be involved. It's not easy because we will feel "cut out". But once you let go, you feel lighter. You don't have to worry about it anymore. You can focus on what's next and avoid unnecessary distractions.

If I didn't learn how to let go, after many years within the company, I would need to be part of way too many meetings. Way too many code reviews. Way too many architectural decisions. At some point you need to trust your team and focus on what you do best.

Projects you started

...that will become obsolete

Writing code is an ephemeral art. Software becomes obsolete and so does the code you write. Do not get too attached to that beautiful folder structure, script, util or anything about the project. Be proud of it, learn from it but don't get attached.

Especially in fast paced environments projects born and die quite often. It would be an emotional roller-coaster if we always got attached to what we develop. Learn to let go of it, put in your backpack and move on. Even though such projects might end in the trash bin, keep with you the lessons you learned while working on it. Those are invaluable and will bring you closer to be the amazing engineer you're meant to be! For this reason here's a hot tip:

When you work on a new project, no matter how small it is, try to add or use something new (even as little as a small utils library). Put yourself in a situation where you can be productive. But also give yourself a chance to learn something in the process.

I have even been in scenarios where I built a small interface or a little dashboard. Then, after a week, it became completely useless. That's because we learned things about the problem that made it not necessary. Poor planning ? Maybe, but sometimes that's part of the game. Was it a waste of time ? No, because I made sure to use a different UI library, so I was able to learn something in the process 💪

Your ego

This is a tough one. To be honest they all are. They seem easy on paper but it's difficult to adjust your mindset to it. A good leader, heck, a great leader does not seek credit. A great leader does not say "I", she says "We".

A good leader is an established presence within the company. For this reason you need to understand the role your ego plays in a work environment. If you don't keep it in check, you risk to put other talented or growing engineers in the shadow. Learn how to use positive reinforcement and let others take credit and shine when the time is right!

Sometimes it's hard because we all love praise. This is why putting your ego on the side for the greater good is hard. Be the kind of leader who helps engineers to grow with suggestions on implementations, but deal with this quietly and privately.

Be ready to forgo credit for suggested improvements

This is something extremely valuable that I learned twice: on the job and from F.P.Brooks on "The Mythical Man-Month". If you gave the suggestion that helped someone better an implementation, be a good leader, let go of the credit.

I would also like to give you a few examples of what a good leader should NOT do:

• When a junior coworker is asked to present a new technology to the team as an opportunity to shine, don't shoot them down while they are presenting. Don't interrupt them with questions, and if you really need to do that (just don't) make sure you know the answer. Talk to them privately if you need to correct them.
• Do not take it personally when someone reviews or critics your work. Understand what you can take from it and move forward (this tweet from Sarah is a good example).
• Do not demand to always be the one to work on the "cool" company projects.
• Do not try to keep every technological aspect of the company under your personal scrutiny, delegate... let go!

There's many more that I unfortunately witnessed. I hope these will give you a few hints on what to expect from a good leader, and how to be one! To be honest this is just a small part of it. Learning how to let go is a main ingredient that has a subtle but significant effect on many scenarios. The risk is that your ego can get in your way. This will prevent you from making decisions clearly and fairly. My suggestion? Let it go (cit. Frozen).

It's a way of thinking and behaving that's beneficial on so many levels, it allows you to declutter your brain. You have to keep fewer things in mind because you are now delegating more. You will take pride because you helped other engineers grow within the company. By doing so you let them become the people you can trust and delegate to!

It's really a win-win 🎉!

👋 Hi, I’m Gabri! I love innovation and lead R&D at Hutch. I also love React, Javascript and Machine Learning (among a million other things). You can follow me on twitter @gabrielecimato and on GitHub @Gabri3l. Leave a comment if you have any other recommendation that you’d like to share, or send a DM on Twitter if you have any question!