Thanks for sharing. I would instead describe this list as "principles" instead of a checklist. A checklist is often used for a much more specific scope with very specific items. These are not applicable to any specific time or scenario and have activities that are not very specific.
Here's my thoughts on a few of the items themselves:
"Follow the principles of extreme ownership." -- Unless the term "extreme ownership" describes something specific (like "Extreme Programming"), it should be reworded to clarify. What are these principles or what is 'extreme ownership'? Is it clearer to say "make sure you take ownership"? Or "don't waste time working on things outside of your domain"? Or "don't limit your focus to just those items explicitly owned by you"? The latter is approaching XP's "collective code ownership" / "shared code."
"Be reachable to other engineers" -- is this like making sure you're available? Like "check into the company Slack channel frequently"? "Make sure you reply-all to that 11pm email so everyone knows you were checking your email then?" Sorry: that sounds a bit cynical but it's easy to misread this principle that way. Best reword this one IMO.
"Avoid stretching yourself too thin to be effective" - this is a great tip but is it specific enough to be useful? How will I know when I've done this? I think I know the answer but would a junior engineer reading this list know?
"When dealing with politics, avoid it, but have right folks vouch for your work" -- this one is not specific enough for me. "Avoid politics"? Who are the "right folks" -- how would I know whether I had asked the right folks to vouch for the work?
"If you are under-utilized, ask your manager for areas to explore" -- IMO this works better if you can specifically say "I want to work on X" and bonus points if "X" is an item that you know contributes directly to high level goals for the company.
>> "When dealing with politics, avoid it, but have right folks vouch for your work" -- this one is not specific enough for me. "Avoid politics"? Who are the "right folks" -- how would I know whether I had asked the right folks to vouch for the work?
It is very difficult to avoid politics unless you operate in a total isolation. Every time I need to talk, to get consensus, to request, politics is involve. It gets much more difficult when folks are not in agreement with what you want to do.
Here's my thoughts on a few of the items themselves:
"Follow the principles of extreme ownership." -- Unless the term "extreme ownership" describes something specific (like "Extreme Programming"), it should be reworded to clarify. What are these principles or what is 'extreme ownership'? Is it clearer to say "make sure you take ownership"? Or "don't waste time working on things outside of your domain"? Or "don't limit your focus to just those items explicitly owned by you"? The latter is approaching XP's "collective code ownership" / "shared code."
"Be reachable to other engineers" -- is this like making sure you're available? Like "check into the company Slack channel frequently"? "Make sure you reply-all to that 11pm email so everyone knows you were checking your email then?" Sorry: that sounds a bit cynical but it's easy to misread this principle that way. Best reword this one IMO.
"Avoid stretching yourself too thin to be effective" - this is a great tip but is it specific enough to be useful? How will I know when I've done this? I think I know the answer but would a junior engineer reading this list know?
"When dealing with politics, avoid it, but have right folks vouch for your work" -- this one is not specific enough for me. "Avoid politics"? Who are the "right folks" -- how would I know whether I had asked the right folks to vouch for the work?
"If you are under-utilized, ask your manager for areas to explore" -- IMO this works better if you can specifically say "I want to work on X" and bonus points if "X" is an item that you know contributes directly to high level goals for the company.