I Missed Two Promotion Cycles Because I Lacked Leadership Skills

I had only myself to blame

My manager said that she would promote me by the end of the year “if I could be consistent with my effort” during our 1:1 at the beginning of the year. That meant I would miss the two promotion cycles before I was “ready” for one.

I asked, “Why?” She painstakingly gave a list of feedback and opportunities that would help propel me to become a senior leader. None of the feedback concerned technical skills.

She said my technical skills were better than some of the senior members of the team. She did not doubt I could execute a project well and design great systems. “One of the biggest feedbacks for you, Edward, is your leadership skills…”

She noticed that I was perplexed with what that meant. She shared her screen with a list of feedback from other team members and pointed out every point of what “leadership skills” entail. It was a laundry list, and by looking at them, I took note of the three big criteria that enhanced my leadership ability.

Here are the three takeaways on why most engineers don’t get the promotion that they want. Learning the lessons helped me land that promotion by the end of that year.

1. Focusing too much on deep technology

Deep technology is a great way to be a subject matter expert in your field. However, focusing too much on deep technology often numbs your vision of what matters — to drive business results!

When I jumped from a Big Tech company to work for a startup, the first thing I did to make an impact and influence other engineers was to introduce them to a more useful library for the team.

In a big tech company, I saw someone who introduced a new technology or system to the team, which helps increase efficiency and can impact the team. I saw lots of promotion cases where the developer introduces a new technology or persuades a new design to the team that it will become beneficial to the team — only after they get promoted that they fully abandon the project.

However, things are less political and more pragmatic in a startup. I was dogmatic with functional programming. I treat Scala and functional programming as a religion instead of a tool.

I had that hero mindset, “If I could persuade and introduce this new technology to the team, it would be an impact that I made on this team. And this impact will propel me to move up, and …. $$.”

The team technology stack uses Scala finagle tech stack, less prevalent than Cats or other functional programming libraries. Therefore, I wanted to introduce the Scala Cats library to the team to increase productivity.

Introducing something new to the team is very tough. The team’s staff members are especially often very skeptical about what this new library brings and how it will benefit the team.

I first showcased a draft and explained why this would help the developer’s efficiency. I had to convince everyone why we should go with this route. Oh boy, did I spend a lot of time and energy in back-and-forth discussions.

Each attempt resulted in pure rejection. In each proposal, they would ask, “How does this help move our business?” I couldn’t give a more convincing reason for introducing a single library to increase the business’s revenue.

After a couple of rounds with the team over a few weeks, I had a scheduled meeting with my manager. “It is great that you are passionate about Scala and functional programming. However, you must jettison that dogmatic mindset and treat those as tools. It doesn’t matter what tools that we are using. If the company decided to switch all of our technology stack to Kotlin in the future, then the impact of introducing such a library is completely useless.”

That feedback hits on the nail. I had spent numerous days and nights focusing on the wrong problem. I was too attached to the technology that I was using.

I felt like a person who had been released from a cult. Suddenly, it gave me more clarity about what “high impact” is.

Staying relevant with new technology is important for engineers, and being good at your technology is paramount in solving problems efficiently. However, your focus should be on understanding how and what is best to solve business problems and help move the needle on team metrics.

2. Closed-minded on receiving feedback

Everyone says that they are open to feedback. In reality, when they are given the feedback, most of them will push back. This is one of the soft skills that is easier said than done.

Why? Because the great engineers are stubborn and have a high ego. They are coming into a company and thinking of making a difference and impacting the company. They didn’t go into a company with a mindset of removing all things that they had learned before and were willing to become a sponge and receive feedback again.

They think, “They hired me because I have an awesome skillset to bring to the table. Therefore, I will establish myself and become a hero by introducing some great revelation to the team so they will be grateful.”

You have to change your mindset that feedback is a source of new ideas and creative solutions because feedback is a tool to provide areas of improvement in your blind spot.

Being open to feedback is also crucial for building trust and respect within the team. Being perceived as someone who doesn’t value others’ perspectives can strain relationships with colleagues, supervisors, and subordinates. This can lead to a less collaborative work environment and may even impact your ability to effectively lead or be part of a team.

I used to attach myself and treat code as a craftsmanship. It is a good attitude to treat coding as craftsmanship. However, one downside is being too attached to your code — and thinking that the critique on your PR was a critique of your art.

I have learned the hard way to get over that hump — treat comments on a PR as a curiosity instead of judgment.

I used to have code reviews that would expand to 50+ comments, and I felt brutally attacked and self-doubt in my coding ability. I defended every question asked and gave examples and points regarding why it was better to do it my way.

To fix this, all I have to do is remove my ego and be open-minded on receiving feedback. If the reviewer discusses a better alternative, and if that alternative is objectively better than the current one implemented, it’s okay to change one’s mind.

By constantly being open to receiving feedback, you can iterate much faster and deploy your code sooner. This helps leave more time and space for you to work on tasks and think about more meaningful ideas for the team’s success.

3. Not stepping up

Stepping up is a criterion for someone to see you as a senior engineer. This is one of the main feedbacks from my manager and one of the opportunities that took more than two promotion cycles to acclimate.

If you want to increase and become a leader in your team, be opinionated.

As an introvert, it is very daunting to give an opinion to a group of engineers at all levels and have to defend your opinion. Every expression of an idea is fair and up for debate.

I used to think, “I need to prepare this idea thoroughly so that I can give reasons and defend my idea and not look stupid.” In other words, I don’t want to “lose face”.

In reality, what matters is participating in the idea generation. By participating in the idea generation, you contribute and are seen as a thought leader. You will receive a few setbacks and questions regarding the validity of such ideas, but that validity will be good for your thought generation in the future. You become better at your persuasion skills.

The more you preach about functional programming or the more you become opinionated about code review, the more they will go to you for questions and decisions.

If you step up and help a junior member of the team with their struggling tasks, you are demonstrating leadership and building trust in your team.

Why is simply having opinionated a great win for being a senior engineer?

Because most engineers prefer to avoid making decisions, if they can NOT make decisions, they will not make any decisions. That is why an opinionated framework exists and is very popular because it removes the responsibility of stepping up from an engineer’s job. “I don’t have to step up and give inputs on how I should design the code because a framework will do that job for me.”

Therefore, it accentuates those willing to constantly step up and be opinionated to become a technology leader.

Recap on developing leadership skills

Most feedback to becoming a senior engineer is about leadership skills. You can write code that gets approved and shipped to production. There will be nothing wrong with you shipping high-quality products.

Focusing on your technology stack is paramount to creating a compelling solution. However, focusing too much on the technology has a diminishing return — you better have your attention on high-impact projects. In addition, receiving feedback is easier said than done. We must constantly remind ourselves that feedback is good and detach our ego from the code we wrote.

Last but not least, step up and become more opinionated. You have to play in an offensive mindset and painstakingly provide ideas and opinions to the team to increase your authority and create trust. With authority and trust, questions and decisions started coming your way.

These are landmines that I hope you don’t stop when you are navigating through your journey. Have you ever experienced similar feedback and opportunities? Share your experience by leaving a comment in the comment section below!

If you like this content, you will also like this article: How Opinionated Help Design Helped Decreased Complexity.

Originally Published in https://pathtosenior.substack.com/