I still remember the minute the idea got into my head.  I was at my second full-time job as a web developer. Little did I know that I would soon figure out how to get the promotion I actually wanted. And it wasn’t the way that I thought it would happen.

Let’s rewind.

The manager who previously led our team left for a different company. The company promoted Jing, a key member of the team.

Jing was a fairly easy person to look up to. He was the first member of the team, always seemed to know all the answers, and had a calm and patient demeanor.  He was always willing to help anyone out. He put in really long hours. Nobody would have ever said anything bad about Jing.

He wasn’t the oldest member of the team. In fact, Jing was in his mid-twenties, which made him younger than other members of the team.

At this point in time, I had never worked gone through a manager change at work.  I soon learned that it was typical for the new manager to talk to each of the members of the team in a private 1-on-1 meeting. It gives you an opportunity to get the relationship off on the right foot.

Jing scheduled time for the two of us to talk. And we did.

I always felt uncomfortable talking to previous managers. I would try to get the minimum amount of direction I needed from them, then move forward on my own. Jing made me feel different, though. For some reason, I wasn’t nervous about talking to him, even though he was my manager. I just trusted him.

We talked about the transition for a while. Then, out of nowhere, he asked me a question that would ultimately change my career:

“Where do you see yourself in the next 2 to 3 years? I want to see you successful, happy and continuing to be a happy member of the company if at all possible.”

He put me on the spot, and I wanted to give the right answer. It was clear that he genuinely cared about the next few sentences that would come out of my mouth. I thought for a few seconds and responded:

“Ultimately, I’d like to lead a team and I’d like to make progress to get there.”

Believe it or not, prior to Jing asking me this question, I had no plan, goals, or aspirations. I was just going with the flow, doing some work, doing a good job and trying to get as much done as I could.

Jing told me that good leaders are the ones who listen to other members of the team.  They help out other people, even when it’s inconvenient. They take ownership of technical aspects and gain the trust from the rest of the team. They make other people believe that they always have things in control. The best leaders prove themselves to the team time and time again.

He told me that people notice natural leaders, the people who do these things, and they decide to put them in leadership positions down the road because of it.

From this point forward, I wanted to get as much responsibility as I could to prove my value to both Jing and the rest of the team. At the time, I wanted to do this to put myself in the best possible position to succeed.

Fast forward a couple months. Our team was about to start a new initiative.

It was 2011. Back then, daily deals websites (like Groupon) were all the rage. Our company was chasing that trend too, and our site was going to begin offering “deal of the day” offers too. This was considered a big opportunity for the company.

This was my opportunity to prove myself to the team.

So I worked hard, longer hours than required. I worked on getting other people up to speed with the work I was doing. And after a fairly long process, we launched the new daily deals product.

I made a couple of mistakes around how I worked with the product managers at our company, but I took on a big responsibility and things worked out. Everyone on the team recognized the key role that I played. And the recognition of the work felt satisfying.

I continued to work on that project. I added features, fixed bugs, and occasionally caused some bugs of my own.

Everything was stable. But then our team encountered a pretty challenging situation.  

We had to replace one of the core aspects of our site, user login, across all our projects.  This included projects that I was far removed from, and the project I was working on as well.  This was a fairly intensive process.

We shipped out the changes and quickly realized there were numerous problems with our updated code. User login, a fairly basic feature that our users needed to get things done, was no longer reliably working across all our applications.

I decided to dig in a little to see what was going on. I was personally involved in building the initial user login system, but I hadn’t been too familiar with the updates.

Our team built our original solution with an entirely different thought process in mind – a solution that didn’t map well to what we needed to at all. Looking through the code, the existing solution was already convoluted and complex due to the requirements. Fixing the bugs would require the code get even more complicated – opening up the chance for introducing even more bugs. There needed to be a ton of workarounds to deal with a handful of fairly nuanced edge cases that were revealed when we launched the new feature.

One team member wanted to completely rewrite the solution, which he ultimately did (and his version came out much cleaner), but we needed to ship this out as soon as possible. After all, user login was broken. This was not a good thing.

As a team, we were in a tough situation. But personally, I saw this as a great opportunity for me to prove my value and stand out.

It was clear that this was a serious opportunity for me to prove myself to the team.

So I…

  • Dropped what I was working on
  • Jumped on the problem
  • Documented the broken edge cases
  • Discovered where the problems existed
  • Presented them to the team.  

I then wrote the code to handle these edge cases. Though it wasn’t very clean code (it was some of the messiest code I’ve ever written), it managed to deal with the problems in the environment we were operating in.

Months later, we removed the entire system and transformed it into a smart, well-thought out solution from of the cobbled mess I helped produce. But the cobbled mess I produced helped allow users log into our site for months. I felt like I had made a significant contribution to our team.

A few months later, our team would be shaken up again.

The VP of Engineering of our company decided to move to Australia. The company promoted Jing to fill the role. And one of my teammates, Michael, was promoted to fill Jing’s role. I was a little jealous, but intuitively I knew it was the right call. Michael had so much more experience than I had, had a ton of respect from me and the whole team, and was an incredibly experienced developer. It really was a no-brainer.

Our team was tasked with a new project, one that had fallen behind and was in need of a fresh start. The project was a fairly complicated ad network utility. The path to launching the product had a number of requirements, we needed to work with a number of different teams, and the project was so big and complicated that no single person had all the answers.

I worked on other projects earlier in my career, but none of them had this clean a slate and so many unknowns. It was clear that this was a very difficult assignment. And it was motivating.

This was another opportunity for me to prove myself to the team.

So I worked really hard. I stretched myself to make the biggest impact I could, while still working together with the other developers on the team, offering help when I could, and being as productive as I could be.

I would need to meet with developers from other teams to get things done. I did this because they often had unique insights into problems that I hadn’t considered.

But, as is the case in the real-world, I was asked to execute on ideas that I thought were terrible: I would bring this up to Michael, saying:

“Michael, writing our code this way, which the team is suggesting, it’s is absolutely stupid – it just involves a lot of work for no reason.”

Michael would respond:

“I know, but can you do it anyway?”

There was something about doing the grunt work that nobody wants to do that got me… well, excited. I was able to make my manager’s problem go away, by writing code in a way everyone on my team agreed wasn’t the right way. I sort of laughed it off to my coworkers and they appreciated they didn’t have to do it.

We eventually launched the product. And everyone considered it a success. Everyone, from the product managers, sales team, and developers, was excited to have built something really cool. The work we did on the ad utility network project was part of a larger effort to implement in-store PayPal purchases at Brick and Mortar Home Depot locations, and it felt really cool to play a role in something that made an impact for a large consumer company.

But then, things were shaken up again. I still remember the day it happened.  

Michael told me he was leaving to move on to a different company.  At this point in time, I was one of the most senior members of the team.

You might think that I was excited to have Michael leave. After all, this appeared to be my moment to step up and finally get the promotion that I had so long desired.

But something was different.

Over this entire process, I learned something important about myself.

I ultimately had no interest in becoming an actual manager.  

As a developer, I talked with Michael about his day to day. I jokingly made fun of him for going to so many meetings. I wrote code in foolish ways, because I could do it in a week or two and that was easier than Michael making a case against it. I learned a little about what it takes to be a manager. It’s a lot. You need to keep the people above you happy, work well with other teams, and make sure that the developers on your team stay happy and motivated too. This is a ton of work. In a large organization, it’s not uncommon managers to lean in a particular direction. They’ll either prioritize making their team happy or prioritize making their superiors happy. It’s difficult to not fall into the habit of doing one or the other.

I had been lucky. I had two really great managers, who really cared about the people who worked underneath them and built a strong reputation with their superiors. I had a great relationship with them, and I did my best to help them look good, for the good of the team.

I had no desire to be a manager…  And why would I?

By helping my team the way I did, I ultimately achieved my goal, I just didn’t realize it at the time.  My ultimate goal of being a manager wasn’t based on reality.  It was based on being the person that I had saw my manager – Jing – being. He was the person who took responsibility for things as they came up. He was the person who jumped to help out when other people needed it most (but only in situations where involvement was welcome).  

But I had become a different type of person. I became the person who people looked up to not because they had to, but because they knew they should.

Being that person has tremendous upside. I had expertise in areas of the code that nobody else had. People frequently asked me for help, and when they did, I would happily give my help. But then I got back to my own work. If I found myself in a situation where dev leads from other teams wanted my help, I connected with them. But I also got to go back to my own work, too.

In short: work was incredibly fun. I was a high-impact employee at a company that was doing cool stuff, playing the role that was right for me.

Managers play important roles on teams. But not everyone needs to be a manager.

I’d had multiple really good managers. They were a critical part of my happiness. And through the process of working with them, I learned two key things:

  • Not everyone is fit to be a manager
  • If you’re not one of those “manager people,” that’s ok. You can still make an enormous impact.

I decided not to try to land the manager position on my team. Instead, I helped convince a worthy coworker, a smart guy named Bill, to step up and take the position. Bill remained the manager of the team until I left, and I’m convinced he did a far better job in the role than I would have.

Going through this mindset transition taught me a very important lesson about how to get the promotion you actually want.

The surefire way to get the promotion you actually want comes down to one thing:

Focus your efforts on proving yourself to the team that you’re working on. If you’re working on a good team, with good leadership – everything will work out for the best.  

Maybe “climbing that corporate ladder” just isn’t important in the grand scheme of things for you. And it doesn’t mean that you can’t be successful. In fact, if you instead opt for what you do best, you can actually become more successful and help your company out more in the process.

If you found this post insightful, share it on Facebook and Twitter using the buttons below.

AuthorKen Mazaika

Ken Mazaika is the CTO and co-founder at Firehose. Previously, he was a tech lead at WHERE.com (acquired by PayPal) and a member of the PayPal/eBay development team in Boston.

Leave a Reply

Your email address will not be published. Required fields are marked *