Bridging Tech and Human Factors in Platform Engineering with Morteza Irdmousa

You're listening to the Platform Engineering Podcast, your expert guide to the fascinating world of platform engineering.

Each episode brings you in depth interviews with industry experts and professionals who break down the intricacies of platform architecture, cloud operations and DevOps practices.

From tool reviews to valuable lessons from real world projects, to insights about the best approaches and strategies, you can count on this show to provide you with expert knowledge that will truly elevate your own journey in the world of platform engineering.

Thanks for tuning into this episode of the Platform Engineering Podcast. I'm Corey O'Daniel, and today I have with me Morteza Irdmousa. Morteza is the head of platform engineering at Curative and previously worked as a director of engineering at Raytheon, where he focused on platform in the defense space. He has deep experience in ML ops, data platforms, and traditional platform teams.

Thanks for joining us today.

Thank you for having me. It's a pleasure to be here. It's going to be exciting conversations today. Happy to be here.

Tell me a little bit about your background. How did you get into platform engineering? Was your first kind of taste and experience of that at Raytheon, or were you seeing platform engineering teams kind of being built up?

I've been kind of all over with my background. I've been involved in software. I've been involved in infrastructure, the traditional sense, building data centers out. And then more recently, more involved with the platform space and the development of that and how we've come from DevOps to Platform and the journey there. Just understanding the cultural aspects of these changes with organizations, whether bigger organizations or smaller. So it's been an interesting journey and I'm happy to share more on that.

Yeah. So it sounds like you have a lot of really interesting things going on. So it seems like your background has been fairly like high compliance, high security, like between defense and healthcare and legal. So I'd love to actually dive into that a bit.

But you hit a really important one for me at the same time there, like talking about like the cultural aspect of DevOps and Platform Engineering, which I think is also (A) extremely important and (B) one of the things that stops many teams from getting to good DevOps. Maybe we can just start there and kind of weave compliance and security into the conversation.

I would love to know what is maybe one of the more challenging aspects you've seen of rolling out good DevOps or Platform culture, maybe at Curative or at a previous organization.

Yeah, I'll talk about Curative a little bit. I've been at Curative for about a year and a half now. It'll be two years towards the end of this year. And it's been an interesting journey. I joined the team, and we've grown massively since the beginning.

And the journey of establishing a platform team, understanding what that means and then working with the software engineering teams and gathering their needs and really building out that product aspect of what we do.

And really driving some of the cultural aspect of what that really means for different teams from our quality and assurance team and compliance team. Security, obviously, a huge aspect of that and how that plug plugs into our platform team. Where do the lines get drawn with the domains and where the ownerships end and where they begin?

So those are some of the aspects that have been kind of interesting going from the DevOps, the traditional DevOps, to more of a platform.

And the way I look at that is actually kind of interesting because we have to go back before that, when we had Dev and Ops completely separated out. You had the development teams and the operations teams. And this is 20 years ago, a lot of DOD defense contractors operated this way. And then the idea of DevOps obviously had taken on in the commercial space a lot.

And a lot of the government aspect of it was more of we want more speed, we want more agility, we want more capabilities. Faster turnaround times with capabilities and features. So it was interesting to see that happen, but then there are some things that weren't necessarily working with that either.

Especially working with various agencies. Like I've worked with DOD, defense side, air force and others. I've been involved in some conversations around Navy. That's been interesting. They're trying to establish a same thing platform. If you're familiar with Kessel Run and Platform One, those were some of the programs we really worked with closely. Some of the bigger programs that had ever deployed in the cloud had gone through that. It's very interesting because FAA is also looking at this in a different way as well and kind of going through the same challenges. They're just at different times.

So DoD did this 15 years ago. They started looking at some of the aspects of DevOps is great, but then if you have the development teams also operating, where do the lines get drawn? And in the world of federal acquisition, it's different. Everything is incentivized around... It's not around how fast you can move and it's not around efficiency necessarily, by design. And so when we go to the model of platform, it kind of gives them that centralized way of operating a platform where a lot of these programs can put in their pieces of software. That fits in well.

But the problem is if you're not careful, you're separating the Dev and Ops again. And that's not what platform is about in my mind. In my mind platform is about keeping that DevOps methodology in place. So the connectedness of the development teams and the platform infrastructure, traditional infrastructure, has to still be there. But it's really about horizontally integrating various tools so that the development teams can more easily self-service and reduce their cognitive load from the perspective of development and not have to worry about and reinvent the operations aspect from scratch.

That's what the problem was with DevOps, from the perspective of, I think, the defense industry. And it's funny because FAA is going through the exact same thing. I'm having conversations around some of those challenges. And they're trying to come up with their own platform system. I believe it's called AES.

One of the challenges they're going to have is the idea of how they structure their systems around how some of the contracts are set up to connect and use this platform. And how do they budget that? And how do they resource that? So those are some of the challenging parts on that end.

So it's very interesting to see, to go back to your question, that we went from Dev and Ops to DevOps, and then we're kind of moving towards the platform. But it gets kind of interesting because people have different understandings of that. And everybody is kind of doing it differently, which is understandable. But then there are some fundamental things that have to be kept in check. Otherwise you defeat the purpose of this whole thing.

I agree. As an industry, I think we kind of failed at that part with DevOps, right? Realizing that people are going to implement it differently, but having that same definition of what it is was key to really making that successful.

And I feel like we're kind of ending up in almost that same place in the Platform space as well. Obviously, people are going to implement it in different teams, different orgs, but having that foundation of those principles in place and having an actual definition of what it is that everybody can kind of understand, I feel, is a place for opportunity for people that are talking about Platform Engineering and trying to get it adopted in orgs that we didn't really nail with DevOps? Everybody is kind of like, “Is it a team? Is it two teams working together? Like, is it Platform Engineering?” Like, it got real like hand wavy.

How do we avoid that? In what you've seen so far, how do you really get a team behind the idea of Platform Engineering? Start to move forward with it without making it feel like just a rebranding of DevOps or rebranding of people's titles?

It's great that you asked that because, in Curative, it's actually one of the things we're working on, and it's not instant. So the idea of we're now going to call DevOps Platform and move on with our lives and now everything is going to be great. It just doesn't work.

It really is about working with your peers. From a leadership perspective, it's really understanding who your partners are, which pretty much is a lot of internal teams, from a Platform perspective. And understanding the true business problems that you're trying to solve.

And then understanding the needs of your engineering teams and how that fits in with the challenges that you have. In our space, healthcare, from a security perspective, there's a lot of challenges in how we want to produce quickly, but then at the same time, there's a lot of things that are related to HIPAA compliance and PHI and how do you protect that? And then how do you standardize across that, while maintaining the speed and velocity of your teams?

So I think keeping those in mind and making the mission of the team clear, that these are some of the challenges we're trying to solve and how we want to get from point A to point B from a metrics perspective. For example, you can use DORA metrics or any metrics that make sense in your realm of operation. So for us, it could be anything to do with velocity with DORA metrics and then also some of the other aspects, like how fast are we deploying abstraction layers that we can build on top of that then can quickly let us put something out there that's useful for our members. So that also kind of plays into it.

So I think depending on your industry, but also from an engineering perspective, you can kind of combine those metrics and understand. And then from there, it's really just driving the message with the team and then with your partners and then with leadership. Really working closely, understanding the problem space and reducing that friction. Really what it comes down to for me from a Platform perspective, that's a lot of the work there.

I loved a couple of things you said there. KPI is door metrics. That one's, I wouldn't say it's a given, but like we know that we should be tracking stuff. But when you said mission and messaging, I feel like that is the key. Especially with this idea of like Platform as products.

In many DevOps organizations and in many Platform teams that I've met that are struggling to move this forward, I think that those soft skills, for lack of a better word… the things that aren't quite engineering, right? Maybe that's your product manager, maybe that's the product owner… but thinking of that like a business, I think is some of the best ways to push it forward. But also make it easier for our non-engineering partners to kind of understand what's going on.

Like hearing this messaging of how it's going to affect the teams, like actually seeing numbers change, and then having a mission. Like the way you describe it, you just described the startup within an org. And I feel like that, when you see a company that's doing it really well versus, you know, the team that's like, “Hey, we get to rebuild Heroku.” and they just run down like technology row, grabbing stuff off the shelf. That's the difference, when you have that, not just like thinking of it as a product, but thinking of it as its own independent business that has to build up a customer base and get people excited.

I think the mission and the messaging are two things that we really do miss when we talk about Platform Engineering.

Yeah, absolutely. One other thing I would add is that I think part of how you implement this is really dependent on where you are.

I've attended many presentations around how a platform has been implemented in different organizations, in AWS re:Invents, from BMW to Autodesk to like massive companies, how they've implemented it. It's interesting to see because there's no blueprint out there.

I think you have to put in the time to understand what the mission space is and what problems you're trying to solve and go from there. I think there are a couple of things that are central and important to include, like the centralization of data. And democratizing data and analytics is a massive aspect in my mind of a platform realm, as well as reducing cognitive load for developers and all of the tooling that you provide. Whether that's internal development platform software or other scripting and scaffolding that you can do to kind of make that easier for developers. Those are all within the realm, but I think it's important to remember that it's different. So it will be implemented differently from one place to the other.

Yeah. You can't necessarily just like grab a recipe and even products in the space, right? There's a ton of products out there from IDPS to portals to platforms to infrastructure portals…there's so many things out there and that's because we have so many tools. Like you don't need them all, and one of them might not even be the end all for your team. Like it really comes down to what that team needs to do and how they got to where they are today and where they need to go tomorrow.

I think taking all that into account that you're not going to necessarily buy a silver bullet or build one. I think it’s one of those other things that can keep morale high, right? Cause when you're building something and you feel like, “My God, we got to get every single thing that all of our engineers do into this platform.” That is hard. But saying we've covered some KPIs, like 80 % of the team is very happy, and there's 20 % of the team that maybe aren't using it and that's fine.

If we can build this efficiency and 80% of the team, that's great. That's a big yield for the business. And we can figure out how to see where the rest of the team is and bring it in later. We don't necessarily have to like get it done out of the gate.

Something you said earlier was pretty interesting. Where do you draw that line between the platform team and the team that's building the product that makes the money at the end of the day.

That is hard. I feel like anywhere from old school Ops/Dev to DevOps to now, that line has always been hard. Just like, where does operations stop and my software begin? But I think it's particularly difficult in security and compliance.

I love that you have that deep experience there. One thing I'd be really curious about, particularly at a healthcare company, is where do you draw the security and compliance line? Because I feel like you can build a lot into a platform, but at the same time, does it serve your engineers well to pull that security and compliance knowledge away from them? Or is it a boon, where they don't have to think about it and maybe it's built into the platform?

I'd love to hear some of the challenges you guys have faced there and how you think about security and compliance at the platform level.

It's one of the levers you can actually use when you're trying to bring in the Platform ideology to your organization, because one of the strongest partners you're going to have is your security team. That's because simply, with DevOps, it's very difficult when teams are moving at a speed of “it's hard to keep up”, security teams aren't necessarily up to speed with staffing to keep up with that. And so from a resource perspective, it's very, very difficult to stay on top of things.

At that point, you kind of rely on your software teams to build things the right way, which is great. But also sometimes you're going to miss things. So I think that's a big lever to have and to partner with your security team. However, I don't think you can fully abstract that away. I think there are still aspects of operations that you cannot abstract away from developers, and there are aspects of security that can't be abstracted away.

We can definitely enable the engineering teams to perform a lot of functions that are repetitive and unnecessary and prone to error. But we can't have the idea of, especially in healthcare, the idea of developers will not have to worry about this aspect at all and everything from a Platform perspective will be handled. So I think that the line is very important there.

I don't think it'll ever be as clear as this is where the responsibilities begin and this is where it ends, I think it's a collaboration. And one of pet peeves that I have is the line between development teams, the product teams—different frameworks call them differently—stream aligned teams, pods, product teams… Those teams need to have a tightly integrated staffing that work with Platform teams. However you implement that is different from company to company, and it's irrelevant, but that tight integration needs to be there. Because it's dangerous to get to the idea of Platform is just going to handle all of the Platform work and the developers are just going to be able to use these abstraction layers because now you've walked into this realm of Ops versus Dev. And so you've done the same thing we were trying to get away from.

And I think that tight integration of development teams and product teams, stream aligned teams, is to make sure that tight integration is there. That kind of is important in the flexibility of your Platform. I think it's important to recognize that those lines are never going to be super clear but that you have to work together to kind of close those gaps. It's not a comfortable answer, unfortunately, but I think the reality is I think there's always going to be some level of integration.

Yeah, there's always like a bit of trying to figure out with these teams, like where do they each end? And it's going to vary, right? And like, that's fine.

You're finding the edges of your platform and you can maybe let some people go out into the range and then bring them back in, right? Like, okay, what did we learn from this experiment? We maybe did something different, right? Maybe we put the security more on the developer side, see how they're implementing that and then bring that back into the platform. That's a great way to find new functionality to build, especially if you start to see like a common case developing amongst a few different teams.

With the security engineers, like, it's really funny. I feel like there's a ton of software developers, we’ve got software developers everywhere. When you start like digging into teams like you see that operations engineers, cloud engineers, there's like a much smaller footprint of like the software developers, and then it feels like the security people are even just like a smaller portion of like the operations book.

When bringing in a security—maybe it's your first security hire or maybe it's the first time you've brought in a security person to work on your platform team—what is a way that you can get the biggest impact out of an extremely limited security staff in your Platform? Like where are some areas that you can kind of have them start to focus on or leverage first to get the biggest bang for your buck?

I think the main tooling that they can start to focus on is actually like some of the procedural things. So, the way your product moves and the process that your product team works to bring in requirements. How do you build in like non-functional requirements from a security perspective? And then how do you make those requirements something that can be bought in by the overall leadership team. The product leadership team has to abide by those and say pretty much this product cannot be launched without, for example, even if it's an internal service, it still has to work over SSL. Whatever the scenarios are.

But I think to make your first hire from a security perspective, the most relevant, I think the first thing is the procedure on process stuff and working with the various teams like the product team, the platform team, and the engineering teams. But also one of the main areas that they can focus on is probably the CI/CD pipelines and understanding where the scans happen and where it's most impactful to put gates in place, and manual checks when needed—which we really try to stay away from as much as possible.

I think those are some of the main areas to start with. But again, I think security teams are also implemented differently from organization to organization. In some organizations, the engineering team is very much integrated with the security team. In some organizations they're very separated, they even operate at a different cultural level. And I mean, in some organizations you have CIOs and CTOs. So they're completely in different organizations, right? So I think it depends on where you are and how your organization is structured as well.

Yeah, it seems like a difficult yet important one is to figure out like how to get them involved early. Because again, it is usually a smaller set of like staffing resources that you have and finding that place where you can get them involved early is I think one of those places where you really see the potential in Platform Engineering, right? To be able to see that I can take maybe a security team of one or two, but make it feel like we have 20 because they're able to do so much more through their work on the platform.

You know, it's really funny, I feel like we use the 10x term as a joke in the industry, but like Platform engineers really do have that potential to be a 10x engineer. Like their work can really be a force multiplier. And I think when we approach it that way, like getting people involved early enough, even adjacent teams like security, that's where you really start to see that yield. So long as you're messaging it correctly and you can get people to buy into it, especially if they're in the CIO org and you have to cross organizational streams.

I'd love to shift gears a bit, because I do know that you have experience in ML Ops and data platforms. I'd love to talk a bit about AI on both sides. How can AI products get benefits from Platform Engineering? But also, how can Platform engineers and Data engineers incorporate AI into their platforms? What are currently seeing your teams being excited about with AI as far as Platform goes?

I mean, obviously there's a lot of noise around AI, right? And I feel as though some of the Platform excitement around this industry is around AI. And so a lot of companies are moving towards a Platform team so they can centralize their data properly and have a data platform that they can tap into for data analytics and machine learning to do business decisions and so on. So I think it's an important aspect of Platform and how Platform plays into it.

We are seeing a lot of excitement around right now, around engineering aspects of AI. FAA is interested a lot about how AI can play into like traffic management. I had a conversation with one of their engineers recently, you have like 20-30 different companies building different aspects of your traffic management systems. And so if you think about these, these are product teams, but they're like different companies. How do you bring all of that data into a space where it can be used for analytics so that we can understand how, for example, a weather cell can affect traffic around that airport that gets 20,000 landings a day or whatever it is.

I think that's the power of data platform, data engineering, and orchestrating how data gets from different domains into one massive data lake so that you can draw analytics, you can do machine learning. So that aspect of it obviously falls a lot on the data teams generally. But I think the data engineering and orchestrating how data gets from one domain to the other—especially when you have these compartments of data that you have to pull from—you start to think about architectural decisions you've made like, do we need to go towards more of an event-driven design? Do we need to go more towards domain-driven design from a holistic view?

We're talking macro level for FAA. Let's talk about a little bit of smaller areas with Curative. You have these data points from different companies and you want to use this data effectively to make good business decisions. How do you make sure that your data platform is pulling all of the data at the right time, making sure that it's clean, and making sure that we are making the right decisions.

The MLOps aspect of it comes in when we talk about, well, if you have this great ML model that we want to push out, but how do we iterate on it just like a piece of software? Of course, the difference is, with machine learning models it's not a piece of code you put in production and it stays the same. It's constantly changing because the model is continually evolving based on the data you feed it. How do you make sure whatever change you do to your parameters actually makes a positive impact at the end? So the whole DevOps cycle applies to ML, but with different tooling.

I feel as though that's eventually going to be part of this cloud of Platform because I think it's so central to how businesses are going to make decisions in the long term.

Yeah, that's kind of interesting too when you start talking about data in the platform, right? Because pre-AI you would kind of think of the platform as a place where your application ran. The platform gives you some sort of definition for how you interact with it, your app's running, maybe you request some cloud resources, you're good to go. You go do your thing. But now, your data is actually feeding back into the platform in which you and other services can kind of tap into just different insights.

When going about that, like starting to put data back into the platform, do you see teams kind of doing that through a very platformesque way? Like there's a definition of maybe, this is how you feed data back into the platform and access it. Or do you kind of see teams leaning back maybe towards that like operations style where it's we'll stream it out of change data capture, we'll attach to a first stage data bucket and we'll map reduce some stuff out of it. Are people building primitives on top of their platforms to ingest and provide analytics or are you seeing it more of an old school approach on that side of the Platform?

The way Platform is structured in my mind, you have your data platform at the very bottom of the layer of how you want to build things off of. And then you have your data orchestration layer. And then you have your development platform layer. And all of this obviously lives in the cloud or in some cases it has to be data center… most of the time, this is on a cloud-based operations. And then you have your product teams, your data analyst team, data sciences teams, all kind of consumers of these layers. And then obviously, some of the business and operations side of your organization also end up being in this place where you can provide Looker dashboards, provide Mixpanel dashboards, and you can help them learn how to quickly get feedback from something they've done.

Let's say we talk about, for example, a communications platform that anybody within the organization can use to include the engineering. So let's say we need to have a campaign to send out 20,000 SMS messages because XYZ is happening, or these dates, or it's been 30 days since X has happened. So there's a lot of like complexity that comes with that. And if we can abstract that away in a way that it relies on the data that sits at the bottom of this layer and that data can very consistently provide some of the analytics that we need to run some of these jobs . That can be a really powerful thing that a lot of organizations don't have access to.

I'd like to mention that a lot of the time Platform teams are associated with cost centers and they're seen as a way to reduce costs and so on. But in my mind, actually that's secondary to being able to bring value, from a business perspective, very, very quickly. And if you can build a Platform and abstraction layer so that you can, within a span of two months, deliver a product that your competitors have no chance of deploying in a year, you're ahead of the game. So I think that's an investment that needs to be realized and made from a business perspective so that you can pretty much use that to your advantage on multiple fronts.

Yeah, I love that kind of focus on the business value that you can create. Again, very startup vibes there. It's like, I can save you time, I can save you some money, or I can make you some money. That's a very interesting way to think about and get teams excited about it, because that's the same thing that people get excited about when they're buying products. Like, I can actually make more money off this. It's not going to make it faster... I mean, if it makes it faster, great. But the fact that we can actually launch more business with this is what's going to get people excited about it.

There's the AI side, but I know one of the other areas that you're very passionate about in Platform Engineering is the human side. We talked offline about psychological safety and the human aspect of platform engineering. I'd love to learn a little bit more about that and why you think it's crucial for Platform teams.

I mentioned earlier about the cultural aspects and how different organizations are going to be different. I think what's important is that at the end of the day, you lose as a business if you do not provide a human platform where people can voice their concerns and if they see something wrong. Not necessarily just from an integrity perspective, but more of like, if we do this three months down the line it's going to cost us XYZ. If people don't have that platform to voice their concerns, especially from an engineering perspective, you're really leaving a lot on the table.

The important thing is to understand that from a people analytics perspective and giving people the space to be able to voice these concerns. There's multiple products out there from an engineering perspective, like you can look at DX, you can look at various products that can do this kind of level of analytics. Where you're constantly checking in with the various engineering teams to see where they're at with multiple different aspects, whether it's your technology platform or whether it's collaboration or psychological safety.

I think it's important to have that kind of pulse from within your org to make good decisions on, are we ready to do this path or is it too early? Maybe we need to do X, Y, Z before we do that. So it kind of gives you that strategic direction of whether we're ready to move towards a matrix structure from an organization perspective or no, maybe it's a little too early, we need to think about first launching product B and C before we can actually do a matrix structure within that organization.

I think it's a really important aspect and it also creates a lot of a lot of movement around motivation, and so people will generally be excited to move the needle. It's not necessarily like trying to extract the most out of the engineers you have, but you're providing an environment where they will provide the best they can.

I think it's really important and a lot of the time, unfortunately, it's missed because sometimes you have people that really are focused on execution and not really strategic in the sense of, is what I'm doing in this meeting working? How do I make sure that it is? Is something missing? What are my blind spots? And those things are where surveys and poll surveys and domain specific surveys can help you really achieve it.

So what are some strategies that teams can use to kind of foster psychological safety? It almost sounds like a place that you can like put things. And what I mean by that is like, if I have this place to kind of like voice concerns about like where the businesses are going or where something might bite me. Like I feel like DevOps people see that a lot and the places that they can voice it today is in a Slack channel or like in an email. And it's very easy for that just to get lost amongst all the other noise.

So I would love to learn like, is this a way that people are using tools in this space? And what strategies or practices can we use to kind of roll this out with Platform Engineering teams?

I think there are interesting things that are happening now, and there are things that are coming out as we speak.

We used DX survey for a while. We kind of got off of it, and we got back on it. There's been a massive difference in what they've brought. But generally speaking, it doesn't matter what the tooling is. I think it's important to try to obviously provide a platform where people can voice their concerns. Of course, Slack is great. You can bring things up. Those are all important.

Radical Candor, I don't know if you've read the book, but it's a great way to promote just calling things out as they are rather than trying to be careful not to hurt someone, but also come from an area of empathy.

This is not about competition. But it's important to realize that like while your messaging might be that, sometimes the way you structure things around how you do promotions, how you do your reviews and peer reviews kind of plays into how the end product is. So things like surveys give you a tool around, Am I doing the right things? Is the intended outcome of what I'm doing here actually the intended outcome or is it actually causing some other problem? And I think that's where some of the value is.

Some of the strategies you can implement are definitely doing surveys and then, if you're big enough as an organization, investing in people and analytics is worth it. Because if you can understand that—and this is a big topic in our industry is—are meetings useful? Are all of them useful? But then, if you cut back on meetings, are we collaborating enough? So like all those things, they're not easy problems to solve. And I think without true data and understanding correlation of, is a meeting of four better than a meeting of two? Like objectively speaking. Or, is it about the context around the topic? Does it require multiple people? And do we sometimes tend to include people just because we feel like they would feel excluded because we haven't invited them? So these kinds of things, like we kind of do guesswork around.

I feel like we could do better than that and if you have a good data analytics team, it's worth to spend in people analytics. Because you already have—if you're using Google Workspace, if you're using Microsoft Office 365, I don't know what they call it now—But if you're using any of these products that already give you a bunch of data that you can use, you have Slack, you have whatever you use for documentation, Notion, or you have all these platforms that are digital and you can get a bunch of information. And if you can correlate the data and combine it with your surveys, you can get a lot of value. And what that does is, you invest in a small team of people in analytics, their job is to make sure everybody is as efficient as they can be, but they're also as happy as they can be.

I can't think of a reason not to invest in something like that. I guess it all depends on the size of the organization at the end of the day, but I think that's something that you have to consider at some point.

And that can be a real miss too. I've seen some very efficient people, people that do great work often be unhappy, and possibly even the most unhappy. I mean, I feel like you see this really surface in people that are workaholics. They will absolutely crush it and they will burn themselves out.

Seeing somebody get burned out always sucks, but like, seeing someone get burned out and losing that person from your team, that also sucks. But when it's an Ops person or a Platform engineer or a Security engineer or a Data engineer, one of these people that are crucial to the business—and maybe the business doesn't realize it until they're gone—Like that's a hard place to come back from.

There's the knowledge that they have, there's lore that they probably didn't get out there. Even if you're doing great knowledge management, like there's some stuff in their head, right, that they're keeping track of. There's the relationships that they've built. And then there's just that velocity that they had.

And I feel like if you can catch that earlier, you can probably get that person to lower their output, get them to be happier. And you'll still probably see a great yield out of it. Like you'll see them doing good work still, even if they're not as efficient as they were. But being happy in the workplace is extremely important.

And I feel like we actually fail as an industry at that. We don’t have the tenure that some other jobs do. I have friends who are like, I've worked at my company for like six or seven years. They're not software developers. Like everybody I know who is a software developer is like, two years and four months. And it's just like, how is it two years and four months? Like this is our hobby. This is what we do outside of work. We love this, right? And it's like, yeah, I don't love it eight to five. And that sucks!

Like the people that you have, you really do have people on your team that love what they do. And then like, you just see them get exhausted after a few years. And I feel like you're right, I feel like we don't spend enough time on that.

And what I'd love to know is, at the same time while we don't, it's also one of those things that, it's probably like a very specific type of engineer. Maybe this is just like gray beard. We'd be like, oh that's woo woo bullshit. But it's not.

You know, I've seen so many people do that. You give them a survey and they're like, yeah, blah, blah, blah, blah. And they finish it like one second after you send it out. Like, how do you roll that out to a team that may historically have some skepticism on it, especially if you have teammates that are potentially close to that burnout point?

There are two things I wanted to mention.

So one is about the question. I think most of the time the reason why that happens is because engagement is not there. So there are companies that will do the surveys and nothing happens. So let's say you do a survey for developers and they're saying that wait time for deployment is ridiculously high, the flakiness of tests is incredibly high, and we need to tackle this. And leadership does nothing about it. Of course, people lose trust, right? And it can't be easily fixed either. So once that engagement is gone, to rebuild that is going to take some time.

So a lot of the time, that's the reason, they've either been part of organizations that haven't cared or the same organization they're in didn't care about their input. This is kind of where I was saying the psychological safety is huge, so that your opinion does count and that people are listening. So I think that's one major way—to actually engage with those surveys and understand them and do something about it. And make sure it's publicly available, transparency is a huge aspect of it to make sure that people know how this is being used and what decisions are being made. Just those areas that are pretty obvious but a lot of the time are missed.

And I think one thing that you mentioned also that was interesting was the under appreciation of some of these jobs, right? It's interesting to kind of note that, a lot of the time, Data engineering, Platform engineering, Infrastructure engineering, System Architecture—those types of engineers, they don't necessarily get the recognition. In most organizations, they don't get the recognition that product aligned or stream aligned teams do because what they put out is in front of the customer and they're getting direct business value. They can put our eyes directly on it.

This is where, I think as leaders, our job is to make sure that translation happens. And so I think regardless, it's one of the most underappreciated industries within engineering teams, generally speaking. I mean, security is even more so, unfortunately, but it's interesting because like I said, these teams can make or break an engineering team.

If you have a bad infrastructure, platform, security, data engineering team, they can really slow you down. I use this phrase a lot, if you have the best locomotive in the world and the rail system you have to deliver products on is crap, then it doesn't matter how fast your locomotive can go. If it's going nowhere or if it has to do 10 circles before it gets to its destinations, then you haven't delivered anything great.

I had to go back on the unappreciation part of it because it's an interesting aspect because it's always fun to have those kinds of conversations with your partners and leadership.

Yeah, I feel like if there was like a volume control or like a playback control for Operations engineers, there's only three tickers on it—you're a 1x engineer, a 10x engineer or a one tenth. And that's the team that just slows you down, right? It's like they've loaded everything up with policies, no automation. Okay, like everything's really secure and it's really compliant. Like, we really do things by the book. But we're writing a book every time we deploy. And then there's, “I don't even think about it. My software's out there.”

I feel like some of that responsibility is on us as Ops people to figure out like how we can become that force multiplier, but also it is on management too. Like it can be a thankless job for sure. It can be tiring to try to constantly prove your value.

Like I remember one time, I worked for a video streaming platform in two thousand and eight and our CEO asked me one day, he's like, I don't understand what you do here. I didn't have this like perfect point back then, but it's like, “You know how it's two thousand and eight and the video streaming site is up? That's me.” But like, I wasn't working on features, so he never really got what I did. And it's very hard to communicate that value and it can be exhausting to do it as an Operations engineer.

So I think that's one of the important jobs of management in the DevOps/Platform Engineering space is making sure that the business understands the impact of what those teams are doing. And like some real numbers, let's go back to those metrics, do a report, KPI, like that makes sense to the business, right? Because when you're talking about like how the test suite's all flaky and it's breaking all the time and CI takes 30 minutes… If you tell like the business, like, “Hey, this team came in, it was 30 minutes for an average build. It's down to five.” They're like, “Okay, what does that mean? I'm an SDR. I have no idea what that means.”

But when you start to spell it out and how it impacts the business and you map it back to that real value, I think that's where people are like, “Oh, this team is important.” It's not that we cut the build time by 25 minutes, it's that we're releasing six times more builds a month. And thinking about that problem, that data a little bit backwards, making sure it's in a way that you can package it up and serve it to somebody outside the org, I think that's some place where management can really, really excel as to how they're talking about the value that their team is bringing.

Look, I know we're close to time. I want to be respectful of your time here. I really appreciate you coming on the show. I would love to know, where can listeners find your work? Where can they reach out to you? What's the best way to find you online?

Honestly, I really just have LinkedIn. I believe you have the link, but that's pretty much where I am. I'm just really passionate about the space and I want to make sure that the word is out there and my learnings at least from all these different areas is out there. But yeah, no, just LinkedIn, really.

Awesome, I love it. Thanks so much for coming on the show. I really enjoyed talking to you about the different human aspects of Platform Engineering. Morteza Irdmousa, thanks so much!

And thanks for tuning into the show!