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!
Top comments (4)
Fantastic!
At my company, I usually assign each individual (including interns) primary responsibility over a sector of the code. When I have a large enough staff to cover our active projects in that manner, I like to go to various staff members, including interns, and ask them what they'd like me to do. I literally let them assign me tasks.
When I'm working on such a task, I refrain from making project decisions; I'll ask them instead. Even if it's not the decision I would have made, if I'm not asked for my feedback, I'll generally go with the flow. [See my other comment.] It's amazing how often I learn things, even from interns, that way.
I find that really empowers the staff members, especially interns, to work independently, make mistakes, and get a taste of real-world project management. Bonus, it keeps me closely involved, without me being underfoot.
(By the way, I do have the authority as lead developer to provide unsolicited feedback and override decisions, but I rarely do so unless the mistake would have significant repercussions beyond the immediate code sector.)
Thanks, great post! How would you approach a situation where a team mostly consists of junior devs?
Practically my entire career has been in that situation, so although I'm not the OP here, I do have some insight. My adage has always been...
So, I'd say this article still applies! I try to stay familiar with as much of the code base as I can, but when I assign it to someone else, I trust them to make decisions (and mistakes) and to deal with the natural consequences thereof, whether good or bad. I'm still available to help, through code reviews, one-on-one conversations, meetings, and the like, but my other rule is...
When I bring an intern on to the year-long internship program, I personally guide them through the first month. After that, I make it clear that I will no longer help unless I'm asked. Aside from my asking "how is it going? any problems?" periodically to help prompt them to reach out, the responsibility to seek help is on them.
All in all, it works pretty well.
@jason gave a great reply in his comments! I have been in that situation before and my goal is to work towards being able to let go. What this means is that I do my best to provide juniors with all the tools they need to be independent as soon as possible.
Most of the times I let them make mistakes in a "controlled environment". What this means is that there's usually some work that needs to be done that, even if big mistakes are made, the consequences are not a big deal. But make sure to be upfront about it! You don't wanna trick them into thinking they are working on something mission-critical and let them stress out for no reason.
Put them at ease, mentor them and guide them enough so they can start working on their own. What I often did is sometimes sit down for 10-15 minutes to talk through something like state management in React. I give them all the knowledge I have and they usually pick it up and start coding! Sometimes they even find flaws or limitations and we go back to chat about it, every time it's a pretty casual chat nothing official.
But yeah the gist of it is the following: do your best to guide them and provide them with the tools to be independent. Help them become the teammates you can trust which will make your life a lot easier. Working towards the "let go" mentality is not something that happens within a day, you need to work towards that and then...reap the rewards!!!