My Top-10 Leadership Practices as a Lead Software Engineer
Sharing some of the leadership ideals I've cultivated as a software engineer over the last 6 years.
--
Background
These tips are not listed in any specific order. Simply, the order in which they came to my mind one windy Saturday evening.
Also, this is not an exhaustive list. Just the practices that I consider to be most vital in one's technical leadership journey. There are lots more!
Dedicated to my Captain Bell 💛
For the sake of protecting this person’s identity and privacy, I will refer to them as: Captain Bell.
Captain Bell has been a huge catalyst in shaping me into the successful individual I am today. From all angles — career and personal. Amazing folks like Captain Bell are extremely rare and invaluable in this crazy world. After I met Captain Bell, my life changed, and I grew in ways I had previously thought unimaginable.
I cherish (and will forever) value the teachings and moments shared between me and Captain Bell.
This article on Software Engineering Leadership Practices is dedicated to my forever dearest coach, role model, top adviser, champion, respected elder, and revered friend, Captain Bell.💛
Today, the fact that I even have this amazing opportunity, and fortune of sharing my insights with the whole wide world is because of Captain Bell’s hard work, impact, tremendous investments, and beliefs in my growth.
Captain Bell, huge thank you for everything! For both, the difficult and the wonderful times, your continued encouragement + support, you and me always brainstorming + partnering together, and you for being a great part of my life. 🙂
Um, ok, so now ... who is this dude? 🤔
My name is Abdul Wahab.
For those new to my Medium blog, checkout my LinkedIn profile (here) to learn more about me and my career.
I welcome questions and comments, so feel free to send them my way after reading!
Abdul’s top-10 Leadership Practices
1) Build a solid foundational relationship with your teammates.
As a lead engineer, you are also an informal leader. Your junior engineers will (and should) look up to you, so it is important that you are approachable.
Create regular check-ins with your teammates, especially with those that are new, or may be struggling with some thing(s). Or even just casual check-ins.
Make sure you have a well-established and effective onboarding plan for new engineers to start them off nice and strong. Don’t let them get lost.
Ask your teammates questions to learn about them, and get to know them.
2) Learn, and be aware of your teammates’ strengths and weaknesses.
Almost every team has a diverse set of engineers with varying levels of knowledge, skills, and experience levels (which includes you as well). Use that as a force multiplier to your team’s advantage, as opposed to viewing it as something lacking. With that, also practice self-awareness.
Example: If Ken is not too comfortable juggling projects with lot’s of cross-functional collaboration, but is exceptionally skilled at delivering effective code in short periods of time, then for now, let Ken write code. Later, slowly partner him up with Bob, who is highly-effective at cross-functional partnerships, to enable Ken to grow out of his comfort zone.
Now, there is a chance that Ken would have done an awesome job handling the cross-functional project had I just delegated it to him without being mindful of his comfort level. But, would I be taking a risk? Oh yes. Would I be creating a bad engineer experience? Yep.
Yes, comfort zones are meant to be stretched, but just be mindful of the risk you are willing to accept for your team and product. Think of the stakes of what could happen if the project had failed in some way.
Some failures are easy to recover from, some are not easy to recover from. You should weigh the options and then decide.
3) Foster a Nurturing environment with psychological safety.
Do not tolerate disrespect and rude jerk-like behavior. Call it out on the spot. Period.
Share your knowledge with others whenever possible to encourage a culture of growth and openness.
You made a mistake/blunder? Accept it openly, explain what happened, and what you are doing to fix it. In turn, expect for others to do the same when their time comes (mistakes happen in IT, it’s natural).
Bottom line is, lead engineers have the privilege to shape the team/suite culture, which junior engineers adopt as time goes by.
Make sure that you are encouraging and promoting the proper behaviors and practices that create a friendly, safe, and effective development environment for the long-term. Not a toxic, cut-throat, and ego-driven mess that takes years of new leadership to recover from.
4) Always be Actively listening.
A junior engineer is reviewing their code? Sharing a design candidate? Walking you through an error log? Make sure you listen actively, and with a curiosity-oriented mindset.
Check for understanding by repeating back what they shared to ensure you understood what was implemented and explained.
This shows that you are engaged and care about your team’s work, and fosters the same behavior and expectation of others.
Remember, lead engineers have the privilege of promoting the team’s culture. So, try to make it a good one.
5) Focus on Situations, not the Individual.
Things will go wrong. Or not work as expected.
Assess and understand the situation, help your teammate fix it, discuss what happened, and move on.
Do not get emotional. Stick to the facts of any situation.
Think back to when you were a junior engineer. What would you have liked your senior teammate to have done to help you?
Or, maybe your senior took some toxic actions, and threw you under the bus.
Do you want to emulate the same toxic behavior of some egomaniac from the past who wronged you? Nope! 🙂 - You want to build a safe environment where people make mistakes, learn from them, teach others, and grow.
6) Set your team up for success - Let them fail a little.
If the risk for failure is low, and consequences are not detrimental, take the risk. Give Ken (from #2) the big project which requires lots of coordination and collaboration across different business areas.
Sure, heads-down coder Ken might complain and even express anger and frustration. But, you are Ken’s senior, you gotta help him grow as an engineer. Encourage him to take things step-by-step, figure out where the origin of his frustration is. Give him enough guidance so he can do some introspection and see where he needs to course correct.
Growth is painful, yes, but that is how comfort zones get stretched. And that is how people learn and realize what they are truly capable of.
7) Cultivate a Learning-oriented (Growth) mindset backed by genuine curiosity.
Always evaluate the what-ifs. Never settle for a decent design, or decent solution. Try to think ahead of the current scope, and how a project may evolve in the future.
I must say though, there is a fine line to balance this. You don’t want to overengineer anything, or prematurely optimize. That will cost you in the long-term.
All engineers (beginners or seniors) are lifelong learners, and curiosity keeps things interesting, and helps us grow.
8) Lead with love.
Always think back to the time when you were a bright-eyed, fresh out of college, newly-minted junior engineer. What did your senior teammate do for you that really helped accelerate your growth and learning? Or, did they do something that led to a toxic and nasty work environment?
Your teammates, just like you, are humans with emotions and may even be dealing with problems and challenges you probably have no clue about.
As mentioned above, as a lead engineer, you are also an informal leader. To build a successful team (and product), it’s advantageous if your team can look up to you and approach you without hesitation. Rather than hide stuff from you, and cause dysfunction and chaos.
9) Respond, do not react.
Easier said than done, right?
We’re all humans with complex emotions. When things go wrong, or don’t go as expected, easy to react.
Once in a long while, reacting badly will not impact others. But if you react consistently, do not assess the problem (technical or otherwise), rant, and don’t take a practical approach to the issue, you will pass that behavior on to others, and teammates will perceive you as ill-tempered and steer clear of you.
Be fact-oriented, and situation-oriented. Solve the technical issue, without being tough on any individual person.
Honestly, I can go on and on for this one, but that would require a whole separate article entirely…
10) Promote a culture of welcoming and offering feedback.
Casually ask a teammate:
- Hey, what did you think of my demo?
- What are your thoughts on my validation logic?
- Hey, I feel like I messed this up. Do you feel that I could have done things differently?
You want to create a culture where people are comfortable sharing thoughts and ideas. Psychological safety is super important.
Ask for feedback, and also provide feedback to your teammates. Do not wait until quarterly reviews. Share it when it’s fresh, so that teammates can think about it, and adopt if appropriate.
Feedback must come from good intentions. Not to bash anyone or complain and moan. Do not misuse the purpose of feedback.
Thank you for reading! 🙏
Feel free to drop any comments/questions below.
To read more of my articles on Technical Leadership, visit my list below:
