How to operate at work

Motivation #

It has been quite awhile since I’ve been trying to figure out how I want to operate at work.

The company expects me to be more of a tech lead because that will allow my manager to scale out and get work out of a larger workforce. And while that does have some merits, it isn’t the best way for me.

1. It isn’t fun and I don’t get to learn much.
2. It isn’t what other companies expect from SDEs, so it decreases my employability. (For example, Facebook and possibly both Google and Microsoft expect their senior engineers to contribute a lot of code).
3. Even within Amazon, they’ll look at my deliverables at the end of the year. If I only work through others, I won’t have a lot of tangible stuff to show forth.
4. I’ve also heard from my manager that whatever I do inside the team isn’t going to take me to the next level, so why do that as much?

The other side of the story is that not behaving as much of a tech lead could lead to some reputational loss, but I think that’s an acceptable tradeoff.

So, I’ve written down how I want to operate below. And hope to refer to it every now and then so as to keep me focused.

Ideas #

1. Today, I often go out of my way to help others or to point out gaps in their design decisions. Instead, I should give feedback or opinion only when sought and focus rest of my time on whatever’s on my plate.
2. Build stuff: I should focus more on building cool stuff. For e.g., what projects I can pick up next or what new ideas can I prototype and propose?
   1. Avoid meetings that won’t add direct value to me.
   2. Leave standup early when possible.
   3. No need to closely monitor team Chime groups.
3. Code a lot: I should be actively coding all the time, whatever the complexity of those changes.
4. Learn a lot: I should find time to learn on the job. It could be a new technology (such as Fastai), Machine Learning proposals from the science teams, Ops meetings or POA talks.