As the saying goes: when all you've got is a hammer, everything looks like a nail. C++ is the main hammer employed in game development and, inevitably, it gets called into service in all sorts of inappropriate situations.
Make sure you know some scripting languages. Python, Perl, Ruby, Lua, PHP (it's not just for web apps!), whatever. They're all fantastic in various ways.
Try and attain at least a passing familiarity with some of the unix-style tools and environments. Particularly unix shell scripting. It's pretty hard to find a more versatile system when you want to glue together disparate programs into an automated process. There are a number of packages which provide windows ports of such tools (cygwin being the most prominent example).
The big argument you hear (especially from non technical management types), is that not all the programmers know how to use language X or tool Y. This really isn't an issue. If you can handle working on something as complex as a game in C++, then you're you're not going to have too much trouble picking up a modern scripting language or tool or three as you go along.
Anything that needs to be done more than once is a candidate. How many late night final candidate discs have been borked by someone who has had too much coffee and pizza and too little sleep?
Scripting (particularly unix-style shell scripting) was built for this kind of stuff - moving things about, incrementing version numbers, checking files, collating disc images, performing sanity checks, starting burns, invoking test suites... all boring drudge work that humans shouldn't be trusted with.
Think beyond build processes through. Step back for a moment and look at the various production pipeline paths in your project. Where do you regularly see human error creeping in? Where do the stalls occur? Where are the bottlenecks? Are there any steps you could decouple from each other?
Do your artists require programmer help to add new assets into the game? Figure out how to bypass the programmer.
Don't trust your artists to keep within memory budgets? Make sure there's something that automatically sets off flashing red lights and alarms if budgets are exceeded.
Do your designers have to manually pull files from various places around the network to try out levels? Hack up a noddy little script with a simple text menu: "Press 1 to install 'Lava world', 2 for 'Ice world', 3 for 'Jungle world'"...
The other great benefit of automation is that it provides inherent documentation along the way. The source code for the automation tool is effectively a recipe that lists the steps required to implement the process. And like all good code, there'll be comments there that explain the rationale behind each step. Right?
Well... obviously. But there are other benefits to using text formats. To begin with, they can also contain meta-data and annotation.
For example, a geometry export tool could always start an output file with a header block of comments saying which version of the tool was used, the source file the data came from, a timestamp, the name of the machine it was run on and the username of the person who kicked it off. This is great for assigning blame when things go pear-shaped.
Text formats are much easier to debug. Debugging binary formats always seems to take lots of painstaking examination using a hex viewer, pencil and paper to note down all the offsets you'll need to keep track of. For particularly knotty binary formats, you tend to end up writing special tools just to debug them. No such problems with text formats - just fire up your favourite text editor!
If you can, prefer line-oriented text formats. Many existing text processing tools work best line by line, particularly the ones with a unix heritage. For example, want a list of the textures used by all the exported ".mesh" files in a directory?
$ cat *.mesh | sed -n "s/^texture '\(.*\)'/\1/p" | sort | uniq
...would do the trick nicely. This scans all the ".mesh" files in the current directory for lines of the form "texture ''", sorts them alphabetically, removes any duplicates and outputs the resulting list to stdout, one filename per line. The 'sed' command in the above example could easily be replaced by grep, perl or awk according to taste (or lack thereof). Regular expressions are great, even if they do tend toward being write-only code!
Another benefit of using text files is that they get you up and running quickly. You can always lay nicer interfaces on top, but users can hit the ground running with nothing more than a text editor.
Incidentally, it's probably worth encouraging all the non-programmers on the team to install a reasonable text editor. There are lots of great free ones out there, and they are all much better than Notepad. For extra points, make up some syntax-highlighting files for any of your file formats that you might reasonably expect to be viewed or edited on a users machine.
Don't overestimate the readability of XML. It really isn't all that readable, even with a good XML editor. The verbosity gets in the way. If your production processes require that members of your team regularly have to manually read or edit XML, they will hate you for it. There are lots of good reasons to use XML, but the limited readability it provides shouldn't be your deciding factor. If your files are designed to be machine-generated and machine-read, then XML provides a great structure to build within. But if they are designed to be written or read by people, steer clear.
At the end of your production pipelines you'll probably be wanting to cook things down into platform-specific binary formats. But try and keep your intermediate formats text based as much as is reasonable.
A tool to let you create binary files from a text description can be useful (one I wrote can be found at http://binify.sf.net). The idea is the files can easily be annotated with comments and other meta-data, making an otherwise unreadable binary format quite easy to follow. The final text-to-binary conversion is generic, so you don't need a new tool to handle each new file format (thus reducing potential new sources of error). It's also a great way to manually hack up binary files for testing. The downside is that such a generic description language doesn't really provide much semantic information about the file format, making it less amenable to further automated processing (as opposed to using, say, XML). So this approach is usually only good for that final text-to-binary step.