Perlcast Transcript - Interview with Tom Limoncelli

Thanks to fax/faxathisia from Freenode and to mr_bean for supplying corrections to the transcript.

[music playing]

Welcome to another Perlcast interview. This is your host, Josh McAdams, bringing you a conversation recorded at January 23rd, 2006 with Tom Limoncelli. Tom is the author of "The Practice of System and Network Administration" - published by Addison Wesley. More recently he authored "Time Management for System Administrators", published by O'Reilly.

In the interview, we discuss his latest book and he shares a few pointers about effective time management. As an added bonus, O'Reilly will be giving away a few promotional copies of "Time Management for System Administrators". To be entered into the drawing for a copy, just send an email to perlcast-at-gmail.com before February 25th, letting me know that you want to be in the contest.

01:15.4

Josh: Welcome to another Perlcast interview. Today I'm speaking with Tom Limoncelli. Tom has over 15 years of system administration experience at many different types of organisations. He's authored the book "The Practice of System and Network Administration" and most recently authored "Time Management for System Administrators", published by O'Reilly.

Welcome, to Perlcast, Tom.

Tom Limoncelli: thank you very much for inviting me, Josh.

Josh: well, Tom, you've been a system administrator for 15 years, you have two books under your belt - any more background that you'd like to give us?

TL: well, let's see, I've worked at a number of large and small companies. The longest was 7 years at Bell Labs, where I think I learned the most about System Administration.

Josh: and so, As said earlier, you've been a system administrator for over 15 years, and we're talking about the book, "Time Management for System Administrators". So when in your career did you start to realise the importance of a systematic time management?

02:00

TL: About a year into my first job out of college it became apparent that I was a disaster as far as time management. The good news is that I think most systems administrators that were around me, were also in a similar situation. I started doing some research, and the company I worked for offered some training, and that was the beginning of me being interested in time management.

Josh: Many system administrators use Perl, as do many programmers. And in the start of the book you say that programmers actually need a separate time management book, but I actually consider myself a programmer more than a system administrator and I actually got a lot from the book. So why would a programmer need a separate book?

TL: Well, thank you. I think that 90% of the book is probably appropriate for programmers - I just felt that as someone who programs a lot but doesn't have "programmer" or "software engineer" in my title, I wasn't really the right person to say this is how a programmer should manage their time.

People that have read the book had told me that 90% of the book is appropriate for programmers, and that I shouldn't have been so self-conscious. I think that to do justice for programmers, I could have maybe added a chapter, specifically for them, with specific tips. And maybe in the future I'll write an extended blog post on "everythingsysadmin.com" that will be specifically for programmers.

03:14

Josh: and so everythingsysadmin.com is a web-site you maintain, I guess?

TL: yeah, that's my blog. I also have an O'Reilly blog.

Josh: I have a question: there are tons and tons of books on time management. One of the most recent ones that I've looked at, besides yours, was the "Getting Things Done" book. It's very popular and you even mention it in your book.

So "Getting Things Done" is a very generic volume. Is it more appropriate? I don't mean to say "more appropriate". Is your book more appropriate for system administrators, and they should just scrap "Getting Things Done", or do they complement each other? What's your take on that?

TL: oh, I love "Getting Things Done". I recommend people read it whether you're a system administrator or not. I think "Getting Things Done" does a better job than mine on the psychology of procrastination and time management and helps get you motivated. But my book is much more focused on specific techniques for system administrators.

You know, system administrators have this real problem with time management. If you're a manager, you can generally get mentoring from your boss on time management, because your boss understands what you do. But if you're a system administrator, and your boss is technical, they're just as screwed up in their time management as you are. Can't really get mentoring on time management. Maybe on, you know, how to install Ubuntu, but not on time management. If your manager is non-technical, then they probably don't really understand what you're doing and any kind of mentoring they're going to give to you is not going to be appropriate.

So I thought that it was really a good idea to have a book specifically on system administration time management, because our *FILL IN* is so different.

But I love what he says in "Getting Things Done", and you'll find some overlap, but my book is shorter and more fun.

04:53

Josh: You actually have your own system in your "Time Management for System Administrators", you have your "cycle". What is "the cycle"?

TL: The cycle is my system for managing the data involved in time management. It's my system for never losing a user's request, managing your day and planning your future.

System administrators always complain, and as I go around and teach on time management at conferences and things, the top two complaints are always about interactions, which prevent them from the big projects done, and how impossible it is to prioritise their work. Well, you know, if you have 50 to-do items in your head, you cannot possibly prioritise them in your head. I mean, an average person can keep a list of seven things in their head... but 50 things - no one's that smart to hold that all in your head.

So in the cycle, you really need to dedicate yourself to writing it all down, and there are some tricks that help you do that, help you develop those habits. And then once you start having things written down, you can start to change the way you work, because you have this written list, and you can invest the first five minutes of everyday reviewing the list, prioritising and planning - things that seemed impossible before. As a result, you start to see the big picture, you start dealing with the big projects, and you're able to plan your day, and most importantly feel a better satisfaction at the end of the day.

I used to always feel like at the end of day... well, I know I got a lot of work done, I know I certainly worked hard, but I don't feel like I accomplished anything. Cause there is no feedback, and with the cycle you get the feedback.

06:33

Josh: and there is one important thing, one point that you made in the book was that you shouldn't get to work and immediately check your email. That you should sit there and take a few minutes to plan out your day. And so that kinda tells why it is important. Would you like to elaborate on it any?

TL: what's a typical day for a system administrator? How does it begin? Often people come in and they check their email and start banging out the different tasks that have come in through email and stuff. With the cycle, my first recommendation is: don't begin the day by checking your email. It can wait 5 minutes. And in those 5 minutes, you invest in some planning. The email gonna be there when you're done, for sure.

I find that no matter how good your email reader is, it's not a good time management tool like a PDA or a PAA can be. And I should probably explain those acronyms. Everybody knows what a PDA is it's a Personal Digital Assistant, like a Palm Pilot or Zauros. A PAA is the paper equivalent - it's your Paper Analogue Assistant. Both have benefits and both have cons. The book is technology agnostic. You can do the cycle with a PDA or PAA. And you know, a PAA is your traditional day-timer or filer-fax that you see non-geeks use.

07:49

Josh: that was one thing that I found interesting. I mean: you're a system administrator, you're neck-deep in technology all the time, and yet you do lean towards the analogue system of recording your time management. Why is that, you know?

TL: it's the first question I always get from people. I am a very geeky person; I'm early adopter on most technologies; I was the first person in the neighbourhood to own a tivo, and yet instead of a Palm Pilot, I use a leather-bound date book. The reason for that is that I started using that before PDAs have been invented, and I think I just got in the habit.

But also - I like it because I like paper. Paper doesn't take any time to put up, paper does not require software upgrades. I can open it up to a random page and start drawing a diagram without having to go into some kind of drawing mode, as opposed to writing mode. I can write big fonts, little fonts, with my pen.

However, the times that I do use a PDA is when I'm working for a company that has a network-based counter system, like Oracle Counter or Exchange. Because if it's critical that I'm syncing my counter with other people then I need a PDA. And a PAA is good if ... well, in that situation you can use a PAA, by manually sort of doing a one-of-day sync-up kind-of-thing, but you're really doing twice as much work in that situation.

09:07

Josh: so there are many others that do love our PDAs and use them even for our own personal planning. Is there any software that you recommend over just the basic task list?

TL: the Palm Pilot software is great software, but it has a lot of areas of improvements, shall I say. If you purchase Datebk5, for example, it enhances Palm OS to give you all the different features that you would need to do a much better job at time management. And in fact everything with the cycle works if you use Datebk5. That's from Pimlico software.

And there's also some excellent products like LifeBalance from LLamagraphics. They have this great whole way of doing to-do list management that is very interesting, because each to-do item - you can give it a priority and that kind of thing, but more importantly you give it a location. So you can have your to-do-list of "Things I need to do the next time I'm in my boss's office." Or "Things I need to do the next time I'm in a grocery store". And you can mark these locations as being work-related or social-life related.

So suppose you've decided that you're working too much and that you need to spend more time with your family or more time with friends, or more time fixing that boat that you purchased, or whatever. You can tell the software that you want say 25% of time to be spent with your family, and it prioritises things, it will try to achieve that balance. So if you've been working too many hours, the things that pop-up or bobble-up to the top of your to-do-list would be things related to being with your family and that will bring your life back in balance. (It's the name of the software.)

So that's a great product, and I talk about a couple of different products like that in the book.

10:50

Josh: Getting back to where we had started on that planning your day at the beginning of the day, before you check your email. You claim there, that whenever you're prioritising your activities, you really only need three categories and not, you know, a top-ten list, or anything like that. Could you explain that a little?

TL: that comes from the fact that I used to try to really be specific about the priorities of my action items. So I put something in my to-do-list, and I'd say well, you know I'm ranking their importance from 0 is not important, and a 100 is the world is going to explode if I don't do it right now. And I spent so much time calculating "Wow, is this more like a 63 or a 67, is it a 67? Wow!". And I just spent so much time trying to get an exact priority. In some cases, the task would have been done already. You know I've spent too much time prioritising.

I'm not sure where I picked this up, but someone recommended three priorities: A - it's due today; B - it's important; and C - everything else. Generally, if it's a day where I have any A's at all - that's all I'll be working on. And the way projects go, I'm generally working on that for the whole day. So that's sort of the exception. Most of the time I'm working on B's, which are things that are important, and C's are sort of those would-be-nice-kind-of-things.

And the nice thing about breaking it into this a simple A, B, C priority scheme is that first of all, you're spending less time picking your priority. And secondly, when you're planning your day, in that 5-minute planning period, you can look at your tasks and say "You know, I wanna work 8 hours today, I have one hour of meetings, so I'm down to 7 hours", and then you can look at your tasks and say "Is this more than 7 hours worth of work?". Because it's written, I can start actually doing this kind of planning, and say "That's more like 14 hours worth of work, so those C priorities and B priorities - I'm gonna move them to the next day's to-do-list." Or maybe, OK, I have time for my A's and my B's and the C's get moved.

If I'm super-duper overloaded, there's a different set of techniques that I talk about using. The most important thing is: you can take this to your boss, you can say "Well, boss, you're the one that has given me all this work, and if you'll look at my time estimate column, that's 30-days worth of work on my todo list that needs to be done today". And even if I eliminated the B's and the C's, sometimes you say "Just my A's, things that are due today, is more than I could get done today". Your boss can look at it, and help you prioritise.

13:16.

I found that managers often feel frustrated, because they can't get their staff to work on things in the priority that they wish they were prioritising things. So rather than getting upset, I find... obviously if I did that my boss everyday, my boss would think I was a little immature.

Josh: you need some help, yeah.

TL: But when you're having an emergency, and you can take this list and say: "Well, this is everything on my plate - can you help me?" - the reaction I always got was very positive. They said, well, finally, I can figure out what the hell you do all day.

I've gotten reactions that are, like, they see a couple of items and say: "Wait, you get requests to do that? No, you're not supposed to do that. People should do that themselves." And they give you permission to say "no". Or one time I did this and my boss looked at my list and realised "Wow, you do spend 20% of your time doing this one thing - I had no idea - that is something we could automate, and I'm going give you time so you could automate this thing, and it will disappear from your plate.

And I also had times when I had bosses that looked at my to-do list and said "Ow! I never had any clue what you do all day and now I've such a better idea.", and we had a better working relationship after that.

It's interesting what happens when you can prioritise things and plan your day.

Sys-admins always told me right away, "Tom, that sounds great, but I don't have a list at the beginning of the day that I can work with all day. I get people coming to me all throughout the day. And the book absolutely covers this kind of thing, I just sort of explained it the first way, just to get the basic concepts. Actually, two jobs ago, I was in a situation where I knew that every day I had about three hours worth of interruptions every day. So I would put that on my to-do list, every day: "Three hours of interruptions".

So when I was planning my day, you know, if I had two hours of meetings, I'm down to 6 hours, I have three hours of interruptions, I'm down to 3 hours - that means I really had only 3 hours left of tasks that I could do. So I could look at my to-do-list and pick the most important 3 hours worth of tasks, and set that as a personal goal. And I could now get those 3 hours worth of tasks done, have the 2 hours of meetings and the 3 hours of interrupts. And if I only had 2 hours of interrupts that day - hey, awesome - I could get some priority C tasks done or B tasks done.

If I had more interrupts than 3 hours - OK that's fine - but at least I was planning and preparing - I've a written list. If a certain project is going to be late because of this, I can call the person who made the request and find out if it's a hard deadline, or it is a would-be-nice-deadline - that kind of thing.

15:52

Josh: a question that I have often had is: it seems that prioritising your tasks, and getting them set in the morning, and then using that at the end of the day to see what you've done and accomplished as a kind of a reward, not only helps you get your priorities straight, but it seems like it will also hone your skills of actually being honest with your time estimations. Have you seen that get better over the years with this system?

TL: oh absolutely. The first couple of months of trying to estimate how long your tasks are going to take, I guarantee everyone who tries it will be a failure. But that's OK, because you'll get better at estimating things as time goes on.

16:23

Josh: definitely seems like it makes it harder to lie to yourself and say "Yeah I'll get that done today".

TL: I find that I take the time estimate - how long I'm thinking something is gonna take - and then I multiply it by Pi. And that generally turns into a more accurate estimate.

It can help with procrastination or avoiding procrastination. I find sometimes there's a project that I've just been procrastinating on forever. In fact, one example is: I'm helping this non-profit re-do their membership database, and I've been procrastinating, procrastinating. And I have this todo list that every day I wouldn't even start and I just moved it to the next day's list, and it just said "Membership Database".

After realising that I pushed it for about a month, I just changed it to "Put all the Data in one Subdirectory". Because, there's going to be a merger of a couple of databases. Let me just make sure that I have all the data so I could get started. And that did take me about an hour, but I felt like I've done something. The next day I could do the next step, and the next day I could do the next step. It let me actually get the project done because I was no longer thinking about this one big scary project that I was able to break it down.

When I do this at work, if I've a project that has five different parts, I'll put parts A to E in Monday's to-do-list for the next five Mondays. I guess one thing I should explain or should have explained earlier, is: one of the principles of the cycle is: instead of having one huge to-do-list, have a different to-do-list for each day of the year. So 365 to-do-lists each year. Much easier to do in software than in paper.

So if you get to the end of the day, and you haven't those items, you move them to the next day. Or, you move them a week ahead. If something's low priority, maybe you don't move it to tomorrow's list you move it to next Wednesday's list. So getting back to the large project system - if something has five parts, I'll put it on the next five to-do-lists, or the next Monday for five Mondays in a row. Each milestone. So that way, I'm sort of giving myself one week to do each milestone.

18:17

Josh: at one point in the book you say that acknowledging the user's issue is as important as solving it. And why is this?

TL: people want to be acknowledged when they make a request - it's very comforting. We system administrators don't go for psychology much, but the psychology of what we do is really important. So if the user sends an email to Help, to create a ticket, but doesn't get any kind of auto-reply saying "Yes, we received your ticket - here's the number.". A user isn't sure if the ticket was lost or if it's being worked on. And they're going to be sort-of stressed until they get some kind of reply.

If you reply five hours later, and say "It's done." - that person has been stressing out for five hours, and probably thinking "Oh, these darn sys-admins, they don't do anything", and then they get the surprise "Oh they were working on it all along.".

Well, that's not good to have the user saying bad things about you for five hours. So if, instead, you reply right away, saying: "Hey, I got your message - I'm working on it.". Hopefully give some kind of time estimate ("it should be done by tomorrow"). Then five hours later you send an email saying "OK, it's complete.".

Now, your user was only stressing out for five or ten minutes or even an hour before they got that initial reply. So psychologically, that's going to make them like you a lot more. If you don't do that and your co-worker does do that - their perception is going to be that your co-worker is a better system administrator, because they're keeping them up-to-date - they're keeping them informed about what's going on.

19:46

Josh: another claim that you have is that managing for filling expectations seems to create the feel [?] of speed, even if a task takes the same or I'd probably assume - a longer amount of time. So why is this?

TL: so fundamentally, people would rather have their expectation met than have every request done instantly. Well, probably they'd rather have every request done instantly, but that's not humanly possible or physically possible. If you ordered software that has to be delivered, even if it's Fed-Exed overnight, you know it's going to be overnight, before they received it. Again, it comes down to the psychology of handling a user request.

Let me tell you a little story. Back in the days that a console server was new we set up a console server, so from my office I could do everything on the console's server remotely, without having to run to the machine room. Now, if a server's down, when a user runs into a system's office and says "Oh my God, the system's down." What's their expectation? Their expectation is that the system administrator is going to stand up and run down the hallway to the machine room.

So we had this console server and I no longer needed to do that. So this user runs in: "The Server's down! You gotta help us." and I said "OK, ", and I just turned my head to the right, and hit the right keyboard combination. And I was virtually in front of the server, and I was seeing it was rebooting and I'm checking things out, and I'm working on bringing up the system.

Well, from my damage point this looked like I was doing a good job as a system administrator. But from the user's point-of-view, they were expecting me to run down the hall instead. And from their angle they couldn't see what was on my monitor, so it looked to them like I decided to sit there and not do anything. Boy, did he get red in the face. And I realised - "oh, I wasn't meeting his expectation".

So now, when this situation happens, instead, I say "Hey, look! How about showing you this cool system we have: I can do everything I can do from the console right here". And I turn the monitor, so that they can see, and I do the key combination and it comes up and I say: "see, it's like we're on the console.", and I can repair it and they can see visually that I'm repairing it, which is matching their expectation.

Now in both of these situations, I was working just as hard and doing just as good a job repairing the server. But in the second one, I was meeting their expectations and therefore they were a happier customer.

It's a funny little, kind-of-psychological thing, but it really does make a difference.

22:18

Josh: it is amazing how true that is. I mean, after I read that, I started paying more attention, and I know some people and they get complaints a lot, even though they do work hard and get a lot of work done. And when you look at it, they get complained at because people don't know what they're doing, and don't know when it's going get done.

I guess these last two questions were similar.

TL: the amazing new system administration tool that I've been using a lot lately is the telephone. Someone sends me an email saying "Can you work on this?", I call them and say: "Hey, I'm working on this and I have a couple of questions", and I answer them, and I just get it done right then and there, because I was able to reach them on the phone.

Traditionally, I prided myself on being completely email-driven. You know, I could do everything by email. A user sent me a request by email, they don't give me all the information I need to get my job done, so I sent them an email asking them a couple of questions, they email back. It's amazing how different it is when you talk on the phone. They're more comfortable; they can answer questions better verbally than typing the answers. Especially if someone is not very technical, it's much more comfortable to them to be able to say: "Well it's the thingy on the left-hand of the screen", instead of writing an email where they essentially flashing back to their evil English teacher in high-school who was correcting their grammar.

23:39

Josh: and I'm going to swing it to the opposite direction right now. I remembered something that I wanted to ask at the beginning and forgot to. And that was one of the first tips that you say in the book was about creating a barrier between yourself and your users. And so this is exactly what we're talking about. Even walking 50 feet off out of your office to see what it looks like going to you, and see if somebody else can answer their questions on the way.

So in the opposite of just managing expectations, also being able to manage your time and not be completely interrupt-driven.

24:09

TL: the book begins and I hope people don't feel insulted by this, but I say "You know, sys-admins get so many interruptions, I'm not sure you're going to get through this next chapter. So let's begin with a quick tip about dealing with interruptions. And it's called the "mutual interruptions shield".

That simply is: you conspire with a co-worker and make a deal: you say "Look, in the morning, if the phone rings, if someone comes into our office, you know, if someone walks up - I will handle the interruption; I will shield you from interruptions, and you can get projects done in the morning; and in the afternoon we'll reverse: I will hide and work on projects, and you handle the interruptions".

Obviously, if the machine room's on fire, or if it's something that requires two people, you'll come out from the shield, but if you do this, all of the sudden, instead of not being able to get projects done, you'll have a consistent half-a-day of project time, every day.

So I call this the "mutual interruption shield".

25:04

You know, if you can't get management approval to do this, you can do this unofficially. Or you can, at least, look at the layout of your work environment, and make sure that if someone is walking up to you, to interrupt you, that they have to pass by your co-workers, in hope that your co-workers would be interrupted instead of yourself. So one of the recognitions in the book is that you walk 50 feet away from your office, and look at your office as a user would look, and think: "What do they see in here?Are they being directed to encourage interruptions or to discourage?". Do you have a sign up that says "Here's how you get help: send email to blah-blah-blah". And that's going to deflect 20% of your interruptions.

Or if you're not the person that deals with the VPN and people are constantly asking VPN questions, you can put up a sign that says "Who do I talk to about VPNs? Sally. Network Issues? Bob. UNIX issues? Nea." So you eliminate the interrupts that people finding out who to interrupt. And obviously this kind-of-thing should be on a web-page some place, and, if possible, people's browsers' should default to have a start page that is the IT teams "How to get help" web-page.

So there are a lot of little things and big things you can do to help with interruptions.

26:21

Since this is the Perlcast, I should say specifically about Perl - one of the best time-management tips I can give is just to use Perl. When you use Perl, you're writing code about 10 times faster than, say, C++. That's just fantastic in itself. Perl lets you automate system tasks like no other language before. So, from that perspective, you get a double bonus because you're writing shorter programs to do more, and you can automate system tasks, easier than before.

And so, you know, any task that you can automate, and therefore remove that task from your to-do-list is just a huge, huge bonus.

27:00

Josh: you mentioned earlier that E-mail is not necessarily a time management tool, and actually it can be a very big time-waster tool, and I know I've read in "Getting Things Done" and I've read in your book, that single-touch-E-mails are the way to go, and I've tried that and I failed.

How do you make your E-mail single-touch?

TL: so this comes from an old time management tip of dealing with paper-mail, which is: you touch every piece of paper-mail once. When you go through your stack of mail - if it's junk mail, throw it out right then there. If it's something that you need to read, read it. If it's something that needs to reply, just write the reply right on the letter and send that mail back to the person. In all these cases, you're touching each piece of paper once.

Every time you say: "Well this is interesting - I'll deal with that later.", then you've used some amount of time, and when that later comes, you're using more time. Because you probably have to re-read it from scratch to get back up-to-speed. So, now you're spending twice as much time on the idle, than if you would have just done the required action while it's most fresh in your brain.

28:00

So E-mail can be similar. I try to not read an E-mail message, unless I know I have time to deal with it right then and there. Oh and to keep my E-mail locks clean, I realise that the strategy has to include the end of all these techniques has to end with the E-mail being deleted or filed away some place or archived.

For example, one thing that helped me doing is SquirrelMail, which is a great open-source web-based E-mail system for reading off an IMAP server. If I read an E-mail message, first of all - I don't read it unless I have time; and if I do read it, I then either have to delete it, reply and delete it or file it, or act on it right then and there. And, often, the action that I take if it's a bigger project is to write down in my to-do list what's being requested. Or forward the email into my ticketing system, so that the request gets recorded.

But even in those two cases, the end result is that I archived the E-mail, so it's out of my inbox. Which lets me keep a very clean inbox, which surprisingly enough makes my E-mail client runs faster, cause it's not trying to index my backlog of 10,000 E-mails. So, I can actually read E-mail faster, because my software is running faster.

It does all come down to trying to touch each E-mail once.

29:19

Now getting back to SquirrelMail: SquirrelMail has "Delete and Read Next" in a different button that just deletes the message and then goes back to the index. So, if I have time, if this is my designated E-mail reading time - I try to read E-mail a couple of times a day, instead of constantly just being interrupted by "You have New Mail" indicator. And I click on the "Delete and Read Next" button if I want to read that next message [?], otherwise I delete and go to the index, and I can look at the subject lines, and make a prioritised choice of what I'm going to read next.

I also let other mechanisms read E-mail for me. If you don't have a filter on your E-mail - you're working too hard. So, if you're using procmail, or some kind of Cyrus-based filtering system. Just about every modern E-mail reader has a filter, so you know - I have E-mails from mailing lists going to a folder called "Mailing Lists" that I might read only in my spare time. Or I have a couple. Actually, I generally have a "Trash Mailing List" folder for the interesting, but not important mailing lists that I'm on, and then the more urgent folder.

And then, there are certain things that you can delete without reading. We as system administrators can make a big difference in other people's time management, by making sure that the E-mails we send out to users have a good subject line, so that from the subject line they can determine whether or not to read the message.

I hate to see system administrators that every mass-E-mail they send is "A message from the System Administration Department". Because, that's not very effective. People are going to delete these E-mails without reading them. It's much more effective to put exactly what they need to know in the subject line. "Printers in Building 3 - Outage - Saturday". Now, if they're not in building 3, they know they can delete the E-mail. Or if they don't plan on working on Saturday, they can delete without reading anything else. But if they are in building 3, and are planning to work on Saturday, then they know they can read the message and find out more.

31:15

Josh: it seems like you had a very interesting filing system for your mailing lists. Was it "remove one every month" or every week? I can't remember.

TL: well, so - I used to be on, in fact I'm still on many many mailing lists, and I decided I needed to go on a mailing list diet. So, once a month, I picked the mailing list I thought was the least important, and I would unsubscribe. And also any time I joined a new mailing list, I had to unsubscribe from an old mailing list.

That was my mailing list diet, which really helped me reduce the amount of E-mail I get. And what I found is that it wasn't so difficult. There's tons of E-mail lists that I'm on, and I realised that I never actually read the messages. I see the subjects and OK, another thing like that. And with procmail putting each mailing list in its own folder, I can tell that you know - gosh.

So I'm on this Java mailing list and I realised that I was on that just because I was sort-of curious, but I don't use Java in my real-life. But once a week, I would look at that folder and sort-of-scan the subject lines and say: "Yep, not interesting again". After three months of doing this, I realised it could save me a lot of time to just unsubscribe from that mailing list.

And I'm sure everyone has a couple of mailing lists like that, especially if you're a big YahooGroups user because you just start searching and find 50 mailing lists that all sound really good, and all of a sudden you're subscribed to 200 mailing lists, while actually really reading the contents of a couple of them.

32:43

Josh: I have a feeling I already know the answer for this, based on a comment you've made earlier, but: instant messenger - blessing or curse?

TL: oooh boy! Big question! You know - it's both. I mean, at my last job, we used instant messenger as a tool. Everyone in any kind of engineering position was just expected to have their instant-message client running whenever they were working. We even had a coding system for the status message to indicate if you're in the building or telecommuting and all the subtle stuff.

But to get a project done, you really need focused effort and your concentration is focused effort, so you need to be able to have a social mechanism, that lets you not get interrupted. So either your team agrees that when you're working on a hard core project that you're allowed to shut your instant messenger off. Or at least set a status message that says something like "Project Time" and that means no one is supposed to reach you.

Recently a friend of mine had an away message that was "Yes, I know it's down and I'm working on it. Thank You!" and I thought that was the perfect status message. You know, if you're required to have your IM up all the time, that's the kind of status message that will prevent interruptions.

Oh Boy, when I need to get something done and I don't have a lot of time, shutting down my instant message clients, my "new E-mail" alert systems, and all those flashy things around your screen just make me twice as productive.

34:13

Josh: Absolutely, I use Trillian a lot because it lets the windows pop-up under the windows instead of over. So I can use them on my own time.

One theme of the book that I picked up on was about creating good habits and doing things in the same way time and time again. You always fill your gas tank on Sundays, you always put your keys in the same place. I never put my keys in the same place. Have you always been so methodical? If not, how did you make yourself that way?

34:35

TL: oh, no - I haven't always been that way. In fact, I don't think I'm that way, today. I'm only methodical in specific areas, where I've identified problems. I like to think any time I find myself apologising for forgetting something or screwing something up, I think "This can be an area of improvement." So - is there a habit I can develop, or a routine I can develop?

Sort of like my routine of before I lock my car, before I close my car-door, I always... I know this sounds pretty anal-retentive, but I close my door with my left hand and with my right hand I just squeeze my hand and make sure that I feel my car keys. Cause if my car keys are in my hand, I know that I'm not locking myself out of my car. It's a habit that has saved me a lot of problems, and it was only developed because I had a problem - I was calling the A.A.A. a couple of times a year.

Anyway, there's tons of system administration things that are like that. I mean the most obvious is making sure you have your card access key before you leave the computer room. But then there's other habits like spending the first five minutes of every day planning. And even if you don't do any other planning throughout the rest of the day, or completely ignore the cycle for the rest of the day - if you just spend those first five minutes, you're going to be ahead of the game. Because in those first five minutes, you'll at least pick the one or two things that are the most important and get started with those things. So at least there's one important thing [?] that you did every day, instead of getting to the end of every day thinking, "Ach! You know, I've been pushing a boulder up till [?] now all day, but I don't feel like I've accomplished anything."

So... I should say that my biggest qualification for writing a time management book is that I'm a dis-organised, badly-time-managed type of person, but I've just developed these techniques and routines, that when I stick with them, when I do have the discipline, I look like someone with good time management, but, really, I don't think of myself as someone with good time management - I just have all these coping mechanisms.

36:32

Maybe no-one naturally has good time management skills, and the people that do have good time management skill, are just these people with the coping mechanisms. Maybe there's no real difference.

36:44

Josh: I love the quote that [?]: "Good techies accidentally raise their hand and get moved into management. How do good techies accidentally raise their hands?

TL: well, usually by being upset about something, some problem, and wanting to fix it. And suddenly they're managing projects, and it's very typical that managers will confuse someone who's leading in the project management way, and confuse that with people management and all-of-a-sudden, the next thing you know, you're spending 40 hours a week writing evaluations and Sunday [?] time-cards. Or you've grown frustrated with how IT is done, and you realise that "well, If I was manager, if I was director of IT, I'd be able to correct all these large-scale problems that I've always wanted to correct" and suddenly you're a manager and you're not doing as much technical work.

37:28

Josh: "You can manage your boss". That's a catchy phrase, but what does it really mean?

TL: managing your boss is all about knowing when to use their authority. And how to stand on your boss's good side without becoming sick of him.

I see a lot of people who are constantly asking their boss to do something. Like: "oh, can you talk to that person about this?" or "can you help me with something?" and that's not always appropriate. Sometimes you see a manager sort-of sigh and say "OK...".

The best time to use your boss is when their authority is required to get something done. So, asking your boss to talk to somebody about something trivial is not such a good idea. But if it leverages their authority... if it's "This person needs to be told 'no' and I've told them 'no' three times." having your boss tell them "no" is leveraging their authority.

38:21

Josh: one tip you also talk about is paying someone else to do menial tasks around your house, so as to free up more of your time. And this for me is very difficult to do. 1. Because it costs and 2. Because having those tasks in my queue provides me a nice little way to escape from procrastinating for a while.

Is some purely laborious work not good for everybody?

TL: this initially came out because I was sharing a house with two mates and we hired someone to come every other week to clean - mostly to eliminate fights about who's turn it was to clean the bathroom. And it did eliminate these arguments.

Where I live in New Jersey it costs about 70 dollars per visit for a cleaning person. And she cleans our bathrooms, vacuums the floors, dusts, washes the kitchen's floor and maybe a couple of other specific tasks. And doing this every other week isn't so bad when you split the costs between three people.

Which is a common situation when you're just out of college. And not to stereotype, but three freshly graduated college guys living in a house, can smell like a locker room after a while and look like a disaster area.

And when you averaged it out, it's about 50 bucks a person per month. Which is money, you know - it's real money. But it has benefits. Most unintentionally, is that the day before the cleaning person comes, you run through the house and sort-of pre-clean, and that helps me stop the accumulation of crap that's in my bedroom. You know - forces me to deal with those issues. Because she doesn't clean up piles of clothes and stuff. Or piles of papers, or books, or God knows what else. So it has that sort-of unintended benefit.

But also, if you think about that - when I do this manually, it usually takes up a Saturday a month or a Saturday every other month. And if I'm paying someone else to do it, then that frees up the Saturday. So, if I was going to spend 50 dollars doing something social on a Saturday, if instead I'm paying someone 50 dollars to clean and that frees up my Saturday - well I can either do something that's less expensive like have friends over, watch T.V. or something.

What I'm saying is that I can justify it as a way of having more social life, which is very important to me.

40:34

Josh: and that does seem very important to you, and so we'll close here with this last question about the epilogue of your book. It seemed like very honest writing where you talk a little bit about ending work and having a social life. And, you know, really living.

And do you live by the statements in your epilogue?

TL: I absolutely try to. If this book helps you find 8 one-hour tips, 8 tips that save you an hour each, per week. That's 8 hours a week saved. That's one work day per week, that's two-and-a-half months or work-months per year, that you have, that you didn't have before. Two-and-half months.

And that's great. And I hope I can help everyone do that. Think about "What am I going to do with all this additional time?" and you decide "I'm going to use this time to work harder, to get more done at work." That's great, but I propose that instead you split the difference.

Sure, work hard - do a good job at work. But use that extra time that you've reclaimed to reclaim the 40 hour work week. I think that's the greatest thing that we can do as system administrators. Is to reclaim the 40 hour work week. Or maybe the 50 hour work week. Either way, we need to end the workaholic craziness of IT.

And with that new-found time - spend it with your family; spend it with your loved ones. There are just too many kids that grow up without spending any time with their parents. If you spend more time with your family, then that makes your family's world a better place.

And if you have time leftover - what I encourage everyone to do in the epilogue, is spend that extra time trying to make the world a better place. By fighting for social justice, or running for a political office. You know - you can be on your local school board with just a 3 or 4 hour commitment per month. And that's not a lot. And I don't know, where I went to high-school there is all this emphasis on the Football team, and not much on the Chess team. I think if more system administrators were on School boards, math and science would get much more attention, much more needed attention than it currently gets.

Give your employer a solid 40 hours - they deserve it - they're paying you, but give the rest of your time to your family and make the world a better place. And that what I hope to inspire in all the readers of the book.

42:48

Josh: thank you very much. That was a very good interview. I appreciate you taking the time to be on Perlcast. I very much enjoyed your book, and hope that other people go out and get it. It was a good book.

Any final words?

TL: I just want to thank you for inviting me, Josh. I had a great time, and I love your podcast.

Josh: It was a blast, thank you very much, Tom.

Josh: thanks again to Tom to taking the time to be interviewed on Perlcast, and as always thank you for listening.

The GarageBand.com track featured on this podcast was "Three Pound Universe" performing "Waiting for the Fall".