The Times Digital Transformation Programme.
Part 4: Lessons Learned and Key Takeaways
This programme is a major project to re-engineer the technology behind the digital versions of The Times and The Sunday Times. It’s transforming a disparate tech stack that evolved from the print editions of the newspaper to a new scalable, performant and rationalised architecture that can support future subscriptions growth and technical innovations.
This article is part four of four:
Part 1: Our business rationale and processes
Part 2: Choosing the technical approach
Part 3: The technical implementation
Part 4: Lessons learned and key takeaways
In this article, I look back at some of the lessons we have learned so far, and offer some key takeaways.
What have we learned so far?
It’s been challenging
We have already faced many challenges during this project and we are not finished yet. It’s certainly been hard in places, and that has led us to question our tech choices more than once. But that’s OK, because challenges are what make our jobs interesting and compelling.
We have spent too much time in some areas
Looking back we have at times spent too long trying to find the perfect solutions to problems. Now we time box that work to make sure it does not derail the project. Adding that constraint has brought about focus and creativity, and we’ve always worked it out.
React Native Web is hard
React Native Web is the hardest part and is opinionated. Media queries and hover state are complex. Cross platform video and ads are a no go or at best a time sink. A cross-platform styling solution wasn’t straightforward and it’s still quirky.
Key takeaways
Don’t stop just because it’s hard
Delivering a large, long term and often difficult project is frequently hard; but ‘hard’ is not a valid reason to quit and go back to something easy. Identifying that something is hard offers you the opportunity to pause and reflect on what you are doing and why things are getting problematic. When that happens, take time out to step back and have a good, open and honest appraisal of where you are; a retrospective, if you will.
Don’t lose track of the effort already spent getting to where you are now and be laser focussed on your stated objectives. Allow your team to contribute to the retrospective and consider all and any suggestions for the next steps.
Only make material changes to the project’s direction or technical solution if (i) you have reached a serious problem that prevents you from reaching your goal or (ii) it is a blindingly obvious that there is now a better technical approach.
Before committing to a new direction consider technical debt, wasted effort and a dissolution of the project’s aims and benefits.
If you do decide to pivot, communicate the reasoning and reaffirm the benefits.
Be agile
Things will change, your internal customers will change their minds and urgent requirements will come in from left field. That’s fine. Don’t fight it. Accept it and do your best to adapt your plans to meet the new requirements.
Equally, you have the responsibility to reflect back the impact of change so that your stakeholders can make informed choices before they commit and agree.
Work closely with product and your other business partners
It’s easy to allow a project like this to be a black box. It’s very technical in nature and can easily turn into an engineering code fest. Do not let this happen. If the project horizon is, say, two years out, you do not have the permission to disappear into the background and pop out again when it’s all ‘done’. That’s what we used to call waterfall. What you eventually deliver will be irrelevant. More than that, you will become invisible to your business partners and they will lose faith in what you are doing.
Keep delivering business value
Keep focussed on what it is you are trying to achieve, but mix up the long term big picture goal with short term targeted deliverables. You will run out of funding if no one can see a consistent stream of business value.
Break your mega project down into easily delivered and consumed chunks that consistently improve your current product offering and demonstrate progress against your long term target and that of your organisation. Then break those down into sprints with clear goals. It’s harder and might take longer overall, but you will perform better every day.
We’ve settled into a pattern of setting ourselves quarterly goals and then work in two week sprints to meet them. Quarters are convenient but do not constrain us; it’s fine if a high level deliverable is going to take longer or shorter than a quarter.
Constantly delivering business value is you paying the rent.
Keep communicating and demoing
Working in an agile manner with sprints, goals and deliverables helps you communicate what you are doing to the wider business. Arrange frequent demos of working software and business value so everyone can see what’s going on. Listen to feedback and take onboard good suggestions. Keep aligned with business goals and the product roadmap. The Times is always looking at increased subscription rates, so where we can we match our deliverables to those goals.
Build the right team
Get people with the right skills who share your vision. Tech skills are important, but accept that not many people have done this before, so be prepared to let good developers skill up.
Build a blend of pure technicians who are coding experts with more pragmatic people able to make decisions and communicate both internally and externally.
Look after your people
Look after your team and do what you can to keep them challenged, growing and happy (yes, even your contractors). Help each person grow so that they view their time spent with pride and respect. In practice, if you build the right environment, people will be loyal.
Understand your role in the project
Each person on the project has a role. Some are deeply technical, some are leaders and some are facilitators. We spent some time pulling together a RACI matrix (Responsible Accountable Consulted Informed) to be sure each person knows what is expected of them and that every part of the process has the right people assigned to it.
Disagree and commit
Not everyone in your team will fully agree with your technology or business decisions. Absolutely listen to opinions and take onboard good suggestions. But do not let discord persist; it will derail your project.
As Jeff Besoz famously said, “Disagree and commit”. Once your team have expressed their opinion they must either leave the project if they feel strongly enough, or — ideally — accept the disagreement and commit to the project, doing everything they can to bring it home.
Do not allow people in the team to constantly whine and spread negative vibes. Recognise their concerns but keep focussed on the project’s goals. Once you have all committed, park the disagreements and move forwards as a team.
As a leader, be a servant
If you have high level responsibility for a project like ours, your duty is to serve it and the people on it. Your role is to keep a watchful eye on what is happening. To sense moods and identify trends. To talk and offer support where it is needed. To be sure your business partners are informed and engaged. To communicate and arbitrage. To explain and coach.
You will only succeed if the project, the people and the business succeeds; you can’t do it alone or by trying to do too much. Trust your team to do the right things and to be the experts they are by giving them the power and freedom to deliver as best they can. Do not micromanage or get involved with things best left to others.
Conclusion
Running a large, complex and long term project is challenging. Its success depends on clear business goals, a strong technical roadmap and the right team that is committed and focussed. Planning is more important than plans (thank you, Eisenhower) because things change. It’s important to look after your people when they lose focus or disagree; keeping people challenged and allowing them to grow is vital. Your project will die inside a black box; it’s extremely important to be constantly aligned with your business partners and their objectives. Keep delivering business value, frequently evidenced by working software demos. As a leader, be a loyal servant.
We are open source
We open sourced the repo, a first for News UK. We auto-publish to public npm on merge to prove out the CI/CD culture with open source CI such as Travis and Coveralls. The backend has a threshold of 100% test coverage with the front-end currently running at ~96%.
Special thanks
Special thanks to our Principal Engineers for (i) making this project work and (ii) contributing to and editing these articles:
- Andy Trevorah
- Craig Bilner
- Joao Jeronimo
