...
Taking Credit: As an old saying goes - the competent IT admin fixes problems before they happen. And then the PHB wonders why he is paying $X for new servers and infrastructure when the current system works fine. IT people should be more proactive about boasting about what they do. Sure, this is distasteful to lots of technical people. But guess what? Everyone else brags and lets their manager know (in a not so subtle way) of why they deserve more money: "I sold $YYY to MY clients". So the IT team needs to take credit for sales they help with. If an employee used a lot of resources to construct a portfolio for a client, it isn't all to the trader's credit. YOUR software and hardware helped him run simulations and generate the portfolio. So add THAT to your pitch. If one of the IT workers stayed up half the night so a client could get some figures/data - he should get credit instead of letting the suit tell the story. A knight wouldn't have killed the dragon unless he had a magic sword - but the armorer doesn't get any songs written about him.
...
If I could change one thing in my personal management, over 30 years in the business, it would be to advertise and promote myself, rather than to passively expect my achievements to be noticed. The passive approach usually worked when I was working with a team of other programmers, but it was spectacularly unsuccessful when I was the only programmer, or chief programmer, in a non-software business. The passive approach was also much more successful in my younger years, than in my fourties. People outside software expect programming to be easy, and, moreover, if the delivered product is good, and produced without visible project stress, they only see that as confirmation of the fact that it was easy. If there are visible problems, which happens on 99% of projects, then they see that as evidence of the incomptance of their programmers, and think that solution is to let the current team go (by no responding to wage requests) and get a better team, at the same price.
I think that "under promise, and over deliver" has to be part of the solution, in sharp contrast to the usual gung-ho, iron-man approach of programmers to estimating and promising.
An anecdote of how non-programmers view software is a discussion I had with my mother about web development. I mentioned to her that it is usually more difficult to build a complex site, than it is to build a pretty interface, and I mentioned google an example of a complex site. Her blank expression prompted me to suggest "You don't think that google is complex, do you?", and she just said, "Well, not really". Obviously, to her, a simple text box which searches the web is not complex! :)