Imagine this. You were a superstar developer! You wrote elegant code, you understood how things were put together behind the scene and you were the go-to person for any technical issue or question about the organisation’s code base. And because of that, you got promoted. You got a promotion and this is what happens.
Being promoted to be an engineering leader is actually not a step up, nor a promotion. It’s a lateral, separate track.
The saying about what made you successful in your previous role won’t necessarily work in your new role couldn’t be more right. As an engineering leader who once used to be a superstar developer, how do you survive and then thrive in your new role? In this article, I will be sharing with you everything I have learned and observed in the last six years as an engineering manager, all the challenges I had faced and my strategies for how to not only be an effective engineering leader but also to enjoy my job. And remember, it doesn’t have to be hard.
So lets start with my struggles… or rather the challenges that I had faced in my early years as an engineering leader.
Struggle 1. I like to code. Period.
The first struggle that I had was that I like to code and I take great satisfaction in creating and building stuff. When I first become a tech lead, I found that I didn’t have much time to code anymore, because I would be busy attending meetings, organising sprints and what not. And then I become a manager, and my time for coding is almost non-existent, because I was busy with doing other activities like planning, budgeting, vendor management, hiring, coaching and more. I just didn’t have a few hours block during the day to sit at my desk and code anymore.
Struggle 2. Technical Pride.
Second struggle was that I consider myself to be technically competent and I took pride in my technical abilities. However, as I started dealing and working with people across the business who were very different to me, my technical skill and ability became less important. What was more important was to be able to explain technical details in a way that everyone, especially non-technical audience understands and get buy-in for.
Struggle 3. FOMO.
The third struggle was that I have worked in technology industry all my career and I have seen first hand how technology is always changing and advancing. So I was afraid that one day my technical knowledge will be obsolete if I didn’t keep up with it. This picture says it all. I was worried that 10 or 20 years from now, people will be talking to me about some cutting edge technologies and I will have no idea what it is. Like the grandma in the above meme.
Struggle 4. Introvert Alert!
My last struggle was mainly to do with my personality aka the type of person I am. I am an introvert, as with most people in technology, and being a manager requires a lot of human interactions. And the picture illustrates what I used to feel when I was in meetings with many people from different departments.
I can almost hear you thinking, wow those were some struggles, how did I survive and then thrive? Let me share with you my strategies which have helped me in my journey.
Strategy 1. Seek first to understand.
My first strategy is to seek first to understand yourself. If there is anything I truly believe in, it’s that we must change ourselves and improve ourselves first in order to best serve others. With that in mind, I unlearn a lot of things I have learned in my developer days and change my mindset completely.
So what are the things we need to understand. First is the list is your responsibilities. Find out what you are expected to achieve in your new role, and I am pretty sure it is not write as much code as you could. It’s possibly around delivering business results through technology, expanding team’s capabilities and company’s technology’s capabilities.
Next up, you need to understand yourself. I’d recommend every leader to do a research about different leadership styles and what kind of leader you are and what sort of environment you want to create for your team. The better you know about yourself, the better leader you become. If anyone is interested, please go and read about “4 Leadership Styles That Triggered Peak Performance” by John Maxwell.
After understanding your leadership style, you need to identify your weaknesses or development areas in order to become better at your job and more importantly, become a better leader and person. I did this with the help of trusted people around me, through 360 feedback or just speaking to people and asking their honest opinion. One of the development areas that was identified for me was that I can be too into technology and too passionate about it that I fail to look at things from business lens.
And last but not least, seek to understand your why and your values and your non-negotiables. In other words, what do you want to be known for and what are the things I really care about. To give an example, a few things that I care about personally are integrity and growth and professionally for my teams are agility, technical excellence and innovation. Knowing these values make it easy to choose between options or avoid making decisions that you would regret later.
Seeking to understand oneself is actually a continuous effort and it’s something that is worth putting our energy into it because as we become more aware about ourselves, we can improve ourselves.
Strategy 2. Understand that People != Code
The second strategy was to understand that people don’t equal to code. This is very important especially for engineering & technical leaders. We can’t expect people to be always logical, reasonable and act accordingly to our predefined assumptions. You can’t create an if then else statement around real life problems and execute them repeatedly, expecting the same answer or reaction.
One of the reasons why technical people often make bad leaders is that they think logically, sometimes too logically. I have learned that listening actively, having empathy and being generous with my time goes a long way in creating trust and fostering an environment that enables people to do their best. As a leader, when you care about your people and look after them well, they will go an extra mile and generally be more effective, collaborative and productive because they are happier.
As engineers, developers and technical people, we are so used to solving problems and fixing issues. However, I have learned that many times, as a leader, your job is not to solve problems, but to listen, to empathise and to empower. So this was the mindset change that I have learnt to made.
Strategy 3. Be consistently learning
The next strategy is to be consistently learning. Technology is always changing and ever advancing. Being a leader in technology means you are a leader of a specific function and you need to have enough understanding of the function. For example: a marketing manager knows about channels of distribution and marketing trends but may not necessarily be managing a social media channel. A finance manager knows how to read P&L and understand cash flow but may not necessarily be doing a balance statement. For a technology leader, you need to know about the company’s technology stack, architecture and technology capabilities at the very least.
To help me keep in touch with technology, I attend industry events, conferences, read publications, and talk and learn from specialists. I also try to learn through my people as much as I can, and it helps create rapport and empowers them as they can see that I am interested in their work and I’m learning through them. To me, realising that we may not know everything, but we can always expand our knowledge if we have the willingness to learn is very powerful. In other words, having a growth mindset.
Strategy 4. Lead by example
And last but not least, I strive to lead by example. Leading by example doesn’t mean doing hands-on work for your teams/developers. Leaders who espouse and practice ethical and responsible behaviors are likely to inspire others to do the same. So think about what you want your team members to do. Do you want them to be accountable, responsible and solve problems? Do you want them to get permission from upper management before doing something? As for me, I like my teams to be honest & transparent, own their decisions, bring solutions, not problems and always be learning. So that is what I do. Because I believe leadership is not a position or title but action and example.
Are we there yet? How did I find joy?
And now I would like to share how I found joy when I am not coding or when I don’t have time to be deep in the code anymore.
It’s a human nature that we want to do things that we are good at, because that gives us joy & satisfaction. I enjoyed coding, because I was good at it. As I try and become better and more effective at my job at an engineering leader, I was able to find happiness in my job. And my values, and strengths such as curiosity, learning agility and wanting to be good at what I do, serve me well. Someone once said to me that confidence is not inborn but it is acquired through taking actions and practice. I couldn’t agree more.
I also realised that I don’t need to know every technology or provide solution to every problem. My job as a leader is to empower people and to give them resources so they can navigate through problems and come up with solutions themselves.
Just in case you’re wondering, it’s not all sunshine and roses every day for me now, even when I say I do enjoy my job. I have days when I need to deal with a low-performing team member, or a project that is not going the way it should or the senior executives requesting for certain things to be done or certain information that I have no idea about. Or stakeholders who would ask questions like “it should be just a simple change right? I’ve seen it on another website/app before. Can it be live tomorrow?” “Aren’t we agile”. Or my favourite one, can we please have resources for this special project? Anyway, I have learned that these are all part of the job and the more I deal with these issues, the better I get at handling them the next time. And with time, I get better at managing expectation and communicating to stakeholders and senior executives.
Anyway, my point is that every job has its goods and bads, whether developers, team leads, managers or C-level executives and as long as we keep an open mind, have a growth mindset and believe in ourselves that we can do it, we will be ok.
If I looked back at my career, the leaders who made the most impact to me were the ones who empowered me to think for myself and do the right thing even when they are not around. And this is what I want to replicate with my teams. When we do this right, we have the pleasure of leading high performing teams made up of very smart and capable people.
So let me leave you with my favourite picture that perfectly sums up the type of engineering leader I aspire to be and this quote on leadership, by John Maxwell who is a well-known author and speaker on leadership.
“A leader is one who knows the way, goes the way, and shows the way.”
If you enjoyed this article, you might like to check out my latest book on engineering management.
A practical guide for engineering managers at tech companies.
The Engineering Manager’s How-to Guide is very targeted for engineering managers, and in this book, you won’t find generic advice like having regular 1:1’s, giving feedback, etc. Yes, those things are absolutely important, but they are not specific to an engineering manager’s role. It’s my goal to make sure this book provides a concise and actionable guide for engineering managers, the specific and niche content for engineering managers that you won’t find in other leadership and management books.