1. It is better to spend the time to develop expertise in and set up an adaptable/customizable solution in most cases — unless your workflow closely or exactly matches a “canned” solution. You’ll be more effective and efficient using a tool you know inside and out on a job it’s not perfect for than using a perfect tool with which you’re only minimally familiar.
2. In regards to IT systems and platforms (e.g. cloud vs. on premise, Dell vs. HP, Google vs. Amazon, Python vs. C#, etc.)—assuming comparable fundamental functionality—the choice of platform matters a lot less than the expertise of the people managing them. Too many organizations spend time agonizing over choosing the optimal solution when that time would be better spent choosing an option and developing solid capability with using it.
3. The most two most important factors in secure IT services are: 1) deep expertise on the part of the technical staff and 2) organization culture that is pro-security. That culture acknowledges the costs of this security stance and chooses to accept them even when the benefits are not immediately apparent.
4. Sometimes, you need to do some math (e.g.to figure out the theoretical maximum throughput for a disk array, network connection, or CPU).
5. Other times, you need to do some real-world testing (e.g.to figure out the load of an application on a server per X number of users).
6. Unless you can come up with a good reason not to, choose a stable build of Linux as your default platform.
7. IT must remember that they are a service department/division. Few organizations exist to develop or operate IT as the end goal of their work.
8. Not knowing the answer to the question, admitting that ignorance, and knowing that this is an acceptable—and in some cases mandatory—statement is essential to effective technical team culture.
9. Having the time, management support, and extra infrastructure capacity for people to play around with interesting things more than covers its costs in the medium and long term.
A. Walls of jargon only serve to convince your listeners with relatively limited technical expertise that you’re a jerk. That said, intra-team jargon allows for increased inter-human communication throughput if the team works to develop this jargon inclusively.
B. Automate a workflow the second time you need to do it. More than likely, you’ll end up using it frequently enough to offset the initial automation effort/costs, and you’ll develop skill in your automation tools and thinking.
C. For some roles, personality characteristics that might cause friction in other roles are tremendously valuable.
D. It’s frequently important to be aware of how large organizations like Google, Amazon, Facebook, and the like do IT. However, it’s infrequently useful to run your IT the same way (e.g. don’t deploy a full-bore MapReduce cluster when you can just let the job run for an hour or two on a robust Linux VM).
E. Encrypt.
F. Set up your backups while you’re setting up the system. Test them as frequently and thoroughly as you can afford to.
10. If a problem is so big that you can’t figure out where to start solving it, keep working on splitting it into smaller problems until you can.
*(Hexadecimal)