thedwick

When most people think of the difference between something Tactical and something Strategic, they often think along one of a few lines:
1) Tactical is short-term and Strategic is long-term, or…
2) Tactical is small and Strategic is big, or…
3) Tactical is kludgey and Strategic is high-quality

These definitions are generally useful and that’s why they persist. But I think they lose one useful quality that my alternative definition captures:
4) Tactical is something you’re willing to change to meet local conditions and Strategic is something you won’t change to meet local conditions

This definition gets to the heart of the problem and it implies all kinds of good things: suddenly, something Tactical can also be high-quality and something Strategic can take less than a day.

Let’s take web services as an example. As technologists, it’s really easy to get distracted by shiny things like Enterprise Service Buses and to get bogged down in arguments with each other about REST vs. SOAP. But then we’re burning lots of energy on Tactics, and losing sight of what was really the Strategy. The real Strategy is: connecting business processes together in a way that can be orchestrated, re-mixed, and reconfigured relatively cheaply. If sending SOAP payloads over an IBM Enterprise Service Bus with 128-bit encryption implements that Strategy best in your organization, then use it. If calling well-defined stored procedures on one humongous SQL Server database running under somebody’s desk implements that Strategy best in your organization, then do that. As long as you’re realizing the Strategy, then who cares what your Tactics are (as long as they’re legal and ethical, or course) as long as they work.

All too often, we find ourselves clinging too tightly to a failed Tactic instead of adapting to conditions as we find them on the ground. During such times, what we really need to do it step back, remind ourselves of what the original Strategy really was, and find a new Tactic (using what we learned from its failed predecessor) to make it happen. Just because your first Tactic failed doesn’t necessarily mean your Strategy is unsound, it just means you need to find a new Tactic.

But if you’re on your third or fourth failed Tactic for the same Strategy let’s just say that’s a whole other ballgame.

When you’re trying to get people to adopt a new technology or process, you’re basically trying to fight millions of years of evolution. You’re paddling upsteam against our basic tendency to (all else being equal) do the thing that seems to take the least effort. So, unless you’re trying to get people to use something that is obviously and immediately better (like giving BMW 525i’s to a bunch of Ford Model-T drivers) you’ve got to do some work to take them there.

You’ll find it takes surprisingly little to discourage a new adopter from doing something. Any tiny little speed bump or hassle will switch your otherwise willing audience from:

“Tim says he’s got this cool thing that will change my life. Maybe I’ll give it ten minutes while I’m eating my salami sandwich at lunch.”

…to…

“Install what? Huh, user manual? Forget it, I’ll just read something more interesting.”

If you are trying to get a team to adopt a new practice or technology, make sure you eliminate as many obstacles as humanly possible. Even tiny obstacles are enough to make someone give up. For example:

• If they need any software, walk over to each user’s machine one by one and install it for them. Even better, install it remotely so they don’t know you were even there.
• …same thing goes for user accounts, permissions, roles, etc. Don’t make the users set up their own, instead do it for them.
• Create a step-by-step getting started guide, complete with pictures. Document every last button click and URL. Make your documentation so straight forward a (literate) 8-year-old could follow it. And I mean that literally, not metaphorically: if you couldn’t sit an 8-year-old in front of it, then you’ve got more work to do.
• …once you’re done creating that getting started guide, automate every last step in it and then remove those steps from the getting started guide. Don’t stop until you are as close to: “Step 1: Push big red button. Step 2: Enjoy.” as you can possibly be.
• Never make a reader move from one document to another. Everything should be in one place. Even more important, never make a reader move from one repository (e.g. a wiki) to another (e.g. a Word document).
• Eliminate all errors and warnings that might scare people away, even if they are harmless. When trying something new, people are like deer: any little rustling in the bushes will give them that scary feeling and make them run away.
• Make things look beautiful. You’re the expert on your technology, so you know that it’s solid on the inside even if it’s fugly on the outside. But your users don’t know that.
• Demonstrate the technology. Then wait a few weeks and demonstrate it again to the same people you demonstrated it to the first time. Repeat until you have adoption or are fired.

I call all of these things Adoption Friction. Adoption Friction is: absolutely anything that gets in the way of someone using something new. I spent many years of my career seriously underestimating the effect of adoption friction, especially the “make things look beautiful” part. Then I came under the tutelage of some talented people who get things done and finally learned my lesson.

I like to think of myself as a decent photographer, which is why I immediately identified with this post on courageous sucking. If nothing else, it taught me that I’m not really such a great photographer because I still feel like a complete idiot when I get down on the floor to take a picture, even if I know the picture will be good.

But after a few days mulling it, I realized it actually applies even better to my career. Almost without exception, the biggest leaps in my career came when I took promotions I didn’t feel totally qualified for. In most cases I was wrong, but thankfully had a boss who knew better. In one case, I was entirely right, and boy did that suck, even though I learned a ton.

The courageous sucking part of your career, though, is that part where you’ve stepped into this leadership role you don’t feel ready for, you’re making (what feels like) mistake after mistake, and to top it all off you’re doing it in front of people. You’re not a solo coder any more who can go hide in a corner. Instead you feel like a ship’s figurehead, lashed there right on the bow taking every stinging, cold wave right in the jaw. Next to learning to delegate, making mistakes in front of people might be the second most difficult leadership skill to learn.

You many have heard of the concept of “Next Action Lists” which are a part of the Getting Things Done methodology. I don’t really use the methodology, but I do use something that vaguely resembles the Next Action part of it. And I’ve found that a really useful Next Action is just looking up people’s phone numbers and writing them down.

Imagine this item is in your todo list:
–Finish Functional View diagram for Currency Trading system

And for the sake of argument you have that item in a vanilla Outlook Task.

As part of creating that functional view, maybe you need to call three different people and ask them some questions. I’ve found that often just having to look up those people’s phone number is a big enough excuse to make me put off that task. It’s stupid, I know, but it’s just the way it is and I bet there are lots of people out there just like me.

So, I’ve gotten in the habit of making this my Next Action:
–Look up the phone numbers of everyone I have to call and put them in the Outlook Task.

That’s a really small action. It doesn’t have any of the mental baggage involved in preparing yourself to (gasp) actually talk to another human being. You don’t have to think about what you’re going to say or ask, or if that person likes you, or if they’re in town or out on vacation, or where you’re going to write down what they say, or anything. You just have to look up their phone number and put it in the same place where you’ve recorded your task.

That’s it. But here’s the genius: six times out of ten, I’ll look up the phone numbers, write them down, and then immediately pick up the phone and call one of them. There’s something about those numbers staring you in the face that’s just too inviting. Try it out!

One technique I like to use is a concept of a Risk Heap. If you remember from your college days, a heap is a data structure that looks like a tree and efficiently keeps the item with the highest value on top, ready to be removed. The ordering of the heap is kept in real time, and at any given moment you’re guaranteed to have the entire set of values sorted in priority order.

To apply a heap to a project, you approach a project by (mentally) inserting everything you have to do into a heap that is ordered by that item’s risk to the project. Then working your way though your project is simply a matter of coming in in the morning, inserting into your risk heap anything new that’s popped up, and then taking the first item off the top of the heap until you’re blocked and have to pick up another one from the top of the heap.

I’m willing to wager that if you use no other technique but this one, and otherwise just blunder and feel your way through a project, you still have an OK chance for pulling the whole thing off.

The metaphor continues to work even when you stretch it a little. For example, if you take an item off the heap, do a little something to it to significantly reduce its risk (but still don’t totally complete it) and then toss it back on the heap it will settle to the right level in the heap and something else more important will pop to the top. If you constantly complete tasks only partly, they’ll remain stubbornly at the top of the heap waiting for you to pick them up the next day.

Of course, what really separates the men from the boys with this technique is how you calculate “risk”. Personally, I don’t run every item through a computer simulation that uses a five-page formula only a Ph.D would understand. I simply use a formula that looks something like this:

risk(x) = (probability_of_failure(x) * (impact_to_quality(x) + impact_to_timeline(x) + impact_to_business(x))) - how_long_you_have_to_deal_with_it(x)

where x is the task in question.

Don’t spend forever figuring this out. Remember the concept of Decision Algebra because if you take as long building and sorting your risk heap as you would have spent just dealing with its contents, then you’ve failed before you started.

There are also a variety of ways you can get the risk formula just plain wrong, like these for example:

risk(x) = impact_to_business(x) - how_much_I_dont_feel_like_dealing_with_it(x)

risk(x) = how_interesting_solving_the_problem_is_to_me(x)

risk(x) = (impact_to_timeline(x) + impact_to_business(x) ) * how_annoying_the_person_asking_is(x)

So there you go. Try it out for a few weeks and let me know how it goes.

Ok, for the nit-picky out there you may have realized that what I’m calling a Risk Heap is, strictly speaking, a Risk Priority Queue. But a heap is close enough and, after all, most priority queues are implemented under the covers with a heap anyway. That, plus, Risk Priority Queue just doesn’t roll off the tongue the same way.

I spent most of yesterday evening helping out at the California Clean Tech Open. Each of the six category winners got a “Start-up in a box”, which is $25k plus another $25k worth of pro-bono legal, marketing, and accounting services. The room at the Palace of Fine Arts in San Francisco was packed wall-to-wall with venture capitalists, entrepreneurs, and hangers-on like me. If there’s anywhere else to be in the clean tech scene I’d sure love to see it; the whole thing felt like ground zero of the New New Economy.

The entire world at any given moment consumes 14TW of power (yes, trillionwatts every second). By 2050, the world will be consuming twice that much. Even with conventional energy sources that demand is nearly impossible to meet. Without terrible wars, rampant poverty and complete environmental meltdown, meeting that demand cleanly is an outright fantasy unless we have something like a Clean Industrial Revolution. Seeing the brainpower in that room last night gave me new hope that revolution might actually happen.

I finally broke down and set up a macro to let me sort through my morning email without actually touching a mouse. It’s not exactly rocket science, but it does require a quick Google search, which I hope to save you here:

Step 1: Copy and paste a macro off the Internet like this one for moving an Outlook email to a different folder:

Step 2: Set up a custom Outlook tool bar and name it so it has a keyboard shortcut

Step 3 (possibly optional): Digitally sign your Outlook macro. I didn’t actually have to do this step, though it seems like I should have had to.

I got a good start on these steps from this post about creating Outlook email shortcuts, but its link to a macro is broken.

I saw this on my home page “quote of the day” widget and thought it was worth sharing:

“There are 10^11 stars in the galaxy. That used to be a huge number. But it’s only a hundred billion. It’s less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers.
- Richard Feynman”

Our debt was already a big monster in the closet; what will it turn into now with the events of the last 10 days?

It seems like it’s x-ray day on the Make blog. Here are two links from a guy who takes beautiful x-ray photographs and from someone who leaves a hidden treat for airport screeners in his baggage.

The more observant among you may have noticed the little SiteMeter icon in the lower right corner. That’s what I use to track visitors to this blog and is the reason I know that 99% of the traffic to my humble blog is to see my post on backing up Mac to Linkstation. Because of that, I thought it necessary to clarify: this is not a Mac blog and I promise I write about other stuff, too.

I take two lessons from this:
1) Apple really needs to get its act together on backing up to something other than TimeCapsule, and
2) If you want to drive traffic to your blog, then write a detailed technical article about something arcane but needed.