A recent layoff impacted my direct manager and many of my colleagues in my department.
They said they are having a "reorg."
Upper management said they are still very optimistic about the company's future and have a pivot to focus on another business strategy. Therefore, they want to condense the talent pool in all departments and put the best of the best in one single department.
I was sad and shocked about the layoff regardless of the bull sh*t corporate talk that the people who survive are the ones who did better in their performance. However, this incident gives me a quick epiphany on approaching performance as a software engineer.
You don't need to be the best to make it. You need to be good enough.
Sure, you may be promoted later than your exceptional peers. However, the effort you must put in to become exceptional doesn't warrant the output.
To be exceptional, aka GOAT, you need to invest upfront in whatever you do.
Kobe Bryant is an exceptional basketball player. However, he invested his time and energy in countless hours, making bets that he could make it to the professional basketball game. Elon Musk invested his life savings and precious time to become an exceptional tech entrepreneur.
Most people think that they are extremely skilled. Thus, they can get exceptional outcomes.
That is wrong.
What we hear from a lot of the media is often survivorship bias. There are many more examples that an extremely skilled individual didn't have as good an outcome on becoming a professional basketball player or tech entrepreneur.
They forgot a big factor of what every deemed "exceptional" - luck.
Being lucky is a huge factor for someone to have an exceptional outcome.
One of my colleagues, a high performer, invested a lot of time and effort to get that promotion. He responded quickly to every comment in the thread, giving him the subject matter expert in the system and the field from the stakeholder. He also spends much time responding to every incident in our system. Whenever I go to Slack to check on him, his Slack status is always on because he has so many feature requests and asks from the stakeholder that he must spend more time resolving those issues.
On the other hand, what are the risks if you are not striving to become number 1 in your team?
You may not be promoted first or pulled into the most important initiative project of the company. However, they will eventually promote you through time horizon once that best engineer gets promoted.
I am not saying that you shouldn't strive to become good. You will still need to be good. But you don't have to become the most skilled person in the room.
You have to think about the distributed outcome of the effort that your input. See if that input is worth it.
All good marathon runner knows that pacing properly is integrated to race day. Pacing is a subtle art and depends on the runner time keeping skills. It is easier to set your own pace to have someone in front of you and follow their pace. Having someone in front of you gives you a caliber on how well you do with the rest of the people. The second runner in the marathon can always beat the first runner; they pace slowly with the first runner to prepare to sprint in their last mile.
The same goes for business. Pioneers are often glamorized as having a distinct advantage over late movers. However, being a late mover has the distinct advantage of not stepping on the failure of many pioneers. In addition, paving the road is much more costly in terms of monetary resources and time. The later entrant can learn from the experience of the pioneer, enjoying lower costs and making fewer mistakes as a result.
Whenever the platform team publishes a new library, our team hesitates to be the first volunteer. It is because being first on library adoption becomes the experiment and test of that library since that library hasn't been tested through the production battlefield. Your system is more likely fragile, and your team may need more time and resources to understand any nuances and gotchas to operate with this new library. Being the second or third mover in this scenario will reap most of the benefits while minimizing the trial and error phase of the library.
The same goes for software engineering. Not being the most skilled person helps decrease the amount of stress and effort in paving the road to success in the company. You can always look at what the most skilled person do and slowly following their footstep to become a skilled engineer. Knowing the expectation to become a skilled engineer helps you become one much faster because you have a clear path to improve.
Although in competition, being second means you are a loser. In life, both parties can co-exist and still win.
It takes a lot of resilience to live as second, without being to feel 'not good enough.' To live as the second is not Second-Best. The second is a role. The second is a position that has its unique requirements. It's not a judgment.
Being the second can help you focus on your craft. You no longer need to think, "How can I keep this high-performing level output and keep up with my position?". Instead, you start working and learning everything in the long run. You can sprint to become the first if you want, but you are pacing yourself to ensure you can have slow, steady growth that can sustain in the long term.
Becoming exceptional requires a lot of time, effort, and luck. Luck is a big factor in who will be promoted or layoff. Therefore, before you invest time and effort in making bets on becoming a 10X software engineer, think about the distribution outcome of that effort.
Being second comes with its fair share of advantages, just like in marathon running and business! When you're a late mover, you can take notes from the mistakes made by pioneers and avoid making them yourself. Plus, you can enjoy lower costs and make fewer errors.
In software engineering, not being the most skilled person can help reduce stress and effort. Instead of struggling to be number one, you can follow in the footsteps of those already skilled and experienced. This way, you can progress more efficiently and have a clear path for improvement.
Living as second lets you focus on honing your craft and working towards sustainable long-term growth. It may require a bit of resilience and a change in perspective, but recognizing that being second is not a judgment, but rather a position that can lead to personal and professional success, is key.
I’m Edward. I started writing as a Software Engineer at Disney Streaming Service, trying to document my learnings as I step into a Senior role. I write about functional programming, Scala, distributed systems, and careers-development.
Subscribe to the FREE newsletter to get actionable advice every week and topics about Scala, Functional Programming, and Distributed Systems: https://pathtosenior.substack.com/