Where David Allen lead me wrong

The first insight I had is that Getting Things Done (GTD) has steared me wrong. This is hard to say because I think it’s a great book with a lot of great insights. In particular the strong admonition to get everything you need to do down on paper has changed the way I live and think. That list includes all the major and minor commitments I’ve made, and having it out of my head and in a system that I trust reduced my stress levels imensely.

But I found that I still have a lot of stress. And I found that I was still thrashing back and forth between projects without making the kind of decisive progress on any of them that I wanted to.

Why wasn’t the GTD process enough?

Because, as I eventually learned the GTD “inbox processing” strategy as described in the book is broken. You are supposed to choose between three options for each input: do it, deligate it, or defer it. But really there’s a key fourth option that is the really important one if you’re life is anything like mine.

What is that all important forth option?

• Don’t do it. Say no. Avoid adding another commitment to your list.

Wait, there’s science behind this!

This is really critical because like any queue that’s processed by a limited resource (in this case my time and attention) filling it too full actually causes the system to break down. This process of breakdown even has a technical name that feels exactly right, it’s called “thrashing.”

Every programmer and computer user knows what this is like. Open too many apps at once, and your machine grinds to a halt, data keeps getting swapped out to disk and the rate at which the machine can process information goes down exponentially.

Ok, so know I knew the name for my problem. Naming it is good, but it’s not the solution.

So, how do I stop thrashing about and get stuff done?

At some point, i’m not exactly sure where, I had a realization that in life, just like a manufacturing line, or a software resource issue, there are two keys to preventing thrashing.

1. Avoid too much multitasking. A system spends time switching between tasks and is less efficent when time-windows for work are too small, and task-switching happens too often.
2. When multiple commitments are being made that require real-time or near real-time responses, you have to keep the task-switching window short enough that high-priority tasks can be scheduled immediately. This, of course, creates a tension with the first principle which suggests larger time windows between task-switching.

This is where Getting Things Done’s todo list system provided me with a lot of help. It helped me reduce my task-switching costs, and that’s allowed me to get a better balance on these two pressures.

Letting the work FLOW

I think there’s a very clear analogy with what happened at Toyota in the early days. Manufacturers had die presses which took a long time to change, so they would run them for a long time. This was great in that it helped keep the machine working and limited the downtime. But it also meant that there were long delays in the system since the switching time and the time for the long runs added up. Toyota decided that since they couldn’t afford more machines, they needed to figure out ways to reduce the cost of switching, which reduced total cycle time, made them more responsive to bugs (quality problems) and helped them to get more done in less time.

Reducing the cost of switching made it possible for the system to run differently, rather than batching up lots of work and pushing it through, it Toyota discovered that you could pull what you needed through the system just in time. This same thing works for time management, when you aren’t overloaded you can be more responsive to today’s needs, and you avoid the inevitable mismatches that come with long delays between request and response.

What happens when there’s still too much to do?

But, to come back to my main point, even when you’ve done everything you can do to reduce the task-switching costs, you still can have significant thrashing problems when the resource (that’s you or me) gets overscheduled.

Most projects I’ve worked on ended up in this situation at some point, where working harder stopped producing results because of schedule pressure and resource contention.

This is why saying no is a critical skill.

If you limit the commitments you make, you can provide rapid turn around on the commitements you do make, and everything runs much more smoothly because you’re thrashing less, and wasting less time on task switching.

Beyond the basics, I’ve discovered that one really critical notion is to have enough slack in your system to handle emergencies. If you schedule the system full, any high-priority, high-urgency task that enters the system can break the whole process.

Without slack in the system emergencies snowball…

I know this from experience, as I’ve had my share of emergencies in the last couple of years, and when there was slack in the system things settled down quickly, and when there wasn’t I ended up with new emergencies caused by the first emergency delaying things just a little bit too much.

So, when you are tempted to take on another commitment, think about what would happen to your life if you had to take a week off to deal with a death in the family, or to help a sick relative. If you don’t see any path to recovery, perhaps you’re over-scheduling your most important resource — you.

When No, really means Yes

In the end I discovered the biggest irony of time management: it’s only when you say No to some things, that you have the ability to say Yes, and make real commitments.

When you say no to helping a friend move, or to visiting family, or whatever feels valuable to you you will feel terrible. But, if you don’t say no sometimes to at least some of these things, you’ll end up not being able to do any of those things anyway, because you’re always behind and never quite able to fulfill the commitments you make.

I learned the hard way, hopefully you don’t have to ;)

Children of kings and great magnates were the first to grow up out of touch with the world. Suburbia means half the population can live like kings….

Paul Graham

You can’t shelter people from everything bad or scary, and expect them to live in the real world.

Project managers, System Administrators, and parents should take note of this.

People can only step up and take responsibility when they actually know what’s going on. Seems to me that there are lessons for how we talk to people about project risks, how we handle e-mail spam problems, and how we think about IT services. It’ll be a while before I figure out what exactly all of those lessons are….

But at least with good tools, I can participate this odd hobby in the comfort of my own home.

SSH makes Remote administration of linux/Unix servers remarkably easy. Unfortunately Windows 2k/2k3 requires a GUI for Remote administration, but Microsoft generosity has alloted two Terminal Server Clients for remote administration purposes on every Windows 2000 and Windows 2003 Server they sell. Unfortunately, sometimes you get disconnected unintentionally. If this happens twice, you could get the dreaded “The terminal server has exceeded the maximum number of allowed connections” error.

Now, you can’t even connect to disconnect the old sessions. You’re screwed, and you need to drive an hour to the server and get to the machine and kill the inactive sessions.

Not really, you can just:

start | run - mstsc -v:10.10.10.10 /f -console

This attaches you to the special “console” session, which kicks whoever is logged in locally off and allows you to remote control the machine again. You can then kill the inactive sessions and move on with your life. Always kill the inactive sessions first, because if you get disconnected again you will have to drive in.

Since I normally run Linux at home, I don’t use the above command, I use:

rdesktop -0

I also have a shiny new MacBook which isn’t always booted into Ubuntu Linux, sometimes it actually runs Mac OS X. Have no fear I can use the Remote Desktop Client to connect to the console session:

No fancy command line option here, but you can hold down the command (open apple) key and click the Connect button.

If you control the server, and you don’t have any long running user processes you want to be able to reconnect to on the server I highly recommend also setting up your servers to automatically disconnect inactive sessions.

That way even if you get disconnected, you just have to wait a few min. until the first connection to drop times out.

Hopefully other people outside IT will post classes that will help us bring new people on board more quickly. This is functionality we need, but I am hoping that it also helps to communicate that the IT department exists to amplify people’s ability to execute on their creative ideas.

Too many companies have an ingrained view of IT as nay-sayers and obstructionists. Or, even worse they see IT people as trying to automate them out of a job. The tools we deploy, and the way we deploy them speak volumes about how we view our jobs — and people know how to read the message we send.

How powerful would it be if everybody saw IT as a lever they could use to move their individual worlds? What if they believed that IT connected to the things they really care about — even if those things aren’t always work related.

Studies at Gallop show that people are consistently happier and more productive when “someone at work cares about [them] as a person.”

So, if IT’s job is to make people more productive, it also needs to be IT’s job to care about people.

Anyway, the new sheet showed dates that were four years and 1 day older than what they ought to be. So a project with a billing date that should have been January 20, 2006 was showing up as billing on January 19, 2002. Nobody could figure it out, and because it is something pretty critical to our business (billing is about as business critical as it gets) it made it’s way up to me right away.

The dates were formated in different ways in the original spreadsheets, but if you turned them back into plain numbers you could see that they were both coming up as 37275. Anyway to make a long story short, it turns out that Excel has a feature labeled “1904 dates system” which is available under the options menu.

This means that under the covers Excel stores dates as the number of days since January 1 1900. Unless of course you have “1904 date system” turned on, in which case it counts days since January 2nd 1904.

As features go, this one seemed pretty absurd to me, but it turns out that this has something to do with Office on the Mac and some 10 year (at least) bug in Mac OS.

It seems like a little bit of foresight 15 years ago would have prevented Microsoft from having to maintain this feature for I don’t know how many versions of office. But, even though the bug this was originally designed to work around has long been fixed, the workaround is still generating work at Microsoft, and for helpdesk people around the world!

Oh well, at least this kind of thing keeps our lives interesting.

TPoSaNA is great!

If you manage computer systems, or the people who manage the people who manage computer systems, you should buy and read this book!

Oh, the full title is The Practice of System and network Administration, and it is highly technical without ever delving into the specifics any specific vendor or technological solution. A lot of things in this book will feel intuitively obvious to the experienced system administrator, but I know I couldn’t have articulated them all very easily without reading the book.

Not only that, the book is well written, and includes enough interesting stories of real life system administration to assure that you will probably laugh out loud at least a couple of times when reading it.

If you manage a large number of systems, or critical servers, this book has information that will make your life better. Buy it, read it, be more successful at work, and have more fun. You’ll learn ways to set up your network so you don’t have to worry about it while you are on vacation — and you’ll learn ways to have more fun at work. Heck, there’s even a chapter called “Being Happy.”

Gerald Weinberg wrote The Psychology of Computer Programming almost 30 years ago, and it has made Software Development better by focusing on the people who do it well and how they work.

But to my knowledge nobody has written anything even remotely like it in the field of System Administration. And it is too bad because Jerry’s work helped lead the way toward programming languages designed for human beings, not machines.

Can somebody write this book soon?

We need to better understand what makes SysAdmin’s tick, and how the great ones solve complex problems quickly under pressure. The more we know about the best at our profession and what particular talents drive them, the more we’ll be able to move our profession forward.

But there seems to be no community of interest around this subject, and unless that happens it is going to be hard to find a market for a book like this.

If you this is something you are working on, or even just something that interests you, let me know and I might start a mailing list or something to help us organize and grow this idea.

Here’s a list of some of the books that have resonated particularly well with me. I have learned a lot from each of these books, and I highly recommend them to all sorts of IT Managers, team leaders, and project management professionals.

Books about IT, but not a specific technology:

• Becomming a Technical Leader: An Organic Problem Solving Aproach
• Rapid Development
• Code Complete
• The Practice of System and Network Administration
• Peopleware
• The Pragmatic Programmer

Books about Lean and the Toyota Production System

• Lean Software Development
• Lean Thinking
• Product Development for the Lean Enterprise: Why Toyota’s System Is Four Times More Productive and How You Can Implement It

Books about Human Relationships

• Crucial Conversations
• Getting to Yes
• Influence: Science and Practice

Books about organization/time management

• Getting Things Done
• Organizing from the Inside Out

I’m looking for revolutionary improvements in how we do IT Support, not just a few incremental improvement ideas.

What can we do to make our users think, “WOW, I’ve never seen IT Support like that!”?

I think one key is to teach our users to do cool stuff.

When we help people do things that make them smarter and more successful, that is going to make them happy. And some of that positive emotion is going to rub off on us.

How many IT Support groups teach people how to do non-linear video editing, or to sell stuff on e-bay, or make cool looking web pages? How hard would it be to do that?

The other day I took a few min. out of my day and showed one of our users how to hook up to a wireless network at Pannera Bread. She loved it, and has spent the last couple of weekends drinking coffee, and reading e-mail.

For many of us, this connecting to an unencrypted 802.11 network seems easy, but it gave her freedom, and made her feel good about herself. And that’s revolutionary because most of the time, for most of the world, a call to IT Support leaves you feeling frustrated, and stupid.

And that’s no way to treat your customer!

I was at the bookstore last night, and picked up a copy of Purple Cow, by Seth Godin.

The basic premise of the book is that mass marketing as we know it is a dying art form, and the new marketing is going to be a new kind of hyper-word-of-mouth, accelerated by blogs, e-mail, and online social networks. Seth argues that the thing you need to succeed in this new kind of market is remarkable products, like a Purple Cow.

A Purple Cow would be pretty remarkable, wouldn’t it? — at least for a while!

How does this impact me? I don’t do marketing. I don’t build the kind of products that individuals buy. I manage and do software development, along with internal and external support. It is pretty easy to see how Purple Cow thinking can help us better make and market software products.

But how can we create the Purple Cow of IT support?

I don’t have the answer yet, but I know it is a question worth asking.

Instead do something that your customers care about! Build systems that protect them from having corrupted files, write unit and functional tests so your users don’t ever see that bug. Get response times down to the point where you wouldn’t have enough “longstanding tickets” warrant a weekly meeting.

And once or twice a month take some time out with the whole team to identify ways to reduce the waste that’s still in the system. The story of Toyota shows that even after 30 years of improvement creative people can still find new areas of waste and ways to remove them.