My IT Philosophy

I recently referred to "my IT philosophy," and I was slightly surprised that I did have a philosophy about this job, one that had evolved over time and had some unifying principles. Some of this is received wisdom, but most of it comes from my own experience. I imagine there are writers about patterns and anti-patterns who have better articulations of essentially identical ideas, but these are how I've thought about them in my own work:

1. Serve the business need first. IT staffers are sometimes so emeshed in their technical challenges that they forget that their mission is to solve business problems, not to merely build or maintain systems. When evaluating priorities or weighing possible solutions, an IT manager should always ask: "What's the business need, and how can respond to that need as quickly and effectively as possible?" For instance, if a salesman can't get an order processed on the last day of the month, a typical IT guy might just treat it like any other issue and tell them to wait for the technical issue to be fixed. A superior IT guy would address the business need first ("here's how we can manually by-pass the bug for this one issue") and then fix the system later.
2. Sales uber alles. Every IT guy has more issues pending than time to address them . . . which means they have to make decisions about which issues to address immediately and which to let burn. The typical IT person will address issues in the order they were received, or worse, reverse order in which they were received. Others categorically ignore everything and only pay attention to the squeakiest wheels. But ideally, issues should be addressed according to a hierarchy of how they impact the business. I work according to the following hierarchy: executive-level issues, then sales-related issues, then customer support-related issues, and then everyone else. Executives are first in line for purely political reasons: you don't get to keep your job unless the top brass are kept happy. But after that, sales is the number one priority. If an issue is keeping a salesman from selling, or keeping him from closing a particular deal, that's top priority. This reflects my overall business philosophy: I believe the most successful organizations are those that are sales-focused and sales-driven.
3. Start with the user in mind. Every aspect of application development should begin with the user. Requirements should be gathered first from the users themselves. Specifications should always flow from use-cases first, and then into underlying technology. Actual development should alway start with the user interface and then implement the actual business logic. All this flows from the first principle: stay focused on the business need, as it is experienced by the users.
4. Gather requirements from all levels. Nobody has the entire picture when it comes to a significant application. The mangers might think they know everything that needs to be known about what an app needs to do, but they often miss important details that are obvious to people working in the trenches. Likewise, end users may know what's important for day-to-day operations but be myopic about long-term issues. When gathering requirements for an application, talk to everyone involved if at all possible.
5. Be agnostic on technology. All that matters is that the solution works and is maintainable. If the solution works, and works soon enough to meet the business need, all kinds of other flaws can be overlooked. A solution might be ugly, use old technology, be less-than-ideal, or just plain un-hip, but the boss's boss won't care if the business need is met. It's amazing how many techies get stuck on trying to find the perfect solution while the world is burning.
6. Design for the long run, but implement for the smallest measurable change. A staggering number of IT projects never get completed, usually because the business needs change before the development could be completed. To avoid making perfect and irrelevant software, you need to always err on the side of making the scope smaller. Don't overbuild. Do exactly what is absolutely necessary to meet the business need, and no more. If the app proves to be effective and important, you will get a chance to build it out some more and add features.
7. Understand your issues (or be doomed to repeat them). This is probably the only exception to the "meet the business need first" principle. It is entirely possible that "try rebooting your computer" will solve the immediate problem, but that's not a satisfactory level of support. You have to make every reasonable effort to really understand what's going wrong, or issues will linger, multiply, and resurface at every turn.