Technical tips:

I have advice pages devoted to the following topics:

Large Installation SysAdmin, PDF output from TeX & LaTeX

General advice from me:

Always solve for the general case

If you're going to the trouble of researching a problem and addressing it, address the general case rather than a point solution. Getting up to speed on the problem is the hardest part. If you only find a point solution, the problem will inevitably have to be revisited by you or someone else.

Pilots shouldn't be projects

Pilot projects often have poorly defined end dates or criteria. As such, they tend to take on a life of their own and continue in perpetuity with no need to perform. If experimentation is necessary, tie it to a real project that will be held to real performance measures.

Don't hold a meeting without a proposal

If you want a decision made, bring a position statement. If you don't, the meeting will go around in circles. A group can agree on or make minor modifications to a position, but cannot generally formulate one from thin air. If you want examples to prove this to you, go to an IETF meeting.

Take time for growth

It's far too easy to get caught-up in fighting the fires of the day. As both an institution and a person, it's important to reserve some time for staying current and thinking about where you are, what you're doing, and why.

Don't optimize a poor solution

Given a bottleneck, it's far too easy to continuously make incremental optimizations to improve that bottleneck. Attempt to completely eliminate the bottleneck by re-architecting the system.

Don't send salesmen to talk to me

Everything that they know should be on your web site (and usually more). Send an engineer or technical product manager who can have intelligent discussions about unadvertised and future features.

Don't buy something because the salesman convinced you it was the best option

This item is a corollary to the previous item. If you can't make an informed decision of your own, you will believe the salesman even when he is wrong. If you don't know more than the salesman, you shouldn't be making the purchasing decision. If you must trust someone, trust a third party who is knowledgeable in the area.

Keep bureaucracy out of the way

Bureaucracy can only hurt morale. It is a demotivator and should be excluded from the day to day work of most employees. Trust your employees and discipline or remove those that violate that trust.

Unload dead weight

You can't keep it around forever. Spend some time to get rid of it know before it becomes a problem. This is true for technology, people, and material possessions.

Use standards (ad-hoc or formal)

Proprietary designs and solutions constrain more than they enable. The actions of a single entity will be exceeded by the actions of the group. If you're not able to take advantage of the group's actions, you've dug yourself into a whole. Further, if you're the single entity advocating a proprietary design, you exclude and alienate people who are using standards.

The web is stateless

HTTP was designed as a stateless protocol. There are powerful benefits to stateless protocols: fault tolerance, parallelization, etc. CGI scripts have traditionally been written in a stateless manner, meaning that no state information is stored on the server between transactions. All complex user interfaces are state machines of some kind. The trick with CGI programming is to have the server encapsulate the state in a form that can be given to the browser. Subsequent requests to the server will thus be accompanied by the full application state.

A lot of business programmers don't seem to get this concept. They depend on server-side state that requires that subsequent connections come back to the same server. State information is timed out and idle users are required to start over. Users aren't given a long-lived link that will take them back to their current state. The web is a different beast from traditional user interfaces and traditional programming methods shouldn't be forced down its throat.

The web is a thin-client architecture

Modern web designers tend to place a lot of logic inside client-side scripts. That is fine for accelerating UI response, validating data in advance, etc. Unfortunately, many programmers rely on it for authorization and validation without putting that logic on the server. The first problem with this is that it places reliance on advanced logic in the client thereby limiting interoperability and agility for deploying new clients. Second, this opens up vulnerabilties to malicious or accidental manipulation of the logic on the client. Keep the important logic on the server.

Pushed Replicas

Things are easiest to maintain in a single point. For network availability, they are best replicated. To meet both constraints, manage your data centrally, but have it automaticaally pushed out to mirrors.

Targeted Infrastructure

Common practice for building infrastructures (particularly information services and technology) is to build infrastructural layers from the bottom up. However, you can spend an infinite amount of time perfecting any given layer, and many institutions do just that. Target your growth by picking some high-level application needs and use cases. Then fill the infrastructure gaps to support those needs. The result should be growth that is useful to other needs.

Consumer Computers Shouldn't Need Manuals

Walk into your local Barnes & Noble Bookstore and look for a book on digital electronics. If your luck is like mine, you won't find a single one. Now luck for books on VCRs, embedded controllers, etc. Nada! Now count how many shelves of books there are on personal computers. When personal computers and their software are to the point where there is no longer a general market for books like "Win32 Registry Hacking for Dummies", that's when computers have matured past the Heathkit stage into where they should be mainstream. Until then (okay, maybe a shelf full of Chilton's manuals) you may reap benefits if you use personal comptuers, but you better be ready to make it a hobby.