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.