Episode 70: Polystream’s Cheryl Razzell - From Database Details to DevOps Director

Brian Dawson: So hello. This is Brian Dawson hosting another edition of DevOps Radio live from DevOps World Jenkins World Lisbon, and with me today I have Cheryl Razzell, the director of platform and live ops at Polystream, and you're gonna tell us a bit more about Polystream and your role there in a minute, right?

Cheryl Razzell: I am, yes.

Brian Dawson: Okay. Awesome. You know what? Well, why don't we jump right into that? Cheryl, can you go ahead and tell us a bit about your current role as well as your background?

Cheryl Razzell: Okay. I've been rehearsing this because of the fact that what we do at Polystream is quite niche. So Polystream is trying to invent, reinvent the way that we use the internet for video streaming. Predominantly we're working –

Brian Dawson: You guys aren't ambitious at all.

Cheryl Razzell: No, not at all. We've got great ambition and are led by a great CEO. So our CEO, Bruce Grove, is, used to work for OnLive so has a history of working in the gaming sector, so we're predominantly working with the games industry to look at streaming or video games. So we're looking to move the compute power of GPUs away from your local machine into the cloud. I think one of the things that we do within Polystream, which was one of the reasons I joined, was the platform that we have is also cloud agnostic. So we have a platform that can use the power of the cloud in any region, so the reach and scale of what we have is what's really exciting for us.

Brian Dawson: Oh, interesting. And so I think as we shared leading into this, I have a particular interest in gaming. I spent a number of years in gaming and I do get excited. It's been interesting to see the move to streaming of games and the potential that we unlock when we have the virtually unlimited compute power to drive complex physics, graphics, et cetera.

Cheryl Razzell: Yeah.

Brian Dawson: And so is Polystream primarily focused on compression technology, on efficiently streaming –

Cheryl Razzell: Yes.

Brian Dawson: – and routing the video? Okay.

Cheryl Razzell: That's it. So our kind of magic sauce is our streaming technology that's hosted on the platform, which is where I come into it, to grow that platform to host our streaming technology, allowing us to reach global capacity of large scale for the gaming sector. But, you know, it doesn't have to be just the gaming sector that we work with. There's other areas that you can use for CAD applications that you would have to have a high graphical processor for, you know, large rendering, so you'd have to have a machine with 16 CPU, you know, huge graphic processor. You can do away with that and you'll be using the power of the cloud to power your GPU.

Brian Dawson: Interesting. I can imagine – I don't know if it's your guys on radar, that medical imaging would be another space where you would –

Cheryl Razzell: Absolutely. There's huge amount of industries that we can tap into that really can benefit from the use of Polystream's platform.

Brian Dawson: Okay. That's exciting. Now I'm gonna want to circle back and double click into the role DevOps plays at Polystream in a moment. But before I do, can you tell us a bit about your journey to Polystream? How'd you end up where you are today? How'd you end up being an influential person in the DevOps community overall? So –

Cheryl Razzell: So I started my career back in 2000 and – oh, actually it was 1997. Started working in the Apple call center. Before that, I tried my hand at working as a gym instructor, and I told Sasha this story once, the fact that my brother worked in the call center and it was multiple team, multiple organizations within the call center. So my brother worked for Microsoft, and there was these roles going for Apple.

Brian Dawson: Oh, interesting.

Cheryl Razzell: And I'd never heard of them, to be honest with you, and I was interviewed for kind of the reception route where I'd take the calls and I would redirect them to our engineers that would help you. So if you bought an Apple Mac and you had technical problems, you'd call the technical call center. So it was multiple call centers. This was back in the day when we had gateway and we had ISPs and the internet was just taking off. This is when you went to a supermarket and you got yourself a CD, and you would use the CD to get yourself online with your 56k modem.

Brian Dawson: Yes, I remember. Yeah.

Cheryl Razzell: So this is where technology was when I started back in the day. So I started off as a, what was called a call director, or taking people's details and type them into the database, and then pass them through to an engineer. I got bored of this very quickly, so then I started to try and work out what the problem was and started to try and fix the issue.

Brian Dawson: Before you were out of the call – you were still –

Cheryl Razzell: Yeah.

Brian Dawson: – supposed to just be routing the call, right?

Cheryl Razzell: I was, yeah. So the calls stopped getting through me and stopped getting to the engineers, and one day my boss called me up and said, "Hey, Cheryl, can we just have a quick chat?" I obviously thought the worst. I was in trouble.

Brian Dawson: You're like oh, shoot. Right?

Cheryl Razzell: Yeah. What's gonna happen here? And he's like, "Look, been listening to your calls." I'm like, "I'm sorry. I was curious. I'm a little bit bored. Kind of just want to help people out." "No, no, no, you're really good." So then put me on my training and I became a third line support engineer for Apple, and back in 2000 – 1997. I'm forgetting my age there. So kind of moving forward, I've worked for multiple, I've worked for organizations, starting in traditional IT and IT support and working my way through IT support into kind of project management. And then there was a pivotal turning point where legacy technology was becoming – there was a trend to implement DevOps – sorry. I have to –

Brian Dawson: No, no, no. No worries. No –

Cheryl Razzell: So there was a –

Brian Dawson: A trend to implement – you started on legacy technologies and there was a trend –

Cheryl Razzell: There was, so there was a turning point. And I worked in, I was working for Yammer, which is an enterprise social platform, and when I was working for Yammer I was working in the traditional IT support. We were then acquired by Microsoft. Microsoft came along and they said, "Well, you're gonna become a shadow IT department." We didn't want to become a shadow IT department. We didn't want to be absorbed into the Microsoft IT department, so we decided to reinvent the team and we started looking at engineering. We started looking at data centers. We started to understand how we could support our developers by the use of tools.

So then I created an internal services engineering team, and we turned from traditional IT, from desktop support, to maintaining the data centers and working on technology that could enable our developers. This to me was like huge potential. So how could we support our developer community within the organization through the use of tools? So –

Brian Dawson: Right. And so just to make sure I'm tracking, so you went from – well, first I'm seeing a theme here. You like white space. You like challenges and solving problems.

Cheryl Razzell: Yeah.

Brian Dawson: But to make sure I'm tracking, you guys were basically the customer facing traditional IT support.

Cheryl Razzell: Yep.

Brian Dawson: And as part of the acquisition you guys wanted to maintain or build out some of your own systems within the team.

Cheryl Razzell: Yeah.

Brian Dawson: So you kind of led a pivot. We're gonna move from supporting our customers and we're gonna be an internal sort of what we would call shared services team today. So –

Cheryl Razzell: Yeah, exactly.

Brian Dawson: Okay. Yeah, that's interesting.

Cheryl Razzell: Exactly.

Brian Dawson: Sorry to interrupt.

Cheryl Razzell: No, and it was a way of preserving the team, but also upskilling the team that we had. So the, we started to expand arena. We started to take on more services. We started to develop internal tools that our developers could use. We started looking after things like GitHub and Jira and kind of taking on those internal tools. And then I kind of moved from – we shut down the London office for Yammer, and I decided to stay in the UK rather than relocate with the rest of the team back to Seattle or San Francisco, and then I joined HSBC. So I'd been doing on a smaller scale what I tried to achieve at HSBC, which was taking on the digital platform and building out the support for, again, the developer community within the bank.

Brian Dawson: So this is – okay. You were probably gonna get here, but I can't help but jump back and ask. So how different was trying to do this for – how big was the Yammer team?

Cheryl Razzell: We probably had about 250 engineers. Yeah, about 250 engineers.

Brian Dawson: Okay. Not small, but –

Cheryl Razzell: No, not small.

Brian Dawson: But then how big was the digital platform team under your purview at HSBC?

Cheryl Razzell: So we had around 3,000 developers using our platform.

Brian Dawson: Okay. So significant change.

Cheryl Razzell: Yeah.

Brian Dawson: Does anything jump out right away as differences, lessons learned, differences between trying to implement and support, implement modern development for and support a 250-person team as opposed to a 3,000-person organization?

Cheryl Razzell: Yes.

Brian Dawson: Yeah, so –

Cheryl Razzell: It's around maturity of development. So when I started at HSBC, the digital space for the retail bank is where I sat. It was around 18 months old. We'd gone from a five-person department to –

Brian Dawson: Oh, wow. Okay.

Cheryl Razzell: – 5,000 in a very short period of time. So when you shortcut and you expand at a rapid pace, you find that process barely exists. Documentation barely exists.

Brian Dawson: Okay. Interesting.

Cheryl Razzell: And there's a lot that people – there's a lot of things that you think about as an afterthought. So it's like, well, let's build something. We'll use it as an MVP and we'll push it out there and see if they're gonna use it. My method to working like that is let's build something instantly that has everything you need as a capability to go live in production, whereas when I joined not everything was productionized. We didn't really have a support model, so I had to build out the support model about how do the engineers get in contact with – so how do the developers get in contact with the engineers? When I first started, they would shoot off an email that would go into this deep, dark hole, and they wouldn't understand when they'd get a response and what communication they were gonna have with the engineers.

So we started to bring out, you know, a support model. We started to implement a Jira service desk, created this wraparound for the platform, so the engineers had a way of understanding if the platform was at fault, if there was a problem with the tooling, and then directing that to the right team to be able to help them. So –

Brian Dawson: Now, to make sure I'm tracking, so first to make sure we don't lose it, so one of your first things is, even though it was a large organization, unlike a lot of financial services organizations, because this team was new, instead of you being hindered by legacy processes that you had to overcome –

Cheryl Razzell: We still had those.

Brian Dawson: You still had those. Okay.

Cheryl Razzell: Yeah. No, there were bucketloads.

Brian Dawson: Okay. There were bucketloads of those.

Cheryl Razzell: Yeah. Yeah.

Brian Dawson: But your first order was that absence of processes –

Cheryl Razzell: Yes.

Brian Dawson: – and establishing those. Okay, and then to clarify a couple of things so I'm tracking with the story – don't lose your place. So when you say engineers, you had a team that was responsible for application deployment, your dev tools platforms, or when you say developers requesting support from engineers can you describe more what the team topology was?

Cheryl Razzell: So I started without a team. It was just me. It was just me, and a few months after it was my number two that I had brought with me from Yammer who came to join. When we started we had development tools in place, and then we had a platform which we were hosting our production data, which is our technical platform, which is the platform behind some of the HSBC mobile apps, web apps, you know, kind of. So to set the scene, we had the platform behind that, which was a microservices and API platform what would deliver our customer journeys. So we were supporting the back end to that, but also the platform at the same time.

So we had a lot of legacy process, and we were building something new within the bank, and we were building new ways of working, and we were working with a rapidly growing team which was, you know, hard to maintain. And as teams were growing, and not just in one location but around the globe, it was how do you get these teams to follow a process to engage with the right team, to understand I have a problem. How do I overcome this problem? It could be –

Brian Dawson: Right. How do I do it efficiently or –

Cheryl Razzell: Yeah, how do I build with the pipe plans that we have? How do I push my code to production? What's the policy around the gateways in production to push my code from dev to production? There was lots of things coming left, right, and center. Yeah.

Brian Dawson: Right. That's what I – right, right –

Cheryl Razzell: And at the same time I had to grow a team that would not only support this, so I had a support division of my team, but also to add to that, you know, was a development team for innovation and moving some of our tools into the cloud as well, because we also had problems with scaling out our tools on prem. So –

Brian Dawson: Yeah. So you've added this extra variable of also migrating – okay.

Cheryl Razzell: Yeah. I like to create my own problems, as my husband always tells me. So by building a successful team to support, we started to look at the underlying tools and they were buckling under the amount of development process and development that we were putting them through. So we started to build out new tools. We started to move things like Jenkins into the cloud and hosting them on AWS and allowing us to scale them on demand. And rather than having kind of an army of on-prem Jenkins – which started with one. We built them out to seven. It was then moving that to the cloud so that we could have teams spin up their own Jenkins master –

Brian Dawson: Right, and then so you could move from unconstrained, you're no – move to cattle versus pet approach. Okay.

Cheryl Razzell: Absolutely. Allowing them to take more control over their development environments as well, giving them a little bit more autonomy so they have a safe space where they can do the development, and then managing a different environment for their production, so segregating out our development and production environments. So a lot happened in a very short period of time. I was at the bank for three years and built my global team to run support, which then became in its own right another support function and one of my team, and took that and ran with that as an entire team. And we started to focus on the development, the developer tools, and making enhancements and working with our developers and building new pipelines and platforms to support our developer community.

Brian Dawson: So really you got the big – so we've kind of, we've got a base foundation sort of infrastructure for development tools and delivering support.

Cheryl Razzell: Yeah.

Brian Dawson: We started to modernize it by moving it to the cloud, and then now it sounds like now you're able to shift more to a establishing and propagating or scaling best practices on top of that platform.

Cheryl Razzell: Yes.

Brian Dawson: Is that sort of what that latter phase was?

Cheryl Razzell: Absolutely, yeah.

Brian Dawson: Okay. So, gosh, so many questions. So my pause is I'm trying, okay, can't ask that. Don't have time. Well, let me – and it may not be easy for you to distill it to this end, but so we've established that there's a very different journey than the 250, than the journey at Yammer. Now the journey at Yammer sounds like it set you up well to –

Cheryl Razzell: Yeah, 'cause –

Brian Dawson: Yeah, go ahead. Sorry.

Cheryl Razzell: Yeah, 'cause working at Yammer we were also working with the greater Microsoft team, so I spent a lot of time working with the acquisition team because they were making large acquisitions. So while also there we acquired LinkedIn, and working with the team to really understand from a developer perspective what kind of tools do these organizations use, what kind of makes them unique, and then making sure that as we went through the transition, because when you're acquired by Microsoft there is an expectation that you'll move to the Microsoft stack. It's really understanding requirements for the organization and comparing well, you know, this product might do this. Are we gonna break the organization if we move from one to the other? How do we do that eventual transition?

Brian Dawson: That's an awesome experience. Right.

Cheryl Razzell: So I went through it myself where we had to transition away from some of the open source and technologies we were using and move towards the Microsoft stack. So I led that because I was the director of IT back then. So having had that experience made, you know, the experience valuable for the acquisitions team to work on the larger acquisitions, understanding their technology stack and how they could transition over to the Microsoft stack. So I spent a lot of time working with some of the acquisitions, which I thought was fascinating as well. So that kind of gave me some, a real understanding of development tools, development processes, and life cycles.

Brian Dawson: And an empathetic view. I'd also say some empathy, right?

Cheryl Razzell: Yeah. Yeah, from an end user perspective and somebody who's working in the development community, rather than somebody coming in saying, "You have to use this today" –

Brian Dawson: Looking at bottom line –

Cheryl Razzell: Yeah, exactly.

Brian Dawson: – reducing cost 'cause we have too many tools and have to get –

Cheryl Razzell: Yeah.

Brian Dawson: Yeah.

Cheryl Razzell: Developers like their tools, and you need to make sure that you're sympathetic to those tools to make sure they have a direct comparison and you help them on that journey to move over.

Brian Dawson: Right. Yeah. Well, there's a couple, a bunch of conversations I've had across that I want to correlate this to, but one of them has been, you know, will we ever really be able to move to a state where an organization like HSBC, for example, or Polystream if we look at it now, will be able to get all teams on a single opinionated solution? Right? And I tend to believe, and some of the discussion we've had today is no, 'cause if there's one thing that is constant it's change.

Cheryl Razzell: Yeah.

Brian Dawson: And what we standardize on today may very well be legacy tomorrow, but more importantly, if I tie back to the point that you've made, certain technology stacks, certain teams' goals and objectives dictate that there are purpose-fit tools to help achieve those. And we gotta strike a balance between standardization, between cost reduction, but also, as I've heard you allude to, enable the team to have the tool that will allow them to best do their job.

Cheryl Razzell: Absolutely. I couldn't agree more. I think as everybody looks towards a standardized solution, the goals constantly move in a different direction.

Brian Dawson: Right. Right.

Cheryl Razzell: So you can't come up with one size fits all in any shape or form. But I think that's also what creates a competitive market. You know, some of these technologies aren't going after the same user base. They have very different user cases. So what might fit a large bank is gonna be different for a different type of institute or a different organization.

Brian Dawson: Right. Like they may for Polystream actually have different tool requirements and –

Cheryl Razzell: Absolutely, and I think that keeps them competitive and I think it also creates a market where they can share ideas and, you know, you've seen that in the open source community where an open source product will be used very differently from organization to organization. And I don't think it's healthy that we have one tool for everything. It would be great for that one company that builds that product, but I don't think we're in that position to do that.

Brian Dawson: Where that would be – right.

Cheryl Razzell: But and I think it's really important to have tools that work together so you can use whatever tool you want, but the interoperability of those products is what's key, and how you tie them together to give you your BI, to give you your, you know, your logs and all the information that you want to gather from those tools is available. And that creates yet another market for a log aggregator or a process aggregator of all that information in a singular place.

Brian Dawson: Right, right, right. But yeah, so it's the aggregation, the shared visibility, and as you've heard some discussions here today control and governance across these teams and tools is important, but the path there is not necessarily to say, "Everybody use the same tool."

Cheryl Razzell: Absolutely.

Brian Dawson: So and I can already tell, Cheryl, that we may have to have a beer or something later 'cause there's a bunch of places I can go. So one thing I do want to ask is – so that ties back to my discussions earlier today. So you were dealing with, you stepped into a role, whether it wasn't just, hey, one problem. Look, we have teams with legacy processes and we need to modernize their tool stack and their processes. Right? We have teams with legacy processes, but then we have teams with no processes. We're going at an amazing clip. We need to get to the cloud. We're distributed. You had a myriad of challenges that you needed to tackle, and by all measurements you tackled successfully.

I had two conversations with people that are both wearing the hat of leader of a DevOps team and leader of an engineering group that has three mission critical applications underneath their portfolio, or some combination thereof, but wear multiple hats dealing with multiple layers of complexity, and it's tough.

Cheryl Razzell: Yeah.

Brian Dawson: You appear to have done it successfully. Do you have, in hindsight or maybe you knew then, was there any particular tip or trick or approach that you took that lent itself, I mean that – I'll have to edit this, but that led to your success, that maybe some other people that are dealing with this range of challenges that comes with being a DevOps leader, a dev tools leader driving shared services, are there any tips that you can share with them?

Cheryl Razzell: So kind of interestingly, when I first joined the bank, a bit unsure what my role was and what my agreement was and what I could and could not get involved in. I'm kind of curious as an individual.

Brian Dawson: I've gathered.

Cheryl Razzell: Yeah, and I like to understand how things work, and I like to have some kind of process around things because it's hard to define what you're doing as a team if you don't have a process to follow. It doesn't mean that I'm rigid. I'm flexible, but also just understanding where we fit in the ecosystem. So one of the first things I did when I joined the bank was to go and interview all the stakeholders, and interestingly enough a lot of them said to me, "This is the first time somebody's spoken to us. What are our requirements? What are our deadlines? How do we get involved and how do we build a relationship between the tool and the platform teams, and ultimately our customers, our cross functional teams?" And I found that really interesting that nobody had gone out to kind of interview or understand what their requirements were.

So that piece was imperative to what we did. So gathering requirements, and then I set up a weekly meeting where we would meet with our stakeholders and we would meet with our developers and allow them to feed back to what we were doing. So what's your problems this week? You know, what can we address this week?

Brian Dawson: I love that, yeah.

Cheryl Razzell: And then we were bringing that back, and we put that in our backlog, or we'd redirect that to a team that would be able to better suit their requirements. So it was really kind of getting involved with the community, really understanding what they want, and then feeding that back. Rather than dictating what we think they want, it's turning it on its head and saying, "Well, actually what is it that you need? What is it that you want?" And I've taken a similar approach at Polystream. We're trying to understand what the business requirements are, rather than trying to make technology fit what I think it should be doing.

Brian Dawson: Right. I love that. Right.

Cheryl Razzell: Is actually feeding those requirements in and then pivoting on what we're building.

Brian Dawson: Right. That's very interesting. I want to underscore that, 'cause it aligns with my experience and what I shared. So one way I'd put it is, yes, you were hired 'cause you have a certain level of expertise. You have an opinion, I'm also going to interpret as what you're saying, but your best job, your best approach is not to come in with that opinion and exercise it.

Cheryl Razzell: No. It's to facilitate.

Brian Dawson: It's to facilitate and –

Cheryl Razzell: I think of myself as a facilitator.

Brian Dawson: Yes, I –

Cheryl Razzell: And I come in and I try to work with the teams that, you know, I'm building tools for, I'm supporting, and understand where their pain points are and their requirements. Because it's very easy for me to come in and say, "Well, this is all right, but this is what we're gonna deliver." And then we jump out of a cupboard one day. "Tada. Look what we've built." And they go, "That's not what we wanted. We're not even gonna use it," because engineers will use what they want to use.

Brian Dawson: Yeah. Well –

Cheryl Razzell: And if you build something, who's to say they're gonna use it?

Brian Dawson: And then, you know what, and there's just a natural human – it may actually be what they would have asked for if you spoke to them.

Cheryl Razzell: Yes.

Brian Dawson: But if you just showed up with a solution, they didn't, they haven't been heard.

Cheryl Razzell: Yeah.

Brian Dawson: They're not invested in it. So there's just human nature that you may have come up with the right solution, but they weren't involved and they weren't asked so they push back.

Cheryl Razzell: Absolutely.

Brian Dawson: And I love – and it's kind of, you know, where I think a lot of organizations are shifting, where cloud at least is shifting, is you know at the end of the day developers want to be heard.

Cheryl Razzell: Yes.

Brian Dawson: Right? And I think IT – did you attend the keynote this afternoon?

Cheryl Razzell: Yes.

Brian Dawson: Say this whole idea of software as a core business function I equate to getting IT out of the basement. Stop treating your software organization as a black box that you feed stuff into and you feed stuff out of and you get a team that supports it, but actually hear them, understanding their needs, motivations, and frustrations and help service those and you're gonna be successful. Okay.

Cheryl Razzell: Absolutely. Absolutely.

Brian Dawson: So I want to jump real quick, and I had said earlier that we were gonna talk about DevOps at Polystream. So you were successful at HSBC. You spun this team up. They sound like they're off and sort of functioning, continuing to improve on their own.

Cheryl Razzell: Yeah.

Brian Dawson: And now you've taken on a new challenge, and I assume that part of that new challenge you've taken on is implementation of DevOps, DevOps processes, and modern development practices, or not?

Cheryl Razzell: Yeah. I mean some of that already existed within the organization, because what you get with a startup is that it's greenfield. You're starting from scratch. When you join an organization like HSBC, you're taking on technical debt. You're taking on processes that already exist and technology that you have to kind of interact with, you know, like an old fulfillment system. Classic technology we used to call it.

Brian Dawson: Yeah, classic. We've been using traditional, so we weren't calling it legacy 'cause legacy –

Cheryl Razzell: Nobody wants to be working on legacy. No.

Brian Dawson: I like classic. That's good.

Cheryl Razzell: No. Legacy makes the person working on it feel like we're done already.

Brian Dawson: Yes. Well, yes.

Cheryl Razzell: Classic is, you know, I can tie my skills into something new and I can work on new age technology and –

Brian Dawson: I love it.

Cheryl Razzell: And I've got great experience that's valuable to the organization. So yeah, it's an approach of using classic. And working in a startup it's you get the benefit of it's greenfield, so you don't have the overhead of some of the processes that you would have done in an older organization. So my role at Polystream is we are a Series A startup, that we are looking to progress to a Series B, and we are still kind of understanding what the market is and where we can facilitate the use of our platform and in which industries, so we're still working through that. So what I'm trying to think about is if we were gonna use this platform for, say, 100,000 users or however many users will be using our platform, how are we gonna scale that? How are we gonna also deploy our platform to different parts of the globe? How will you use multi cloud vendors around the world and how are we gonna orchestrate our platform at that kind of scale?

So taking my experience at the bank and kind of bringing that to where I am today, I have a small team of really talented engineers and I'm trying to formulate a platform team that can also build and support the platform at scale. So incorporating kind of your dev and your ops together in your DevOps with a singular team, rather than having to have a separate first-line support, and building in kind of SRE functionality so that we can also recover and also scale and bring in things like login and monitoring alerting with a very small team. But rather than this being an afterthought, which I've seen – knowing my role previously –

Brian Dawson: Right. It's built into the, right, where you've had to bolt it on to whatever –

Cheryl Razzell: Yeah.

Brian Dawson: – existing process was. Now you're building –

Cheryl Razzell: Building the platform of the future today.

Brian Dawson: Right, with the responsiveness to properly support your end user and end customer.

Cheryl Razzell: Yes, absolutely.

Brian Dawson: So has there been – it sounds like, and I may not be hearing this correctly. So you started real early with customer support, traditional IT support. You used that experience to turn it inwards and fortify internal processes –

Cheryl Razzell: Yeah.

Brian Dawson: – and support internal developers, and it's now kind of coming full circle. And you're using your experience in being able to build modern processes, modern teams, to now better support external –

Cheryl Razzell: Well, we will be a B2B platform, so we won't be supporting customers. We'll be supporting other businesses that will be using – we're a deep tech technology platform, so we will be the underpinning platform for, you know, could be from a – could be a gaming store or, you know, wherever we might end up with that customer base.

Brian Dawson: Right. Right. Okay. Awesome. Well, as I've said before, and I guess this is always the case, I find this stuff fascinating. I could actually continue to talk to you for another hour, but I know I can't. We both have things to do. A couple of questions I'd like to ask as we wrap up. One is I always like to have our guest share key and influential readings or books with our listeners. So I'd like to ask you if there were one to a few books that you think our listeners that are following a journey similar to yours absolutely must read, what would those be?

Cheryl Razzell: Well, it steals James' thunder. So James already mentioned the Accelerate book, which was actually gifted to me by CloudBees and I absolutely love the book.

Brian Dawson: Awesome.

Cheryl Razzell: There is also The Phoenix Project, which gives you a great insight to DevOps at scale and some of the issues that you'll come across when you're trying to scale out at speed, followed on by The Unicorn Project, also by the same author. So and then also one book I particularly really like, which is It's a Good Time to Be a Girl, which is talking about women in technology and –

Brian Dawson: Awesome.

Cheryl Razzell: – the role of women in technology, and it really shows the strengths of women and how we can empower each other –

Brian Dawson: That's awesome.

Cheryl Razzell: – to support each other in taking a step into a technology role.

Brian Dawson: That's a new one. I had not heard that. I'm gonna add that to my list. My daughter is a CS major and –

Cheryl Razzell: Oh, wow.

Brian Dawson: Yeah, and I'd like –

Cheryl Razzell: Oh, get her the book. Yeah, get her the book for Christmas. She will love it.

Brian Dawson: We just got her Christmas present. Okay, awesome.

Cheryl Razzell: Yeah, she will absolutely love it. Christmas tree present, fantastic, and she'll really enjoy it. It's a really good read.

Brian Dawson: Awesome. Well, thank you for sharing that. Any other final thoughts, tips, lessons for our listeners before we wrap it up?

Cheryl Razzell: Always think about your customer when you're building something.

Brian Dawson: Love it.

Cheryl Razzell: Because that is so easily overlooked, and when people build things they always think about the features and functionalities they would like to see, but genuinely don't engage with their customers.

Brian Dawson: Yeah, I love it. Thank you for that. All right. Well, thank you, Cheryl. I appreciate your time. Hopefully you enjoy the rest of the DevOps World Jenkins World show here, and hopefully we'll be able to get you back on a podcast in the future so we can take another chunk at the hours of discussion that I think we should have. Thank you, everybody, for listening. We'll be signing off, and we'll see you on our next episode.