CTO: The Evolving Role of the Chief Trade-Off Officer

“Stop trying to make everyone happy. You’re not chocolate”

– Anon

As a distant observer of the art of being a DJ, I believe I can make their jobs easier. My cunning plan is to replace all those complex sliders on their mixing decks with binary switches. Volume: yes or no? Bass: on or off?

Ridiculous? Absolutely, but this is the same oversimplification often applied to technology. It’s a conversation that will be very familiar to many, particularly Chief Technology Officers (CTOs). CTOs live in the grey space, understanding that they have a variety of competing demands they need to manage, commonly referred to as the “-ilities” such as scalability, affordability, and supportability. CTOs’ customers wish for everything – completely reliable, highly flexible solutions with negligible run costs, minimal time investments outside of IT, and complete security. These demands are increasingly couched in terms like “the need to be more agile.” The reality is somewhat more challenging.

Metaphorically, I’m sure we’d all love a twenty-bedroom house with a mortgage of £5 a month. The reality is that we make trade-offs between costs and features. Simply put, a trade-off means that more of one thing necessitates less of another. If I run a restaurant, I might choose to go full-service, but there will likely be a trade-off between a higher average cheque and customer throughput and staffing costs. It’s no different for the CTO, although words like prioritisation and governance are often seen as ways for the CTO to say no.

While there will always be constraining factors, how do you do more with less and make explicit trade-offs that better support your business? Some of the best leaders I’ve met, CTOs in particular, understand that making investments that maximise their abilities to do more is at the heart of their roles. As my colleague Gregor Hohpe highlighted in his blog post, mapping present and future business needs into a technology blueprint while leaving options open to adapt to different futures is what architecture is ultimately about. For anyone who remembers their integration equations from school, CTOs continuously try to maximise the value (area under the curve) given parameters such as cost, time, and risk.

Here are a few things I’ve learned from these leaders, lessons that are not profound but often lost in the noise of dealing with complex challenges.

More Alignment Means More Autonomy

The word autonomy is frequently misconstrued to mean leaders stepping aside and letting teams make decisions. There is a vestige of truth here, but leaders must be clear about the one-way door decisions only they can make, which have profound implications for their organisations. Every other decision is pushed to people closer to the proverbial action who can make lower-risk decisions quickly and then pivot or continue depending on the result. Here leaders become the champions and propagators of the vision and business outcomes desired, the guardians of the culture that unifies an organisation, and the destroyers of silos. My colleague Mark Schwartz wrote about one such example core to CTOs— centralising platforms to enable more autonomy—in his blog post.

More Principles, More Speed, Fewer Silos

A key part of the alignment-autonomy paradox recognizes the frequent tendency to satisfice when it comes to software—trying to keep everyone within your organisation happy by taking a little from all their wish lists. The CFO wants it built at the minimum cost; the COO wants it to be nondisruptive to the company’s operation; and the CMO wants a plethora of features to appeal to every customer group. It’s a very human desire to avoid alienating co-workers, but satisficing creates solutions that satisfy no one.

One lesson I’ve learned in the last few years at AWS is the power of tenets, or principles. They are simple statements that form the basis of any initiative or business case on which decisions will be made. They make explicit to everyone how decisions will be made. They form a common language that all participants can refer to when making decisions and are the basis of faster, more aligned decision-making.

An example tenet is “We build to differentiate.” A description might be: “Every line of code is a future liability, so we choose to buy and implement the most vanilla version of applications where they are non-differentiating by changing business processes first. We are clear on what really differentiates our company, taking ownership of our destiny in these areas. Even here, we use patterns and technologies that maximise the work not done.”

Such a tenet helps everyone in every seat understand what trade-offs are being made (build versus buy) and why. It prevents the agility-killing need to relitigate every decision by establishing principles shared by all and makes technology—and technology decisions—more inclusive.

More Progress, Less Perfection

It’s not an original phrase, but “progress over perfection” served us well in the early days of McDonald’s digital transformation. We had previously analysed and planned every possible contingency for every project. Initiatives took years. Even deciding to undertake an initiative could take a decade or more in some cases! And when we finally got those initiatives into restaurants, we always missed something in our exhaustive planning.

Spending time on what customers wanted (e.g., a mobile app, home delivery, and a modern restaurant experience) and underlying tenets enabled teams to focus on outcomes, not detailed requirements. A grounded vision centred on the customer helps an organization cut through its own bureaucracy and get new ideas into customers’ hands quickly and cost-effectively, enabling progress, innovation, and differentiation in competitive markets.

Less Abstraction, More Choice

I see few real abstraction choices that create more value than gets destroyed. Perhaps at the risk of dating myself, I recall the promise of Open Database Connectivity (ODBC) to abstract code from the underlying database. It sounded great until you wanted to use a native capability of the database or tune performance. It is similar with the cloud. Hiding cloud-native services from developers through abstraction layers or similar means narrows the choices you have to use powerful, evolving services. I’d prefer to see time spent delivering value through serverless rather than attempting to grow Kubernetes clusters. Abstraction is often used as an excuse to avoid setting a clear strategy, which introduces complexity and heavy lifting work that distracts from building business-aligned features. Gregor Hohpe wrote a great article on one consequence here.

More Value, Less Time

The modern CTO role isn’t about control but outcomes and enablement. Modern CTOs don’t try to design every aspect of the proverbial house, preventing builders from building because there is no standard in place for a newly discovered issue. Rather, they focus on implementing pragmatic architectures, patterns, and tools that enable the builders—technologists, non-technologists, and partners—to deliver more value faster. Patterns and tools can take the form of APIs that enable teams to develop and release new features quickly and independently, CI/CD pipelines that don’t necessitate every team inventing their own deployment methodology, or self-service infrastructure and automation that enables teams to spin up and down their own Amazon EC2 instances quickly and securely. The modern CTO is a lean practitioner, maximising the work that others don’t need to do by focusing on areas that eliminate wasted time and money. In doing so, they directly contribute to reducing the cost of experimentation and scaling within an organisation.

The CTO’s role is mired in complexity, a reflection of the demands on them and the pace of change in expectations and technologies. It’s also one of the reasons modern CTOs gravitate toward the cloud, removing from their plates a number of traditional, pre-cloud trade-offs such as cost versus reliability, security, or geographic reach. Now CTOs can be like DJs, tweaking the sliders of their metaphorical mixing desks to ensure technology supports business and customer demands instead of making stark, binary trade-offs.

It’s still not an easy job, but it is one that can look more deeply at the trade-offs associated with people and staffing, organisational designs for predictability, efficiency and agility, the right balance between autonomy for speed and guardrails/centralised decision-making for control, technology selections decisions, and how much or little innovation is democratised. I look forward to sharing more in-depth perspectives on these issues from my colleagues on the Solutions Architecture team this year.

Phil