The difficult teenage years: Setting tech strategy after a launch

By Anna Shipman

When you are launching a new product to replace an existing one, it’s easy to rally behind the mission and make the right technical decisions that will get you over the line. But after the launch, it’s very common for things to lose focus: the vision is no longer so clear, corners you cut to get the product live come back to bite, and the tech can start to feel like it’s drifting off track.

This is the difficult teenage years.

Setting a strategy to get back on track

When I joined the FT in 2018 I found an excellent, smart and motivated team, good tech and a great culture. However, some things were drifting off track. This post is about how we created our tech strategy for getting out of the difficult teenage years, and how you could too.

Strategy is diagnosis, vision and a plan

  1. Diagnosis: What’s the current situation?
  2. Vision: What is your desired end state? Where are you trying to get to? What does ‘good’ look like?
  3. The plan to get there: What are the highest impact steps you can take to get to your desired end state?

The vision for the launch of “Next”

Initially, a small team worked on a prototype of a new website, which they called “Next”. Next has a microservices architecture and is built in Node.js. The Next team focused on building a fast, responsive site, with an emphasis on shipping and measurement. Users were given the opportunity to opt in to the Beta, and 5% did, allowing the team to develop the site in the open with real users.

In October 2016 it was rolled out to all users, and “Next” became the current site.

Diagnosis: The difficult teenage years

However, there were some cracks starting to appear. Some of the types of comments I heard were:

  • Engineers weren’t sure of the value of the work
  • There were areas of code people didn’t want to touch
  • There was duplication of code
  • A couple of services required deploying microservices in a certain order to make a change (which contradicts the point of microservices, as independently deployable units)
  • Feature changes felt too bitty
  • Some of the people who set technical direction had moved to other projects
  • Someone said, and this was echoed by different people in similar ways, “It doesn’t feel like we are owning or guiding a system, we are just jamming bits in”.
  • Finally, something I heard from different teams and different disciplines, a red flag that indicates a lack of focus: “We need more developers”.

These kinds of comments show the main themes of the difficult teenage years:

  • Lack of clear vision
  • The tech can start to feel like it’s drifting
  • Things aren’t communicated as well as they used to be

This is very common after a launch.

The vision after the launch needs to be different

It is also easier to have conversations about what is in scope and out of scope before launch because there is usually a date in mind or some kind of milestone, so conversations about whether we have time to get something done before the deadline are much more focused.

After the launch, you no longer have the old site for comparison. So you need to be clear about what ‘good’ looks like.

Vision: No next Next

Good is a healthy codebase that is simple enough for new starters to understand and for us to maintain, that is supportable and operationally reliable, delivers a good user experience and allows us to maintain and increase our ability to add value to the customer and the business.

Bad would be the tech drifting so far off track that we end up in a position where we have no choice but to do another rebuild; another “Next” project again in a few years, with all the costs associated with that.

So our vision is No next ‘Next’.

The plan to get there: The highest impact steps

How we worked out what to do

  • Listen to the patterns in what people say. When I joined the team, I had a one-to-one conversation with each of the engineers, to ask them what was going well, what was going badly (or was about to go badly) and whether there was anything they thought I should know. Some clear patterns emerged from those incredibly useful conversations.
  • If you have a specific questions, surveys can help. For example, we wanted to find out what areas of code people were most afraid of, so we sent out a survey to ask that question, and why.
  • For general patterns, the Spotify healthcheck is very useful. We send this out every three months, and can see clear patterns which help us prioritise.
  • Early on, I gathered the senior engineers together and we had a session where you lay out cards on the floor to identify priorities. (I explain a bit more about how to run that session here). This is a really useful exercise for surfacing things you haven’t thought of, understanding dependencies, and making sure that you are all on the same page.
Image for post
Image for post
People laying out cards to identify priorities
  • Look for artefacts, for example technical principles, dashboards, architecture diagrams and runbooks. These are high leverage things that help make sure everyone has a shared understanding. If they are missing, getting some of those in place is likely to be an early priority. If they are in place, how frequently are they updated and are you sure they are current?
  • Finally, a live site is different from a site in development. There are areas that won’t have been a priority before the launch that are for a site in production. For example, how does out of hours support work? How do you handle critical security vulnerabilities? And how do you act on — or even get — customer feedback?

It’s all about communication

Everyone in the team needs to understand where we are heading so they can make decisions about what they work on so we all get there.

People outside the team need to know our strategy so they can see how it helps the whole FT with our goals as a company, and so they can influence it if they have information that we need.

Communication takes a lot of effort

You have to say the same things over and over again, until you are bored of the sound of your own voice saying them, and then even more; because every time you say it, it will be new to someone. Perhaps they missed the last meeting, or weren’t listening, or are new. But if you want people to know what the strategy is, you need to keep talking about it.

Communication is harder after the launch because the vision may not be as clear, and some of the people involved in the launch will have moved on to other projects. So it’s important to put even more effort into how you communicate your vision and strategy.

It isn’t too late to get back on track

More detail about our tech strategy is on its way!

This is a blog post version of a talk I did at Continuous Lifecycle Conference London. You can watch the video here, or see the slides here.

And if you are interested in joining us on this journey, we are hiring!

You can find Anna on Twitter at @annashipman

FT Product & Technology

A blog by the Financial Times Product & Technology…

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store