In an industry buzzing with enthusiasm for Engineering Platforms, many are developed without a clear product vision, leading to poor adoption or even hindering organizational performance.
On this week’s episode of Dev Interrupted, cohost Conor Bronsdon talks with Simone Casciaroli, Head of Engineering at Onto. We first encountered Simone's insights at LeadDev New York and immediately knew he'd be the perfect guest to discuss how to build engineering platforms using the right metrics.
Join us as Conor and Simone delve into the HEAT metrics and explore how they dovetail with established engineering standards like DORA. The episode rounds off with an engaging discussion about electric vehicle startup Onto.
Episode Highlights:
- (2:00) Are we building engineering platforms using the right metrics?
- (9:00) Internal platform teams are on the rise
- (14:00) How to think about output vs. outcome
- (17:00) HEAT metrics
- (27:00) SLOs and DORA
- (29:45) Simone's work at Onto
- (32:45) Future of electric vehicles
Episode Transcript:
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Conor Bronsdon: Hey, everyone. Welcome to Dev Interrupted. This is your co-host, Conor Bronsdon, and today I'm delighted to be joined by Simone Casciaroli, Head of Engineering at Onto. Simone, welcome to the show.
Simone Casciaroli: Thank you. Thank you. I'm so excited to be here with you today.
Yeah, it's funny. We actually set up a conversation at LeadDev New York earlier this year, but had audio issues.
Conor Bronsdon: So I'm really excited to have a chance to have you back on the show. There was an awesome opportunity to see one of your talks there actually and I was losing my voice because we were talking to so many people. You were like doing these amazing speeches and it was really a great event and you Really caught my attention based on the talk that you gave, titled, Are We Building Engineering Platforms Using the Right Metrics?
And obviously, as anyone who listens to the show knows, we are very passionate about understanding engineering here at Dev Interrupted. Can you introduce this talk to our audience?
Simone Casciaroli: Yeah, of course. So this talk comes from a number of passion of mine. So on one hand, I truly believe in the power of platforms in enabling teams and creating an environment where basically like you can do, your team can do their best.
At the same time, I really believe in driving engineering through a metrics approach. It gives so much more autonomy to teams. Instead of, saying something like, you shouldn't implement X and Y and Z, you focus on the outcome, you focus on, what you want them to achieve.
I come from a business product background as well. I run two startups. I work with a number of startups as well. And for me, it's very clear that, a platform team should basically treat, the team that are using the platform.
And, trying to use the same umbrella of knowledge and tools that I normally use if I had to run a company that had the specific sort of target tokens. I do the same for platform. I literally use the same product tools that I would do if I had to run a SaaS. And have a certain target audience.
It's just that I do internally for the internal teams. So that was the idea. I think platform as a term has a lot of has been abused massively. And as a consequence, I really see some places where they use a metrics. I don't think it's right. And. If it was just like syntactically wrong, I would be okay with that.
The thing is that I see big impact, big negative impact by, using the right metric. So this is why I felt like it's definitely something I want to get out of my chest. And so that's the talk.
Conor Bronsdon: What are some of those metrics that you feel are causing problems when they're being used?
Simone Casciaroli: So this is going to be super controversial.I think, so let's talk about something that we're all familiar with that are Let's call it infrastructural or, cloud platforms. This is something that every, a lot of company have a platform.
Now, in this space as this is probably a space that you follow very closely. There has been like a huge, among the progress recently, we used to have ops teams there that would be responsible basically for, deploying what the engineering team would be responsible for building.
And then at a certain time, we started to talk about DevOps. Obviously, there are still a bit of confusion what DevOps is, but the truth is that sometimes when we build platform teams, I think we treat the platform almost like an ops team. So we target them with metrics that are actually metrics for the whole company.
I don't know are we sure that, for example, the normal corporate is something like, are we sure that DORA Is a matrix for the platform. I wish that Dora is actually not, for the teams and then it's recorded out to the platform. So these are where I see more struggle or assuming that, I don't know, or security is another one, improve the security standing of our.
company. I know potentially the platform team has, hold the keys to the AWS account or the Google account or the cloud account, but doesn't mean that they are responsible. They are solely responsible for security. Absolutely not. So if we take a product approach probably you, those teams should look at what metrics or what goals their customer have.
Basically, they're internal teams, and then depending on that, they find their own metrics. I'm expecting that a lot of their customers, a lot of their teams are going to have metrics or outcomes that are related to Dora. It could be that they want to speed up how long it takes to deploy its production.
It could be some teams have it, some teams don't. So it's maybe some team are releasing like a, like every couple of weeks and it's fine because I don't know, it's a special product that they don't get to reiterate quickly. There are other teams where actually, I don't know, changing moving like 10% reducing like time to production is key.
So even that, we should also build different pathway for different teams that have different needs potentially. So I guess this is where the problem I see, one side of the problem, at least. The other side. Now, the other side is because we focus so much on metrics that are looking mostly are, let's say, if we talk about platform as a cloud platform, We mostly look at metrics that are related to the operational aspect.
We forget that as a platform team, if the user experience or developer experience of our tool is poor, we're causing a huge amount of cost and pain to the other teams. Especially for platform teams that basically everybody uses it. Let's imagine like a team that has hundreds of teams. If something, you could have done I don't know, like in two hours instead of six, that is six hour waste across 100 teams.
If this is painful and it's blocking people and frustrate people. that affects so much the company. Before I start working for the company I work right now, I work for, a company called Babylon Help. And at the time I was working with, a data platform. Every time we were building functionality with that data platform, really the team morale would drop into zero.
Like it wasn't real. The reason was because The whole developer experience of using the tool was poor. They weren't doing anything wrong, it's just they weren't really measuring how their work was impacting us. The only thing we could do was escalate in the bad experience. So this is where I start asking questions like okay, but how do how do you know if you're successful?
And, the usual metrics was like improving how long it takes for you to deploy these things to production. We're improving how long it takes you to, measure a new data entry and so on. It was like, these are all great. What about there is something else that these are.
How happy are we with this? How hard it is to onboard with your platform? All this kind of thing, all this kind of metrics. And, I must admit that was basically like the other part of the challenge that I foreseen.
Conor Bronsdon: So this is where you view Platform as an internal product that needs to have differentiated goals, differentiated needs, because the customers you're serving are distinctly different.
They're the developers, they're the other teams. I remember at one point, You asked the audience at your LeadDev New York talk how many of the men worked on platform teams, and not many raised their hands. But many more raised their hands when you asked if they had benefited from a platform team, and I'm sure others would have also raised their hands if we had asked if they'd been frustrated by a platform team.
There's very clearly a shift happening right now where companies are paying more attention to these internal tooling pieces, these internal platform teams. How do you see that shift taking place in startups, whether at Onto or elsewhere?
Simone Casciaroli: That's a great question. First, even if you're the team that you're using, so sometimes you have even a team doesn't have the platform name, but you're using their tools.
You're using their APIs. You basically integrate with them They're basically building a product for you. So this is why it's so common. Now again, as platform as a name has exploded. So every, everybody wanted to have a platform in their name and look great,in fairness, it's mostly because it make it look more like generic, multipurpose, something that they can achieve more. But the reason you can achieve more is because it's a product. It's not a project. It's not hey, we now ship the continuous integration server is in prod.
Go ahead and use it. That's iteration one. Then you need to trade with the teams and understand how to improve it. So by moving those teams into platform teams, putting that label, you have some responsibility, with great power comes great responsibility. And the responsibility is that they need to start treating, older teams like customers.
So obviously it's very different depending on your skill. Ontu is not like a huge engineering team. We are about 25, 30 engineers. So we have a tiny platform and mostly it's focused on infrastructure kind of platform, but at the same time, I was having like a meeting where I invited a platform this morning, for example.
To understand the pain point of our teams, because again, if those are your customers everywhere, every place where you can go to understand their pain points is a good data point for you. How can we help to make their life easier? How can we help to make them faster? That's the, that's at the end is the goal of every platform.
Imagine if as a platform, often this thing come with gated approach to platform, right? Let's assume a platform decide to do when we're gonna improve security. So we're gonna include gated approach to security workability, that's great, but what's the impact on the teams? Are we gonna make us faster or slower?
If it's lower, there is something we can do because, we want to make it easy to have a secure system. so these are, I think the trend that I'm seeing, like obviously the more people are using platform, the more hopefully they realize that platform, despite is not just a name, it come with a number of responsibility and number of tools.
Probably like another thing that is not very common, but it should be more just that it's a challenge is to have someone that has some product thinking. That is in the team very often, but often they don't have a product person and mostly because you need like a product person that is comfortable with, technology, knowledge, but at the same time, maybe the right approach would be to take an engineer and that is passionate about product and make it act as a product manager.
it's very hard if everybody's wearing the engineering hat. Because you don't have friction, you, everybody that is an engineer know exactly what's easy and what's hard. And if you don't have someone that push and is, rooting for the customer, then it's sometimes it's hard.
So it's saying should we check with our customers, how they're doing? Should we run a survey? Should we measure their behaviors? These are all things that, these are all things that I think are going to come. I see when I'm. Last year I wrote like a blog post on this concept and there were many articles.
Now I see many more articles on the topic of let's treat platform as a product. Has been a concept for a while because it was mentioned, I think, in Team Topology that now it's a... I think it's a few years old as a book. But I think the whole concept of, okay, what does it mean to have a product as a product?
I think that's surfacing more and more in the current year, so I'm expecting to see it much more commonly discussed.
Conor Bronsdon: Yeah, we had that Team Topologies authors on in, I believe, Season 2, so a little... About a year and a half ago and really great conversation, but it's interesting to see how much more I'm hearing their book be cited now, a couple of years on after publishing, because it's very clearly become popularized in the public consciousness and engineering leaders like yourself have read it and are saying, Oh, like, how can we apply this?
And one concept that comes up a lot, whether it's through. Their work or through other conversations with engineering leaders is this problem that you're alluding to around, are we treating, the challenges we're trying to solve as something where, hey, output is our goal or the outcome is the goal?
Are we trying to actually solve the customer problem? And it's an internal struggle for a lot of engineering teams, but particularly for platform teams where, to your point, it can be easy to lose track of who your internal customer is, or to think, Oh, I understand the problem here.
Let me just go solve it. How do you think about that challenge?
Simone Casciaroli: It's tricky. I'll be honest. It's tricky. It's a great question, but it's tricky. The reason is it's much easier to deliver to an outcome, sorry, to an output than to an outcome, because it's like the output is like. It's still hard, but it's let's release that feature by X, meaning like a range of time that you can deliver.
It's much harder to say, let's change your behavior, because normally an outcome is often related to someone else's behavior. Or some internal measurement of, stability, security, and so on. That's much, much harder. And that's the challenge. The challenge is that mostly we require a bit of a, mentorship, I'm saying, okay if you're optimizing for output, we're gonna optimize to get something out as efficiently as possible. Now, imagine if what we release, as efficient as possible, is a very long release, that, is very efficient, we're releasing two months, but then it doesn't do anything to the outcome.
What's the point? So if instead you give it to the team, the tool, to say look, we relatively care about the output, but what we care is to move the outcome. The team will self organize, will organize themselves to start to iterate until they reach the outcome. And maybe, if they. Knew upfront what they needed to achieve the outcome that they want, probably that would be more efficient.
But we don't. What have you done? It's a bit like when, we're launching a website and you're trying to say, Oh, we want 10% conversion of the signup funnel. I wish we know how to do it. We know best practice, except if you've done the exact same thing with the same target audience on, there's going to be a lot of learning.
Oh, what are the main pain points when people sign up, for example? So CIMA is for platform also we are experts in the field, in the platform, right? So also understanding. When we build something, when we build a tool that for us is obvious, it's Oh, when, how do we create, provide this as a platform?
Oh, that's easy. We're going to do something with Terraform and we already mentally we eat a Terraform for lunch, but what about the other teams? So how long is it going to take them to get used to it? When they get an error for us, like understanding error for time and time is like that. What about them?
This is just an example, but again platform is just because it's especially close to my heart, but when I start this trying to use these approaches to platform as a product, actually, I wasn't even working on a cloud team. I was working on a very different platform team. So it applied to every type of platform.
Conor Bronsdon: So the thing that is a through line through this conversation is the idea of using. The right metrics and customer centric metrics, what's actually delivering for the customer, because that's, what's going to drive value for the business, and, or for your team, right? So if it's a development team, are we actually improving development experience?
If it's an external facing team, are we actually improving the customer experience and driving revenue. What, in your mind, are the right customer centric metrics to leverage, whether you're on a platform team or an external facing product team?
Simone Casciaroli: Okay obviously the answer may change, but I can tell you what I used.
I used a framework called HEAT, it stands for Happiness, Efficiency, Adoption and Task Success, right? And I didn't invent anything. Basically, I come from a framework that was invented by Google called Heart. I just removed a number of metrics that I didn't think was very useful in platform and introduced some that actually I think are very important for the graphing team.
This is where it's coming from. And the idea was to say let's recap. We're building a product. Our customers are the teams that are actually like using our product. That's great. We know roughly what they want to achieve. They want to do their job better. They want to get faster at achieving their goals.
So when we know that, how do we start? But normally where I would start, imagine again, if you start a company, where you want, the first question you want to know is that is anyone interested in my platform? Do they want to use it? Like you can't really spend months building something and then start looking for, it used to be like that, I used to work in a company that built like a big, data platform.
And then they were going around and say, are you interested? Are you interested? It's a big investment. And if it doesn't work, you waste a lot of money. So adoption is probably the first thing that you want to look at. And, it sounds obvious because it's of course, but we don't do it.
Obviously like platforms start with two different, in two different situations. Sometimes a platform starts from scratch, so there is nothing like that. There is no servings whatsoever like that in the organization. And someone feels like, Ooh, you know what? Our team really needs an analytic platform. It's they are going to start creating their dashboard.
It's going to be amazing. And we're going to pull And other times, instead, it's the opposite. Other times, it's there is a team or a group of people or one person that is providing a service. It's more like a job for him, let's say. Let's imagine your usual ops team. They're manually, when you say, hey, this is ready, can you deploy to production?
They're already doing it. It just is not a platform. Why is it not a platform? Because it's not a service. Because it's not a product. It's like it's actually a human being doing it, so it's not scalable. If I ask you, which one is riskier? Implementing a platform from something that already exists, or something that doesn't exist.
Which one would you pick as riskier?
Conor Bronsdon: Probably the one that doesn't exist already.
Simone Casciaroli: Because you don't know if actually people care. My advice in this case is always like, when you measure adoption, If you can move into a very a low key, low fidelity, like service, you put a team, the manner it does what your platform wants to do is a much cheaper and a better way to actually figure out the option because what's the best adoption?
It's not Hey, I promise that we're going to use it. Especially in big company, one month they say they're going to use it and then priority shift. And I'm like, It happened to me more than one time. When I was at Babylon, we learned some new functionality. We ran down we got three or four, teams that were interested in using it.
By the time we released it, we had two only, the other two kind of like they changed priority. So also this is why like adoption, you want to measure like in a way that's give you a bit of bandwidth. So don't get one customer, get more than one. and that's one. So adoption again, this one is probably the most important one, trying to figure out exactly and treat them well, because your first customer likely going to be the one that you want to get closer so that you can learn the most.
And then normally, depending on another thing that I normally do, so adoption is definitely the first. And then depending on if I, what road I picked. So if I pick the road of doing like a lot of manual work, I may look into efficiency next. So let's imagine what I described, like I wanted to do something and at the beginning instead of creating like a self service analytic platform, what did I do?
I put three engineers that, they get like a, a JIRA board and people say, Hey, can you create this dashboard? Can you create this dashboard? This is the data, and they do everything. People are using it. Yeah. And when you figure out the option, then the challenge is that how do we scale it?
Or at the moment, let's say it takes 14 days, 15 days a month to get dashboard created. And not only takes a long time, but internally. It doesn't scale because if you have more than four people asking for a different dashboard, basically we max out the team, so it's not very efficient. So then you want to look at efficiency.
Efficiency is basically a way to say how can I reduce the time it takes to support a service I don't know, maybe 30%, 50%, 80%. And like in the talk, when I was at LeadDev, I was, as a joke, I said I know you're thinking, if I have something like that, I just stop people from posting things on my, ticket, tool and I'll fix it, no one is coming through, but efficiency is tricky because when you try to improve efficiency, normally you do it through some sort of automation.
Sometimes the, the human aspect of doing something manually has a better user experience. Or potentially another thing that could happen is I need to learn our tool before I just create a ticket and that's it. And now I need to do something myself. So it's tricky because normally what happens is when you increase efficiency, all the things drop.
And what are these things? These are two other metrics. One I call happiness, and one is task, success. So those are verbatim from the heart framework. Happiness is easy. It's like how happy and satisfied your customer is with your software. it's if they see you in the corridor on Zoom, do they smile or, they want to slap you in the face?
If it's the second, I don't know, happiness is not very high. Obviously you don't want to measure slapping the faces as a matrix. I don't know, I think it's quite painful as well. Yeah.
So what do you do? Normally these are surveyed. Happiness is a type of survey when you ask, how happy you are, satisfied you are, and it also, if you are in a larger enough organization, my advice is when you do survey, really check with your research or user experience team, your product team, because they know much better than us how to write surveys that are not biased.
That's definitely my city. At the beginning, there is a lot of qualitative surveys. Sometimes we focus too much on the quantitative part, I think a lot, at the beginning, especially at the beginning, for a long time, you really need to get a lot of real feedback. These are questions, discussions, and so on, interviews.
And that's one. The other is task success. So let's imagine, apart from the habits, general habits, how successful your teams are at achieving what they need to do. So we mentioned before how long it takes to get the dashboard ready. To them, maybe with you, it was, I don't know it was, yes, a month, but they were just waiting.
And when it was ready, it was there. What if you launch it and it takes them 15 days? Yeah, it's half the time, but how do they feel about spending 15 days to set it up? So that's something you want to measure as well. That is depending on the size of the organization and how many customers you have.
You can. You can instrument your tools to measure some of those behaviors, but again, I will mix quantity and quality type of research in there. So get some feedback and get some measurement if you can. Again, if you have three customers, pointless to instrument your software because, variance is going to be like quite high.
But yeah, these are the four one. And normally another advice I give is that don't focus on one at a time. Try to counterbalance them. So as I mentioned before, efficiency is a tricky one because you, you want to increase it without affecting happiness and success. What you want to do is you want to agree with yourself, with your team, how much you're happy to lose.
So you're going to say, I don't know, let's say I want to increase efficiency 50%. At the same time, I don't want to get happiness lower than, I don't know, 10%, but that success, I don't know, less than, I don't know, 80% of what it was before or something like that. So that if something happens, you can stop.
Okay, this is not working. This is not a solution. This is not an option. We need to find a solution. So this is how I did it. I was working on a workflow platform team, so quite different from like an infrastructure team, and we implement all of them for a year and a half. It was very cool. It was very cool because everybody in the team understood what we were trying to optimize for.
It was easy to explain to the senior leadership what we were trying to achieve, what we were focused on things. Sometimes it's hard for a platform team to justify why we do something, especially efficiency.
Conor Bronsdon: Yeah, I appreciate this framework context. I think to your point, there are multiple challenges here depending on the size of the company, who your internal customers are and how you get started. So I love that idea of focusing on adoption first and then making sure you're paying attention to all the metrics.
And I'm sure as you alluded to, sometimes DORA metrics are the right way to approach pieces of this problem. And maybe they're a good fit for some adoption or happiness or efficiency metrics, but other times they're not. And I'm sure it also impacts the kind of service level objectives, the SLOs, that teams set out, depending on what they're doing as well.
Simone Casciaroli: Yeah, and normally for me, so let's talk about security. It's an area where I spent like the past six months. So I didn't set up an SLO for the platform team. I set up an SLO for all the product teams to improve their security. How long I'm expecting to have a vulnerability to be able to be fixed. If it's critical, if it's high, if it's low, if it's medium.
That was the SLO for the product teams. And the reason was for them was because obviously there is a lot going on. There is a lot that the platform team need to do for the infrastructure to make it secure. And that's okay. I treat them in that case as a product team. But at the same time, there is a lot that a platform team needs to do to allow those teams to be able to achieve their goal, to achieve their SLO.
It's the same for every other metric. Let's imagine lead time. It would be, for me, I think it would be pointless for me to have lead time as a, I don't know, as a goal for the team because, we can have the best, deployment planner in the world, but if the team is slow in the way they, I don't know, in their process to, to deploy to production, you're not gonna improve lead time.
So it's better than basically lead time is something you agree with all the product teams, maybe a different type of lead time, depending on their needs. And then the platform goal is to help them. So you're most like this trickle down to them. It's not like directly impacting to them. Again, what you said before, it can't even make sense.
Besides the company and also sometimes you need to compromise. Am I saying that everything I do, I want to add in the platform is set up like that? No, we have a small team. So sometime I have to, get some of these, non functional requirements to the platform team. And if I had a better team, I would do it differently, but again, it's not about perfection.
It's about creating tools that allow team to do as best as they can.
Conor Bronsdon: I really appreciate this conversation, Simone. It's been interesting to talk through your approach. I do want to spend a little time on your current work as well. It's not every day that we have someone on the show from the electric vehicle space.
Can you tell us a bit about what you're doing at Onto and some of the work that you have been completing?
Simone Casciaroli: Yeah, of course. So Onto is a UK company. It provide, subscriptions to electric cars. Subscription to electric cars is like adding a little track to your own electric car, but have it, using it without really owning it.
So basically you get a car that is already insured and if when it needs to be serviced You know, it's not your responsibility. We deal with that. So you get all the fun of having a car without all the pain of owning a car. That's the concept. And we've been running that like for, I don't know, I think it's been four or five years.
I've been Onto for one year, but I've been a customer and like a community member for three or four. I'm a big fan of the company. And probably that's why I joined them. I really believe in this concept of, I want the flexibility of having an electric car, but I also think that at the moment is, maybe you want to, have a subscription to an electric car, not necessarily buy one.
Because the world of electric cars changed so radically that maybe in six months time you wish you had another car. So if you have a subscription, basically in six months time you just change car. We have, it's a monthly subscription, so I change, I don't know, probably four car per year. So this is what we do.
And I must admit it is quite a lot of fun and obviously the challenge is, sometimes I say to my colleagues, it's like working with the, in the real world, it's it's not like having a digital business, we're moving cars, if someone can't access their car, they really get pissed.
It's not like you can't access Facebook and it's Oh, whatever. I'll have a bit of. Time for myself finally. So it's there are some complications, some service that we provide at a very high level of need to be very resilient. Obviously we, we own a lot of data, so the security needs to maybe be up for scratch.
But also in general, it's quite complicated to digitalize like this user experience because not a lot of companies have done it. How do you do, having a car without owning a car? that's quite a challenging sort of thing to do. but I think the most interesting challenge has been, how do we make these not, Owning a car as smooth as possible, because again, that's the main reason why I use it.
I mentioned servicing before, but it could be, I have an accident. I am, my car breaks, how do we deal in a way that you imagine if you break your car and you start thinking, Oh, I need to do this. I need to do this. How can we make it like very Obviously, there is potentially, and people often expect that there is, oh, this is going to be so expensive, actually, it's not even, we're able to also make it a decent price.
It's a, I think it's a higher, service comparing to owning a car, but at the same time, it's not that expensive.
Conor Bronsdon: Makes sense. It seems like that space is changing rapidly. Where do you see it going in the next, I don't know, three to five years?
Simone Casciaroli: Yeah, you're totally right. I think at the moment, again, the speed of improvement of electric cars is a bit insane. How better battery gets.
How efficient the car are getting. So it's just insane. So I'm expecting that we're going to follow that for the next four or five years. Hopefully at some point it's going to be a bit of diminishing return. Obviously we've been having like a, petrol cars and things like that for a long time.
So there, the level of improvement is minimal, almost for example, in terms of efficiency is more zero right now. But electric cars still have a, like a they can improve so much. So I'm expecting that a bit of that is gonna be done. Also, something else I'm expecting is that, it's gonna be probably a revolutionary in terms of like how the motor industry is gonna look like probably in four or five years time.
Certainly there are, from my perspective, again, everything I say is miscible and it's not on to but there are some manufacturers are definitely struggling more with electric cars than others. And so I don't know. What's going to look like, Chinese manufacturers are doing incredibly well, for example, with electric cars, so it doesn't mean that in five years time, some of the big names, big brands are not going to exist and we, a bit similarly to what we do in the, in the mobile market that a large percentage is going to come from.
Branded and especially in Europe, a lot of brands of Android phones are Chinese and that's okay. That's completely okay. But, they displaced what, that we are like incredible big brands in Western Europe or us. I'm expecting a bit of that is going to happen is probably.
Partially, it's inevitable, I think.
Conor Bronsdon: It's going to be fascinating to see the changes that happen in that industry. Broadly, technology is just moving at such an incredible rate of change, and that space is still so nascent. Simone, I really appreciate you coming on to share these insights and also talking to us about metrics and platform teams.
It's been great to chat with you again and catch up. Before we go, I do want to ask, what's the best place for our listeners to keep track of the work you're doing and stay in touch?
Simone Casciaroli: Sure probably you can follow my website, that is https://simonecasciaroli.com, or you can, follow me on LinkedIn. At the moment, I think I'm the, that's the social media where I'm more active, but I tend to probably I tend to post or blog rather often. I have quite a few things on platform that I'm working on at the moment. There should be new things coming through soon. So I would guess these are the two places to find me.
Conor Bronsdon: Fantastic. make sure you check out Simone's blog and also be sure to sign up for the Dev Interrupted Substack.
Each week we'll be giving you the latest episode of Dev Interrupted right in your inbox, as well as articles from some of the best engineering leaders in the industry. Hopefully Simone soon. Upcoming events and all of your favorite Dev Interrupted episodes, past and present.
All of the insight, none of the fuss. Check it out at devinterrupted.substack.com. And Simone, thank you so much for coming on the show. Really appreciate it and great to catch it up.
Simone Casciaroli: Thank you. Thank you everyone. And it was great to be here.