Gregor Vand (4:07)

Yeah, yeah.

Dylan Etkin (4:07)

Are you effing kidding me? And he was like, no, I'm not. And I'm like, well, there you go.

Gregor Vand (4:12)

You tried to leave, but I know.

Dylan Etkin (4:14)

Yeah, went back and the mothership pulled me back in, you know, but that was a great experience as well, like to sort of. I can't imagine what it would have been like to navigate an acquisition if I didn't know where all the bodies were buried inside of Atlassian, you know. So, like, I think it was a good thing for Status Page and it was a good thing for Atlassian that I could bridge that gap. And, yeah, so spent a few more years at Atlassian doing that, and then eventually just spun out and decided, you know what? There's a problem that I've been itching to solve for quite some time, and that's sleuth. And, yeah, I've been doing that for about the last five years or so.

Gregor Vand (4:45)

Yeah, that's amazing. I Think you just reminded me the fact that jira etc wasn't SaaS at one stage. It was you deploy for a good.

Dylan Etkin (4:54)

Portion of its life. I mean, there was like a good 15 years into Atlassian's journey. The lion's share of its revenue was coming from people that downloaded the software and installed it. It's also hard to remember that it was not ubiquitous. Like there was a time where it was the scrappy upstart and the IBM rationals of the world were like the things that it was displacing. And it was quite a journey because people were just throwing their credit card down and being like, I don't want to use an issue tracker that sucks.

Gregor Vand (5:22)

Yeah, absolutely.

Dylan Etkin (5:24)

And now some people think it's the issue tracker that sucks.

Gregor Vand (5:28)

Yes, there's all these cycles. I mean, I have been watching this space quite sort of closely for the last couple of years. There's a linear is obviously the big name that seems to be eating up a lot of, I imagine eating up a lot of jira's business now. But yeah, well, yes and no. Exactly. But anyway, let's talk about Sluth. So let's just sort of start at basics, like what is Sluth high level and why. You've just given us your working history. And what was that? I think you said you had an itchy you wanted to scratch by founding sluth. What is that?

Dylan Etkin (5:57)

Yeah, so I mean, really our goal in life is to help align business and engineering. And the way that you do that is you kind of demystify the engineering world a little bit. I think an analogy is a good one. Like I often think of like Salesforce. You know, Salesforce is one of these things where it helps a lot of the operators do things. But at the end of the day it also helps you understand, are you working efficiently in terms of sales? Do you have bottlenecks in any of your processes? It generates reports for really important information and data. You know, engineering has lacked one of those tools. I think, you know, we've had a couple of false starts in terms of measurement around like lines of code or number of pull requests or like metrics that most engineers worth their salt will recognize don't really measure very good things. But I do believe that we're in a point in time where we can measure things fairly well. We can get a very broad view of those things and then we can use those in that same way to generate reports and things that are going to help an engineering organization understand are we operating effectively, where are our bottlenecks? What are we spending our time and our money and our effort on? Are those the right things? And ultimately, are they aligned with the business and the business's needs?

Gregor Vand (7:13)

Yeah, so I mean, if you go to Sleuth IO, that's where you can learn about the product and a few things are mentioned there. Sort of, there's a lot of idea of running an engineering team, a sort of theme there. How do you define what running engineering is? And sort of, how would you say again, especially with your experience and now that you've got a product centered around it, like, how would you say that sort of evolved in recent years?

Dylan Etkin (7:37)

I mean, it's different based on scale. Right. So if you're a team of three people, you're going to behave and operate in a way that's very different than a team of 100 people. And it's very, very different than a team of 10,000 people. Right. But there are some commonalities and that's a gift. It's a gift to us who are trying to solve this problem. And those commonalities are somewhat in the tools that we use to work. So like most teams are going to be using some primitives, like an issue tracker or like a git repository and pull requests in some way, shape or form, or you're going to have something that's going to be doing monitoring where you're collecting a certain amount of KPIs on something, or you're going to have like an incident management tool or at least an alerting tool and something like a pagerduty. Right. And that's if you're a tiny little team of three, you probably have some of these tools. And even if you're a giant team of 10,000, you're just using the tools very differently. And then the other thing that I think is a commonality is for these much larger teams, they do tend to break down into smaller teams. Like, you don't usually have a team of more than like, you know, 50 or 100 developers on something and then you tend to break it down into littler silos in between.

Gregor Vand (8:48)

Yeah, no, I think it was good that you sort of outlined those primitives, as you say, again, just to give that high level to the listeners, Sluth doesn't come in and try to replace a jira, et cetera. Is it fair to say that those primitives you just mentioned, like issue tracking and PagerDuty, for example, oncall, they plug in, they integrate with Sleuth, is that correct?

Dylan Etkin (9:09)

Yeah, you said that really well. And I'M glad you called that out. It would be unreasonable to think that you have to prescribe somebody's tools because often you're already invested in these things. So, yeah, on our side, it basically means that we support issue trackers as a concept and then in reality we support Linear and JIRA and shortcut and GitHub issues and GitLab issues and, you know, the list goes on and on and on, unfortunately.

Gregor Vand (9:34)

Yeah, I'll be curious maybe as we get through the episode, just to hear more about the actual engineering evolution of the product itself, because I think that part that's quite interesting, but let's sort of keep kind of moving through the product. Generally, Sleuth is emphasized as predictable delivery. In your experience, what's the most common reasons that it's unpredictable? And I guess why does Sleuth change that?

Dylan Etkin (9:56)

Yeah, I mean, that's a great question. I would say that there's a million reasons for unpredictable software, right? But there's some things that help spot where your next opportunity lives. One of the things that we've leaned very heavily into is this idea of DORA metrics. You know, that's the folks that were acquired by Google a while back, they do this date of DevOps report every year. And I think as teams started moving into SaaS, those of us who were deploying in that manner, we had a gut feel that all of those things were the things that were important. And I think the DORA folks did a great job of just adding some research to it and putting some names and saying, hey, these are four things. And they are really strong indicators, you know, and that's like deployment frequency change, lead time, failure rate, and then mean time to recovery. So those can be just a really strong indicator of like, how are we doing in relation to the industry, where are we potentially running into bottlenecks? Like, for instance, maybe your team just for Some reason takes 48 hours to pick up a code review, right? But you're coding things up in six hours and you're deploying them in two hours. Well, where should we spend our time? Right. Let's look into tooling that's going to help us be more effective in that area. So, I mean, that's just an example of one way that you could be inefficient. I think there is an infinite number of ways. I mean, you could just be working on things that have no driver in your business, right? Like that's the most insidious kind, right? Where you're like, you're doing a great job on shipping a Thing that nobody actually cares about.

Gregor Vand (11:31)

That's probably, you know, 50% of startups at least.

Dylan Etkin (11:35)

Well, they don't know it yet, right? Yeah.

Gregor Vand (11:38)

So you called out the DORA Metro metric, sort of tracking. I believe there's three parts to the product and the latest one being called Pulse. But maybe could you just sort of highlight what are these three parts to the product and then we can maybe move to Pulse specifically after that.

Dylan Etkin (11:55)

Yeah. So I mean, our desire is to really be, like I said, an operating system for engineering. So if you're looking to align your processes, understand what are strong measures of efficiency, spot bottlenecks, actually do things about those bottlenecks, like in an automated fashion, and then report on those things. Like that's kind of the spectrum of solutions that we're trying to attack. And as you mentioned, there's a few different modules that we have. It's kind of like, you know, you start on something easy and then you move to the next one and then you move to the next one. And I think that tends to fit with team size as well. So the DORA metrics are something that we really focus on. We can attach to a lot of things and get very high quality DORA metrics. Those tend to be really good for team leads and engineering managers to understand, like what's going on. Again, that's going to help you spot those bottlenecks in the work that you're doing day in and day out. That's going to get a lot of information from like your Jiras or your githubs and those sorts of things. Now when you've spotted some of those issues, the very best kind are the ones that you can automate away. So we have an automations marketplace and framework. A great example is the one that we were just talking about, where your review time is too. You should be able to set an automation that says, hey, as a team, we want to hit a goal of, let's call it 12 hours, right. For every review to get looked at, you shouldn't have to have humans nagging other humans about that shared agreement. Instead you just delegate that off to the robots, right? And so what we do is we say, cool, set a goal. You know, at the 75% mark, we're going to send a slack notification because that's where everybody lives anyway, that says, hey guys, remember you agreed on this thing, you've got about three hours left, so you might want to take a look at it. And then we'll help you see, like when you're hitting it and when you're not hitting it right. And we have like a couple hundred automations that do similar things like that. Like basically best practices that some of the best teams use and helping you set guardrails and sort of like, you know, standards that you won't cross. And that's again based off of the measures that are saying, hey, here's where I think you could improve. I have a way of getting you better really quickly. And then the other piece is really like the operationalization piece. So, I mean, in our market in general, I think that's probably one of the hardest things to do is, you know, we've honestly had failure conditions where we've set up a company and gotten them rock solid metrics that are really interesting, that are trying to tell them a lot of things and then they turn around and they say, how do we use this? Right? Like, what are we supposed to do with this? Who's supposed to look at this? When are we supposed to look at this? How do we drive actual change? Because it turns out I don't. I don't actually care about the metrics. I care about changing something. And so that's what Pulse is meant to do. It's a broader set of metrics that help you talk about engineering at the sort of higher levels than just engineering managers and team leads, but also it's helping you operationalize. So it's saying, look, I know that you likely have some ritual where you're either doing an operations review or maybe you're reviewing your monthly state of engineering, or you're talking to your exec staff about engineering allocations or those sorts of things. Let's key into those moments. Let's give you the tooling and the process and the data to make those really, really impactful moments.

Gregor Vand (15:13)

Yeah, so I saw the Pulse product fairly recently and I love to dive into that in just a second. I just want to go back on something you said there. Having been a CTO myself, very aware of all the pain points of trying to get that exact example of review time. And what is it that we need people to be doing to ensure that they are reviewing within a certain timeframe? I completely agree that humans exactly should not be having to be the ones sort of doing those reminders. I'm curious, what have the results been in terms of does a bot giving that reminder, does that genuinely change the landscape? And my concern, I'm speaking maybe behalf of some listeners here, my concern might be that my team are now going to have nine different reminders every day saying Sleuth says X Sleuth says Y. So how do you approach that?

Dylan Etkin (16:05)

Yeah, I mean, notification fatigue is real, which means that we just have to be really smart about these things. And what that looks like is we're fortunate that a lot of the tools, you target a subset of reviewers. Right. And so we are clever about only targeting the people that are the targets of those sorts of things. It does tend to really work. I mean, we've seen teams really see a difference, specifically with that one. Right. And it's so interesting because it's just about visibility. It's not even like technically very complex at all. You're just saying, I forgot. You know what I mean? It's like I just needed somebody to remind me because I got like 25 things I'm trying to do in a day. Another one that I love, and it's one of our more popular automations, and it's so stupidly simple, is don't allow a pull request to be merged without an issue key referenced in the title.

Gregor Vand (16:53)

Nice.

Dylan Etkin (16:54)

Right. Like, almost every team I've worked on in the last 15 years has done that as a convention, but occasionally, then it gets missed and then you're like, oh, hey, what issues is this trying to fix? I don't think I have the context as to why you're doing this pull request, you know, and you can go from. We can sort of show the stats, like when you've enabled the automation and you see teams go from like, oh, we do it 65% of the time to 100% of the time. Right. And I feel like that's the power of automation, is that you're just saying we all agree. So even if it's a little annoying, we were annoying each other anyway. And now I don't have to have this simmering thing of like, Joe never remembers to do the thing. I've told him a hundred times and I'm ready to kill him. You're like, the robot does it and you just can't get your work done, Joe. So put it in there.

Gregor Vand (17:39)

Yeah, and exactly. It still kind of amazes me. Obviously, tools like Linear, and they were not the first to do it, they literally provide a branch name that you can copy and then that sort of all flows through to GitHub and et cetera. Yet still pull requests get made with none of that. And you kind of say, like, exactly, hey, Joe, we have this thing in Linear that's super helpful, that ties this whole thing together. What's going on here? Exactly.

Dylan Etkin (18:03)

And there's a heap of those all of those automations are really about just saying we agree as a team to do a thing, let's enforce it, let's give ourselves the best chance at doing the best practice.

Gregor Vand (18:16)

Nice. So let's talk about Pulse. I saw Pulse fairly recently. I think the way I would describe it is just sort of as a layman is sort of taking those metrics and making them much more presentable and sort of especially to, I would say almost like partly to non technical folks but as well as I think developers I imagine are also a bit metric fatigued. Like just seeing charts and graphs about we did X and Y. So my feeling was it kind of blended two things together, like more qualitative as much as it has quantitative and Pulse, that word, there seems to be a sort of cadence to when it sort of looks like almost like a card and then you click into the card and then you've got a whole bunch of information. But maybe I'm just giving the kind of the layman read back of what I saw in Pulse, but maybe you want to walk us through.

Dylan Etkin (19:04)

Yeah, no, I think that's right. And I guess I would just jump back one little bit and I believe that data is interesting. Metrics are interesting. I would say that they're about a third of the problem right now. If I have a dashboard and that dashboard is showing some very interesting metrics, I would argue that you're a third of the way there. And the second part that is very, very important is a shared understanding and interpretation of what those metrics mean. I can't tell you how many times I've seen a dashboard. I look at it and I think one thing, I have a very strong opinion that comes away thinking one thing, somebody else has a very strong opinion thinking something completely different. If we're just using that as the source of truth and then taking action on that, we haven't arrived at any consensus about what the data is trying to tell us. Right. So one of the key things that we're trying to do in that Pulse product is allow you to surface the right data that's going to tell a narrative that is something that then you can agree on. Right. We're going to have the collaboration tools inside of there as well to be like, hey, I don't understand why there were so many incidents this period. You know, did that mean there was user downtime and somebody can come back and say, no, those were just back end things, nobody saw a problem. It doesn't indicate that we are slipping. And you can see that in this other Metric over here. And I go, okay, cool, level set. I understand. And then that leads us to the third part, which is, what are we going to do about it? Like, why do we care at all? Why are we having this shared understanding? Unless we're trying to drive something different? We're trying to drive an outcome. We want to hold ourselves accountable to that outcome. We want to understand that there's like data attached to that outcome, right? So that we can measure when we've decided to do something different and see if we move the data. So I would argue that the thing that I showed you in Pulse, it looks a lot like a dashboard, but it's very subtly different because dashboards can be really stale. You don't always know if the data is working. You don't always know what the interpretation is. The interpretation might change over time. You don't have a window of understanding of when was this relevant? When did we discuss this? When did we decide that this was true about the world and maybe that same set of data led you to believe something else that was true about the world later? So, yeah, the Pulse product is basically trying to allow you to be very specific about the data that you want to pull in that means something for you so that you can have these data driven discussions come to an understanding, track the outcomes. I feel like that's very vague for our listeners, though, unfortunately.

Gregor Vand (21:38)

It definitely covers, I think, a lot of what a listener might understand. I was actually, just as you were going through that, I realized, is it right to analogize what the Pulse, at least the data that is viewed in Pulse and so the discussions around it, is it sort of correct to analogize that with like a retrospective effectively, like the. In the Scrum analogy or.

Dylan Etkin (21:59)

I think so. You know, we honestly think a lot about it as like pull requests. So I think that was a key moment for us was when we were sitting down and like, you know, we've been doing this for years and we had gone really hard into Dora and we knew that we had an issue around operationalization and that like, basically everybody does. And when we asked ourselves, like, how do we fix that? We went like, you know, I think the development world, we have the same problem, right? Like, I worked at Atlassian forever. We had a code review tool called Fisheye Crucible for those, you know, like in the Wayback Machine. And it didn't work real well. It was a beautiful code review tool, but it was against subversion. And the trick was that you basically did the review after you had merged your changes. And I Can't remember anybody who ever, ever made a suggested change because you're like, I already shipped that, it's working, it's fine. So pull requests. Had this thing where you were like, oh, we can have a conversation at the right moment and make a change to the way that this is going to go down. And we thought, you know what, that's the same thing. If I'm doing a review with my CEO about how is engineering going and how are we doing these things, why would we not try and use that analogy? Right? You want to find the right moment, you want to find the right data, and you want to like be able to have a conversation that changes outcomes at the right time, you know? And so, yeah, it's really a review that's very interesting is what we think of it as.

Gregor Vand (23:24)

Right, okay, so yeah, a review. I think that's a very good way to analogize it. I say I was, when I was thinking about it, it was sort of, where have I been in this situation before? And it sort of, I was like, well, this feels a bit like what a retro is where we all talk about what went well, what didn't go well, et cetera. But I think the review analogy, because pulse, that word, it is exactly that. It's not that we all arrange every two weeks to just get together in a room and say, right, what went well, what didn't go out? This has a much more frequent cadence to it.

Dylan Etkin (23:52)

Yeah, well, the other thing that we found that was, I mean, kind of obvious in retrospect, but interesting because just like we don't ask you to change issue trackers to the Sleuth issue tracker because let's be honest, that's a method for failure. Right? Like, nobody's going to do that. Similarly, if you want to add a new process to your process, you want to adopt something new. How do we do that in a way that is the least amount of pain for you? The answer is that we attach to your existing rituals, right? And most organizations actually, just like the primitives of, you know, issues and code review, have some rituals. Like you're going to do a sprint planning that's either going to be weekly or bioweekly. If you're big enough in your SaaS, you're going to have an operations review where you're just checking out like, how many incidents did we have? How are things going? What are our KPIs? More than likely, if you're big enough, you're going to say, how is this subset of engineering going? You know, what I mean like, is it healthy or is it not healthy? If we have seven things in flight, how are they going? How much of our time is being spent on support? How much of our time is being spent on keeping the lights on? And then if you zoom that up a level higher and you're big enough, you have 20 new hires coming in. How are we going to allocate Those? We have 300 people. How are we allocating those? What does the business need us to be doing and how are we tracking to those? How are the real things that we're doing every day and these big projects that we have, how are they moving? How are they allocated? Do they match what we want to be doing? These are conversations that are happening inside of organizations already, but they're happening very often with a very anemic amount of data without necessarily doing a lot of the heavy lifting offline. So the conversations tend to be very statusy in these meetings instead of actually getting into the meat and potatoes of what you're going to do different.

Gregor Vand (25:39)

Absolutely, yeah. I mean quite literally ceremonial is kind of how I often saw those meetings where.

Dylan Etkin (25:44)

Yeah, they're rituals.

Gregor Vand (25:46)

Rituals, exactly. Yeah. I'm afraid I have a fairly love hate relationship with the term Scrum Master because it just was these sort of self, semi self certified people who sort of thought they could just get developers to kind of work on a sort of factory line type arrangement. And it doesn't often work like that. And to that point a lot of our listeners are developers and developer satisfaction is I believe, a metric that actually sleuth brings in. Talk to me about that. How is that measured and what sort of outcomes do you see from tracking that and how to actually improve that?

Dylan Etkin (26:20)

It's hard to tear it all apart. Right. So like we focused for a really long time on DORA metrics and something that I as a former engineer really enjoyed about that is it's a hard number, right? Like I can drill into that number and I can like understand like where it's coming from and I can compare it to other numbers. Like that is very satisfying to an engineer to be like, yeah, like we don't have to argue too much about this. There's some truth behind this. But the truth of the matter is a lot of what I did in my past life as an engineering leader was one on ones and making sure that my team was happy and that we were having fun doing the work that we were doing, that we felt satisfied with that stuff. So there's an element that there's the qualitative and the quantitative. And I think if you want a full understanding of your engineering organization, you have to blend the two. So devex experiences or devex surveys are a great way of doing that. It's not really new, but I think it has seen a bit of a resurgence with the whole space framework. And I think the great example is that you are elite in all categories of Dora, but everybody wants to leave your company because they're miserable, right? That is very possible. I've been in environments where that's true. And so it's obvious that it's not the full picture if you're not getting all of it and mixing it together.

Gregor Vand (27:41)

And I think from what I saw in the product, and I did actually ask you, while we're going through the anonymization of input from developers, that, to me seems very important. Could you just speak to that?

Dylan Etkin (27:54)

Yeah. I mean, from day one, when we started this journey, it was very important for us to worry about developers. I think that this whole space, it dances on a razor's edge. And that razor's edge is if devs are pissed off or think that you're, like, just trying to track them for no good reason with metrics that don't work, they are going to revolt and they're going to be like, f you. I don't want to do this. And I understand that because I have been in that same spot myself. But the interesting part is, and I truly believe this, every team that I have ever worked on, the individuals on that team want to do better as a team. They're really interested in improving. Like, developers are super cool in that way that they want to know, how do I do this better the next time? I don't want to do the same thing over and over and over again. I actually want to, like, get 2 to 7% better every time I do a thing. And so when you frame metrics at the team level, which is really very easy to do with Dora, you know, and you don't surface, stack ranking views and those sorts of things. And similarly, you know, you worry about anonymization when it comes to survey data. You basically take everything through the lens of how can we improve the teams and not worry so much about the individuals. Because software development is a team sport. It is not an individual sport. So, I mean, that's our take on everything. And we have lost deals to competitors because we have had people show up to, you know, sales calls and be like, look, I need to stack, rank my people, because I need to know who to fire. First and I'm like, well that's really sad for you and like, I wish you luck, like that's great, but we're not your right place for that. I think there's other ways that you can figure that out and you're not going to get that from us.

Gregor Vand (29:35)

Yeah, that's an awesome approach. Really like that. And you know, I think it's just always obvious when it's a developer, whether past or current, that is the CEO of a company. Especially when the platform is ultimately something that developers are being asked to use, I guess, because they might not be the ones actually buying it into the organization, but it really matters who's leading that company. That platform actually can put themselves in the shoes of a developer, which I don't believe a lot of other platforms. That's actually their background. That comes through really strongly.

Dylan Etkin (30:08)

Yeah, I mean it's a chicken and egg thing too, right? Like, I like working in developer tools because I wouldn't know what to do with an insurance platform. You know what I mean? Like, I buy my insurance, I'm like, sure, I'm insured because I'm a human and I live in society and I have to, but I don't care, you know what I mean? Like, I don't get passionate about that. I don't really know what's good and bad in that arena. Whereas like, you know, developer experience, now that's a different thing, right? I'm like, yeah, man, I've run teams, you know what I mean? Like, I've run really excellent teams and I love the idea of encoding the best practices into a platform and allowing teams that have some distance to make up the tools to do so.

Gregor Vand (30:47)

And just in terms of the actual implementation in a business, you mentioned in the material, start with your biggest problem, that you can actually implement one part of the product or two or three. And so how does that actually work in practice?

Dylan Etkin (31:03)

Yeah, so with the Pulse product itself we have like, it's a little bit like of a widget builder, you know, so there's a lot of based on the different systems that you can connect to. You can get pull request outliers, right? You can get like issues shipped in a certain period. You can get support escalations from a support system, you can get a cost analysis breakdown of the work that your developers are doing based off of like JIRA and those sorts of things. So like there's all these different widgets. But then again, because we understand that teams have these rituals that are fairly common, we've bundled up A bunch of templates that say, hey, this is the right level to start at. If you're trying to do a Sprint review, this is the right set of data that you could start at to do your CTO conversation. And I'd say the customers that use it probably stick with 95% of what's in the template, but then they drag into this and they drag into that and they have like, oh, well, we like this ritual of having a screen share of what we built and I want to pull in that widget here so that I can have that in the presentation. And so you can see how if it's templatized and you're like, look, we don't do operational reviews right now. We would like to, that's aspirational. But I'm not going to worry about that right now. But the burning issue that I have right now is I don't understand allocations. And when I talk to my board or to my executive team, I don't have enough data to tell them like, you know, where we're at and how we're tracking. And I want more rigor around that. So I'm going to start there, you know, I'm just going to like plug it into JIRA and get that information and be able to have those conversations and decide if, like with a smaller group, if that works and if you quite like it, you're like, hey, engineering managers, I could see how you could use this to run that level of conversation as well.

Gregor Vand (32:48)

And you know, you mentioned the automations and the integration side. I think you say you also offer, you know, 100 pre built automations. How do you decide on those? You know, is that quite customer driven or is it again, sort of chicken and egg where you're having to think ahead of what a customer doesn't even know they need yet, but we think they do, or how does that kind of look?

Dylan Etkin (33:07)

So what we'll do is because we're fortunate enough to have a really strong view into the data, we also have a lot of opinions, you know, so if we are surfacing, say for instance, like, if we see that review lag time is not great, right? Like, and it's outside of norms, it's outside of your norms, it's unrelated to, it's a bottleneck that we can identify, then we'll suggest that up and we'll basically throw that into the interface just to be like, hey, I think we can help you here, you know, but it's absolutely up to the customer as to whether they want to adopt these things or not. They're all opt in and opt out and you know, we've had folks that turn on a thing and think this is going to be a great idea and then they're like, actually it was a terrible idea, it just generated a lot of noise. But you know, we also take the same approach to everything that we build. And in the automations it's a little bit like Legos, you know, and if the audience is more developer oriented they might enjoy this. But there's basically like a lot of like little custom conditions, custom actions and like there's a whole rule set and there's like a YAML that's behind all of these things. And so we have built a marketplace that lets you just say, hey, we put together a YAML for a very common thing that you might want to accomplish, but we've also allowed you to like just add custom. And then we say like, look, you can, you can build the craziest LEGO thing you've ever wanted. If you want to build a LEGO Death Star, you go ahead and do it, you know, and then you know, that allows you to get like very, very customized with the automations that you want to do.

Gregor Vand (34:29)

Nice that you've got that in the platform already, that customization piece. I mean, I think, you know, Sleuth, you're still a fairly young company. I believe you've got a lot of quite big names on the front page, you know, the trust banner as it's often called these days. Could you just speak a bit to kind of what was your. I mean, especially for, you know, we've got a lot of developers in the listener base and startups generally like your kind of go to market. Like what did that kind of look like in terms of getting these sort of quite big names on board?

Dylan Etkin (34:55)

Oh man, you know, startups are rough is what I'll say. I mean, you know, I would love to just tell a story of a forward sprint and winning the world record in the 100 meters or something like that, but that's not how it happened. You know, I mean we started with this idea of deployment tracking which, you know, we were like, hey, this is a great area. And you know, didn't quite find the traction that we wanted there, but really set ourselves up to. It was fun. We were always surfacing kind of dora metrics on the side and then like we had all these customers being like, I love that stuff on the side, could you put it in the middle? And we were like, that's a, that's a good call, you know, and same with like, you know, expanding out some of these metrics. But, you know, as. As you do so you start to get, I don't know, a little bit of noise. Like, we were fortunate that we did have the DORA folks out there because, you know, originally with deployment tracking, we were just trying to build a space, which I would highly recommend that nobody does as a small startup, right, you have only so much energy and time and you're probably better off spending that energy and time on product market fit rather than educating a market that they need what you have. So that was a really big helper for us that organizations that wanted to adopt metrics, they basically would do some research and end up at DORA Metrics. And that's how Puma and Red Bull and some of those folks ended up coming our way where they just, we know we need this, we know we want to do this. We did some research. You guys seem like the ones that are killing it in this space.

Gregor Vand (36:23)

Yeah, I think that's great. I'm sort of in the same boat, the same situation. The sort of common wisdom is exactly, do not create the space. Find something where people are actually actively going out and they want to put money down somewhere. They know they've got this thing that they need to be solved. But how do you angle and fit your product into that, solving that problem? As much as, I think as developers and dreamers, I think you can call us that, we always think there's a better way to do something and there's this grand solution out there that if only people knew about it. But reality is actually businesses that want to pay money for products, it doesn't often start that way. It starts with a existing need. And I think, yeah, anchoring around a established framework like dora, that's a really smart way to approach that. So that's super interesting. And just looking at the, I guess, future for sleuth of what you can reveal, what are you going to be adding to the platform? I know six to 12 months. What does the roadmap look like?

Dylan Etkin (37:24)

Oh man, there's always like 50 million things that we want to do. So like, prioritization is like, you know, one of the hardest things that we've got going on. But I mean it. With the Pulse platform, it's really exciting because we have all of these widgets that allow you to tell a much broader and richer story. And there's also a whole aspect that is just like collaboration. And so, you know, we have like a v1 of like almost like a GitHub workflow review. So like you can go in there and say, I own this section. I want to be reminded that I need to have this done by a certain time. You know, like I want to be able to approve and request changes. We have like improvements to that. We have like just so many capitalization widgets and other cool things that we can do with the data that we have. It's really just around telling that much broader story. And honestly I think some of the automations that we have right now are very oriented towards the DORA side of things. But there's a ton of very, very interesting things that you can do at that sort of executive level too where you're just saying like, hey, I'm not just automating like code flow stuff anymore. Now I'm getting into helping the business to remember that you need to do your quarterly goals or your. You know what I mean? Like there's so many things that we do in the world that automation and data and interpretation of all of those things. There's a lot of really interesting potential there. So I guess that was sufficiently vague for a future roadmap. I would say anybody who wants to really know, jump on a call with us and I will talk to you about our next 6 to 12 month roadmap.

Gregor Vand (38:55)

Yeah, absolutely. So we'll wrap up shortly just with a couple of set of side questions. But before we do that. Yeah. Where is the best place to. You want to actually try Sleuth out or speak to someone? Where's the best place for them to go?

Dylan Etkin (39:08)

I mean our website is the right place to go. Go to sluth IO. There's a big button that says talk to us. If you're interested in just trying out the DORA stuff, you can follow a link that lets you self sign up for that. We also are really big on openness, so our DORA projects are all available for anybody to look. So if you want to see what would this look like with actual data in it, you can see the pull requests that we're working on and see what our change lead time looks like. Spoiler alert. It's pretty good.

Gregor Vand (39:34)

Awesome. That's really fun. Yeah. So that's Sleuth IO S L E U T H I O. Okay, so just a couple of kind of final questions I ask most guests now. First one, you know what is just a day in the life of Dylan, CEO of sluth. Like what does that look like?

Dylan Etkin (39:53)

My calendar drives. My day is a lot of interrupt. It's good stuff. I mean, let's see today, talking to a new hire, just about overall direction of the company. Also doing some marketing activities with my cto. We're running this like kind of fun campaign where we're interviewing some engineering leaders and then turning that into like a tag like of this interesting stuff. What else was on my calendar? I'd have to look at my calendar. I can't even remember.

Gregor Vand (40:18)

A podcast, apparently.

Dylan Etkin (40:20)

Oh yeah, a podcast apparently. At the end of the day. Yep, absolutely. I did one of those interviews for that campaign. We're using an AI based SDR tool so like jump on a call just to like make sure that that campaign was up and running. It's a lot of different things, but that's why I'm doing it, because it's kind of fun.

Gregor Vand (40:39)

Yeah, absolutely. Couldn't agree more.

Dylan Etkin (40:41)

Don't look for focus time though.

Gregor Vand (40:42)

No, that's hard to find. And yeah, final question. Just if you could give advice to yourself when you were starting out in tech, knowing what you know now, what would you say?

Dylan Etkin (40:53)

I would tell myself to potentially be a little less opinionated and a little more listening. That's generally been a journey of my entire life. But if I look back at me back then, I think I knew the answer to everything, which obviously is wrong and definitely had a little bit of that arrogant developer. Like, I know how to fix things, so I must know how to fix all the things. Things. And yeah, looking back, I'm sure it wouldn't have hurt if I was a little bit more like I am today, where I'm much more able to hear others and be more open minded to different opinions and different potential possibilities. But then again, maybe I just had to get old in order to get there too.

Gregor Vand (41:34)

That's good. You wouldn't be the first developer originally turned CEO that we had on the podcast, where that's actually what they've said as well. And I think it just makes a lot of sense. I, at least with one other sort of agreed on that point that unfortunately a lot of us start out very opinionated, thinking we understand the world inside out. But as we get older, it's not often the case.

Dylan Etkin (41:55)

Not entirely true.

Gregor Vand (41:57)

Funny that. So, Dylan, very great to have you on the podcast today. I think we've learned a ton about sluth. Again, just a reminder, SLUTH IO, that's where you can go to check out the product. Just really interested to follow along. I really love the kind of concept of this product, given that it's not trying to replace Ajira or something else that is really trying to help the whole developer experience and all the engineering experience effectively for everyone involved. So, yeah, I just want to keep it up. Want to follow along?

Dylan Etkin (42:30)

Thanks, man. No, this has been a really fun conversation. I appreciate it.

Gregor Vand (42:33)

Thanks a lot.