Early in my career I learned that there are 3 types of value to an employer:

• Increase revenue (grow the top line)
• Decrease expenses (grow the bottom line)
• Reduce risk

In an ideal world your employer would understand and value all three equally and you'd be free to pick and choose what you work on in order to be most valuable.  Even if your employer could choose to be that balanced, the market wouldn't let them.  Instead, you have to read the tea leaves (or the corporate memos) to figure out what's what.  If you align what you're working on with what's most desired, you're in for a Big Swinging Payday.

Alright, that's the general rule.  Let's get a little more specific for the folks out there who write software for a living.  There's a development analog for each of the 3 types of value listed above.  In matching order they are:

• Increase capabilities
• Decrease effort
• Improve process

You increase your capabilities (and those of your group) by learning new technologies and tools.  This increases the range of what you're capable of delivering.  There are times when providing what couldn't be done before is incredibly valuable: typically at the start of a project or during project turnaround.  At the beginning there's a much better chance that new capabilities can be incorporated into the project.  This also happens when the project hits a, "We've got to change because what we've been doing isn't working" point.  Another way to look at it is that if things are moving along, don't risk getting in the way with offering something new.

You decrease effort by bringing efficiencies to the group that either didn't exist, or were poorly exploited.  The simplest way to do this is to automate the living daylights out of everything you can.  Automated builds, testing, documentation, etc. will help developers focus on the things that only they can do: write code to solve problems.  This doesn't mean that developers will end up working less, it means that given the same amount of time/effort they will produce more.  This is easiest to do at the start of a project (before things get messy), but is actually more valuable in the middle once bad habits and thrashing have begun.

Improving the development process is almost always valuable, but becomes particularly important between the middle and the end of a project.  This is due to the fact that from the middle to the end is the time when the project needs to be set up for maintenance mode.  If you wait until the end to do that then you won't have nearly enough time to get everyone used to the process.  In addition, from the middle to the end is when people will be rolling off the project and the level of talent should be constantly increasing until right before the end.  This is not to say that process isn't important until the middle.  Chances are that when a project starts there will be a period of process development that lasts the first quarter of the overall time.  Then people settle into a groove and crank things out for a while until they hit the halfway point, when it becomes time to plan for the end of the project.  By improving the process, you make development more predictable which lets those around (and above) you plan better and control the end-of-project glide path.

Notice that I'm talking about relative value at specific points the the project's lifetime.  All of these things are valuable and you'd be well off learning how to bring any of them into your organization.  If you want to really capitalize on them, though, take a look around and align what you're doing with what's most needed.