Creating Effective Technology Strategy

Technology strategy is one of those elusive, esoteric topics that we work in or are involved in daily, and yet it might seem difficult to formulate one. This is part-1 of 2 part series focused on a practioner's guide to "How to strategize". Part-2 would go deep dive into the "What to strategize" of technology strategy.

Problem: For our example i am choosing a fictional Digital product organisation that serves its customers in the SaaS business. As a CTO you you're entrusted with finding the next product line while migrating its legacy operations and systems
Your Job: Fix the technical organisation and propel the product into next phase of growth.

1) Defining the right problem

If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions. Albert Einstein.

Don't assume you have been given the right problem: This is often the most critical and overlooked step in creating a technology strategy. I often step into meetings focused on resolving complex tech systems and processes and I'd invariably encounter the initial argument to jump on microservices implementation or ask for a multi-million, multi-year system re-writes. When the actual problem might be deeply rooted in a product decision taken years ago that doesn't apply in the current context.

Your actions: As a CTO you would need to take a wider view of the organization. Atleast initially it can be difficult to pin-point to the underlying issues at hand, which can range from talent, leadership, communication issues to architechure and product/market fit. You spend next 30 days on getting perspectives from all levels of organisation.

2) Embracing diverse perspectives (Go wide)

I often encourage to have orthogonal views on a topic coming from a diverse audience. Not only does it force you to think outside of the box, but it also raises the critical thinking of the whole group. Go Wide: While seeking perspectives.

Did you end up with too many choices to choose from? Try affinity mapping or money-spending exercises

Your actions: As a CTO you would need to take a wide view of the organization. Get diverse perspectives from Marketing, sales, customer service, customers. Its not uncommon to end-up with 100's of feeback items from your network.

3) Solutioning and Trade-off analysis (Go narrow: Less is more here)

This is often the stage of the activity where crowd-sourcing and a democratic approach don't always succeed. Go narrow: Include your critical folks who can represent many. Speed is key here.

Trade-offs: Diverse groups can weigh in on different trade-offs. For example, Marketing departments might prioritize speed and experimentation while engineering might prioritize scalability and architecture. A shared dictionary of non-negotiables is often helpful here, which can range from data security to high-quality end-user experience as a common denominator for all groups.

Depending on the complexity and abundance of options, you may opt-in for conducting brief proof of concepts or assembling key practitioners to evaluate trade-offs among the myriad of choices available. If the group ended up choosing all problems to solve at once, you probably don't need a strategy session but rather a planning to sequence your actions.

Your actions: There is new product launch for small market due in 3-months. While sales number and quality are projected to go down if not attended to immediately. Which one do you choose ? Are there clever alternates to both ? What are the trade-offs ?

4) Know thyself

Culture eats strategy for breakfast. Peter Drucker

Key questions to ask in this phase:

Do I understand my team's capabilities? Do I understand my Organisational culture? Is there a mandate, willingness, and maturity to solve the issue?

Your actions: Now you beleive that the group is very close to formulating the technical strategy which was created by support from cross-departments. Would marketing, sales department still support the strategy if plan goes south? Do you cross-departments have skin in the game and not just a superficial approvals ?

5) Anticipating and looking ahead

Formulating a strategy can stem from an organization's internal aspirations, external pressures, or responses to threats. Leaders must grasp both the internal dynamics and external challenges to effectively prioritize and present choices. Considering the strategy's timeframe—whether short or long-term—requires anticipation not only of your own future steps but also those of your competitors and the evolving marketplace.

6) Action plan

This is part where the organization collectively agrees (disagrees and commit) to the initiatives and tasks it will own. This is where your operational tools like OKR's, product plans and RACI can be used for a smooth execution.

Your actions: As a CTO you can further optimize the plan by squeezing the action plan timeline from 24 months to 9 months. This will invariably surface the most critical and actionable items the organisation can do.

Note: Not only its important to outline what the organization is willing to undertake, but equally crucial to specify what it won’t pursue at present. If the group wants to execute all of the selected problems at once, chances are you might need to re-run the exercise#6.

Execution is everything, planning is nothing. Anonymous

More than 70% of organization strategies fail.

What if 6 months into your execution plan your executive board draws out a plan to launch a new product offering. ? Do you abandon your plans or go back to board to ask for more funds or time ?

Execution is as important as the strategy itself. The brilliance lies in understanding how to break down the execution cycles into a concise and efficient feedback loop. Flavors of Agile framework are perfect candidates for these.

Final thoughts:

• What not to do: Items and initiatives slated for later time should be the second most important deliverable from these exercises. If the group chooses to solve all problems at once or doesn't identify a critical path, chances are you don't need a strategy exercise rather simple planning should be suffice.
• Trivial problems: Not all transformations require a formal strategy. Most of the trivial problems can directly go into the planning and execution phase.
• Enterprise architecture is usually the backbone for any transformations. When executed in isolation seldom results in the intended outcome.
• Tools before problem: OKRs, goals, product-plan are not strategies but simply tools to get your destination. Using them as a strategy would lead you off-path.