As stated in other posts, it’s all about local system knowledge + tools
Survival (and bonus, stress..) is always linked to benchmark against team peers, not
external teams like another department, not the manager himself. If entire team is low-calibre, then it’s a problem for the manager, but rarely your own problem. (It might threaten your team’s survival…)
LG2: system performance. Most guys in the team probably aren’t so good at this kinda thing, unless the team has a specific mandate to monitor and fix performance.
LG2: test coverage. May affect your reputation, but once I figure things out I can often relax and test
LG2: code smell. May affect your reputation but is clearly a LGlp compared to getting things to work.
LG2: code quality
LG2: readability by the team lead. OK team lead may complain, but if it works then it’s relatively easy to improve it.
LG2: extensibility. Yang is big on this. Many books are big on this, but it’s an art not a science. Many team members probably aren’t good at it.
LG2: system stability such as occasional hangs. Often a non-show-stopper.
** eg: my VS2015 build tends to hang and I had to research on how to fix it — show-stopper.
All of the above are secondary to … “figuring things out” i.e. how to get something to work, at a minimum usability.
Design? See also posts on arch_job. Can be a real problem, because if your design gets shot down, you waste time on rework.