(nothing to see here). first thing you need to learn is that sysadmin is about people, not...
TRANSCRIPT
• (nothing to see here)
• (nothing to see here)
• First thing you need to learn is that sysadmin is about people, not technology
• If you’re a sysadmin so you don’t have to deal with people, you’re in the wrong business
• People need computers to do their jobs
• If there were no people, the company wouldn’t need computers
• If the company didn’t have any computers, they wouldn’t need a sysadmin!
• Everything a SysAdmin does must have a business reason behind it
• Like meet an SLA, conform to a regulation, etc.
• The gear isn’t there for you to do “cool stuff” with
• If there’s no business case for doing something, don’t do it
• Given that, let’s talk – briefly! – about hard skills
• You know, commands and technology and stuff
• Well, OK, you need these skills
• But which ones you need are specific to your domain of expertise
• And you can probably guess which ones you should learn
• And I’m betting you can teach yourself the ones you don’t already know
• Unlike hard skills, this is something you need to learn
• And something you may not already know
• Ability to look at the big picture
• Figure out requirements
• Make a plan
• Evaluate the results
• “Big Picture”
• Applies to existing systems as well as new stuff
• Speaking about designing stuff …
• From Agile / Extreme Programming
• Met the requirements and no more
• Yes, economy of scale and growth
• But those should be in the requirements
• Again, anything more and you’re wasting time / money
• Also, unless you’re very good at predicting the future, the product (service, business, whatever) will change in the not-to-distant future and not only won’t that feature you wanted to put in now be needed, some of the stuff that’s actually in the current spec will need to be thrown out
• So again, just what’s in the spec and no more
• Getting back to people …
• If people don’t want to ask for help – either because you scare them or you’re unpleasant to deal with – you have failed
• Yes, you have to stay within policy
• But the goal is “yes,” not “just say no”
• Don’t be pedantic
• Part of this is giving the answer that is most helpful to the user, in terms the user will understand
• Don’t be pedantic
• Don’t answer with “don’t do that”
• Show respect for users
• It’s not their job to know about computers
• If they knew about computers, the company wouldn’t need you
• So stop saying rude things about them because they don’t know as much about computers as you do
• Your users are not stupid
• Really, they’re not
• Here’s something that happened to me that illustrates that …
• My wife uses a Mac
• I use a Lenovo ThinkPad
• They’re different in ways not obvious to us
• On vacation, she asked to use my ThinkPad
• How do I open it?
• How do I turn it on?
• Which button clicks the mouse?
• “Boy, is she dumb!”
• Um, no
• MS in biomedical engineering
• At least one patent
• Got bored with engineering, became a doctor
• Probably smarter than I am
• She has ~7,500 hours experience using a computer
• I have ~120,000 hours experience
• That’s a factor of 16
• 16!
• That’s a lot!
• Most sysadmins forget how big a gap that is
• Stop whining about Windows
• It’s pretty much the standard in the business world
• Get over it
• Better yet, accept it
• Whining just annoys your boss
• Reinforces his/her belief that you have a bad attitude
• (And if you’re whining about Windows, you do have a bad attitude!)
• Learn to use Windows desktop
• Learn common Office apps
• Learn Outlook
• If that’s what your boss uses for meetings, you use it, too!
• The point isn’t security
• The point isn’t about making sense
• It’s about complying with legal requirements
• Which means staying in business
• You don’t have to like it
• You do have to help implement it
• Ideally help improve it
• Process – if done correctly – helps things
• Learn how to assess process and effectiveness
• Learn how to change process to improve effectiveness
• Change management – again, if done well – prevents mistakes
• Mistakes cost money
• Again, learn how to improve the process so stops hindering and starts helping
• And do it without whining
• Specifically ...
• His/her job is to manage people / projects, not be a sysadmin
• Learn to accept this
• Learn to get help from other people
• Conferences, IRC, mailing lists, etc.
• If there’s a problem, don’t bash them, go help them fix it!
• Probably not their fault
• And they’re not dumb!
• Ops stuff doesn’t usually make it into the spec
• Devs can only code what’s in the spec
• Summary: Stop whining!
That’s All,Folks
Any questions?
