Evolving platform and enablement at Thomson Reuters

Abi: Justin and Matt, thanks so much for sitting down with me. Really excited to chat with you both.

Matt: Yeah, thanks for having us.

Justin: Very excited to be here.

Abi: So before you all were the platform organization, you guys were something else. So I want to start by outlining for listeners the history of your organization. How did you become the platform organization? And maybe start by just sharing the background on what things were like before you guys were the platform organization.

Justin: Sure. Yeah, happy to. So Matt and I have worked together for a number of years and we both were together around the end of 2015 when we started The Cloud Center of Excellence at Thomson Reuters. And that’s when we essentially made the decision to pivot to public cloud as an enterprise. And we worked as The Cloud Center of Excellence for a couple of years. And then in around at the end of 2017, there was a decision made to merge The Cloud Center of Excellence team with our data center infrastructure services organization to form a new organization called Infrastructure Hosting and Networks.

That organization was very purposeful, because we wanted to have a consistent strategy towards running our infrastructure at Thomson Reuters and cloud had become big enough by that point in time where we wanted to bring it together with the broader team and leverage the domain expertise that we had across the broader technology organization. And we ran as infrastructure hosting networks for about three years, made substantial progress in our cloud adoption, cloud migrations, and different other strategic programs before rebranding the platform engineering in 2021. And we did that also very purposefully because we wanted to ensure we were looking forward and representing really what our goal and vision and strategy was for the organization, which is to provide that underlying engineering platform to all technologists and developers at Thomson Reuters. And we felt it was time to lose the infrastructure brand since we were offering a lot more to the company than just infrastructure.

Abi: When did that vision begin to materialize for you guys? You mentioned this bigger vision around that underlying platform. It seems like you went through a lot of different names, a lot of disparate teams coming together. So when did that vision and what inspired that vision?

Justin: So I think a lot of it started for us in 2018 when we announced the divesture of half of our business. It was our finance and risk business that’s now known as Refinitiv, an LSEG, a company. And at that time, we were trying to lead and run a program centrally to migrate out of data centers that we were divesting and took the opportunity to build on our cloud expertise to migrate workloads that were in the divested data centers to cloud. And so we formed a team of experts, of solution architects and solution engineers, to lead and drive that program of work. At the time, not necessarily knowing we were doing enablement per se by that name, but I think it came more clear as months and years past that there was a good appetite for that type of engagement with our technology teams across the company, as well as a lot of value where we could take lessons learned from one area of the business and bring them to other areas of the business and really accelerate the overall goals and initiatives that we are looking to drive.

Matt: Yeah, I think what’s interesting is when we started The Cloud Center of Excellence really focused on cloud native architecture and how to do it really well, we were doing enablement and service work all at the same time. Myself, I started that focused on data services, so how should our data services change from how we build our products today to how we deploy them in the cloud and what databases we use. And so we picked a handful of projects to really start out with and dive deep.

And I found there was a lot of context switching in trying to be obsessed about our product developers and what they needed versus also figuring out all of the best practices and non functionals around running a cloud database as we’re learning all of this at one time. So I think how Justin highlighted, hey, when that divestiture happened, we became infrastructure hosting and networks and we kicked off this data center exit program and we realized that we needed that dedicated focus to enablement, it was a real light bulb moment for me in showing how we then could get out of the business of trying to do both for one person, which got really tough once the scale started coming in.

‍Abi: Well, I love that. And we’re going to be diving deep into the journey of the enablement org soon, but couple more questions about the platform org. I’m going to ask you, not all organizations have made the migration or transition to emerging these different functions under one roof as you guys have. So I want to ask about that journey. What was the thinking at the time around the benefit of consolidating under one parent organization?

Justin: I mean, I think it’s grown up organically through a lot of micro decisions or iterative cycles. I mean, at the end of the day, all the technologists at Thomson Reuters are really just trying to be helpful. I mean, we’re trying to help other technologists with NTR and the product teams that are building product are trying to be as agile and innovative as they can be for our customers and organically as we start working together and building relationships and running a community of architects and interested parties and really sharing secrets and common goals. And it ends up happening almost by accident. And then with some of the programs, like the Refinitiv divestiture that we mentioned, bringing focus and resources and investment to drive. And in multi-year programs, you start building this muscle that really is something that can be flexed to point at different other areas of the business. And we’ve run multiple different programs like that and it’s been quite a success.

Matt: Yeah. I feel it felt very organic and natural to start out that way. And also with the context of the time where our hosting locations were so different between the cloud and our data centers and how that conversation unfolded, it was very natural to start at the hosting layer and then move up the stack. And so with our backgrounds in application development and application architecture, I think we always feel a natural tendency to move up the stack and be more helpful.

Justin: One additional thing I’d add, Matt mentioned in 2018 when we were having the conversation specifically about Matt, where he was running data services architecture as well as we’re trying to peel off and do more enablement and help for the product teams as driving solutions architecture, I mean, it was a very purposeful decision to peel those apart and we’ve respected that up through today. So we have separate, I call service teams, within the platform. So the service teams actually build and run and support the services that are part of the underlying engineering platform. And so that’s from running our data centers worldwide, to running our networks, our WAN, our LAN, our office wifi, our cloud landing zones, all of that stuff. We have patching services, backups, things like that, also more progressive services around CICD, common pipelines, observability, like monitors, code, all of that good stuff. Those are the service teams.

And what we really try to do is encourage separation, but also that healthy tension to the enablement function, which really is a team of engineers and architects that market the platform, if you will, to our consuming teams, but also bring back feedback and roadmap items and, “Hey, this isn’t working,” and so we can have some good inner debate amongst ourselves on when is a platform service done or when is it good enough or what does it need to evolve to next and where are our consuming teams going that we need to lean in and help them with. So that’s one of the reasons why we still operate very separately, but we also work very closely and collaboratively together, where we’ll pull in resources with expertise or interest or we do secondments across the team. So it’s really worked out well to have them under the same tent.

Abi: Awesome. I have two more questions, actually, two more questions about your platform organization as a whole. First question, with where you guys are at today, what do you look for as measures of your impact and success? Is it primarily being measured in terms of dollars, in terms of the cloud migrations, things like that, your focus on… What do you look for? What are you reporting to the rest of the business on what you guys are doing?

Justin: So, a handful of the key things that we’re focused on, one of them is finishing the journey of our cloud migration. So we’re about 83% in public cloud today from an overall infrastructure footprint perspective. We’re driving the exit of our last owned data center in Minnesota as we’re progressing to the cloud. And the percent complete is certainly a metric that we’re measuring there. We expect to be about 90% in the public cloud overall by end of year 2023 and about 95% by end of year 2024.

Separately, we’re also leading and driving the adoption of a modern strategic DevOps tool set. This is something we’ve been running at within the enablement function for the last two and a half years. We’re currently at… We measure percent adoption across the different teams and what teams are yet to be adopted or to enable the new tool set and which teams are been adopted. So we measure and report on that and then we also make sure to circle back around and help teams use it in the most value-add way. So it’s not just a check the box tool adoption program. It’s actually like being a bar-raiser for us around nonfunctional requirements and things of that notion. And then obviously there’s a slew of other ones around cloud modernization and helping different app teams with their journeys either to cloud or modernizing in cloud or improving or adding value to our end customers that we try to help with as well.

Matt: As part of the DevOps program, I just want to add that we’ve put in place DORA metrics so we have some baseline metrics to measure. So going forward as we get into other areas, like Justin was saying, around a cloud native modernization of an architecture or an infrastructure architecture, we can measure what effect that’s having, so really excited that we’ve been able to get that in place across the vast estate that we have.

Abi: And when you say modern DevOps tool set, share with listeners, what is the migration for a typical team or part of the organization that you’re working on adoption for?

Justin: So one of the things we announced a couple of years ago, we had a, it was called a DR change program, and it ran for 2021 and 2022. And one of the things that we were sharing with our customers, our investors, and our employees is that it really was a pivotal point of shifting from a holding company to an operating company. So Thomson Reuters historically has been very acquisitive company. We had lots of different product offerings, lots of acquisitions that were at various stages of integration. And what we were trying to do is have a prescriptive way to develop software at Thomson Reuters and have commonality from a development tool stack, a development excellence or development experience, as well as how we manage and run the services.

And so really trying to take the snowflakes that perhaps were representative of the past and have a common strategic go forward path. So we were standardizing on tooling, standardizing on source code repos, CICD pipelines, things that, trying to promote a happy developer or developer happiness and take those decisions off the table from every single development team so they can just focus on customer value and developing features and functionality that would be advantageous to our product teams and to our customers and trying to minimize the number of disparate solutions that we had running, which were the gamut of internal proprietary develop tooling, to open source tooling, to third party tooling, multiple third party tooling. So really just trying to get prescriptive on a single path forward.

Abi: Shifting gears now, I want to talk about the enablement function within your platform org specifically. This is something we explore a lot on this show. I know both of you listened to my conversation with Manuel, Team Topologies. The enablement org sounds like it’s sizable at your organization and it’s gone through a lot of growth. So I want to take listeners through that journey of evolution starting with, and Matt, you already touched on this, but tell us about how the enablement team originally got formed. I mean, where did the idea for it even come from?

Matt: Absolutely. I would say it started around the time we became infrastructure hosting and networks in 2017 and then had our first data center exit program. We realized that we needed to be pretty proactive and upfront with how we approached the migration. Now when we started building cloud native up in 2015, we did put in place processes to help people understand, “Hey, how is cloud development different?” And we needed to do that at scale, so that once we scaled up two more and more products in the cloud, we were ready, but we started out with just a handful. So it was very maintainable.

Like I mentioned, I think I mentioned before when I was an architect at The Cloud Center of Excellence beginning, I was doing enabling and service work. And that’s what really, context switching got tough. So when we started that first data center exit program, we started realizing there was this upfront enablement, how can we accelerate all of our consumers who don’t really have a lot of experience with cloud, how can we accelerate their experience to get them out of these data centers that we needed to exit for the divestiture? And that’s what it really came as far as having a centralized team of architects to help accelerate that.

As we explored the next step, then it was what does this overall migration look like? And very naturally then, how do we accelerate the creation of infrastructure for teams in the cloud? And that led into some professional services type engineering work that we could do for our product teams as well. And so given the nature and the time sensitivity of that particular project, we knew we couldn’t re-engineer everything to follow our cloud native strategy right away. So we put that central team in place to really accelerate the migration to cloud. Yeah, go ahead.

Justin: Yeah, and just to add to that, I think what we learned early on is solution architects are extremely valuable and they provide a lot of insight and guidance and strategic direction and, “Well, here’s three different things that you could do and whatnot,” but without a supporting engineering cast and hands-on keyboards to embed with the different teams that we were working with to enable. Their value is somewhat limited, so we ended up kind of pairing together engineers and architects as part of enablement, but then I think as it grew, we found ourselves trying to keep track of all of the work intake and the different priorities and requests that were being made. And the squeaky wheel gets the grease, so how do we have a holistic view of what our team should be leaning in on the next quarter, the next month, the next week?

So we started to bolster around different business analysts and other type of roles that are within enablement to make sure it’s a well-running machine and make sure that we have some elements of organization around what architects get pulled in, what engineers get pulled in. Different engineering teams have areas of expertise that they can hone and grow their skillset sets, but also we’re very cross-cutting in terms of pulling in right individuals to the right engagements and trying to make sure that we are focusing on things not just cloud migration, but the DevOps tool adoption, decomposing a monolith, microservices, the best practices around running a database, all sorts of different things.

Abi: Well, what you brought up around the vast array of roles and types of folks you have in the organization is really interesting. I want to ask you more about that in a moment, but I want to go back to just the trajectory of this org. You started as nothing and it sounds like the enablement org really started out almost as a special forces operation, accelerate the exit from cloud. Today, I understand the org is just over a third of the overall platform org. So from that early beginning, what really drove the next phase of growth in terms of the org size? I mean, you mentioned just organic inbound requests and other projects coming up, but take us through the decision-making around expanding the headcount in this organization.

Matt: Yeah, I think a lot of it started from, when you refer to decision-making, it started from what’s the value opportunity of having a central team like that. And so it was very clear with the first data center exit project, then we got into the change program with the DevOps project, and another cloud migration. And in order to really drive that engine and see what we could do over these multi-year projects, it became very clear that that’s a function that we needed to build out to support this ongoing. So I think those key milestones and those key projects, as we evolved, each of them had really good focus on the different business value on our journey up the stack essentially in why we very thoughtfully increased the team size for each outcome.

The other thing that has happened during all of this is we’ve not stopped acquiring companies. And so as we do that, this team plays a major part in helping teams adopt the TR way of working. And same we’ve done through the change program in advertising, that we’re moving from a holding company to an operating company and doing the same thing with our new team members that we get there, has been one that’s caused the team to grow as well, just naturally.

Justin: I would say too, I mean, one of the best compliments is when different teams that we work with come back and ask for help on something else, and so it means that hopefully we added value, they found it valuable. It was a collaborative effort where everyone was ending that engagement happy. And then when there’s another thing that an application team is maybe struggling with, maybe it’s because they’re tackling it for the first time or they’ve got resource challenges or it’s a new technology problem that they’re trying to solve, when they come back and ask us for help, “Hey, would you mind helping us with this?” it also brings the organic nature of evolving and shifting what we focus on to align with what we’re being asked to help with and trying to make sure that we’re bringing the right skill sets and people together that have the engineering expertise and the architecture expertise, but also that aptitude to being a friendly and helpful collaborative person, 'cause obviously that excels in enablement. So I think we’ve seen pointed engagements fire up that maybe we weren’t even really planning about, but mostly because our consuming teams were asking for it.

Abi: Matt, when you were describing the journey at several points, you said the value of the org was very clear, but as I talked to a lot of other organizations, the value or even idea of having this type of enablement function is not clear and is not something that often even exists. So I want to ask both of you to say a little bit more about the value of having an enablement more again. Maybe also I would just pose a question, could platform engineering be successful without the enablement function?

Matt: Interesting. I’ll tackle that first one. I think we’ve been really lucky to have really good projects and programs that have clear outcomes that are really aligned organizationally-wide, be a key driver for the funding, for the business outcomes that we’re going after. That’s been a really key part of this whole thing. I think as we go into the future, the question is how do you maintain that? How many DevOps programs can you do? At some point, you’re out of the data centers and in the cloud. What’s the next thing?

And we certainly generically say we’re going to move up the stack and help our developers just be able to focus more and more on our customers and the features that they need, and anything that’s non-differentiated, much like how we talk to cloud providers about them taking non-differentiated efforts and not needing to focus on those from a TR perspective, how can we do that for our developers? That’s our next challenge. And how we’re trying to do that is multifaceted, in one is just something that all of our engineers are maybe not naturally good at, which is marketing. So how do we tell the stories? When we do swing in and help a team out and we are able to provide some value, how do we just say that? And that’s been something that we’ve been really focusing on this year.

If you don’t manage the work, right, we have an intake process and giving the work transparent and in systems so it’s not floating around in emails. That’s a huge part of it, then you can measure velocity and even the lifecycle, cycle time of an actual engagement. And that cycle time may span from an engineer at TR asking for help, to a solutions architect helping figure out the context of the problem, to pulling in a service team to implement a feature in one of our services so that that engineer can use it, to then an enablement and engineering team coming in and helping the developer adopt that capability. So spanning all of that, how do we measure essentially the friction between those different steps? And getting some of the table stakes of that and working in a transparent, pretty agile process is a key point. That will now enable us to tell the story, to measure the right things, to have health metrics versus OKRs that we can track to ultimately show that value.

Justin: Yeah, two points I’d add to that. I think one, so leading and driving technology training at Thomson Reuters sits within enablement. So we’ve created cloud learning pathways, we’ve created DevOps learning pathways. We’ve even launched a FinOps learning pathway this year to help improve financial acumen of our developers and our engineers so they understand the impacts of some of the things that we’re doing, especially with cloud, and really trying to make sure that we’re providing on-point learning and training opportunities with our vendor partners in collaboration with the technology and technology teams at TR so that they’re getting the right training that they’re needing.

And we’re measuring obviously how many people have gone through different pathways, certifications, and things like that. That’s been very helpful. And then I also wanted to say we’re trying to also… What the hell was I going to say now? Hold on. That was a good point. I’m glad you can edit this. Oh, the second point is we’re also trying to keep track of a way to measure how cloud native an application is so that we can help with incremental modernization, because we do have some applications in the cloud that are a hundred percent cloud native.

We have some applications in the cloud that were more of a lift and shift because it was a data center exit play. We have a lot of applications around the journey of lift and shift to cloud native and trying to really help and make sure that we’re there to help the teams on that cloud native journey. And so we’ve got metrics around scoring the cloud nativeness, we’ve got metrics around DORA, as Matt mentioned. We’ve got metrics around service and stability, so meantime to mitigate, meantime to resolve, meantime. So that’s the data set, and then where we can lean in to help, is where the business is identifying priorities. And we do our best, roll up our sleeves and dig in.

Abi: Matt, I want to ask you, you talked about the journey and focus on marketing your work, telling your story. So how do you do that? How do you market your work and successes to help sustain the success of your organization as a whole?

Matt: Yeah. What we found was, in the pockets of success that we had, the stories really resonated with people, so we did a couple different things. As part of the change program, one effort we had was really focused around communication. And we had a tech writer come in and help us tell those stories. And we’ve had a tech writer role for several years that have helped us get our internal intranet presence a little bit more polished, more recently, feature announcements of everything that we roll out and trying to build a model there where a developer at Thomson Reuters just knows. If they’re wondering what capabilities are new, they can come to a single spot and see that. So we focused on that for a while.

What was cool about the change program is we had a really close partnership with our product team where we were telling that story from the product owner’s perspective. And it was a shared published story between product, product engineering, and platform engineering. And so it was less of a focus on, “Hey, look at this cool thing, platform engineering enabled.” It was more about, “Look at this success that we’ve had as a company,” which has really, really been cool.

So that set really good momentum that we’ve really, now that the change program has ended, we’ve tried to keep that as a business as usual process. When we crank out a feature, write it up from a consumer’s perspective. When we enable somebody to do something, let’s celebrate that success and write that down as well and in different ways and in different avenues we can use that. One of the other key successes there is just relationships. So much of what has enabled us to be successful has been the relationship we build and the trust we build with our product engineering counterparts. And so being able to build those relationships, write up the stories, and then share those in all of the different touch points that we have really helps spread the word.

Abi: Well, I think having that tech writer role, which is awesome by the way, I’m impressed, just goes to show how deliberately you’re thinking about how this organization functions. I want to ask you, we touched on this earlier, to share more with listeners about the makeup of your org in terms of the different roles. You’ve mentioned, tech writers, business analysts. Can you give a breakdown of just the makeup and different types of roles and people in your org?

Matt: Absolutely. It’s been a moving and a changing thing over time. As I mentioned before, we started out with just solutions architects and it’s organically changed as we’ve had that next need. And so we grew from solutions architects into architects and engineers for some of the programs I discussed. Then when we had the communications issues and realized that was a priority, that’s when the tech writer came in and we realized that that was a role.

And for a while, that tech writer just reported to a solutions architect and then we realized that, “Oh, this transparent intake process is going to be another, the next priority.” And so that spawned a lot of the BAs that we’ve grown into to help our internal processes change and adopt and modernize. Underlying all of this as well, and this started back shortly after The Cloud Center of Excellence formed in 2016, we did form a technology standards and governance group.

And it’s an interesting organization for it to sit in. You can say, your enablement, “Why are you running technology standards of governance?” And I think reflecting on the last five to seven years, it’s been a great tension where I get to swing in and help people, but also I have this responsibility to help us align to common solutions and optimize. And that natural tension helps me really empathize with people that I’m enforcing standards on, while at the same time trying to drive that overall business benefit.

And I say that, in this roles conversation, that has driven a lot of the BA and process management roles that we’ve needed to fill out to mature that over time. And so it started from a architecture review board, and the governance of what does your architecture look like, and what cloud services are you using, it’s grown into, “Oh, now in order to build a modern application, you actually use different SaaS components to do that, so let’s move into how are we purchasing software at the company for building these things?” and a governance process around that. And then it moves into, “Oh, we’re a company that have been around for quite a while. We have a lot of software already, so software renewals.” Maybe at that time we start looking at what the strategy is.

As we’ve done all that, we’ve realized we put this framework together that a lot of other teams can really plug into. And while we don’t make every decision or anything like that, we have the framework and the ability now as a company to tap into those decisions at the time of renewal or new purchase. So when we need to make shifts, we need to make it transparent, that somebody in the company is the subject matter expert of a particular area. We have that foundation. And so that’s been a huge growth of our, like I said, business process and BA roles. So all of this has come together into what’s been a makeup of certainly largely technical roles, but are more diversified with the tech writers and the BAs.

Abi: Follow up question to that, how exactly does enablement interface with the rest of the platform organization? Are the teams almost cross-functional across these different organizations or do they really operate independently and separately?

Matt: Day-to-day, they operate independently and separately, but I think one of the benefits of being part of the platform engineering organization is just the communication latency is less. Pulling that a little bit from Team Topologies, which really resonated with me, because even though you want to ignore and try and work across the company, which we absolutely do and do well, anytime you can lower that threshold in a thoughtful way, it’s very convenient.

So although we’re separate organizations within platform engineering, there are meeting cadences and just an understanding of roles and responsibilities of who does what are very clear and documented, so my solutions teams know, my enablement team knows who to go to if we’ve encountered a situation where we need to extend the platform to accommodate a business goal. So in that spirit, it feels like one team. And in many cases, there’s so much enablement to do, that we’re two teams as well. And so I don’t know how that’s ended up working out so well, but it just does feel like we’re one team team when we’re able to work like that.

Justin: I think it’s almost an evolution by capability as well. So when you look at the capability model for platform engineering and all of the services and shared components that we provide to the company, some of them are a lot more mature than others. So for those really mature capabilities, we’ve already got the implementation guide, we’ve got reference material. It’s been done 10, 20, 30, a hundred times. It’s pretty easy to enable a new application team or perhaps if there’s an acquisition that we’re integrating, it’s pretty easy because it’s a well-defined runbook.

Also, if you go to the other end of the maturity spectrum, there’s things that we’re trying for the first time or the second time or the third time. And those are usually more heavily enablement-led, where until a pattern is flushed out and there’s something that we think is valuable to the broader enterprise or maybe a service improvement or a new service or a new capability is needed, then that’s that healthy tension, where if Matt’s team is doing the same thing two or three times, hopefully they’re flushing out requirements and identifying commonalities and how we would want to maybe tackle this at scale. If they’re doing the same thing 10, 20, 30, 40 times, then obviously we didn’t do a very good job on our service. So that’s where there is feedback and improvement for the platform team to improve and make their service a little bit more easy to adopt.

And really what we’re trying to do across the gate is promote self-service, but also transform from just providing guidance to implementing engineered solutions. So we don’t want to hear like, “Oh, they did it wrong. We had a nice how-to guide and somebody didn’t follow it correctly.” That’s not a very helpful experience for our consuming team. So what we want to do is implement as much as we can in the underlying platform, where the only thing that’s left is really that value-add that is tailored to a specific product or application. And hopefully we’ve minimized the risk of, quote, unquote, “doing it wrong,” whether that’s setting up a database or multi-region replication or encryption or how to set up RUM or synthetics. We can take that to the next level and have a lot of that stuff out of the gate, but we don’t know exactly what to do without enablement feeding that pipeline.

Abi: One of the things that’s been touched on a few times, or a word I should say that’s come up, is engagements. So I want to ask for you guys to explain more what you mean by an engagement and how does this work? Is your organization like a doctor’s office or teams just book an appointment or is this part of quarterly planning?

Matt: That’s a great question. So we have what essentially becomes a CRM tool to manage what enablement, what the work enablement does, and the core work item there is an engagement. And all it means is it’s a generic placeholder for working on some business value for someone. And so defining it like that allows flexibility. It could be helping a cloud migration lift and shift for one of the programs that we talked about. It could be a cloud native architecture modernization. It could be the DevOps modern tool set engagement to help one of our teams improve one aspect of their DevOps tool set.

It could be any of those things, but essentially it represents a business problem that we’re there to solve. When we talked about communication, helping the solutions architects who often are at the front of the engagement and then helping make the decision, “Ah, is this one where a professional services style engineering effort would help out or is this one that’s going to expand the platform features?” Where they’re making that decision, having this work item to work off of that really has fields that really illustrate, “Hey, what’s the business value? What’s the outcome?” really helps those technologists keep a business mindset too.

And what we’re there to focus on is value for our customers. And we reserve the word customers for Thomson Reuters customers, not the internal consumers of our services.

So if you’ve noticed, consumer means people that use platform engineering capabilities, customer truly means our customer. And by doing that intentionally, it keeps that top of mind for our platform team, which sometimes connecting our work to the value can be quite a challenge, because in an organization our size, there’s a lot going on. And that engineer who’s one to two years in their role may not understand all of the lines of businesses and all the products and what they’re working on this infrastructures code for. They may not really fully understand that, so engagements are just the core of that that help us align business value and keep focused on what we’re doing.

Justin: I would also say we’ve formalized engagements a bit because just being a helpful engineer showing up at some product teams door, it has to be a two-way arrow across enablement and product engineering. And we have to make sure that our desires are in line with their goals and their desires. And so it requires some planning to make sure that the things that we feel are valuable are in alignment with what they’re tackling today and tomorrow.

And if not right now, then maybe, okay, well, we do quarterly planning, so we’ll line something up for a specific month. We need resources from their team, resources from our team. So formalizing that into an engagement really seals the contract of like, “Okay. Well, here’s the scope. Here’s what we’re looking to get out of it. Here’s the timing. Here’s what they need from us, here’s what we need from them.” And it’s been a lot more helpful to formalize that a bit, 'cause otherwise, I think early on we were a bit running around with good ideas, or at least what we thought were good ideas, but perhaps weren’t at the right time for some of the teams we were working with. Then that just makes it very difficult for them to try to do everything that’s already on their plate, plus absorb something else that maybe we are trying to influence.

Abi: And what percentage of these engagements are driven by your organization versus being like an inbound request asking for help?

Matt: That’s a good question. I don’t have a direct percentage for you, but you can imagine when those programs kick up that are essentially run aligning with a strategy that we have, that in those moments we’re largely focused. It’s largely outbound. In between, I would say over the years as we’ve been successful re-communicating that we’re here and we’re there to help and how we’ve marketed ourselves, definitely noticed an uptick in organic requests where people just know, “I’m going to go submit a ticket in the system and get platform engineering to help.”

So we continue to fight that, I’ll say fight that battle. We continue to work on that, on marketing ourselves so people know that they can come, 'cause we find once they realize the help that we can provide, it’s a pretty easy answer. And so that’s a really fun part of my job, is just being able to be there to help to accelerate time to business value, but we’ve wrapped a lot of this in to help increase the number of organic asks. We’ve wrapped this, all of what we’ve talked about with communications and what features next, into the platform as a product project.

So how do we treat our capabilities? As Justin said, we want to move towards engineered capabilities. How do we treat those as an internal product that we essentially have the mindset that we’re selling to our consumers? So actually one of the episodes you had on product ownership really resonated, because we’ve bounced that around a little bit where we’ve had service architects act as a product owner. We’ve had conversations about should enablement have a little bit more of a say as far as what the feedback is and the product owner. And so really that product owner role, we’ve distributed across a number of different people.

Abi: Awesome.

Justin: It’s funny because… Oh, sorry. I was going to say, it’s funny because we started off about a year ago talking about bringing a product mindset to the platform, to the platform engineering team. And I feel like I didn’t do a very good job explaining what the goals were or why we were doing it and confused a lot of people. And so Matt and I were having a lot of side conversations on the value of thinking about platform as a business or thinking about it as a product. And the confusion was like, “Well, platform’s not a product, it’s a platform.”

And so late one night, doing some Googling, that’s how I stumbled across Manuel Pais and his platform as a product pitch. It’s like the light bulbs went on. And so we grabbed that a little bit more formally internal to TR in January and have been focused now in 2023 on platform as a product and really trying to bring that mindset change or that culture change to our platform capabilities so that we actually are thinking about it as that consumer and as a user and what they need to be successful and all of the things associated with that, including the brand, and the marketing, and the engagements, and everything. So it’s really come together serendipitously, I guess, in terms of how we stumbled across that or how I stumbled across that, but it’s been a fantastic push.

Abi: Well, Justin and Matt, it’s been awesome hearing about this journey from cloud migration to now being a product-minded platform engineering and enablement organization. Thanks so much for sharing your story and these insights. I think listeners will get a lot of value out of this. Thanks so much for your time. I really enjoyed this chat.

Matt: Thanks for having us.

Justin: Thanks, Abi. It’s really great having us on.