I previously wrote “1:1s and Mid-Cycle Check-Ins in Silicon Valley Tech” and “Performance Reviews at US Tech Companies”, sharing what I have learned about how Silicon Valley tech companies evaluate employees, and how to regularly seek feedback and help from your direct manager on your performance and career development. From those posts, I also learned that many readers are interested in how to become an engineer who can stand on their own.
I am very interested in self-improvement and career development myself. From my own experience, what I have learned from books, and the chances I have had to discuss and learn from more senior engineers and higher-level leaders, I have organized what I have internalized into this series of career growth posts.
When it comes to career development, the most important thing I have come to realize is the ability to observe and reflect on yourself. We see many success stories of great engineers, and it feels like they did the right thing at the right time, and their careers took off. If we do not have that kind of foresight, we can at least practice hindsight. Hindsight means keeping a record of what we have done, and trying to discover which parts we did well, and which parts we did poorly.
Everyone knows the normal distribution in statistics. If we think in terms of abilities, the distribution of people in the world for any given ability should also look like a normal distribution. If one of our abilities is more than one standard deviation above the norm, or even in the outstanding range of two or three standard deviations above, we should find every way to use that skill more. We should look for career battlefields where that kind of ability is the main requirement. That is where we can best demonstrate our value, get the most done with the least effort, and achieve the most.
If some area falls in the negative standard deviation range, we should find every way to avoid having to compete head-on with others in that field. If we can raise it to a positive standard deviation, of course that is good. But if it takes too much energy and only brings us to the middle level, considering the time cost and the final output, we might seriously consider giving up further investment in that direction.
A book I have read and highly recommend is “The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact”. At a book event with the author a while back, I asked him a career development question: “Should we strengthen our strongest abilities more, or spend time making up for our weaknesses?” His advice to me was to build on my strengths, and strengthen the related abilities in the skill tree together, almost like building a “mountain” of skills (shaped just like a mountain). The peak is our most important, strongest ability, and the related abilities on the side peaks should also be raised in line with the main peak. But for abilities that are further away, we can decide by interest whether they are worth spending time on.
Analyzing your own abilities also takes a lot of effort and experimentation. One rule of thumb is this: if you find you can usually do something faster than other people, and you do not feel much pressure doing it, that is probably an ability where you sit in the positive standard deviation range. If you often have to work overtime, and you are often stressed and nervous about the results, that is probably an area where you are weaker, in the negative standard deviation range.
The above is of course a very general, very high-level reflection. I have been busy lately, so I can only share a small piece at a time. XD
How do you evaluate your own abilities? Do you have experiences of foresight, or of looking back and summing yourself up well? Feel free to share in the comments.
Also in this series: How to Keep Growing Your Impact Inside a Company and The Many Kinds of Communication at Work.
This post was originally published on my former blog, 「半路出家軟體工程師在矽谷」, on November 7, 2020. The blog is now offline, and the text is preserved via the Wayback Machine. It has been lightly edited for this site.
