How a Software Engineer went from SW2 to Principal in 4 Years [StoryTime Saturdays]
How To Get Promoted FAST. How an engineer received 4 promotions in less than 4
Happy Saturday my amazing readers,
I hope you’re all having an amazing time. I’m flying to India tomorrow, and am super excited about that. Will be seeing my family and some friends, and have an amazing time. I will be traveling quite a bit. Continuing with the theme of meeting my amazing audience, drop your locations to me by replying to this email/my social media. If you’re in India, I might just drop by your city.
In this post, I will cover a very interesting story that I came across. It is the story of a true Rockstar Software Engineer. He went from a measly Software Engineer 2 to a Principle Tech Lead Manager in less than 4 years. Today, we’ll cover how.
The estimated total pay for a Principal Technical Program Manager is $165,559 per year in the San Francisco, CA Area area, with an average salary of $144,822 per year.
-According to Glassdoor. This goes all the way upto 322K for more well-established companies.
Background
This story was first covered on Rahul Pandey’s YouTube channel here. A team was struggling to reduce their operational costs on their services. While the engineering team focused on engineering heavy solutions, one creative engineer started digging into the problem. He noticed that there were a few clients that added a lot to the costs and not as much to the revenue. By dropping the costs from these clients, this problem would be fixed. Without the need for expensive engineering. And much quicker. This was allowed him to gain lots of promotions.
The highlights
This story will cover the following ideas
Sometimes you have to cut the Gordian Knot. Software Engineering can often be about untangling a large set of problems. Sometimes engineers have to come up with intricate solutions to untangle the threads. Other times, you want to cut right through. Featuring a story about Alexander the Great.
Engineering is good. Engineering in the context of economic solutions is much better. Instead of approaching things as a pure engineering problem (which would have been hard), this engineer tried to fix the economic aspect (make the solution more sustainable). This was much better.
Broaden your horizons. The solution that our beautiful rockstar came up with is one of the major examples of Pareto Principle (80-20 rule). Every software developer serious about their career has to read a lot. Or expose themselves to different ideas. Being able to code is cool. Making the correct decisions is much more important.
This is not a post you want to miss. Let’s get funky.
[FREE SUBS]To buy access to this post, use any of the following links. The price is 3 USD. Once you send the payment, message me on IG, LinkedIn, Twitter, or by Email:
Venmo: https://account.venmo.com/u/FNU-Devansh
Paypal: paypal.me/ISeeThings
Or you can sign up for a Free Trial Below. Get 2 weeks FREE at no risk to you.
Alexander the Great and the Gordion Knot
I would like to start this post with one of my favorite historical stories. This story is the peak example of changing your battles to come out the war.
Back when Alexander The Great started his war against the extremely mighty Persian Empire, many people thought he was insane. The Persians were a powerful empire, and Macedonia was a comparative nobody.
Thanks to early victories, Alexander arrived at the town Gordium. There lay the famous Gordian Knot, a tangled mess of rope. Legend had it, that anyone to untie the rope would rule the world. Keep in mind, that the Greeks were huge believers in this stuff. Thus it was very important to get untie this.
Alexander struggled with this for a sec. The more time he spent, the more uneasy his soldiers (and he himself) would become. In the end, Alexander declared that the legend didn’t state that the knot had to be untied in a particular way. So he drew his sword, and cut the knot, untying the thing in the process.
Why am I telling you this? Software Engineering is very similar. Real world problems don’t come with an instruction booklet. However, our minds are experts at going into autopilot and attempting what they’ve always done. This is efficient when the problem is similar to others we’re familiar with. However, when it comes to new problems, this can be a detriment. Chances are you will be stuck in the same old kinds of thinking. The assumptions and constraints that helped you get to the problem, will stop you from solving it.
So how can we make sure that we don’t fall into this trap? Let’s cover that next.
Keep reading with a 7-day free trial
Subscribe to Technology Made Simple to keep reading this post and get 7 days of free access to the full post archives.