In conversation with Thomas Squeo, Thoughtworks CTO for the Americas

Episode transcript

Ken Mugrage: Hello, everybody. Welcome to another episode of the Thoughtworks technology podcast. My name is Ken Mugrage. I'm one of your regular hosts. We have a little bit different format this time. We are lucky to be joined by the CTO for the Americas for Thoughtworks, Thomas Squeo. Thomas, do you want to do a short introduction?

Thomas Squeo: Sure, Ken. Thanks for the opportunity to join. I've been a long-time listener, first-time caller, so this is fun for me. My background is a career technologist and executive. I've been working with Thoughtworks as a customer for over 22 years. In that journey, alongside, I've done everything from be a software engineer to run a function, to be the executive sponsor in multiple roles around chief technology officer, chief information officer, product officer, chief strategist, architect, and head of transformation for various organizations.

Most recently, I joined Thoughtworks as the head of enterprise modernization platform and cloud for North America. Then I was given the opportunity to join the CTO organization and strategy team to lead the Americas, which is essentially the intersection between strategy and demand, and our relationship to the service lines.

Ken: Perfect. Thanks for joining us. Just to be fair to the audience, Thomas and I work together on a fairly regular basis, so we'll try to not use insider terms and so forth. I want to talk to you about a bunch of different things. First off, CTO for a larger company like ours, what are you looking at from a technology perspective? What are your priorities for 2025?

Thomas: I think that when I look at the market landscape and I think of the position that Thoughtworks has in it, I look at the application of artificial intelligence for software delivery at scale. What are the foundations that are required to be able to drive those, whether that be platform engineering or platform as a product mindset, looking at things like data quality, how that then in turn feeds and builds upon each layer into a more capable organization? One of the things I always view, and I've heard this quote recently and I really liked it, was organizations have to be brilliant at the basics in order to be able to get better when they're actually implementing these more sophisticated techniques.

I think if you hear about some of the things that the analyst community is seeing or hearing from their surveys is that quite a few of the AI investments in various industries are abandoned because of things like data quality. Knowing that and knowing Thoughtworks' position in that conversation, when I think about what's being done, I think about data as a discipline. What's the governance structures? How is it promoted through its lifecycle of readiness for consumption? Then how it's ultimately going to inform a foundation or a frontier model that is being customized from the taker to shaper to maker journey from if I'm going to use the McKinsey language as well?

Ken: Cool. If data is one of those basics that you need brilliance in, what are some examples of some others? What's the foundation you want to build on?

Thomas: The big foundations from my view are really around the engineering effectiveness dimension, the understanding of the business outcomes and their correlations. From there, you then have the ability to look at what is the life cycle around continuous delivery that's happening. What are you doing from a platform engineering standpoint and how are you able to enable teams at scale? I think typically the problem set that we are dealing with and the problem set that I've dealt with as an operator has been largely in and around that notion of when you're bringing capabilities to many teams, as opposed to bringing point solutions that are embedded in a single product team or delivery team.

When I think of that scaling opportunity for being able to take advantage of the techniques that we evangelize as Thoughtworks and we see that our customers are adopting, I think that it comes from an understanding of what are the foundation principles around, what are they trying to drive from an engineering effectiveness standpoint? What are they trying to drive from a capability perspective? Those capabilities could be everything from cloud consumption, FinOps, it could be the things around their software delivery lifecycle, their intersection with product, how they're engaging with enterprise architecture, and ultimately, what are the things that are going to drive outcome for an organization.

When I say things that are going to drive outcome, you could think about those in the context of metrics, but you can also think of them as what are the broader techniques that an executive can overlay on top of a technology or a product organization that drive behavior change. I think those are the things that I look at. Then many of the conversations that I'm in are typically with the leaders of the technology organizations in our customer base.

Ken: What can these leaders do? In our organization, we're talking about thousands and thousands of people globally. Many of our clients were small compared to them. What can you do, in some of these organizations, to get your people and keep your people up to speed? This all changes so fast. How do you keep track of these basics?

Thomas: There's a need for a certain degree of market sensing for engineering teams to be able to understand what the landscape and ecosystem is having. I think with the groundswell of activity around gen AI, you're seeing such a frothiness inside what the tools and capabilities are. Again, I say that you need to come back to what are the basics so you could be able to understand. Something that's an innovative product today might be a feature in another product in very short order. In the way that for any organization of any size, whether you're a 50-person startup or a 15,000-person enterprise, there's a notion of what you could think of as continuous learning.

The same activities we do as technologists to be able to manage our own career, there's a way of scaling that out so it's evangelized and supported inside an enterprise that'll ensure that teams have the ability to understand and learn from each other, learn from what the key inputs that are being taken from outside the organization. Then using tools like-- I was always a big fan of the technology radar long before I joined Thoughtworks. I would use it as a way for me to be able to understand what things are emerging, what things are in trial, what things should be held back, why they were being held back, and so on, and so forth.

I think that in that journey, there's ultimately an opportunity to manage a view of how people adapt technologies over time. I think that one of the things about Thoughtworks being the size that it is, is that when we do produce an artifact like the radar, it's statistically accurate. It's got an end count well over 300. That then gives me the ability to shape what does a forward-leaning learning organization look like, and what are they seeing in the diversity and the heterogeneity of the engagements that are out there, whether they be based on industry or problem set being solved and so on and so forth.

Each of those are dimensions, from my view, of how an organization can start to take that in. One of the things I think is a foundation is that the understanding that a continuous learning organization and a continuous learning capability is part of the professional development necessary for any organization to remain relevant. If it is not invested in, ultimately you'll start to have a lot more transformation initiatives because the plot will have been lost and you'll start to see, you'll start to accrue a lot of technical debt because you're not evolving your platforms with the techniques.

I think that when we see large system portfolios or large product portfolios in many of our customers, there's a geology of the generations of technologies. They don't necessarily go away because once they're delivering value, they're very hard to sunset or update, and so on and so forth. One of the other things to an earlier question that you asked is I think that we are at the point where the modernization imperative for many of the systems that were just never going to be touched is now upon us. We are now at that point where the can had been kicked so many times that the current generation of apex technology leaders and executives are now having to change some of these systems out.

That could be whether or not the providers are requiring a cloud migration. That could be that the technical debt that's been accrued has now caused enough metastasization inside their systems that they're not able to extend what they're looking to do anymore, or it's actually become an inhibitor to any market opportunity or market capture opportunity.

Ken: I know you had said during your intro that you joined us in the enterprise modernization space specifically. A lot of times in this modernization, we have this miracle platform. We'd love to talk about platforms and the fact that platforms mean different things to different people and so forth. What does that really mean to you as a CTO? You got a platform, they're not magic. How do you actually make that useful to developers, useful to business, useful to modernization?

Thomas: Platform is a couple of steps up the value chain from basic hygiene and practices around software engineering and delivery. I think there needs to be a notion of how does a team manage the deployment of their software as an individual organization, but in a enterprise of any real size, you're going to see teams that have varying degrees of capability in their teams. For example, previous organization that I was part of, we had many teams. All of those teams did not operate at the same level of capability. They also didn't operate in the same regulatory environment at the same time.

You saw different ways of those platform capabilities being brought to bear. I couldn't necessarily, and I wouldn't recommend for many organizations to just put in one platform with one operating model and say, "Hey, this is going to solve everything for all your needs." Especially in a house of brands company where you're working in multiple regulated environments, that doesn't necessarily scale because the techniques that are going to drive value for one environment are not necessarily going to be the same as another.

I do think that there is a set of capabilities and guardrails that you could layer onto engineering teams that give them the ability to take advantage of platforms, but a platform has to be managed as a product in order to support the developer community and the developer experience necessary for teams to be able to come to it or have it be pulled into that. If it's a push from the platform team, if you'd say build-it-and-they-will-come model, it's unlikely to work. The evangelization has to come from within the teams, and ultimately, they need to have the support structure at their altitude inside the organization. Engineers learning from other engineers, the leadership teams and directors, and VPs with other folks that could be able to part of that enablement journey and how they actually adapt. All the way and underpinning that is a product mentality to how that platform operates.

Ken: We hear, as a product, products over projects, product mentality. What does that mean to you? What does product thinking mean to you?

Thomas: Anything that you've done twice should be automated, first and foremost, because the third time you've now seen a trend happening. When I think of a project, it is a short point-in-time point solution to solving a problem. If you think about programmatic implementation when you're working at scale, many little projects inside of a larger program, the analogy that I would take when I look at the platform engineering is that you could have many products that are taking advantage of the platform capabilities in a unified way that creates guardrails.

Engineering leaders and executives have the confidence of knowing what is in line with the governance of the organization is ultimately being driven. The right way is the easy way. There's a path to production and a way of dealing with requirements management. What is the deployment cycle or the life cycle around continuous delivery? How does that then move into things like observability and monitoring in an environment? What is ultimately, the ways in which things like FinOps or GreenOps CloudOps can ultimately be overlaid on top of that?

You don't get any of those higher-order capabilities that delight procurement officers and CFOs unless you actually have the ability to have this unified layer. I view platform as a product as that unification layer. Teams ultimately have then the ability to communicate what is happening inside their system. You will know when there is a team that might very well be overconsuming something that might give an opportunity to be optimized. It isn't necessarily meant to be the platform being a view for punitive action, but it is definitely this notion of, hey, I can give you a tool that will give you a degree of visibility into the use and what's happening inside your system that ultimately gives you the ability to make decisions on what you want to prioritize. That collaboration between engineering teams and product teams at that product level are deriving value from that platform.

Ken: One of the things that you touched on a little bit there that I've seen, at least, and I'd love your take on it. I'm a continuous delivery freak. I spent a big part of my time at Thoughtworks working on some of our tools in that space and that sort of thing. I love the idea, obviously, of all of that, but it does actually produce some product-style challenges. What do I mean by that? If you have a release every quarter, then you update documentation, you update training, you update marketing material. You have your big bang where you go educate your sales force and you educate your marketing people. For a lot of organizations with continuous delivery, whether it be a platform as a product or the product on top of it, that gets skipped, right?

There's new features just trickling out. The support people don't always know how to support it. The salespeople don't know always how to sell it. As the technology leader that's rolling out these features, how do you keep the rest of the organization in step so they know what you're doing and so that you're doing what they need?

Thomas: There's a couple aspects of your question that I want to unpack. One is that platform team, ultimately the platform owners and the product owners associated with that, have a market sensing requirement of their role. They need to understand what's happening and what their teams need. That then gets incorporated into that platform, for all intents and purposes. When you start to now see that there's a tipping point around utilization in that platform, there's then a need for an enablement team that runs alongside it.

You need to have champions and evangelists inside the organization that understand what that journey is. There needs to be a continuous communication loop. If we think about the change management that goes along with any programmatic or systematic change inside an enterprise, you ultimately have to have a communication strategy, you have to have playbooks, run books. How does it actually work? Think of your development teams as customers that are on that journey. When they're on that journey, they are also a source of inputs into how that platform needs to be improved over time.

One of the things that I've seen, and I've seen this at Thoughtworks is that we have platforms that have to be able to support multiple operating models as well inside of our customers. It can't just be a Kubernetes plane that's basically automating aspects and then assume that everybody in the organization is running it because not every stack is the same. Not every approach is the same. Not every outcome is going to be ultimately measured the same way, but there is a pull effect that happens when you see what good looks like in one aspect of the organization.

You can then go and say, "Hey, how can I take advantage of that in another part that might be on a different cloud provider, might be doing different techniques?" and so on, and so forth. That continuous learning across these platform teams ultimately ends up being something that's an opportunity. I've never seen a single platform team solve all the problems of an organization. It's just not what they're really doing. I think that when you think about this as almost a customer segmentation strategy, there are customers and products and engineering teams that fit the profile that are going to derive advantage from that.

I also think that there's an opportunity to learn from inside the organization about what you're trying to accomplish. Some teams move very quickly past the capabilities or taking on architectural patterns that the platform might not actually solve. There are teams that might not be at the level of capability of the platform. You have this ability to normalize what good looks like inside the organization. Exemplars, there's always an outstanding. Unfortunately, there's always what I call a furious five. Those teams that they benefit from almost any practice improvement that you can actually apply to them.

Ken: If I could, just taking advantage of what I know about your background, our listeners are often the people that are wanting to create these platforms because they will derive those benefits, but often there's chief financial officers and everything where it's not quite as apparent. I've had conversations with business leaders that were like, "Wait a minute, you're going to replace my mainframe that does a thing with this magical microservice platform that does the same thing." Now, we know it doesn't, but when you have to bridge that gap and you have to say, "Hey, we need to modernize because we want to enable things," what are the things that our listeners, the tech leads, the directors of technology, what are the things that our listeners can use inside their organization to convince the finance people this is a good investment?

Thomas: I think the number one thing that any executive engineering team leader or so on and so forth needs to understand is that there are a lot of dimensions of any program or initiative that are not just financial. If you think about the mainframe example that we're talking about, we know of scenarios where the roadmap to just get to parity to the current cloud environments is measured in half decades. That is insane when you think about a team or an organization that needs to be able to take advantage of some of what their customers expect. For example, if you think about what has happened with the Amazon experience and the Netflix experience feeding into the B2C expectations of what technology is going to be doing, the enterprise is expected to operate at that level as well.

That now is no longer a question of, does my mainframe need to be modernized to be able to be at parity with the current generation of technology. It's not uncommon for a mainframe to be able to be carrying technical debt that is not understood. For example, replications of the code bases, dead tree branches in that tool set. It doesn't mean that everything in that system, that origin system, is going to be part of that modernization journey. I think that when we think about some of the work that we've done around application modernization or enterprise modernization across many of the customers that we have, ultimately that ends up being a journey that is not couched in purely financial terms.

Those financial terms need to be understood. There needs to be a benefit analysis of it, but there also needs to be a risk analysis of it. There also needs to be an understanding of what is the extensibility and the operational comfort that's derived from having a net new system. Now, I worked for a CIO a while back, and it was really enlightening when he said, "Don't bring me a million-dollar initiative that saves me $500,000 and then turns around and increases my risk profile for the organization." That is how a CIO in a global mid-cap company looked at the problem set.

When he said that, I was like, "Yes, understood." Now I understand what are the dimensions that that initiative needs to be able to be brought forward for. The CFO is a partner in this journey. They will typically tell you no three times before they say yes. Let's just accept that. If you're not going to be willing to run at the problem and to refine the program in that way to get your pencil sharpener out and get more specificity about how that is going to be derived, I think one of the things that's out there is that they want to be your partner to be able to drive value.

It's not uncommon. There's a reason why the strategy function is handling of love with the finance organization. The CIO and the CTO and their respective organizations are the only part of the organization, besides the CFO, that has a foot in both the current state and the future state at the same time. By being able to understand that, how do they cross that chasm to be able to get to that other side, that's something that the teams need to be able to understand how business cases are created, how value is captured, and ultimately is derived because the lingua franca of business is dollars and cents.

The understanding of what drives strategy is risk and opportunity. I think those are things that are really important for today's engineering managers are tomorrow's engineering executives, and ultimately, potentially, the heads of operations, the CEOs of firms, and so on and so forth. By understanding that context, it's ultimately how that journey will be undertaken.

Ken: Great. Somewhat of a switch gears, but also a bit of a callback, if that's possible to do those things at the same time. You had mentioned things like market sensing. What do you look at? What are you reading? Is there a book you like right now? Is there a publication you read? What are the things that you want to look at on a regular basis that you are confident are going to give you a view into what's more likely to happen than not?

Thomas: Great question. I am, I would say, a voracious reader and a voracious consumer of relevant content to what we do at Thoughtworks. Obviously, all the analysts, when they're publishing reports, I'm consuming those reports as they come up. Gardner, McKinsey, Forrester, IDC, all of those folks, Constellation, Everest, any of those groups that are actually producing reports where they're seeing things. I'm also listening to our partners and competitors. The Accentures, the Deloittes, the PwCs, those folks that have those engines inside their organization, hear what they're saying about it.

I'm also listening and reading to some of the folks that are on the cusp or leading edge of AI and other things. When we think about what is happening in our current landscape around the introduction of gen AI and the groundswell about the inflection point that we're at right now, which is probably at the same degree of transformation as the introduction of mobile, the introduction of net-centric systems, and so on and so forth, I think that there is also a philosophical aspect of this as well. When you think about the ethics of AI, you think about explainable AI, you think about the things that we need to be able to understand, as a technologist, understanding our history that got us here and the philosophical aspects of how we're going to get to that next generation, I think are some things that are very critical for us.

When it comes to the books that I'm currently reading right now, I just finished Nexus by Yuval Harari. That was a really interesting one. I am pretty much a regular listener for things like Sam Harris' podcast because the diversity of thinking that gets brought into that contextualizes what we're doing from a technology standpoint. When I think about the non-technology inputs, it's always things like Harvard Business Review, it's the McKinsey Strategy podcast, so on and so forth. The reason why I'm listening to things that are not directly related to my role is those are the people that I'm typically interacting.

What is driving the strategy conversation? What's driving the M&A conversation? What value or value capture, what is the investment thesis associated with doing a transaction of scale, which is actually very disruptive for a business and almost imperative that if a bad transaction can sink a large organization, those are all key aspects of how we contextualize what we do as technologists on behalf of our clients. Those are really key. I'm happy to share my reading list with you if you're interested because I get asked for that pretty regularly.

Ken: There you go. Pop it up on LinkedIn or something, and we'll link to it. Yes. Cool. I guess we've brought up AI a couple of times. We try not to make every podcast about AI, but that said, what excites you? What scares you? Yes, there's some hype. What are your thoughts? Where are we going with this thing? Don't say Skynet.

Thomas: I think that what we need to think about when we think about AI and scale, especially when AI and software delivery is that AI is an enabler for teams to go faster, become smarter, and ultimately become more effective. AI is a partner in this journey. I believe that it is not going to replace a pair of engineers, but it will be part of that. That'll be a guide down the side alongside that pair. When I think about the things that I find very interesting and exciting from a Thoughtworks perspective, it's things like ruggedized DevOps.

It's the introduction of things like RagOps. what are all the aspects of evaluation frameworks that need to be brought to bear to ensure that when you're putting a production-grade system in that is being driven with a foundation model, or whether you're taking a single foundation model that's driving something in an agentic fashion, or you're taking many models that you're having to stitch together in an orchestration model? Many of the foundation software engineering and architectural techniques are still applicable. What I find very exciting from my view is that we are taking the practices that we've created, evangelized, and we see ubiquitous around the industry, and now we're applying a new level of technique.

If you think about some of the things we do around like API strategies for our customers, those API strategies are going to become agentic workflows or a chain of thought, prompting, and things of that nature where that will be part of the application that will be doing that. That's something that I find very exciting. We're seeing a lot of use cases right now. Life sciences, financial services, automotive manufacturing. I think that any organization right now that is not experimenting with AI is probably going to be very quickly left behind.

I think that one of the things that we see is there are many ways to be able to bring AI into a production model in the operations of an organization without necessarily exposing it to your customers until you're ready. There's an aspect of that that I think is really important. What I also think about is when I classify gen AI, we're now mixing what we consider to be data science and machine learning on the deterministic side, with the large language models and all the activities you're able to do on the other side. I think that whole ecosystem is what you're able to bring to bear with AI as a capability. I love some of the work that we're getting to showcase inside the organization, yes.

Ken: I guess I'll close with a career development question. You're at a conference, somebody walks up that's a lead developer or principal, been around for a little bit, and they're saying, "Hey, Thomas, how do I go to the manager path? How do I become a CTO?" Yes, I'm sure that's a just quick 10-second answer. What advice would you give folks that want to do what you do when they grow up?

Thomas: One of the things that I have found is that you need to volunteer for the work that is difficult. It might be outside your comfort zone, and it might be what you would consider risky, but ultimately, at the end of the day, if you have the ability to lean in on the hard projects and ultimately, stretch yourself into those next levels in the management hierarchy or take out those opportunities. The other aspect is that you need to find a mentor that's willing to invest in you and be really clear with you around, what the expectations, what they see, and even the language.

I have had an executive coach before. Those were never comfortable sessions, and I've been in the C-suite for a while when I had that conversation. You're not used to having somebody saying,"Hey, I hear in the language that these are the anti-patterns in your behavior or what you're seeing," and so on, and so forth. Having a mentor or a coach can really help you there. I think that in some cases, some engineers get very comfortable in a single organization. Then when they move, they move into a role that's identical to the one that they were in in the last organization.

That is a foundation problem because that's not how careers progress. If you're just going to wait for somebody to see your sparkling talent inside the organization and then promote you in and throughout the organization, that's probably not the way forward unless you have somebody that's evangelizing on your behalf. The reason why I say that is because some of the best principal engineers and leads and tech leads stay the best principal engineers, leads, and tech leads for their whole career because they don't necessarily see themselves at that next level.

I think that some technologists view management as a path that they don't want to go down. Ultimately, at the end of the day, when you think about systems thinking and organization design, it's the ultimate architecture problem. It is. It is, oh, it never changes. What that happens is that the complexity changes because now you're dealing with people. That's the journey. I think that it's a much larger conversation than that. I would be happy to dive into all the aspects that drove it for my view, but I think that there's this notion of some technologists really want to be in the IDE their whole time. I think that there's a point where you have to understand that delegating somebody to be successful and driving that success, understanding what that standard is, and ultimately holding that team to that standard, that's that journey started.

Ken: Great. I appreciate that. Again, for our listeners, we'll put a link to some of Thomas's social networks. He's pretty active on LinkedIn. Active speaker. Highly recommend following him, following his content. Thomas, as always, thank you very much for your time.

Thomas: Perfect. Ken, thanks for the opportunity, and, anytime.