Working together on tech strategy

09 December 2022 / Leadership / Strategy

When working on tech strategy I like to involve as wide a group as possible. During the pandemic, with remote and hybrid working, this become more difficult. This post is about a way we found to define the 2022 tech strategy that worked well.

It’s important to involve a wide group in tech strategy

The ideal when working on tech strategy is to involve a wider group of senior and principal engineers as well as representatives from other disciplines, e.g. product and design. There are two main reasons for this.

The first is that input from the people doing the work leads to better decisions.

The second is that a big part of creating and implementing a strategy successfully is having a shared understanding of what you are are doing and why, and being involved in that process means we all understand that better.

I can share context about the business and what’s coming up organisationally, and the wider group know about the detail of the day to day work, technical challenges and opportunities.

The more people understand what we are trying to do and why and are involved in the creation of strategy, the better able people are to make independent decisions about the right thing to do.

Previously, we clarified the bigger picture through a card-laying exercise

In my previous post about setting a tech strategy I described the process we used on Customer Products at the FT (the team in charge of FT.com and the apps) to work out what highest leverage actions we should take to move us towards our vision of sustainable, supportable, simple tech.

One of the activities we did was a card-laying exercise, where we laid cards out on the floor and rearranged them to work out what the priorities were. That exercise gave us clear outline and a shared understanding of where we were heading for a few years.

Over the next two years, we had quarterly, shorter meetings, where we refreshed where we had got to and looked forward to what the next steps might be.

However, after a couple of years, we were getting to the point where we needed to have another card-laying exercise, with everyone involved, and we booked an Away Day for March 24th, 2020.

However, on March 23rd, 2020, the UK went into lockdown. The Away Day was cancelled, and we did not arrange another one. Partly because I could not work out how to do a card-laying exercise remotely, and partly because a full day remote meeting is a horrible thing to ask people to do.

During the pandemic we tried various different ways of working on the strategy

We couldn’t have the full day meeting we had planned, and in the first, very stressful, few months of the pandemic, it didn’t feel possible to think about how to plan ahead.

Once we were able to do so, we continued with our quarterly meetings, and tried different ways to prioritise remotely.

Discussion and voting

The quarterly meetings in the office had involved a discussion, proposing priorities on cards and then voting. The discussions, however, usually were two or more hours, and it is much harder to have a long and constructive meeting remotely.

We attempted to replicate this by populating a Trello board with cards ahead of time, then discussing in the meeting and voting using a Trello plug-in.

This had the advantage of being a shorter meeting, but we found that it was quite easy to sway the meeting; often the priorities ended up being something that one or two people could speak passionately about, rather than the things that actually had the highest leverage.

This was something that had also happened in the in-person meetings as well, but because there was more time for discussion when we had the meetings in-person, this effect was slightly mitigated.

In addition, it was harder to get everyone to participate in these remote meetings than it had been in person; body language, moving around the room, the ability to have quiet side conversations were all missing.

Deciding within a smaller group

Because we still felt we were unable to prioritise bigger, more impactful pieces of work we also had some smaller discussions with just myself and the principal engineers to identify priorities. I’ve written that up here.

The advantage of this was we were able to make some big decisions because it’s easier to discuss in a smaller group, but the big disadvantage was that we didn’t involve the wider group, so we missed out on their input and they missed out on the context.

Focusing on specific activities

Alice Bartlett led two remote tech strategy meetings with the wider group focusing on specific activities. In one, smaller groups worked on assessing our capabilities and identifying our pain points, and in the other the team worked on drawing our software architecture using the C4 model.

These were really useful for context-sharing, surfacing issues and getting agreement, but they were less useful for setting the clear priorities and next steps, or clarifying the overarching most important themes.

We were able to move forward with the strategy, and do some great work, but we still felt we were missing out on the bigger picture, shared with the larger group.

Changing the process for 2022

At the beginning of 2022 we decided to try a new process. I had initially been looking to get a professionally facilitated remote workshop and have a full day event, but as I started preparing what we would need to share ahead of that workshop, it occurred to me that we could learn from what had worked and what hadn’t.

One thing we know is that meetings are not the best way to get input from everyone. Some people don’t feel comfortable speaking up in group meetings, and some people need time to think things through and don’t have their best ideas in the meeting, but hours, or days later while reflecting.

So for 2022 we did it completely differently.

First, we had a meeting purely to share the context

This time, our quarterly tech strategy meeting was explicitly and purely for context sharing. We invited guest speakers and the purpose of the meeting was to share context of the various strategies that affect our work, discuss and ask questions.

For example, Debbie McMahon, Product Director for FT.com and apps, talked about the subscriptions strategy and the FT.com & apps product strategy. We also talked about the wider tech strategy, across all groups, and any relevant OKRs. We then talked about our plan for working on the Customer Products tech strategy in 2022

We then shared a document with possible areas of focus

I and the Principal Engineers put together a document outlining our prioritisation framework, and then a list of all the areas of focus that we thought might be worth prioritising. The document was 8 pages long with about 12 possible areas we could focus on and some bullet point details about why each was important and the impact it could have.

We shared the document with the wider group: senior engineers, tech leads, principal engineers, product managers, delivery managers, designers and user researchers.

We asked for comments, corrections, and to add additional things we should cover, and their thoughts on priority.

Interestingly, one early comment we got was on our prioritisation framework. Initially this was:

1. Supports FT.com & apps product strategy for 2022
2. Something we should invest in now to put us in a good place in 3-5 years (This is No next Next, our Customer Products tech strategy)
3. Something that supports and/or shapes the overall FT tech strategy

But Tatiana Stantonian made the excellent observation that this ordering very strongly implies that the top priority has to be feature delivery for 2022. But part of the purpose of even having a tech strategy is to make sure that we are prioritising the investments we need to make to be in a good situation in the future.

So we swapped the ordering of 2 and 1.

We then had six smaller meetings

After people had some time to digest and comment on the document, each Principal Engineer (of whom there were six at the time) set up a meeting with the tech leads, senior engineers, product managers and other interested parties for each of the teams they oversee.

In that meeting, we talked through the document and got feedback.

The advantages of the smaller meeting was it was easier for people to contribute, and everyone did; there wasn’t anyone in any of the meetings who didn’t say anything. And because people had had time to digest the document, they were able to give good input in the discussion.

There were two main disadvantages to this approach. Firstly, because the process was a document, then six meetings, it took longer overall to get to done than an Away Day would have; however, the content was better because people do not always have their best ideas on the day.

The other disadvantage was that because we split it into six discussions, the only person who had the context of the whole lot was me, as I was in every conversation. We mitigated that by the principal engineer making notes on each meeting which we shared with everyone, so people could at least see what was discussed in the other groups.

Finally, after we’d broken out into the six meetings, we pulled it all back together, outlined what our top two priorities were, and shared it at an all staff meeting as well as in the document.

The feedback on the new process was positive

There was generally positive feedback on this approach. 50% of those who attended returned the feedback form and all of them answered yes to the questions “did you find the meeting useful?”, “did you find the meeting interesting?”, “did you feel you were heard in this meeting?”. To the question “Do you feel you have a good idea of the Customer Products tech strategy?” 80% answered yes, with the other 20% answering “partly”.

There was also a lot of useful comment and suggestions for improvement, mainly around making it more focused in the conversation (perhaps with homework beforehand) but also how to make sure we shared the context across the groups – the notes were useful, but some people wished they’d been able to join multiple discussions. One point made was that the document possibly made it feel too concrete; less of a discussion, more of a plan.

There were also useful comments on what people would like from the Customer Products tech strategy, mainly around clarity on what it meant for each person and team. This comment was a representative and insightful one: it should offer “clarity on what we should prioritise (and therefore what to push back on). A feeling of moving forward and not only clearing up previous mess.”

The results over the year were also positive!

The big advantage of doing it this way meant that we had clear priorities for the whole year, and that meant we were able to invest in the areas we’d prioritised. For example, we identified as our top priority rationalising our content APIs and we were able to build a team and give them six months to work on it, i.e. properly invest in things that put us in a good place for future.

We identified two top priorities, and we also identified that one of the things we had deprioritised was very important but we did not have the right capacity to work on it. This meant that when an opportunity emerged to focus on that, it was an easy decision to change the order, deprioritise the second thing we’d agreed to work on and and focus instead on the top ‘unprioritised’ piece of work.

There were also advantages to having listed out and discussed all the areas of focus. With that shared context, when opportunities came up to move forward on some of these, teams knew that it was valuable. So even pieces of work that had not been deemed top priority were able to progress. For example, the reliability team did a huge amount of work on operational excellence.

This process meant it was much easier to get product involvement, which is really important for a successful and useful tech strategy. We were also able to share this outside of the Customer Products team which helped others understand our tech strategy in more detail than usual. Not everyone likes to read long documents, but it was useful for those who do.

One thing that it missed out was creating the forum for ideas generation. People did add suggestions to the document of things we might consider, but they were usually ones they’d already been thinking of. One advantage of a big group discussion is, if done right, it can really create the environment to spark new ideas and thinking. It would be good to incorporate something there in future.

We will probably do a similar process next year

On balance, this worked very well, so we will definitely use parts of this process next year, though next year we will have more inputs to draw in, and we are very close to having a tech strategy for the whole of the FT not just the separate groups. I’m really excited to see what we do next!