I am now more or less in the position you're applying for. It's not even been six months so I lack the experience to give you a truly wise advice, but here is what I have learned so far.
First and foremost,
You need to be patient
There are always plenty of broken things we want to get fixed right away. But you can only allocate this much amount of resources to it, changing things mean it will take time to get used to it, and changing to many things at the same time might alienate your team.
This being said,
You want continuous integration
You, your team, your hierarchy, your customers, you all want continuous integration. Even if some of you don't think so. Set up a build server with incremental builds, nightly builds, documentation generation, automatic tests, direct access to the latest stable package, and you will make their day.
You want to get rid of anything that wastes time
Your team should be spending their time doing great stuff. But most likely, they spend a sizable amount of it doing something totally unproductive. Identify all the things that steal time from them, things they should not have to do, things a machine could do, things that should not be done more than once, and fix them. You're one of them, you know where time is wasted and what they really want to be doing, right?
That build process that takes a dozen steps that you just "have to know"? Get it done by a script once and for all. For some reason it cannot be fully automated (yet), document it!
That compilation that takes two hours to complete? Do what it takes to reduce it to an acceptable amount of time: chop it, profile it, assign a task to someone, but don't let your team stare at compiling screens.
That one issue that keeps coming back every other month and each time takes half a day to figure out? Get it fixed, really fixed, write tests for it, and make sure the test is run automatically with every new build (I'm not even talking about TDD here, simply regression testing and automated tests).
That project you're working on that takes 5 minutes to launch? Take the few hours it takes to identify the bottleneck and get it to launch in a flash. While you're at it, why relaunching when you can simply reload the data!
That workstation that takes ten minutes to boot in the morning? Give it RAM, give it an SSD, give whatever it takes so it doesn't waste hours of engineers time when a hundred bucks would cut it.
That server that takes so much time to handle your requests you're seriously wondering if it's not sequencing DNA? Get someone to identify the problem.
Those people who keep coming several times a day with incomplete half-thought requests that were not even validated yet? Tell them to come to you or to one person in particular, but don't let them interrupt your team's work. Shade them from these annoying distractions, from irrelevant details, and give them well processed information they can work with.
That bunch of documents spread all over the intranet that nobody ever knows where to find or which version to use? Get it all in a same place (or at least referenced in a same place), dated, with a version and a contact.
Your hierarchy will frown upon some of these ideas, but here one of your best arguments is the technical debt metaphor. Also recognize what doesn't need to be changed though: "If it ain't broke, don't fix it." Or put differently, "Is it worth the time?"
How can I convince management to deal with technical debt?
You don't want to get too crazy
Your team is small, so no need to hammer them with overly complicated processes. Hey the point was to get stuff out of their way! And again, be patient, bring one change at a time and let it sink in, and fine tune the wheels until it runs smoothly.
Since your team is small, you can also experiment. Once you've identified a specific problem you want to nail (say, the bug tracker is too cumbersome for example), see what solutions are available to you (bugzilla, Redmine, Trac, Atlassian, Trello, old fashioned white-board...), then try one, maybe only for yourself, maybe with just another team member, see how it works, how it's accepted, and adapt. The solution turns out to be uneasy? Try something else. Is it better? Good stick with it.
These were my two cents on the topic. As I said, I'm quite new to this too, so people who know better are very welcome to comment. :)