Firefighting or fire preventing: how to do strategic technology planning when everybody is busy

Informed decision-making and risk mitigation.

Strategy planning sounds easy - but it’s often difficult to do successfully. Strategic technology planning is no exception, especially if your team is already stretched thin.

How do you know if your current strategy needs adjustment and how should you approach the planning process itself to make sure it works?

Let’s start by looking at the signs that your planning or execution can use some help.

Signs your tech strategic planning is not pulling its weight

Daily firefighting

Something always seems to fail, pulling valuable resources towards urgent tactical issues. Your staff and vendors spend countless hours keeping technology running. You may also notice a fear of change and reluctance to touch anything that’s still operational, even if it’s barely functional.

Operational surprises

Unexpected changes to vendor contract or pricing, discontinued products, product updates that changes the way you operate, expiring licenses, failed audits - it feels that business-impacting tech changes are constantly happening without warning.

Reactive budget spend

Even thinking about investing in research or new revenue sources development feels impossible as you constantly reallocate budget to cover unexpected tech surprises.

The team is tired

The chaos of fighting daily tech challenges wears thin on your team, leading to burnout and decreased morale.

Why strategic planning is hard

In smaller teams daily work takes priorities and it’s easy to see why.

Today’s problem always wins over tomorrow’s problem. Strategy can feel like an unnecessary luxury, especially since the tech - and the world - keeps changing at an increasing speed.

It’s significantly easier to manage “the now” while simply increasing budgets to deal with next year’s issues as they come. And as people no longer stay at the same company for long, the chance of facing the consequences of ignoring future problems is low.

Recognizing the future needs is a skill that requires practice. While CEOs in large companies get paid to predict trends and provide strategic directions, carving out time and getting the team’s input is a challenge when things just need to be done.

Tactical always wins over strategic.

Why strategic planning fails

Even if the signs indicate a clear need for tech strategy, will the planning be successful?

Often the planning follows an established framework, involving multiple meetings and brainstorming sessions. Documents and slide decks are produced, the plan and milestones are defined, but at the end things do not improve. Tech is still broken, budgets are still overblown and the same issues still exist years later.

Every failed cycle kills morale and saps team energy more and champions - the most energetic supporters of change - quit.

It’s easy to attribute strategy plan failure to implementation issues, but even flawless execution cannot correct a misfit plan that simply does not align with your organization.

The alignment is critical to get right. Working through conflicting priorities - choosing between internal needs, market changes, customer demands and being realistic about what can be accomplished is not easy.

Here how I usually approach the process to overcome these challenges.

What works - culture of ownership

In my experience strategic planning imposed from the top down often fails.

As a leader, you need to talk to the people doing the work and create a culture where they feel ownership over decisions and priorities.

The reason is pragmatic - even if you had risen through the ranks, just a year or two away from tactical tasks warp your understanding of how work is truly done.

Having a culture of ownership means allowing people to see that their input matters - and understanding the reasoning behind the decisions. If the outcome of planning is a “us vs them” dynamic where the team is not clear on why certain things were prioritized, you’ll have less and less valuable input with each cycle.

Considering how much time is dedicated to status updates to grasp the real picture of what’s happening in organization, it’s not practical to damage the culture where you lose insight into challenges your team experiences daily.

What works - interview tour

Before the planning officially kicks off, take a “interview tour” across your organization. Talk to people from different functions and levels. Listen for patterns and categorize the root causes into distinct buckets. I call then “Must Have”, “Should Have” and “Nice to Have”

‘Must have’ bucket

This is the least fun bucket that includes items that simply have to be done, typically with a specific deadline.

Items may include new compliance or regulatory requirements, license expirations, product discontinuation, unsustainable price increases. ‘Must have’ items could also be triggered by business change or market shift, new technology that can solve existing issues or modernization of aging software. The penalties for not addressing ‘must have’ items are clear and usually severe.

Nobody is excited about ‘must have’ bucket.

The primary goal is to minimize and manage. You can do that by questioning if the item is truly a“must”. Can it be replaced? Tossed? If one piece of your software triggers compliance issues, decommissioning or replacing it may be a solid, less painful strategy.

Once your list contains ‘must haves’ along with their deadlines and estimated effort, establish the optimal order of operation. Some items may have dependencies and need to be done in a specific order to avoid redundant work.

‘Should have’ bucket

‘Should have’ is a bit more innovative. Here you will align with your business goals, vision and inspiration to define targets for the future. What initiatives would help you to be more competitive in the market? Are there new products, services or revenue sources you can consider?

A good ‘should have’ bucket item may require significant brainstorming and research to define. While ‘must have’ are obvious, ‘should have’ demand tough questions.

Ask - “Are we correct in our assumptions? How do we know is this project is successful (and how do we define success)? How will success be measured?”

It’s also important to distinguish between ‘should have’ and ’nice to have’. Ask “What happens if we don’t do this?” and “What happens if we do?” ‘Should have’ items will generate clear, impactful answers.

‘Nice to have’ bucket

‘Nice to have’ bucket improves business process and makes life easier. These items address a long term pain or a gaps that aren’t painful enough to be considered a “should” have. It’s an inconvenience that everybody got used to - and usually startles a new hire.

You should try to include at least one ’nice to have’ in your planning. It boosts morale - sometimes even a tiny improvement makes a huge non-monetary impact on the team.

How should you pick the best ’nice to have’? Listen to the team, what is the most frequently mentioned inconvenience? Pick the most low hanging fruit - select items with the quickest, most noticeable win.

What is a win? It can be a tangible (time saved) or intangible (morale, customer experience, better brand perception).

If your company is in survival mode, it makes more sense to pick a tangible item.

Do you have what it takes?

While sorting, keep in mind that planning is empty without execution. ‘Must haves’ are a must, but ‘should have’ and ’nice to have’ selection should be driven by a realistic assessment of your resources.

Do you have internal talent, budget, vendors, tools?

I like to assign a probability of completion to each item - based on what you know about your business now.

Probability helps with prioritization. For example, you may not have the internal skills to complete a specific project. To solve, add a ‘must have’ training to acquire the skills.

Good rules to follow

At this point you have a collection of important items categorized in three distinct buckets and probability of completion. Usually the amount of items will exceed desired execution timeframe. How do you narrow it down?

Here are some rules to help.

Rule #1: do not redo

Do project once. Agile makes it tempting to do “something”, experiment and then redo if needed. Committing to a solution feels risky and permanent.

For strategic initiatives the cost of redoing the same thing over and over is just too high. And I am not talking about financial side only. Your team appreciates stability. And if you listened to their input, you will make the right choice.

Rule #2: finishing one project could cancel other. Choose wisely

Completing one strategic initiative can render other projects irrelevant or unnecessary. Evaluate potential overlaps and choose projects to maximize impact - don’t invest in projects that won’t matter.

Rule #3: momentum is everything

Build upon previous wins. Small successfully completed projects add up, demonstrating progress.

Rule #4: change is easier to accept when doing nothing is too painful

Sounds like a life advice quote, but what I mean is - finding the worst gremlin projects to build up the team morale is the best way to balance change resistance.

Tools and materials

You really don’t need anything special.

Do not overcomplicate things. Excel is fine. Notion is fine. Whatever you have already is fine. Project management software is fine - if you already know how to use it.

Strategy is not made by fancy software tools.

Putting it all together

Let’s go over the whole process for successful strategic planning.

Gather input - an interview tour

You need a good pulse of the whole organization. Talk to people on all levels, not just department heads and managers. The problem discovery is not a problem - people in the organization already know the challenges. The issue is doing something about them.

Sort into buckets

‘Must have’, ‘should have’, ’nice to have’ buckets help to prioritize your strategic map.

What to include?

‘Must haves’ must be included - look at the timeline and completion estimate to evaluate which strategic cycle should include the item.

‘Should haves’ - sort by ROI and pick the most impactful with the highest probability of completion. Also select at least one innovation or R&D item per planning cycle.

If you still have room, include one or two ’nice to have’, focusing on quick wins that boost morale.

Assign priorities

Most strategic plans are not executed at 100%. Assigning priorities is easy with bucket categorization, but pay attention to sorting within the bucket.

Paying attention to resources and assigning probability helps with prioritization.

Picking a time frame

Shorter the horizon, less items you can realistically include but better odds that no major outside changes will derail your planning.

With tech planning I would not go beyond two years. Technology changes fast and longer horizon creates more work as you’ll need to review and adjust the plan frequently.

Model the outcome

It’s often a missed step in strategic planning.

Take some time to envision what would happen if everything on your plan is completed. Where would that place your organization?

What if something is not completed or if everything is a failure?

These mental exercises are excellent gut checks for the items in your plan.

If you ask yourself “what if half of these fail?” and your response is a mental shrug, the items included are not important enough.

If you don’t feel joy imagining entire plan succeeding, there are too many ‘must have’ items. Go back to the drawing board and make plan more exciting and impactful.

Commit

After modeling the outcome, commit to the plan for the decided duration. Nothing kills the team morale faster then constant priority switch.

And if you find yourself switching priorities often, determine why and address the root cause.

For example, if the changes driven by the business shifts, consider shortening the strategic time horizon.

Explain the vision

Your team needs to understand the ‘why’ behind the plan.

Communicate and overcommunicate. Explain every concept and acronym. When people have excessive information, they don’t guess, fret or disconnect.

Expect heated discussions and arguments - that’s a good sign as it shows involved audience. Address skepticism early, acknowledge past failures and express believe that new approach will succeed.

Rally the troups

Explaining the plan is only part of the battle. Build up excitement for your team to see the vision come to life. Celebrate the small wins along the way.

Publish the map and review

I guarantee that after you finished explaining the plan, half of your team will forget everything you said within one week.

Publish the plan somewhere easily accessible. Provide updates - not just to the board of directors, but to the team. Keep building excitement and celebrate the milestones.

Borrow from Agile - use retrospectives

Agile methodologies are common for software development - steal the idea of retrospectives for strategic planning.

At the end of the cycle run a retrospective. Was the plan good? Was it realistic? Were the items picked correct and important? What would you do differently if you knew what you know now?

Evaluating the planning session helps you to become better at strategic planning.

How do you know if strategic planning was a success?

Nobody has time to sit in meetings to create a plan that will linger in a document pile. Tracking the reduction of warning signs is a sure way to determine if your planning is succeeding.

Beyond that, use other metrics to measure your impact:

• Reduced unplanned firefighting and work - measure planned vs unplanned work ratio
• Increased team retention and satisfaction
• Budget predictability - did you go over, under, as planned?
• Reaching strategic goals - measure the business impact of your ‘should haves’. Do they have expected ROI?
• Stakeholder feedback - collect feedback from the team on the clarity and effectiveness of strategic roadmap