After reading Jonathan Danylkos blogpost about 20 lessons learned in 20 years I thought about things I’ve learned in the field over the years.
1. There’s no point in being #1 if what you know isn’t used anymore. – Even if you happen to be the best in the world at what you do, times will change and new versions will come around or the technology you work with will disappear altogether. Make sure you learn something new and useful every day. If you attend for example Microsoft TechEd, go to sessions on totally different subjects than what you work with. This will give you new perspectives on life and you might even find a subject that’ll save your career one day. Make sure to realize when someone younger just took your place as #1 also. It will happen!
2. Inform your customer or boss about all the stuff that’s your fault. – Restarted a server which affected the whole company? Didn’t bother to apply for a service window and ran Windows update anyway? BSOD because you just HAD to test something? Take responsibility for the stuff that goes wrong before someone eventually hunts you down anyway. Doing it that way instead of waiting for someone to come around and ask who’s fault it was shows that you have the courage to admit when you did something wrong. Not everybody has that.
3. You’re gonna miss deadline? You know it already but haven’t told anyone? Do that. – Mostly when you work in projects or you get an order from a project that they need 1,2 or 25 servers there are a lot of people waiting for those servers. If they won’t get it it’s usually appreciated that they know it as early as possible. And shows that you respect their time too.
4. Help your colleagues! – Even if your colleague needs help installing an x64 printer driver and you’ve done it 400 times and get sick every time you have to do it now. It might be their first time, and if they try and fail and no one can print, it’ll be your problem anyway. Helping your colleagues shows that you care about the team and your success together. (Teach a man to fish… You know.) As Jonathan says too, it’s good to do a lot of high fives and happy dances when things go right. No one outside your department will knock on your door to tell you that it works. They’ll just come running to yell when it doesn’t.
5. Do not try your luck on stuff you don’t know. – You were just going to change some stuff in a switch? Changing some unknown parameter in your SAN? This is NOT how to learn new stuff because once you’ve taken down 400 servers because you luckily succeeded in implementing a new routing algorithm or switched the authentication protocol in the SAN you’ll have to learn how to drive a cab or swing a hammer real quick. Test environments, courses or borrowing (ask first) equipment from your company is the way to go.
6. Hey, that looks easy I could do that! – About the same as above but this goes for consultants (mostly). In these times it could happen that you’ll accept a project where you’re not really feeling secure. Like implementing smart cards, upgrading from Windows 95 to Windows 7 with the help of Ghost/Altiris/MDT/SCCM/insert whatever here. Well, we all need the cash right? This will make your customer not too happy and make a big dent in your reputation as a consultant. Know your limits. Respect your customer.
7. Stop, collaborate and listen! – (Vanilla Ice, you know the song…) Make sure you collaborate with peers, colleagues and competitors. Listen to which problems they’ve run in to and how to solve it. New stuff hitting the market? Anyone tried it? Make sure to share your knowledge too. You could blog, speak, user groups, social media and so on. In the beginning a few will listen, if you’re good the rest will come too. (But it’s kinda tough to start off with 3 readers / week, I know.)
8. Make contact. With everyone. – That guy you met at an after work 3 years ago? He could be a great contact when you need a new job. Or he could be your new boss without you remembering him. Switch business cards, connect on facebook, follow on twitter, have lunch. Remember what people do, where they do it and if they’re going anywhere. That network will most likely be very very useful one day.
9. Understand the spiderweb – How is everything connected? Why does rebooting this server take down the cluster over there? Why is our BI-system so slow? Why are we using that old technology instead of upgrading? Once you know why and how stuff is connected it’ll be a lot easier to motivate a migration, explain to your boss or a project that you can’t take server A down because service C which is your data warehouse is dependant on it. Which leads us to point 10!
10. Document everything. Instantly. – “I’ll do that later” is a very common way to push documentation forward. Until next project comes along and the first one will NEVER be documented. Are you required to document your server installations and configurations? Script it! Or find a script that does that. Or hire a programmer that can make a program that does it and outputs it in a common format, even if it’s just a textfile. Documentation that isn’t done immediately will most likely never occur either. And if it does it’s even more boring if you have to do it six months later.
Are you in the IT-industry? What’s your tips for surviving, being a better consultant or colleague and learning new stuff?