A Primer On Strategy for Technicians

Everyone in IT has heard their boss, their grandboss, or executive leadership use the word “strategy” at some point.  What does it really mean?  Getting beyond the buzzwords can be hard, especially if one’s organization is not skilled at communicating these ideas.  It’s impossible if one is laboring under the false belief that strategy isn’t relevant to technical work.

If you don’t understand why you are doing what you are doing, you can’t make reasonable decisions. That means you are more dependent on your manager to think for you, which makes you expensive to manage, less valuable to your organization, and assumes your manager has a reasonably deep understanding of your job.  If you don’t understand why your boss is doing what they are doing, you can’t anticipate what’s coming next, let alone influence it.  You have less power in your organization.

Having at least a basic understanding of strategy, especially since most people in your position don’t, can be a massive career accelerator for an individual contributor.  This is especially true in IT, because our technological systems influence the behavior of the organization and sometimes of its customers.  

What is strategy?

A lot of people don’t actually understand what a strategy is, including an unfortunate number of leaders.  There’s a whole book about this: Good Strategy, Bad Strategy by Richard Rumelt.  In his introduction, Rumelt says: “The core of strategy work is always the same: discovering the critical factors in a situation and designing a way of coordinating and focusing action to deal with those factors.”

Put another way, strategy is the combination of a model of how the world is working with a rule or set of rules for how to respond to that in decision making and action.

If your leadership is telling you that their strategy is to “be the best” or “don’t give up” or “give great customer service”... that is not a strategy.  Those are aspirations.  Aspirations are great, but they aren’t the powerful tool for effective, coordinated decision-making in groups that strategy is.  That’s the point of having a strategy: so independent actors can individually make decisions that further a common goal, rather than bottlenecking on leaders’ decision-making, or working at cross-purposes to one another.

How do I build a strategy?

Imagine, for a moment, that your executive leader says, “We’re starting a major hardware refresh in six months. I need a strategy for how best to improve security as part of that process.”

What do you do?

Start with a mental model…and the expectation that it will change.

You’ve used mental models before, even if you’ve never put a name to what you were doing.  If you write code, then at some point you decided what variables you’d be working with, how to handle them, and when to throw an error.  You chose interfaces and storage.  That’s building a mental model.

As a technologist or technology manager, you probably have a rough mental model of a hardware refresh you can pull out of your hat.  You know that hardware has to be purchased, received, and inventoried.  You know someone puts software on it before racking it or delivering it to end users.  You know that software must be configured.  You know that data must often be migrated.  You know that the disruption caused by changing over from the old to the new presents an opportunity to re-architect networks and services or make other changes without additional disruptions, and at lower cost if the re-architecture is planned early enough to influence hardware and software purchases.

You also likely know something about the current state of the technology being refreshed.  What’s the network layout (physical and logical)?  What software do you depend on?  What’s cheaper to do during the refresh vs. after?

That’s your model.  Many technologists fall into the trap of not trying to make a model until after they’ve done all their information gathering.  Don’t do that to yourself.  Having a model at the outset, and updating it along the way, helps you show progress earlier, helps you make better decisions about what information to gather, and leads you to have a better strategy in the end.

To understand how the model helps you show progress earlier, pretend your boss asks you for an update at your one-on-one two days into the project.  If you don’t have a model to work from, the best you can say is “I’m still researching”.If you do have a model, you can say, “It’s early, but let me share the model I’m working from so you can catch anything I’m missing.  I’m working under the assumption that we care more about our TCO over the next 7-10 years than the up front costs (within reason).  I assume that we’d save money (due to labor savings) if we replaced everything that can’t be centrally managed, even though some of those devices have 12-18 months of theoretical life span remaining.  I’m working to get numbers to either back up that assumption or refute it.  Given what our SOC manager has told me about what they most observe and respond to, I want to focus on centralized configuration and change management, patch management speed and reliability, and getting more advanced monitoring in the three places our SOC team says are most lacking.  Does that sound right to you?”

You probably got that from some guesswork, poking around your asset inventory, and taking the SOC manager out to coffee… but it’s a heck of a lot more than “I’m still researching.”

Understand priorities

Once you have a basic mental model to work from, the next step is to figure out what you are trying to optimize for.  Do you need to reduce spending in the current fiscal year?  Do you need to front-load as many costs as possible (i.e. spend more up front for lower costs later)?  Do you need the lowest total cost over 5 or 10 years?  How important is your ability to support future expansion vs. saving money now?

The reason we do this before information gathering is that you may find that your leadership has not been clear on their priorities.  It’s wise to interview your boss to understand their priorities as soon as possible after accepting the assignment… but you may or may not get much from it.  Sometimes, this is because your boss hasn’t decided what the real priorities are.  Sometimes, it’s a development challenge to find out whether you can prioritize effectively and offer you feedback and guidance.

Many technologists lock up when they hit a situation where they need to prioritize to form a strategy, but you don’t have to.  What you should do is come up with the 2-3 most plausible priorities, and offer your management 2-3 options along with what trade-offs are involved and what you recommend they do.

Start thinking now… is it about cost vs. effectiveness?  Is it about fast vs. good?  Is it about prioritizing uptime vs. prioritizing confidentiality?  If you want to make a good A/B/C proposal, you should be keeping track of trade-offs as you go so you can offer intelligent options down the road.

Gather information

Depending on your organization, this will be some combination of spelunking through internal data, talking to people who know things you don’t (stakeholders, people working on the refresh, etc.), and learning about things outside the organization (opportunities and threats, new techniques others are applying, available technologies and their pricing, and so on). You may need to directly test some options.  This is usually the easiest part for technically-minded folks.  If you are a working manager, remember, while the strategy needs to come from you, this may be a great time to develop one or more of your directs by sharing the research tasks.

As new information comes in, you need to keep looking at the mental model you are using.  It will need changes and refinement.  Perhaps something you thought was wrong.  Perhaps you were right, but there’s a nuance you can add to that understanding.  There’s a meaningful difference between “we think cloud will save us a lot overall” and “going to the cloud saves us $X/year on labor while costing us $Y/year in service fees, for a total $Z advantage over on-prem”.

Connect the model to decision-making

Strategy isn’t just about what we know, it’s about how we will make decisions.  Too many people get stuck on what decisions we should make…but that’s not strategy, that’s tactics.  Here’s an example of an A/B/C proposal that includes all three parts:  what we know (the model part of strategy), how we’ll decide (the decision part of strategy), and what we’d do to execute on that strategy (tactics). 

“We’re focusing on centralizing configuration and change management, improving our patch management, and improving our security monitoring.  There are two different ways we could approach this:Option A would make the refresh more expensive by about 20%, but has a lower overall TCO (total cost of ownership) over 7 years.  It could also take two additional months to complete the project.  

Option B would make the refresh more affordable up front, and faster.  Option B will costs more over 7 years as it will require higher labor costs over time.  Option B still adds the same security monitoring capabilities as option A, and meets or exceeds our compliance requirements.

I recommend option A.  Option A allows more central management, and reduces labor.  IT estimates that they can move 1 FTE to the refresh project, and it will free up 1 security FTE.  If we chose option B, repurposing existing FTE’s will not be possible.  IT and Security will have to hire an additonal 1-2 FTEs to handle increased maintenance needs as our infrastructure expands.”

Now What?

You’ve given your boss a solid recommendation.  It should be backed up with a clear explanation of the information you used to build the model and the strategy.  Track how this plays out, so you can learn and improve over time.