Creating an integrated business and technology strategy

Rethinking the Starting Point for Technology Strategy

The standard recipe for a technology strategy is deceptively simple: document the current state, define the future state, and build a roadmap between the two. In practice, that approach tends to produce a wish list rather than a strategy. Everything that could be done ends up in scope, and the result is often disconnected from what the business actually needs — largely because the technology plan is drafted only after the business strategy has already been locked in.

There’s a better way to think about this. When a doctor builds a health plan, they don’t start with a full-body scan and a list of every symptom to fix. They start with your health objectives, then check whether your body can actually support those goals — and if not, they put a remediation plan in place. Technology strategy deserves the same treatment. Instead of beginning with an inventory of systems, begin with the organisation’s objectives and outcomes. As the business explores different strategic directions, run focused investigations into whether your current technology environment can support them. The results of those investigations reveal feasibility issues and enable you to build a remediation plan grounded in evidence.

Working this way also creates a two-way street: technology is not just a constraint on business strategy but an enabler that can inform new revenue streams. When both strategies are developed together, the technology strategy is integrated with the business strategy by construction.

Eleven Strategic Directions

Most strategic initiatives share common patterns. From those patterns, we have identified eleven prevalent strategic directions that organisations pursue, grouped into four broad categories.

For each direction, we outline the key business questions it raises, along with the lines of inquiry that guide the technology investigation. Many activities support multiple lines of inquiry, so you can often consolidate effort: instead of running separate investigations for each question, one well-designed activity can answer several at once.

How to Work Through a Strategic Direction

Each strategic direction follows the same format, giving you a clear route from business intent to technology implications:

Direction

A statement of the technology implications of this strategic direction.

Key Business Questions

• Questions to pose to the business so your subsequent decisions are well-informed.

Lines of Inquiry

Each named line of inquiry describes the investigation to run, and opens to reveal:

• Questions about the topic: prompts that guide the investigation
• What to look for: signals and conditions worth noting
• Activities: practical steps that help answer the questions

Pick the line of inquiry that matches the strategic direction under consideration, and use the sample questions as a springboard. That is the shortest path to a technology strategy that reflects — and shapes — the business plan, instead of reacting to it.

Pursuing growth through technology alignment

Business growth generally follows three paths: selling complementary products to existing customers, entering new markets or regions, and attracting new customer segments. Most organizations pursue one or two of these at a time while maintaining their existing business. Growth is often organic, but can be accelerated through mergers, acquisitions, joint ventures or other strategic alliances.

Each growth path places distinct demands on the technology estate. Asking the right questions before committing to a strategy can reveal where the engineering effort will land and whether the current architecture can absorb it.

Adding Complementary Products

Introducing new products alongside your existing offering can ripple through the entire system stack. The buying experience, payment and invoicing, distribution, warehouse management and reporting may all require adjustment. The magnitude of the change depends on how the new product differs from the existing suite.

Key Business Questions

• How different are the product types and will business processes need to change?
• Which business capabilities can be shared across products — for example, payments, distribution or inventory?
• Which capabilities are undifferentiated yet still require significant changes, and are there packaged products on the market that already meet those needs?
• Do you need a single customer view across products?
• What is the opportunity cost to the existing product? Will investment across products degrade the experience of the original offering?

Technical Lines of Inquiry

How product categories are represented in the code base heavily influences how easy it is to add new ones or adjust categories as products evolve. Look for assumptions baked into other systems about product line information. Product codes might be hard-coded, some systems may assume only certain kinds of products exist, and changes may be needed throughout the stack — from UI navigation to domain model entries and database table structures.

Expanding into a complementary area can also expose process mismatches. If the blast radius of change is wide, assess how easy it is to make large, coordinated modifications through the system. Shared-service backend systems such as payment, invoicing, distribution and reporting are common points of friction.

Identify which capabilities should be shared across products and what special treatment each requires. Sharing capabilities lets you focus on the differentiators of the new product and speeds time to market. However, mandating shared capabilities where processes genuinely diverge can create needless complication and technical debt. For capabilities that don't contribute to differentiation, evaluate packaged software — installed or SaaS — as a safer buy decision.

Entering New Markets or Regions

Geographic expansion brings the challenge of running a global platform that accommodates regional differences in integrations, buyer personas and processes. Some capabilities suit a single global platform; others need room for local variation.

Regulatory requirements like GDPR, data sovereignty rules and compliance frameworks such as SOX and APRA affect where data is processed and stored, and may introduce new features for compliance handling.

Key Business Questions

• How do customers differ between markets?
• What regulatory compliance requirements apply in the new market?
• Do language, unit formats or time zone conversions need to change? Are there cultural differences that affect the UI?
• Are new tax calculations or additional reporting requirements needed?

Technical Lines of Inquiry

Map capabilities to determine which can be diversified or replicated per market versus which should be unified or coordinated through a central platform. Diversified and replicated capabilities can live with each market, while unified capabilities belong on a global platform.

Infrastructure repeatability is critical. If regulatory or performance reasons force you to host infrastructure in the new market, deployment must be repeatable. Organizations that set up separate teams to customize each region often end up with configuration drift and manual maintenance. This slows fixes and makes the cost of geographic scaling near-linear rather than efficient.

Commissioning a new data center in a new country can take considerable time. If there's no repeatable process and time pressure is real, consider a move to the cloud. Cloud infrastructure generally makes data sovereignty adherence easier, but database partitioning may be needed to stay compliant. Also review third-party systems: they can make you non-compliant by passing regulated information across borders.

Internationalisation touches more than language files. UI frameworks with built-in support for translation help, but retrofitting internationalisation is tedious. Content length varies across languages, so dynamic UI elements are needed. Time zones, daylight saving changes, tax calculations and units can each hide assumptions in the code that need isolating. If translation requires external agencies, the added wait time affects continuous delivery and feedback loops; plan the translation step into the design process.

Serving New Customer Segments

Selling your existing product to new customer segments ideally requires minimal system change. In practice, new segments often bring new operational processes, customer journeys or channel experiences. A bank extending credit cards to the sub-prime market, for example, introduces risk-heavy operational processes, regulatory obligations around responsible lending, different collections strategies and altered marketing. A move from B2C to B2B might require exposing an API channel; serving more mobile customers might demand a native app experience. New reporting requirements often follow, to capture sentiment, adoption and usage for the new segments.

Key Business Questions

• What differs between the current and new customer segments?
• What operational process changes are required?
• Is the move between B2C and B2B?
• What interaction expectations does the new segment have?

Technical Lines of Inquiry

If the customer journey differs, the front end must change. Hard-coded navigation, rigid front-end code and weak front-end test coverage make offering new experiences risky and slow. Untested JavaScript in particular increases the risk of regression, and front ends covered only by slow, flaky end-to-end tests stretch development time.

New channels may also be implicated. If you extend from web to native mobile, look at how the digital platform accommodates different front ends while integrating core business functionality. Microservice or micro front-end setups may need Backend For Frontend (BFF) mobile adapters.

Growing Through Acquisition

Mergers, acquisitions and alliances accelerate growth along those same axes but introduce their own line of investigation. As a technology leader, the integration effort benefits from clarity on intent.

Key Business Questions

• What were the value drivers for the acquisition, and how are they protected?
• Is the long-term view to merge the business in, or keep it separate?
• Are there divestment plans for the asset later?

Technical Lines of Inquiry

Independently run businesses. Where the acquired business continues to operate separately — perhaps as a first phase or ahead of a future sale — systems remain distinct but loose coupling through well-formed RESTful APIs enables the integration that genuinely matters, typically around finance. A business capability map is a fast way to show crossover at the business level before diving into APIs. APIs that behave as stable, secure facades over the business description are far more valuable than ones exposing internal mechanics. Partner ecosystem coordination grows costly when APIs change.

Tightly integrated, independently run. To amplify customer value across two businesses that still operate independently, the API strategy still applies, and you gain additional levers. Shared event streams and shared storage become possible. Domain models need alignment: the same concepts must look similar across systems, and connecting entities like customers requires data matching and replication decisions. Working this out at the model level makes later system integration simpler to configure.

Unified customer experience through single sign-on or dashboard views of the acquired company’s systems increases satisfaction and retention. Without it, customers bear the burden of operating across disjointed systems, and support teams lose transparent intelligence.

Complete merge. When acquired systems become first-class citizens in the existing ecosystem, expect rationalisation and consolidation. CRM, CMS and payment systems are common candidates. Data must be migrated, archived for compliance, or deleted. Run a security review before migration: runtimes and libraries may need updating. Architectures can often be consolidated by unifying libraries and frameworks to improve the developer experience.

Operational consolidation reduces cost and management overhead. Log formats, severity levels and frequency may need to change to ensure observability across the merged estate.

Why the engineering agenda must serve business goals

Engineering leaders are often fluent in the discipline of platform and developer improvements, but those improvements only deliver value when they map to what the business actually cares about. Four themes tend to resonate across the rest of the organisation, and each can be directly advanced by technical work: accelerating time to value, lifting product quality for happier customers, containing cost and operational risk, and enabling decisions from data.

These are not abstract goals. Each one gives the engineering roadmap a business-facing justification and exposes where technical debt and frictions are blocking growth.

Speed as a business engine

Accelerating time to value means shortening the journey from an initiative to measurable benefits. Three technical areas commonly throttle this: code that cannot be changed confidently, a poor developer experience, and a delivery process cluttered with waste.

Code quality. Well-structured code with appropriate test coverage is straightforward to extend. Teams move fast when they trust changes will not introduce hidden defects. Review code for size, complexity, coupling, and cohesion, and consider whether it mirrors the domain. Test strategy matters as much as coverage: examine where tests sit against the test pyramid, how long they take to run, and whether failures reveal real problems. High defect rates in production are a signal quality issues run deep.

Developer experience. The quality of a developer’s interaction with tools, systems, and the organisation shapes output. Self-service engineering platforms can streamline every stage of the software lifecycle. Where feedback loops are long and build times drag, delivery slows accordingly. Look for missing documentation, unclear onboarding paths, fragmented toolchains, and what a new hire has to learn before becoming productive. Cognitive strain—context switching and tangled abstractions—silently increases defect rates and delays.

Delivery process waste. Handoffs between groups, approval boards that gate releases, and rework all add time without adding value. Examine the friction in the workflow: how hard is it to find information, and how many separate systems must a developer navigate? Measuring lead and cycle times will help quantify bottlenecks.

Quality that reaches the customer

Product quality extends beyond whether code passes tests. Performance, design debt, and complexity all surface in the customer experience, often as support tickets. Addressing the riskiest parts of the system that teams dread touching is not just clean-up; it prepares those areas for the features they will need to support.

When reviewing defect patterns, use a heatmap of incident data to see where attention is deserved. Ask how well systems handle peak volumes; whether the current build copes with the stress of a Black Friday or equivalent is a reliable guide to scaling headroom. Analyse call-centre data to understand which complaints align to product gaps, but also examine drop-off in the funnel for a full sense of failure points. Technical debt surfacing slowly in the codebase—tight coupling and hotspots of frequent change—steals velocity from future feature work.

Cost control and shielding the business from risk

Operational risk is exposure to losses through failures of internal process and systems, or external events. In technology, three areas dominate the risk profile: unchecked cloud spend, weak data governance, and obsolete dependencies. The business expects its technology organisation to manage those three defensively.

Cloud cost discipline. Move to the cloud can erode financial visibility and control. Bills arriving at month’s end often come as a surprise to finance, while engineers make infrastructure choices without seeing the price tag. Tag infrastructure and run dashboards for cloud spend next to uptime and usage to bring financial control into the engineering loop. Aggregate data on what is actually consumed, not merely what was provisioned, and ask about orphaned systems still burning budget that could be switched off.

Data governance. Digital operations create data on everything, but data at scale is also a liability, and privacy failures undermine the trust the organisation relies on. Governance touches how data is collected, stored, used, and shared, and attempts to create an organisation-wide framework for managing that lifecycle. Scrutinise whether policy, control and ownership are consistent across departments.

End-of-life and supply chains. Any dependency on software whose vendor has stopped patching it exposes the company to security vulnerabilities, regulatory failures, and compatibility issues. Scan for EOL tools and frameworks, have a refresh path in mind and take the opportunity to migrate. Beyond software licenses, consider the wider digital supply chain. If a supplier with privileged access is compromised, how would the interruption be managed? Map supply chain vulnerabilities and maintain contingency plans for disruption.

Turning data into a tool for decision making

Data platforms rarely earn their investment in retrospective reporting. The real advantage arrives when the platform lets its people recognise what is happening and what to do about it, as a matter of working routine. Inferior approaches will stage decisions first and then hunt for figures to support them; proper data architecture gives teams access to high quality, live information to guide decisions.

Access speed matters. Business users need data in the format they need it, and quickly, without escalating requests up the chain. That means self-service data platforms underpinned by solid engineering for the data sets. Content matters too. A set of facts unconnected and atomised is of little analytical value, so make structured, curated views that meaningfully combine information from products, sales revenue, and customer feedback. With that singular view embedded in working practices, data begins to steer operational improvements and customer interactions—not merely to validate guesses after the outcome.

Culture, Talent, and the Systems That Support Them

Technology leaders have a dual mandate: not only do they drive business processes and data-driven innovation, but they are also responsible for the people who do the work. As the saying goes, digital transformation is less about technology and more about people. Technology can be bought, but the ability to thrive in a digital future hinges on developing the next generation of skills.

A well-defined digital talent strategy is a significant competitive advantage. It ensures the organization has the right people with the right competencies to meet current and future business demands and sustain digital transformation initiatives.

Culture as a Technical Concern

Though it may seem intangible, culture is a demonstrable factor in technical performance. Research from DevOps Research and Assessment (DORA) shows that a high-trust organizational culture that emphasizes information flow is a strong predictor of software delivery and organizational performance. These findings are supported by Google’s Project Aristotle research on what makes teams effective.

The DORA research is grounded in the work of sociologist Dr. Ron Westrum, who identified three characteristics of useful information: it answers the questions the receiver needs answered, it is timely, and it is presented in a way the receiver can use effectively. Westrum’s work shows that culture influences the flow of information. Crucially, culture is not changed by altering how people think first. As John Shook notes, you start by changing how people behave—what they do; the thinking follows.

Leadership is the key lever for shaping and embedding culture. Leaders set the tone, model values, and make hiring and promotion decisions that reinforce the desired cultural fit. Effective leaders are those with a clear vision who act with integrity and emotional intelligence. They are decisive, empowering, adaptable, and focus on results. They also build diverse and inclusive environments and prioritize mentorship. When assessing leadership and culture, employee surveys can reveal whether these traits are present and where gaps exist.

Knowledge sharing is another pillar of a healthy technical culture. Human knowledge often lives in the heads of key individuals who know where things are. A strategy must plan for replicating these people, breaking down information silos, and providing the right tools so information can flow to the right people at the right time. This requires evaluating whether teams are internally motivated to share and whether they are humble enough to learn from others. Look for incentives and recognition systems that encourage these behaviors. Systems must be easy to access, navigate, and contribute to.

Employer brand is the external and internal perception of what it is like to work for your organization. It is a function of the collective attributes, values, and culture you demonstrate. A strong employer brand builds trust and credibility, making it easier to attract and retain the right people. Monitoring retention data, analysing exit interviews, and tracking reviews on employer review websites can reveal recurring themes that inform your ability to hire in a complex, chaotic business environment.

Treating Internal Systems as Products

Technology leaders also own the internal and back office systems that employees use every day. These systems directly influence employee satisfaction and the pleasure someone takes in their job. However, many tools—CRMs, ERMs, timesheets—feel stuck in the 90s. For internal systems to serve their purpose, they need a frictionless experience.

The same discipline applied to customer-facing products must be applied internally. That means identifying which systems are critical to running the business, mapping what is lacking, and treating your colleagues as customers. Product thinking, customer research, and service management are as relevant for your intranet as for your website.

Streamlining Business Processes

Technology should streamline processes by identifying and eliminating unnecessary steps. When examining workflows, it is important to look for waste, queues, and friction. High numbers of in-progress work items waiting between steps are a sure sign of bottlenecks. Just as important is the number of digital or human interactions needed to complete a process; supporting too many communication channels creates confusion about which to use. Handoff points between stages typically generate friction. Value stream mapping and service blueprints help uncover that waste.

Geographic duplication is another efficiency trap. While some systems require country-specific differences due to regulation and culture, local business units often build or buy their own tools because they cannot wait for global prioritization. This results in supporting many near-identical systems with duplicated effort. Understanding where true differences exist and where they do not is the first step to a more sustainable portfolio.

Speed to access is a simple symptom of internal system health. If it takes too long to grant requests for software, tools, or access, you are wasting employee time that should be spent on value-add tasks. Value stream mapping and service blueprints can guide the necessary changes.

Measuring User Sentiment

To know whether internal systems are working, you must measure the employee's experience in the same way you would for external customers. Sources of sentiment data provide a leading indicator of tooling and process satisfaction.

• Chat sentiment: Pay attention to the number of questions, complaints, or negative comments in chat channels. Sentiment analysis tools, often used on customer feedback, can be applied to internal dialogue as an early warning system.
• Support ticket volume: A disproportionate number of support tickets for a specific system should prompt a review for enhancement or replacement.
• Shadow IT: Observe the percentage of people who find an external workaround instead of using the sanctioned internal option. When employees vote with their feet, it is time to assess whether the internal system is worth maintaining.
• System age: A portfolio dominated by legacy systems wears down sentiment and harms productivity. Old, tired systems should be evaluated not just for technical debt but as a factor in employee experience.

In short, the technology strategy for your organization must be as focused on the internal customer as it is on the external one. Treat your employees as customers of your internal products. Provide them with the modern tools they need to achieve their goals, and apply the same rigor to your back office as you do to your revenue-generating systems. The result is a culture that attracts talent and a workforce that executes without impediment.

Watching the Horizon: Technology Trends and External Pressures

A technology strategy cannot be built in a vacuum. It has to account for what is happening outside the organization: emerging technologies, the direction of the market, and broader shifts in the economic, social, and political environment. Keeping a close watch on these areas helps an organization identify new opportunities and potential threats before they become urgent.

The strategic review should involve a survey of these external factors to understand how they may affect the organization, its customers, or its employees. Key business questions to guide this survey include:

• What role do emerging technologies play in our industry or within our company?
• What are the main trends that will affect our industry in the near term?
• Which competitors are rising in market share and prominence, and how do they differentiate from us?
• What is happening in the social, economic, and political environment we live in?

Emerging Technologies

Emerging technologies have the potential to reshape industries and disrupt established business models. Being aware of what is emerging matters because it lets you decide what to watch, what to understand better, and what to experiment with and trial. The goal is not to chase novelty. New and shiny technologies should not be chosen for technology's sake—there should be clear value creation for either customers or employees.

One expression of that discipline is the concept of innovation tokens. The idea is simple: You get three innovation tokens. Every time you innovate by doing something other than what is standard, you spend one. Once you have spent them all, you are out and don't get to innovate anymore. That constraint forces a focus on which innovations genuinely matter.

Several publications can inform a technology leader about current and emerging technologies, including the Thoughtworks Looking Glass report and Technology Radar, alongside analyst reports like Gartner and Forrester. Organisation-wide technology radar exercises and reviews of analyst reports are useful activities in this area.

Market Trend Analysis

Market trend analysis is the process of studying changes and patterns in a specific market over time. It involves collecting and analyzing data from various sources to identify trends and shifts in consumer behavior, technological advancements, economic conditions, and competitor activities. Segmenting the market and forecasting future trends enables businesses to make strategic decisions, adapt to changing market dynamics, and take advantage of emerging opportunities.

When doing this analysis, it is important to use reliable data sources and historical data, focusing on relevant metrics aligned with business objectives. Make comparative analyses with industry benchmarks and competitors, seek input from industry experts, and validate assumptions. Activities that support this work include PESTLE analysis, SWOT analysis, STEEP Analysis, Five Forces Analysis, Scenario Planning, and Porter's Diamond Model.

Broader Economic, Social and Political Changes

Beyond the immediate market and technology landscape, the strategy should factor in broader shifts that impact society at large. These range from technological advancements like automation and digitization to demographic changes such as urbanization and aging populations. Growing awareness of climate change and income inequality, the effects of globalization and political instability, public health crises, and evolving social norms all contribute to the complex environment in which the organization operates.

Useful questions here are pointed and practical:

• How does increased attention on carbon emissions affect the business—and how does technology react to that?
• What if more trade barriers go up?
• What's the impact of an aging population?

Considering these broader issues allows an organization to adapt quickly to rapidly developing situations. A technology strategy for a client in the travel industry provides a good example. Using travel insight data and customer research to explore how travel patterns changed after Covid-19 lockdowns, it became clear that ease of canceling and rebooking had become an important factor. The resulting technology strategy included a focus on improving capabilities for cancellations, notifications, and back office integrations. The strategy also identified where machine learning could help predict the likelihood of cancellations, which led to the introduction of ML and data engineering to help customers return to travel while reducing the load on customer support teams. That is a useful case of shiny technology solving an actual problem, not being adopted for its own sake.