Scaling oneself as a Software Engineer

Tuesday. October 24, 2023 - 2 mins

If you’re working in tech, and/or are interested in startups, chances are you’ve come across the word ‘scale’ quite often. Masters of scale, blitzscaling, “does this business model scale?”, etc.

The importance of scaling is pretty self-evident in the world of entrepreneurship: you want to meet growing demand while maintaining quality, without resources growing linearly with that demand.

As a software engineer working in a team of ICs (individual contributors), I have heard of the notion of ‘scaling oneself’ plenty of times in different contexts. But I had delayed diving deeper and really exploring the idea until one day, I found myself starting to stretch myself thin in an attempt to help and unblock teammates and x-org partners. While seriously considering the option of creating a slack bot trained on some of the FAQs, I realized that this would be a good time to start to scale myself.

I brought up my thoughts and questions on scaling to my monthly chat with an engineering manager at Pinterest, and was able to gather some concrete examples that helped me better understand the idea.

Writing and sharing helpful context.
Giving talks of learnings from past projects.
Keenly observing and connecting the dots for potentially related / recurring patterns of problems, for collective problem-solving. For example, you can introduce two engineers in seemingly unrelated teams who are both experiencing a similar problem in a shared tool. If both engineers were in fact experiencing a symptom of a shared root problem, there is immediate benefit in pooling their knowledge and potentially developing a more efficient solution than if they tackled the problem separately.
Empowering other ICs to scale themselves. This way, your scale factor could grow exponentially because your teammates’ scale factors are now greater than 1.

A common theme here is that the knowledge transfer is now no longer 1:1, but 1:N, and the additional resource for an increasing N is relatively small if not zero.

As an engineer who loves finding efficient solutions to problems, I find the notion of scaling oneself a promising and sustainable way to being a resourceful teammate and x-org partner (“meet growing demand”) while continuing to give myself the time for deep work (“while maintaining quality”), and without putting a strain on myself (“without resources growing linearly with that demand”). After all, you can work only so many extra hours and make tweaks here and there to better ‘manage your time’ before the 24 hours run out.

SOYOUNG PARK

eng @pinterest