Building a strategy is always an involved process. This past fall, we took it upon ourselves to build a technology strategy for Futurice leading up to the year 2022. By structuring the work in a smart way, we were able to make it fairly easy on ourselves and complete it in less than three months. In addition to an actionable tech strategy, the process also yielded a ton of important lessons.

The primary focus of our strategy work was on the business landscape in Finland, but naturally many of the themes and trends around it are global. The main reason for building the strategy was to create clarity and focus, both for our people within the technology domain and others around it, like sales and HR, or HC as we like to call it – short for Human Care.

Additionally, with a technology strategy in place, we are better equipped to take a stand on what we want to do and what we don’t. It also gives us a handy tool to help guide our focus and efforts in the long term, and conversely, it will also be an instrument we can check retrospectively and see which bets we got right and which ones we didn’t. Having those insightful "Hey, we nailed that one" and "Yeah, didn't see that coming" moments.

In order for our tech strategy to do its job properly, we needed it to be an inspiring read for our technologists and touch their daily life at work. On the other hand, it would also have to be easy for our business people and other stakeholders to utilize in their work. Not exactly an easy task.

Our desired level of detail was set to be tangible enough to apply to everyday work, but not get all the way down to the nitty-gritty. We can expect to see lots of changes in tech over the next two years, so there’s little use trying to make guesses on an unnecessarily detailed level.

When creating our strategy, we wanted to get as much information from our tech community as possible. It was clear from the get-go that the strategy would be the culmination of our technological knowledge gathered from the community, and not just a handful of key people. All told, the process spanned little more than two calendar months and unfolded over the course of about 10 workshops of various sizes.

From the high level to the day-to-day

The strategy was designed to work on all levels from the bird’s-eye view all the way to more specific grassroots items with the level of technical details increasing when moving from the higher-level items to more detailed issues, like the use of TypeScript in frontend development. The transition from "fluffier" themes towards the hardcore technology landscape felt natural and gave our strategy more structure.

Figure 1: A gradual transition from high level items to technical details

First, we needed to align our technology strategy with our wider, company level strategy. We did this by binding our company level items to technological items on the country level to create a natural progression. At the same time, this also helped outline what kind of projects we take on, and with what kinds of teams. And so, the basis for the rest of our technology strategy was set.

Next up, we created a country level vision for our technology business. One can always argue whether this is necessary, but we felt that there was a need for a simple and concise statement that encapsulates what we stand for:

Inspire our clients to use technology in creative ways to solve complex problems for their customers, employees and society at large.

And building on the above statement, we also defined a set of principles that we see as overarching guidelines of how we want to run our technology practice. This step takes us closer towards concrete things. The roughly dozen items on that list contain statements like:

Our technology choices are guided by feasibility, maintainability, and business rationale. We enable people to evolve within the tech domain and outside of it.

Many of these are things that go without saying, but putting them in writing makes them more effective and something we can use for guidance when making decisions in the future.

Naturally, a strategy also requires us to have goals. These goals are something we should be able to reach with the right actions. They describe our desired state in market position, people development, partnerships and the kinds of projects we do. Since these are long-term items, they require incremental progression to reach them. This progression happens through concrete actions within all of our specialty areas – hence the next and most concrete part of the strategy, specialty areas.

Figure 2: Inputs to the strategy, its alignment outside the tech domain, and use after the process

Specialty areas

The various areas we cover technology-wise is massive, and basically extends from mobile to cloud infrastructure, and everything in-between. To make the work more manageable we ended up splitting it into these specialties:

• Web development (frontend and backend)
• Mobile development
• Data science and data engineering
• Cloud and architecture
• Technology in the business context
• Agile delivery
• Partnerships
• Tech community

Naturally, there is lots of overlap between all of these – for example, consider Firebase, which can land either on Cloud, Web development or Mobile development. When such issues came up, we simply made an educated judgement call. For the end result, it didn't really matter which side of the fence the items were on.

In that list of specialties, two areas – Partnerships and Tech community – stand out as slightly different from the rest, but both nonetheless involve analysis of our current state and include focus points for the next two years.

Each specialty needed to reflect on three main points:

What are we good at now and where do we have room for improvement?
What trends affect us globally and through our clients?
What should we focus on for the next two years?
Again, we wanted these topics to give us a nice flow. The first step would be to look at where we are now with a CSA-type of approach. We did this by analyzing our data on what kind of skills our people have and what we've been using in our projects. This gave us a good picture on where we are and where the market is at regarding the specialties. This yielded us insights like:

In front-end development, we have 195 people skilled with React and the most common choice in our projects is React with TypeScript. In web development, we are experts at building complex, high-performing and scalable web applications like the Sanoma News Platform.

We then started researching global trends, our clients’ future needs and our own views on where the world would be going. The goal here was to create a clear and focused outlook from the point of view of technology-enabled business. Naturally we tried not to embrace the whole world and instead stay focused on technology in our context. On the other hand, this also meant technology in almost all business verticals – which is not exactly a small focus... This gave us outputs like:

While in most cases APIs serve a specific purpose and it may not be necessary or even desirable to centralize everything, there is a clear trend towards a more structured API development strategy.

After compiling these two parts it was finally time to make choices on where to focus based on the background work done so far. This part also included choosing where not to focus.

The growing need from our clients to move their on-premises monoliths to serverless cloud environments also requires us to keep building our capabilities in that area.

The final result was a package that described what to do next as well as the background behind that decision.

How we organized the process

The building blocks that eventually made up the core insights within each specialty area, as well as the underlying trends, were generated by assigning people the responsibility to facilitate the process under each specialty area, and gather information from our technology community and other sources.

In practice, this meant looking into lots of data sources and workshopping with the relevant people. In the end, the results were distilled into a more condensed format, while all the material that went into them and was created during the process, like slides, documents, Miro boards etc. were of course stored for future reference. Once all the specialties were packaged, it was a question of doing a once-over and checking that everything was aligned, logical and made sense business-wise.

Figure 3: Involving people outside the core team benefits the knowledge gathering phase

Our approach was highly participatory, and it involved dozens and dozens of contributors from across the company. A big part of why we did it this way was to be inclusive throughout the process. Managing contributions from a large number of participants always runs the risk of devolving into a sprawling mess, but we were able to avoid this by introducing precisely the right amount of structure – not too rigid, but chaotic either.

Looking back, I feel that this was by far the leanest strategy process I have ever been involved with, but at the same time, we ended up with a very clear and usable document going forward. It will also be an important input for planning our future activities around recruitment, training and business.

What's next

In its plainest version, a strategy is just a document in a cloud folder. That is why the road that took us there was already important in and of itself, having involved multitude of technologists and business people. Right now, we are in the process of planning the actions based on the strategy, and agreeing on them with all the stakeholders within the company. To ensure the planned actions are executed, they will be a part of our quarterly OKRs on the country and/or team level.

To remain agile, we will have strategy reviews every six months. The changes in technology never stop, so we need to assess what we have been doing and adjust accordingly. Now that the strategy is already in place, adjustments are much easier to make.

As a byproduct of this work, we have spun off the Futurice Tech Trends 2021–2022 report from the strategy work, and made it into a standalone website and document that describe the driving technology trends affecting our business and that of our clients. Definitely an interesting read for anyone working in the technology industry.

Takeaways

• Start with the “why”. Make it super clear why you are doing the strategy, and keep that as your north star. Know your audience. Know who you are trying to reach, and speak their language.
• Involve technologists. Use your people to gain the best possible overall picture as well as their buy-in. A good technology strategy does not come from the heads of only a few senior experts. On the other hand – make sure to keep moving, lead the process, and avoid analysis paralysis.
• Don’t forget the business. Technology is never an island. Every tech decision needs a business rationale, and you will also need the business buy-in. Furthermore, business has unique knowledge on client needs and the overall market situation.
• Make it tangible. Company level strategies can be more high level and inspirational, but a tech strategy has to be something that people can relate to in their everyday work.
• Relentless actions. Align your actions with the strategy, and relentlessly drive them forward. Otherwise the strategy will amount to nothing more than just another document on your cloud drive.
• Establish follow-up. Schedule a review every six months and go through the strategy. What did we get right? What needs adjusting? After the foundation is there, fine tuning will be much easier.

If this raised any comments or questions, I'm happy to hear them in the comments section.

This post was originally published in the Futurice blog here --> Link