Strategy First

With the new year looming, I've been thinking about technical strategy. What does it mean for an organization to have a technical strategy? How is technical strategy related to business strategy?

As I've worked through this I've come to the following definition:

Technical strategy is the set of principles that drive the direction of technical decisions. These principles need to be deeply informed by business objectives.

Technical strategy is not about technology choices. It is about the principles that guide your decisions and give your business a strategic advantage in the marketplace and it is imperative that these principles are guided by business strategy.

Another way of putting this is:

Strategy first. Technology follows.

With strategy first we understand the why behind our decisions. Understanding "why" and aligning on "why" makes technical decisions succeed.

Too often, organizations pick technical solutions because they think they'll solve a problem but haven't understood the direction that technology is taking them. Developers implement the technology because "they were told it was the thing to do" but they don't know why it is the right thing or even if it is the right thing for their use-case.

Time is a flat circle, and technologies come and go and come again. Defining technical direction without principles is a Sisyphean task of decomposing, recomposing and decomposing monoliths over and over again.

Strategy needs to start with principles because we need to know why we are taking the actions we are. And these principles will only succeed if they are aligned with the rest of the business.

Lets look at a practical example.

Lets say you are on the technology leadership team of a startup. You know you have a bit of technical debt and some relics of past experiments, but overall, you have an app that works for clients and is making money for the business.

You might be tempted to say, "Hey! lets clean things up and make them fast! We're profitable after all." But then business leaders come to you and say, "We want to drive customer acquisition in the next year. Can our app handle 5 x the number of users?"

You are in the business of making customers happy and making your app easy to use, so what you need now is a technical strategy that can support this goal.

From an engineering perspective, there are two common ways of answering this question:

1. Yes, we'll just throw money at it and scale our services.
2. Yes, we just need six months and two new teams so that we can implement <insert hot new technology here>.

The second answer is obviously an exaggeration, but I hear something like it all too often. GraphQL will make things better! Microservices are our future! But...why? Why that technology or design?

The first answer is actually not a bad decision if you use this time to understand how your system performs so that you can eventually spend less money on it to support the same number of customers. But without a guiding strategy, you might just end up spending more money and burning out your developers who are supporting your systems.

A better answer is to ask, "What are the core principles we need to guide our decisions so we can support 5x the users?"

Now, I don't know your system in this hypothetical startup, but I can suggest some principles that might help scaling your system.

We build systems for our customers first.

This principle centres the customer in your technology decisions. I hate to say it, but your customers don't care if your code looks bad. The only care if it works well for them. With this principle in mind we can focus our technical decisions on building things that delight the customer.

This principle intentionally introduces a challenge. What about parts of our system that are hard to deal with but customers don't see them? Often, the immediate effect on a customer isn't apparent. But poorly designed systems can impact the customer's perception of your app. That's where the second principle comes in.

We build systems that are resilient and responsive.

Resilient and responsive are two very intentional words here. A resilient system is not one that never fails, but one that recovers--bounces back--when it fails. A responsive system scales well and feels intuitive to the customer.

With this principle in mind, we can look at our end to end performance and focus in on problem areas that affect the resiliency and responsiveness of the system all while keeping the customer's experience in mind.

From here, we can start to make technical decisions. Perhaps a team member wants to introduce GraphQL to your architecture. You can now measure that against the principles and decide if GraphQL takes you in the direction the business needs to go.

Choosing GraphQL, for example, might enable improved resiliency if you have the expertise to build a schema that is resilient to failure cases. However, this choice needs to be aligned with business goals. Does replacing REST with GraphQL inherently let you scale as the business leaders said?

I'll leave that up to you in this theoretical startup. Once you have the right principles behind your technical strategy, you can empower teams to confidently make technical decisions that support the business.