Good techs working for good tech companies will know if what they are seeing is their fault, and will take responsibility. Poor training or dedication in the tech or restrictions set by the company or department they work for may prevent them, but if your experiences have been positive, and especially if they have taken responsibility for fallout before, then ask about the cause only if you have a serious concern. Technicians are often blamed for problems that are not related to their work, and even the cheeriest ones get worn down by it. Your experiences with IT workers will be healthier if you reserve judgement of fault for the most important cases.

Also, give clear pricing goals to IT staff. There are different solutions for different price ranges, and IT people need to know your budget so they can choose products that stay inside it. If your primary goal is saving money, say so. Then you can find the best product with a minimum of back and forth to compare features and get new quotes.

Remember that time is money. Suppose you ask IT staff to find a cheaper laptop. They spend two hours searching and getting quotes. The laptop that meets your price has quirks, but IT staff can work around them. It takes two hours to setup. There is a problem when the employee starts using it, and fixing it costs half an hour of IT time and interrupts the user’s work for a day. The money saved has been spent on labor, and work has been more frustrating for everyone. This is true even on salary. Less work gets done per hour, which raises the cost of labor (if salary employees work extra hours the money comes out of their pocket instead of yours, but they will notice).

Last, wait to start a project until you are ready to spend money. Good IT staff can cut costs, but only some. Effective IT projects need a healthy budget.

In general, manage IT staff by focusing on features; let them find and price solutions. If you want to upgrade your network, make a list of your ideas and show them to your workers. Good IT staff will find products and compare the technical merits, then come back to you with options. If you find a product that looks appealing, explain why you like it and ask them to evaluate it. They will consider its technical qualities and compare it to other products that provide similar services.

Also, list your goals by priority. Sometimes the exact set of features you want is not available, or, more often, is not available on your budget. IT staff need to know which features are necessary, which ones you really want but can live without, and which ones are cool but unnecessary. This way they can find the best fitting products.

PDF files are a better choice when you want to share a document. There are free, powerful tools for all the major operating systems that let you view and create PDF files. Also, most PDF viewers present a simple screen meant only to show you the file.

Collaborating on a project is different. When several people are working on the same document, Word may be a good choice. Still, be willing to use other software if Word is not the best fit.

Use PDF files unless you have a specific reason to use Word.

Documentation should record system configurations and the reasons behind them, but should be brief; the goal is to reduce work. There are different styles, but all documentation should be two things: a guide for new IT staff, and a quick-reference for current IT staff.

Passwords and other sensitive data should be documented separately. Non-IT management should have access to documentation, and there should be backups. Talk to your IT staff and make sure they are following good documentation practices.

It is well known that weak or rarely changed passwords are a critical security risk to any computer system. To keep data even minimally secure, users must have complex passwords that are habitually changed. Passwords should never be written down, except on documentation that is locked away.

Enforcing good password practices is notoriously unpopular, but when business data is at risk, I think they are a necessary inconvenience. The human mind is an impressive storage device. With a little effort it will reliably store good passwords as often as you want.

Because there is so much email, private data is often sent in unsecured emails without consequence. If your email is unsecured, however, you will not know the probability that it will be compromised, or if it has been.

Many think the risk is low because it takes too long for someone to look for profitable data in all the email on the Internet. People do not need to, they can write software to do it for them. Unlike people, computers are equipped for that task.

If your email system has not been secured, do not use it to send sensitive data.

When I get an email with capitals in places where a person would not speak loudly, even if I know the goal was only emphasis, it reads like the sender was angry. If you want to emphasize something, I suggest using italics, or choice of words or grammar, but not capitals. The convention is to reserve capitals for loud speech.

Emails should not be typed in all capitals unless there are special requirements, like you might find in legal documents.

The ellipsis mark (three dots . . . ) is not a replacement for the period. According to the fifth edition of Diana Hacker’s A Writer’s Reference, it is used to mark omissions from quotations and “may also be used to mark a hesitation or an interruption in speech or to suggest unfinished thoughts.” When using the ellipsis mark in quotations follow the rules of your preferred manual of style. Other uses should be rare, especially in business email. If you are hesitating on an issue, say so. If your thoughts are unfinished, finish them.