I disagree with the assertion that managers don't look at code. When I've managed teams, I've looked at some of the output of every engineer - and a big one is code. But not the only one - emails, design documents, whitepapers - it all factors in.
But that's definitely not the only factor. If one guy is sitting in a corner and writing brilliant code but he's a beast to talk to, won't answer questions, won't share status and won't compromise when develoment issues come up - I'm not so sure he's an asset to the team. Especially compared to a guy who writes moderately decent code but can do all of the above.
Here's some stuff I look at when I'm in a position to give out rewards, but with the huge caveat that it is absolutely a gut reaction, cause none of this can be quantified:
- Status - is it clear, accurate, & timely? When discussed, is the person on top of the status or a little blurry on the current issues? Does the person have the right judgement to raise a red flag when something has caught on fire?
- Problem-solving - both asking and answering is important. Does the person know when to ask for help, or where they spinning their wheels indefinitely? Better yet, when others have problems, does the person help find the solution or become part of the problem? Even having the good sense to back off when the problem isn't in your area of expertise is worth a few points. Also there's points for going outside the group or the company, and going to sites like this, or other internet answers.
- Attention to process - usually this is pretty obvious - even in a non-anal-retentive company, if someone is bucking the system, it's seen in the chaos they leave behind them. If other people are cleaning up another person's features because they didn't adhere to guidance or architecture, then we have a problem. Bonus points go to those who figure out ways to make consistency and quality easier.
- Completion rates vs. bugs vs. complexity - get stuff done, but get it done right. Everyone's got a few bugs, but if the guy gets stuff done fast and buggy we have a problem. I generally find this isn't something that you can assess in the daily sense - it has to be looking back at a release or a phase or a fiscal quarter.
And other people's input. Frequently I've been in a position where various engineers were in charge of various parts of the project. Sometimes team leads, and sometimes just the owners of a particular peice of output (like "the build guy"). People LOVE to talk about the extremes - the acts of heroism or the frustration of the problem children. Usually in the act of following up hands on with those issues, I find out a lot about BOTH parties.
There's also a factor in there regarding Managing Humans. No engineer is exactly like any other. So they don't all shine in the same light. One writes brilliant bug free code, but another helps solve cross cutting problems that breaks everyone's code. One is great in person, one is better in writing. One is incoherent at 9:00 AM, one is out of here by 3:00PM. There's a certain need to step back, figure out what is most beneficial to the team and what might be a factor of personal bias (like the desire to kill that chipper 4:00 AM guy, just because I can't function until 11:00 AM).