Time Management for System Administrators

What Hacker News says

1. basscommDec 2025
   It's not about having time, it's about making time.

   One thing that helps me is to actually schedule time to do the cool, fun stuff, put it on my calendar and treat that appointment as inviolable as missing work. Because it is work, and eventually it will become a habit.

   I also recently read Time Management for System Administrators which has some other helpful suggestions: https://www.oreilly.com/library/view/time-management-for/059...

   Show morethread
2. mystickphoenixDec 2022
   A few things come to mind along with what's already been mentioned:

   Assorted Non-Book Readings:

   - https://randsinrepose.com/dont-skip-this/

   - http://www.stilldrinking.org/programming-sucks

   - https://sysadvent.blogspot.com/2019/12/day-21-being-kind-to-...

   - https://donellameadows.org/archives/leverage-points-places-t...

   - https://grugbrain.dev/

   - https://changelog.com/posts/rich-hickeys-greatest-hits

   - https://github.com/papers-we-love/papers-we-love/blob/master...

   - http://www.cs.unc.edu/techreports/86-020.pdf

   Books:

   - The Phoenix Project: Gene Kim, Kevin Behr, George Spafford

   - Deep Work: Cal Newport

   - The Art of Leadership: Michael Lopp (Rands)

   - Extreme Ownership: Jocko Willink and Leif Babin (once you get through the ho-rah stuff it's a fantastic read)

   - Time Management for System Administrators: O'Reilly (fantastic for interrupt driven work)

   - Elements of Clojure: Zachary Tellman (not just for Clojure devs)

   Show morethread
3. dredmorbiusAug 2021
   Oh, just a few.

   Time Management for System Administrators, by Thomas A. Limoncelli (2005) https://www.oreilly.com/library/view/time-management-for/059...

   Getting Things Done by David Allen https://gettingthingsdone.com/ https://www.worldcat.org/title/getting-things-done/oclc/9347...

   Cal Newport, generally: https://www.calnewport.com/

   About 9,700 results in Worldcat, by title: https://www.worldcat.org/search?qt=worldcat_org_all&q=ti%3A%...

   Show morethread
4. pjungwirMay 2021
   The most famous book to discuss this idea is The Goal by Eliyahu Goldratt, published in the days when American manufacturing was trying to compete with Japanese methods. That book inspired The Phoenix Project by Gene Kim and others, which applied the ideas to DevOps.

   It's been several years, so I don't remember how TPP tied slack to concrete DevOps practices. But in Google's SRE book (published by O'Reilly), they talk about how if more than half of an SRE's time is consumed by incident response, they push maintenance back to the developers. Reserving 50+% time for project work is a way to maintain slack. (See Time Management for System Administrators by Thomas Limoncelli for more techniques.)

   (EDIT: I'm starting to remember more details from TPP now: One way to add slack is to find & remove bottlenecks, e.g. the sysadmin who was "too good" at solving everyone's problems. This is also why you may want to mix more generalists into your teams than is strictly efficient. Likewise with having "cross-functional teams". They can share work so there are fewer bottlenecks.)

   In other software development, you can achieve slack by filling each sprint with a mix of high- and low-urgency work. (And btw, we should replace the word "sprint".) Or leaving 20% of your time for refactoring. Or practicing the Boy Scout method (and factoring it into your estimates). Or when the graybeards double any estimate before sharing it with the customer. Google's 20% time is another form of slack.

   Webdev shops struggle with this since utilization is a major driver for profitability. I've seen many start in-house products to fill the time between client work. You'd think these would turn out great, since they are (or ought to be) experts at building and launching new tech ventures. But I've only seen a couple work out. In practice they get neglected as soon as more billable work arrives.

   What works better is a focus on internal tooling. This is much like Toyota's continuous improvement (a connection also made in The Goal). You don't get continuous improvement unless you have slack, and it's a good way to "use" your slack. If you don't have any ideas for internal tooling (ha), maybe encourage your devs to make some open-source contributions.

   It's notable that you don't achieve slack by sleeping in. The secretaries still had to show up to work, even if they didn't have too much to do. So you still need a good work ethic. This makes me skeptical of the author's idea that you can motivate yourself with tight deadlines. I often wait until the last minute to do things, but that's not really buying me slack.

   On the other hand playing Counterstrike may be genuine slack, since you can always turn it off if something comes up. :-)

   For developers, another way to use slack time, besides building tools and playing games, is personal development: read a book, do a course, write a blog post, etc. Your greatest asset is your mind, and you must invest in it! Or engage in a community and meet new people. That is a kind of investment too.

   I suspect slack is better managed in the small than in the large. I'm thinking of Hayek's critique of central planning in Road to Serfdom, or Michael Polanyi's objection to centrally-planned scientific research. I knew a company once that devoted one in four sprints to refactoring. While that would be an improvement in many places, it feels a bit too centrally-planned to me. Give people slack, but let them use it how they like.

   Show morethread
5. galvinApr 2020
   Focus and practice helped me.

   Cut down the number of tasks you're working on at once. If you think about it there's probably some that don't need to be done. Personal projects that you'll never see through can be dropped. Narrow down the most important and focus on them. Throwing something away isn't failure, it's a decision to prioritize.

   It's an ongoing process which requires practice.

   With focus you can practice finishing things, starting small. Finishing tasks feels good and leads to more things being finished.

   If you feel lost or are having difficulty taking next steps it's probably a sign that you need to break up a task into smaller pieces. Try picking one small part you can do now and finish that.

   Tangentially, you might also be interested in "Time Management for System Administrators" by Limoncelli. It's got a lot of good info about getting things done (in any domain).

   Show morethread
6. mantleproFeb 2020
   Productivity increased greatly for me after ditching my smartphone for a dumb phone and using a bullet journal when I'm away from the computer. That plus a disciplined regimen of daily planning, execution, and migrating tasks to the next day if not finished; learned from "Time Management for System Administrators" by Tom Limoncelli.
   thread