I was recently at the MACH alliance, one of the largest tech conferences in the world, when an engineering leader at an enterprise telecommunications company asked me a seemingly simple and yet complex question: how do we at Code and Theory lead tech modernisation for our clients?

While we have a robust program, I found it challenging to break it into an elevator pitch. I felt that I didn’t deliver on the full opportunity and promise of tech modernisation, and it ate me up the rest of the conference. So I found the engineer on LinkedIn and wrote him a version of what you see below: a more in-depth, thoughtful approach to how Code and Theory, a technology-first creative agency, approaches tech modernization.

You see, tech modernization is not one-dimensional. It offers the opportunity to enhance efficiency, foster innovation and stay competitive. It promises streamlined operations, improved collaboration, and the ability to adapt to future challenges. If executed consistently, it should drive tangible growth and deliver greater value to our customers.

1. Build a collaborative environment

When we’re undergoing change, we must get into a learning mode and create a safe space to say 'I don’t know' and be wrong. We have to model this from the top and make it the core of how people spend time. In my experience, this has to be related to the code generation process — whether it’s pairing, synchronous code review or async PR review. Peer-based review has to be the norm. As a principal-level engineer, I learned a lot from people of all experience levels, from seniors to interns, just saying, “Hey, I don’t understand this nested ternary.” I rewrote things to reduce complexity, which created a ton of value because the following person (who might just be me in six months) may not appreciate the cleverness of the nested ternary either. I always say that the reviewer is doing you a favor and focus the process on the reviewer to encourage collaboration (i.e., well-defined pull requests that clearly indicate how to know that the PR is functioning correctly). And if there is a disagreement, the 'tie goes to the reviewer'.

2. Create tooling-based guardrails

While the human interactions should be the focus, taking off the cognitive overhead of validating whether code matches a style, that it’s runnable at all, that it fulfills high-level specification criteria, etc., can all be validated by simple, fast tooling (i.e., AST-based formatters, static code analysis, snapshot testing, basic unit testing). Let the robots yell about the simple infractions and save constructive human conversations for more meaningful architectural change.

3. Make ambitious choices, but know your limits

I have seen TypeScript written by Python devs who did not want to take the time to learn TypeScript, so I have seen how it can go wrong. You have to know the limits of the team. On a recent broadcast application, due to our need for absolute predictability of interface and 100% correctness, we chose XState, which is a lovely state management library with React, Angular and other bindings based on finite state machines. However, on that project, our junior developers were lead level, and we have yet to roll this tech out as our company-wide standard.

4. Decouple systems via strong data contracts

Starting from a data model or “contract” is critical. I’m beginning to insist teams use https://typespec.io/ to specify, as it’s fairly independent from any particular implementation. With tech like GraphQL (which I’m partial to as it’s solved big problems for me in optimizing some complex data resolutions at Condé Nast on a data model that was overly atomized), if you start from the schema, then backend engineers can run off and build the resolvers, validate and optimize them, and the frontend engineers can run off, build mocks and do their component work. When a service starts to come online, just replace the mock with a query and you’re integrated.

Preparing for Future Challenges

Often, I hear from CTOs and engineers alike assuming that tech modernization is about adopting new tools. However, if that is the focus, it will fail. It must be about fostering a collaborative culture that leverages tools to streamline processes, which then has a network effect across the teams making the product and those using it, too.

I’m grateful to the engineer at the conference for his question and willingness to let me share my deeper point of view here. Diving into the annals of tech modernization has reminded me of how we stay innovative, efficient, and prepared for future challenges and, most importantly, how we use it all as fuel for tangible value for our clients.