antipaucity

fighting the lack of good ideas

traveling consultant cheat sheet

“Join the Navy and See the World!”*

Perhaps one of the most famous recruitment phrases ever established in the United States.

And it’s not at all dissimilar form what a lot of budding consultants think they are going to do when either joining a services organization, or starting their own business.

I have been fortunate in that I have gotten to “see the world” as a professional services engineer – at least a little.

What the recruitment phrase fails to mention is that while you may “see” the world, you [probably] won’t get to do much while you’re “seeing” it. I’ve been to or through nearly 60 airports in the last several years. I “saw” the coast of Japan a few times when going into and out of Narita. I’ve “seen” Las Vegas – from a couplefew thousand feet. I’ve “seen” Houston – from IAD. And so on and so forth.

The far more realistic view of what will happen is something like this:

  • get call Friday afternoon asking you to be onsite in <someplace> Monday morning
  • book flight, hotel, rental car (if appropriate)
  • make sure clothes are clean
  • do as much Saturday and/or Sunday as you can, since you’ll be gone for a week
  • fly out Sunday evening or Monday morning (I’ll talk about this later)
  • get rental car
  • check into hotel
  • go to customer site
    • work
    • eat
    • sleep
    • repeat
  • check out from hotel
  • return car
  • fly home
  • repeat all of above

As someone who has been doing a travel-based job for 7+ years now, let me share some of the things I have learned with you.

Basics

Loyalty programs

Sign up for airline frequent flyer programs. In the US, this means Delta, United, Southwest, and American Airlines.

Sign up for hotel rewards. Hyatt, Hilton, Marriott, Wyndham.

Sign up for the car rental programs. Hertz, Avis, Budget, Dollar, Thrifty, Enterprise, National.

Stay “loyal”

So long as you are able, ie costs are reasonable, schedules are good, etc, stick with a single primary chain for each of the travel categories (airline, car, hotel). If you’re going to get status, might as well get it all with one place when possible.

Sign up for every promotion your loyalty partners make available. For example, I’m a United Guy (used to be a Delta Guy – but that’s a different story). I’m also a Hilton Guy (because Marriott hasn’t been as competitive (price, location) in the markets I’ve been to as they used to be). I have my Hilton HHonors Double Dip go to HHonors points and United miles. And I make sure ay time there is a promo to get more points or miles that I sign-up for it. If Hilton wants to give me an extra 5,000 United miles for every stay after the second between now and 31 August, why not take advantage of that?

Choose the best rewards – for you

Maybe you like traveling so much you want to have Avis points so you can get free car rentals on vacation. Personally, I find turning all my reward points into frequent flyer miles is my best option – renting a car for a week is almost always less expensive than paying for a flight – especially when my family goes somewhere on vacation.

Clothes

Every shirt and pair of pants I take when I go onsite are “no iron”. This saves time when you arrive. And you won’t have nearly as much time as you think you will, most of the time.

Get slip-on dress shoes. You will appreciate this most when going through airport security. But also if you have to go through security to get into customer buildings, etc.

Have an arrival and departure change of clothes that are comfortable – I like jeans and either a polo or comfortable t-shirt.

What about jackets? I like the lightest-weight jacket I can carry/wear: there will not be enough space on the plane for it, it’ll get hot in the airport, and you really only normally need it to walk from the airport to the rental car shuttle / counter, form the rental counter to the car, the car to the hotel, the hotel to the office, and all in reverse. You probably won’t need a parka for those types of activities.

Baggage

There’s a big conversation that surrounds this topic, but I’m going to tell you what works for me. First, check your main bag – it’ll accelerate your time to board, your time between flights (if you have one or more connections), and make it easier to get around the airport when you arrive (easier to use the bathroom, get a meal, etc). So save everyone headaches and check your main bag.

In your one carry-on – a laptop bag- you should have the following:

  • single change of clothes
  • snack & water bottle (empty, of course)
  • basic minimal toiletries (toothbrush, toothpaste, deodorant, etc)
  • book (or Kindle, but I like a physical book – there’s never anything to have to turn off)
  • all required chargers (laptop, cell phone, mifi, etc)
  • portable battery backup like an EasyAcc Classic

Arriving and Departing

Day-of? Or night before?

This is almost entirely a personal preference: arriving day-of (eg Monday morning) can be good if you have a family, don’t mind getting up hyper early to get to the airport, and can functional well enough on little sleep.

Arriving night before (eg Sunday night) can be good because if you’re bumped or delayed on a flight, you have cushion before your customer expects to see you.

Either way, always try to check-into your hotel before going to your customer – if it’s an early-Monday arrival, change out of your travel clothes at the airport into work clothes, and have the hotel hold your bags for you.

I alternate between which is better for me to do based on how many connections I have, customer expectations (if you have a mandatory 0900 meeting Monday, and you flight won’t arrive til 0930, you have to come in Sunday night), time of year (weather considerations), etc.

What did I miss?

What would you add/change/tweak on this cheat sheet?


* I always though it should read, “Join the Navy and Sea the World”

what level of abstraction is appropriate?

Every day we all work at multiple levels of abstraction.

Perhaps this XKCD comic sums it up best:

If I'm such a god, why isn't Maru *my* cat?

abstraction

But unless you’re weird and think about these kinds of things (like I do), you probably just run through your life happily interacting at whatever level seems most appropriate at the time.

Most drivers, for example, don’t think about the abstraction they use to interact with their car. Pretty much every car follows the same procedure for starting, shifting into gear, steering, and accelerating/decelerating: you insert a key (or have a fob), turn it (or push a button), move the drive mode selection stick (gear shift, knob, etc), turn a steering wheel, and use the gas or brake pedals.

But that’s not really how you start a car. It’s not really how you select drive mode. It’s not really how you steer, etc.

But it’s a convenient, abstract interface to operate a car. It is one which allows you to adapt rapidly to different vehicles from different manufacturers which operate under the hood* in potentially very different ways.

The problem with any form of abstraction is that it’s just a summary – an interface – to whatever it is trying to abstract away. And sometimes those interfaces leak. You turn the key in your car and it doesn’t start. Crud. What did I forget to do, or is the car broken? Did I depress the brake and clutch pedal? Is it in Park? Did I make sure to not leave the lights on overnight? Did the starter motor seize? Is there gas in the tank? Did the fuel pump quit? These are all thoughts that might run through your mind (hopefully in decreasing likelihood of probability/severity) when the simple act of turning the key doesn’t work like you expect.

For a typical computer user, the only time they’ll even begin to care about how their system really works is when they try to do something they expect it to do … and it doesn’t. Just like drivers don’t think about their cars’ need for the fuel injector system to make minute adjustments thousands of times per second, most people don’t think about what it actually takes to go from typing “www.google.com” in their browser bar to getting the website returned (or how their computer goes from off to “ready to use” after pushing the power button).

Automation provides an abstraction to manual processes (be it furniture making or tier 1 operations run book scenarios). And abstractions are good things .. except when they leak (or outright break).

Depending on your level of engagement, the abstraction you need to work with will differ – but knowing that you’re at some level of abstraction (and, ideally, which level) is vital to being the most effective at whatever your role is.

I was asked recently how a presentation on the benefits of automation would vary based on audience. The possible audiences given in the question were: engineer, manager, & CIO. And I realized that when I’ve been asked questions like this before, I’ve never answered them wrong, but I’ve answered them very inefficiently: I have never used the level of abstraction to solve the general case of what this question is really getting at. The question is not about whether or not you’re comfortable speaker to any given “level” of customer representative (though it’s important). It is not about verifying you’re not lying about your work history (though also important).

No. That question is about finding out if you really know how to abstract to the proper level (in leakier fashions as you go upwards assumed) for the specific “type” of person you are talking to.

It is vital to be able to do the “three pitches” – the elevator (30 second), the 3 minute, and the 30 minute. Every one will cover the “same” content – but in very different ways. It’s very much related to the “10/20/30 rule of PowerPoint” that Guy Kawasaki promulgates: “a PowerPoint presentation should have ten slides, last no more than twenty minutes, and contain no font smaller than thirty points.” Or, to quote Winston Churchill, “A good speech should be like a woman’s skirt; long enough to cover the subject and short enough to create interest.”

The answer that epiphanized for me when I was asked that question most recently was this: “I presume everyone in the room is ‘as important’ as the CIO – but everyone gets the same ‘sales pitch’ from me: it’s all about ROI. The ‘return’ on ‘investment’ is going to look different from the engineer’s, manager’s, or CIO’s perspectives, but it’s all just ROI.”

The exact same data presented at three different levels of abstraction will “look” different, even though it’s conveying the same thing – because the audience’s engagement is going to be at their level of abstraction (though hopefully they understand at least to some extent the levels above (and below) themselves).

A simple example: it currently takes a single engineer 8 hours to perform all of the tasks related to patching a Red Hat server. There are 1000 servers in the datacenter. Therefore it takes 8000 engineer-hours to patch them all.

That’s a lot.

It’s a crazy lot.

But I’ve seen it countless times in my career. It’s why patching can so easily get relegated to a once-a-year (or even less often) cycle. And why so many companies are woefully out-of-date with their basic systems from known issues. If your patching team consists of 4 people, it’ll take them a year to patch all 8000 systems – and then they just have to start over again. It’d be like painting the Golden Gate Bridge – an unending process.

Now let’s say you happen to have a management tool available (could be as simple as pssh with preshared SSH keys, or as big and encompassing as Server Automation). And let’s say you have a local mirror of RHN – so you can decide just what, exactly, of any given channel you want to apply in your updates.

Now that you have a central point from which you can launch tasks to all of the Red Hat servers that need to be updated, and a managed source from which each will source their updates, you can have a single engineer launch updates to dozens, scores, even hundreds of servers simultaneously – bringing them all up-to-date in one swell foop. What had taken a single engineer 8 hours is still 8 – but it’s 8 in parallel: in other words, the “same” 8 hours is now touching scores of machines instead of 1 at a time. The single engineer’s efficiency has been boosted by a factor of, say, 40 (let’s stay conservative – I’ve seen this number as high as 1000 or more).

Instead of it taking 8000 engineer-hours to update all 1000 servers, it’s now only 200. Your 4 engineer patching team can now complete their update cycle in well under 2 weeks. What had taken a full year, is now being measured in days or weeks.

The “return on investment” at the abstraction level of the engineer is they have each been “given back” 1900 hours a year to work on other things (which helps make them promotable). The team’s manager sees an ROI of >90% of his team’s time is available for new/different tasks (like patching a new OS). The CIO sees an ROI of 7800 FTE hours no longer being expended – which means the business’ need for expansion, with an associated doubling of server estate, is now feasible without having to double his patching staff.

Every abstraction is like that – there is a different ROI for a taxi driver on his car “just working” than there is for a hot rodder who’s truly getting under the hood. But it’s still an ROI – one is getting his return by being able to ferry passengers for pay, and the other by souping-up his ride to be just that little (or lot) bit better. The ROI of a 1% fuel economy improvement by the fuel injector system being made incrementally smarter in conjunction with a lighter engine block might only be measured in cents per hour driving – but for FedEx, that will be millions of dollars a year in either unburned fuel, or additional deliveries (both of which are good for their bottom line).

Or consider the abstraction of talking about financial statements (be they for companies or governments) – they [almost] never list revenues and expenditures down to the penny. Not because they’re being lazy, but because the scale of values being reported do not lend themselves well to such mundane thinking. When a company like Apple has $178 billion in cash on hand, no one is going to care if it’s really $178,000,102,034.17 or $177,982,117,730.49. At that scale, $178 billion is a close-enough approximation to reality. And that’s what an abstraction is – it is an approximation to the reality being expressed down one level. It’s good enough to say that you start your car by turning the key – if you’re not an automotive engineer or mechanic. It’s good enough to approximate the US Federal Budget at $3.9 trillion or maybe $3900 billion (whether it should be that high is a totally different topic). But it’s not a good approximation to say $3,895,736,835,150.91 – it may be precise, but it’s not helpful.

I guess that means the answer to the question I titled this post with is, “the level of abstraction appropriate is directly related to your ‘function’ in relation to the system at hand.” The abstraction needs to be helpful – the minute it is no longer helpful (by being either too approximate, or too precise), it needs to be refined and focused for the audience receiving it.


*see what I did there?

may 11 bglug meeting 6:30p at beaumont branch: topic – freeipa

We will be meeting at the Beaumont Library Branch at 6:30p on 11 May.

Our speaker is the LUG’s own Nathaniel McCallum, one of the FreeIPA maintainers – and all-around nice guy.

Come out and support the LUG, learn something new, and meet cool people.