Made by
Made by
Head of DevRel
Ambassador Labs
DevRelCon Prague 2022
In this talk from DevRelCon Prague, Daniel Bryant asks whether Product Led Growth (PLG) can do the same job for DevRel and DevOps has for engineering. In other words, can PLG help DevRel break down silos in order to be more effective across the organisation?
Daniel talks about how PLG emphasies establishing cross-functional teams with common goals and common language. How does that relate to DevRel’s superpowers of empathizing with developers, identifying user value, understanding end-to-end experience, and regularly experimenting and reflecting upon feedback?
Daniel Bryant:
So, yeah, welcome to is product led growth, the DevOps of the DevRel world. Now I start all my talks with a bit of a high level tl;dr. I’m gonna whistle through these points, don’t worry. We’re gonna cover them in the talk, and I’ll put this slide up at the end too. I think Product Led Growth when done well, can break down barriers between departments and teams to drive more adoption and ultimately revenue, right? And this is where the DevOps thing comes in. Devops, cats, dogs, chalk, cheese, call it what you will right. I think PLG can be a useful tool in the DevRel toolbox to break down some of the silos. We have a lot to offer here in terms of PLG, right? And whistlestop empathy superpower of the DevRel, right? Thinking about end-to-end developer experience, another superpower of ours. And identifying how users, developers get value is key.
And these things relate to PLG. A key takeaway, hopefully you’re gonna hear me multiple times say, is establishing a cross-functional team with common goals, language, and understanding is critical. I had a fascinating chat at speakers dinner last night, and I’ve seen it from some of my buddies as well. People have tried to bring in the latest hotness that is PLG and it’s not worked. And often it’s lack of leadership. People are saying different things all the time, using words, think they mean the same thing and not and there’s a lack of alignment, right? I’ve been a consultant in a previous life and I saw that quite a lot. So cross-functional team for the win, very briefly @DanielBryantUK on most of the interwebs, GitHub, LinkedIn, all the places. My background, it’s like Pokemon job titles, I’ve tried to collect them all.
I’ve been a developer, I’ve been an operator, I’ve been a architect. Did a CTO gig a few times. I started my career as an academic of all things in, in artificial intelligence. So I just love learning. And what I’ve come to understand, I think about myself over the years is I like to be the bridge between technology and people. And that’s what we all of us love at DevRel, right? So yeah, find me, I have a couple of books actually. ‘Mastering API Architecture’ has just been released, perfect for loved ones at Christmas. Who doesn’t want to learn about mastering API architecture? My buddies, Jim and Matt. So yeah, just that last week it got released. Thank you. So, setting the scene I don’t really need to do this definition for this audience, right? But I wanna put up for completeness, for me, DevRel is about building that community of mutually beneficial relationships.
That’s key. And we are put towards purchasing, using a product. I think that’s, you know, critical as well. In my definition of DevRel. I think this is more interesting for like this audience, right? This is my take. I’ve tweeted it a few times on what DevRel at Ambassador Labs is about. And I joined the company, you know, no product market fit, five people in a WeWork in Boston. And now we are a lot further along than that. But I was doing all of this at the start, right? And I have an amazing team that works with me that do this. But that’s the definition that I work with when I talk about Dev Advocacy, DevRel, think about awareness, education, tech demos, community building, empathizing, acquiring feedback. We’ve had it all already today in the talks, which has been fantastic to see. What is product led growth.
And for me, it’s, I’ll read off a slide here. PLG is a business methodology in which user acquisition, expansion, conversion, and retention are all driven primarily by the product, right? And that comes from ProductLed.org. And I think the direct opposite that helps you is sales led growth. I started my career that where sales folks were calling like cold calling, cold emailing, trying to sell the product. When you want to expand, you sales folks would reach out and call again. So the growth of the company, of the product of the user base was driven by sales. PLG is driven by product. And many of us have been doing PLG for many years, right? Think of open source, pretty much kind of PLG led. Think of SaaS, Software-as-a-Service kind of PLG, like, right? It’s a bit like DevOps. We would, many of us were doing DevOps before it was labeled that.
But the label helps the community form around it. Patrick Debois, Nicole Fork, Jean Kim, all the fantastic folks. We’ve got many folks in the audience already. Matt, I’ll see you there as well, that have really contributed to the DevOps idea. We rally around this, what we’re now calling a thing, DevOps, PLG. And I think DevRel has a lot to add to the PLG space. We’ve talked about friction already today. PLG is about folks, you know, getting started really quickly, getting hands on. And the folks that are using it can buy, start with swiping that credit card and then level up, think Datadog, think Snyk, think all the cloud services, right?
That’s correlated. Now, I’ve got the links at the end, but they’re an awesome podcast to check out. Now I show my age a little bit here, right? I started when it was very much the on-premise era. And you look, we’ve moved into the kind of SaaS world, think Salesforce, HubSpot, that kind of stuff. Github in our world, right? And now we’re going into this age of PLG. And things, you know, I’ve put this more for like your reference later on, I’ll dive into the important things on the next slide. But things just change. Things evolve, right? And we need to co-evolve the approaches we use whatever role we’re in. But definitely in DevRel, we need to co-evolve those processes. PLG is very much a bottom-up go-to-market motion, right? It’s not sold top-down no more what I used to call ‘golf course’ selling, right?
And I started my career again 20 years ago, right? Show my age. But I’d roll in as a Java developer on Monday morning and have to adopt a new ESB, a new message bus, a new application server. And my boss had done a deal, like, and it was all legit, as in they’s not saying anything shady about this, but they’ve been sold over a number months, right? On the golf course, wind and dined. And they had now bought this million dollar contract that I and my team, we had to go and make work as developers top-down, right? Wasn’t great, if I’m being honest. I like the bottom-up approach, in terms of that. We wanna get hands on these days, right? And then we’ve had the talks say that already. I’m a big fan, you know, give me a quick start on searchable docs, happy days, right?
And I was at KubeCon Detroit recently, and folks were coming up to the booth. I was doing my pitch Ambassador Labs, what we do. And I was, you know, selling the value. Buteven the really C-level folks, the high level flight folks in an org were still wanting to get hands-on with the tech. Like I’m chatting, just think this one very high level person who’s asking great business led questions. And suddenly he dropped down and went, I wanna play with this. Where’s my docs? Where’s my, where can I download the software? And I was like, huh, interesting. Right? Everyone wants to get hands on with the tech.
We’ve had it said today, but show me the value in my workflow. That’s what, when I started poking a little bit of why he wanted to play with it, he was like, I want to understand and plug it into my workflow. The demo you showed me looks great, but I wanna see how it looks in my system. I’ll download the thing, plug it in, connect it up to your cloud, see what it’s like. And a lot of developers don’t like talking to sales, right? And I’ve been there to be honest, but there’s a lot. I’ve worked with a lot of amazing sales folks in my time as a developer, my time as dev advocate. But I think the bad ones stand out quite a lot. The ones that are constantly spamming you on email, the ones that are cold calling you with inappropriate job offers or inappropriate products, right? So I think a lot of us as developers are a bit like a natural aversion to talking to sales. So the fact now we can jump on and try our own, like try the product ourselves. And we’ve been like cloud-based consumption, like pricing now is a thing. We’re totally used to swiping a credit card, paying five bucks or whatever, five pounds, five euros, five krona, or crowns, whatever your choice. And this becomes more normalized now, right?
For me, DevRel and growth is the bridge between developers and sales, between developers, sales and product. I should have probably put in there as well, right? And this is where DevOps plays into it for me, right? Got to hat tip, Andrew Clay Schafer, I think who’s already been name checked today at Andrew Andrew’s awesome. Learned a lot from Andrew over the years and this is an awesome blog post for someone else as well. I’ve linked there, but Andrew first introduced me to the wall of confusion many years ago now. And it made sense in my world at the time. I think, that role, I think I was playing a dev role. And frequently we get, you know, the business requirements handed down. We build something, QA would go, we’re good. We throw it over the wall to ops and they’d have a hard time running it and they throw it back to us and we are cats and dogs, right? Just speaking different languages, doing different things. What if I change the silo names for a minute?
Does that look familiar to anyone? I’ve definitely had like heard of worked with maybe teams where products would go, Hey DevRel, we’ve got a new feature for you. Cool. Like understand how it works. Oh, great work with growth or, marketing. We, we call our team in Ambassador Labs growth, effectively marketing. And then we pass off, you know, we generate market qualified leads, sales qualified leads, MQLs, SQLs, we generate that for sales. And sales will be like, these aren’t the customers we want, right? And it’s like, ah, goes back to DevRel. Oh, we’ve misunderstood perhaps some of the product, right? But there was a bit of that cats and dog relationship between all the folks in these silos here. There was walls of confusion across all the different teams. And that’s why I think we can learn from the DevOps playbook of breaking down some of these silos.
So my experience is quickly not doing the product pitch today, but very quickly, just to give you context. So I’ve been working at BAS Labs now for five or so years. It is now a series B funded Kubernetes tooling company. We’ve got two open source productsEmissary-ingress, CNCF tool and Telepresence. And Emissary-ingress is an API gateway for Kubernetes. Telepresence is a remocal, remote-local dev debugging tool. And we layer on product led and sales to mar sales led go to market motions for a open core version of the API gateway. So Emissary-ingress we sell as Edge stack, bit of a SaaS component to it as well. And telepresence has got kind of a SaaS component to it as well. You install it on your local machine, you install it in a Kubernetes cluster, but the SaaS product kind of joins it together.
And the SaaS aspect is kind of interesting for product led. Interestingly, I saw someone else flag this. We do, I do my team, we report into the chief marketing officer CMO, right? I’ve worked in some companies where I reported into engineering. I’ve even seen some companies report into sales as an example in the minority with DevRel, but that does happen too. So we have got a kind of marketing theme about us, right? We report into the chief marketing officer with that context, breaking down all the silos. Is it ProdLedBizEngRel not quite as good as DevOps, right? But work with me here, I’ll come back on on that in a moment. But we lent heavily into PLG for telepresence selling our commercial tool telepresence in early this year. We created a cross-functional team at the time it was driven by the CEO, Richard Lee, co-founder as well.
And he assembled an awesome team of growth marketing folks. Kelsey Evans, a shout out who led the charge there with growth engineering, who are effectively engineers with a mindset of very business focused and happy to run rapid experiments. Not every engineer wants to work like that, but we found some awesome folks that did, which is, that’s a critical thing for growth engineering is a bit different than feature engineering product folks. Richard actually ran that show cause he was a founder. He sort of knew the vision there. Devrel, that was me, right? And then we had sales folks. Typically the business development representatives, the BDRs were in the loop because we were handing off interesting product qualified leads as we called them there, kinda like MQLs, right? We were handing off those leads to the sales folks and they were then working them and you know, making, making money.
We had a weekly review of our funnel, which you can see here. And the, the classic kind of funnel, right? Awareness, consideration decision with product led growth. You can see in the middle here where the product experience kind of allows folks to self-service to become a customer. No longer do you go MQL, SQL opportunity sales on the call sort it out. We do have sales get involved sometimes, but you can just go straight through and self-serve on the credit card. That’s fine, right? And PLG, that works quite nicely. I mean I’m sure if you work in marketing like, like I do, you see a lot of funnels. But critically for product led growth, we do a lot of experiments in the product. And this is where SaaS comes into play, right? We tweak things. It can be as simple as how a button looks, but it can be as you know, as rich as features and competitions.
But we’re doing one to five experiments a week. Try. Does it drive conversion, activation, different kind of behaviors, right? And we look for signals that that’s a win. So hopefully that sets the scene for kind of how we, we did PLG. Oh yeah. And I will say we mentioned PQLs, which is product qualified leads. Well also some folks call them PQAs, but those are collections of PQLs to become a product qualified organization. A product qualified account. And the interesting thing you’ll see is once you’ve got more than a handful of PQLs at one organization, they’re more likely to buy. Does that make sense? Individual developer might buy, but when we’ve got two a three Sneak have played this really well, Sneak like, they kind of like, it’s very viral the way they do it. They get into pull requests, you like Sneak the value’s, awesome. They’ll scan you code for you. But then you see the, the like the Sneak pull request and suddenly before you know it, all the folks that are product qualified leads become into a a PQO. They turn into a product qualified organization. 10 developers are using Sneak 10 developers are using our products, that kind of thing. And we call them optees, opportunities. That’s who our sales folks, our BDRs, our SDRs, that they actually reach out and, and email and engage and offer like educational material to folks that may wanna buy our products too.
As an example, experiment. And I’m just gonna share the DevRel superpowers example experiment, large bet for KubeCon. So we came up with a hypothesis, and I’ll break down how we do some of this stuff in a moment. But if we guided users through a typical case study of building an app and deploying it and releasing it on Kubernetes and showing them how our products play into that workflow, could we get folks to activate as in use our products and become product qualified leads with multiple products? Cause we’ve got, you know, three products depending on how you count them. We actually spun up this K8s in 8. We did an eight mile Eminem theme as well. It was quite, quite fun at the, at the event. And we basically had eight steps where you like install the application.
And, and you can imagine we can play around and experiment a lot with this. We can change the steps, change the order the way we do the kind of calls to action, the docs we provide. We can just do a lot of, this is a, this is a bigger bet, but we can do a lot of experiment, experiments to see how people interact with the products. And then metrics wise, we are looking at how many folks can we drive top of funnel, get them looking at the page, how many folks sign into our cloud product to begin the challenge? And then how many folks get so far along completion percentage, right? And then we look for the PQLs. They only become a product qualified lead once they have activated with their own services. We give them a demo cluster and demo service to spin up.
Like it’s literally spin up within, within like two or three minutes. But we, they become a product qualified lead when they’ve plugged our technology into their own ah, applications, their own cluster. And then if they don’t become PQLs, maybe they’re just happy ticking along. Cause like we’ve got an open source offering, a freemium offering, they just become monthly active users, MAU we’re cool with that too, right? That’s, that’s no probs. So that sets the scene for I think the superpowers. If you are looking to get into PLG, if your company’s looking to get into PLG and all the cool kids are, right? And, I say cool kids with a bit of irony, but everyone’s, I think it’s gonna be like DevOps now. Everyone’s agile, everyone does DevOps, whether they really do or not, right? It sort of becomes a bit meaningless after a while.
But I think PLG at the moment is a thing, right? And it’s, it’s a very interesting kind of space that we can learn from each other in this space. So a DevRel superpower is empathizing with users to drive effective experiments. I think DevRel, like we can really help a lot with effective hypothesis generation. Like, and I, my team a often chat a lot about does this idea that the product folks have got all the sales folks, does it pass the developer sniff test? Cause we come up with some amazing crazy ideas, right? And then we as developers, cause a lot of us on the team are ex developers, were like, I don’t know, I don’t see myself doing that to be honest, right? And we, we can kind of give more context to the experiments. Our gut feel isn’t always right. I have learned data analysis and storytelling are a PLG superpower. And Kelsey, who I mentioned who leads the team has two data scientists reporting into her. And they have shown me the light when it comes to data. I mean, I guess I’ve got a data background, but in, in the way they tell stories and come up with hypotheses, there’s a lot of metrics in our products. They emit certain things when people do certain things. And we have learned a lot of how to make the products better for folks, right?
Data doesn’t lie, but it doesn’t tell the whole story. We found qualitative data can be very useful. And this is our domain, right? We are really good at chatting to folks. We’re really good at listening or, you know, that’s a key thing with DevRel, right? And, and like sort of helping generate hypothesis, or even that sniff test, run it by a few trusted folks in the community. Does it make sense? Get that feedback and iterate. Don’t discount the value of talking to actual users and your community. And I think to this audience, it kind of makes sense, right? But I’m gonna give you some ammunition here, right? Because this is what I find a little bit in the company. The data scientists are not like they love data, right? Cause that’s why, you know, they’re data scientists and they’re a little bit reluctant to ask us for help sometimes.
And I was waiting, oh, shortly they’re gonna ask me to do some in user interviews here, maybe chat to some community folks, tick, tick, tick, tick, tick, more experiments, more data, tick, tick, tick. And I’m like, we should just chat to some folks. I think like the experiments wrong, but I had to proactively reach out and I’m being a bit facetious. See, the team is amazing that I work with. But the, there was a few times where I was like, hey, my team can really help shortcut these experiments. This is the domain of us, the DevRels, right?
We are really good on focusing on the end to end experience. This one came to buy us a few times. Rapid experimentation is a superpower, but with all great power comes great responsibility, right? Very easy. Particularly if you are not particularly developer savvy or technology savvy, like some of the marketing team, they’re not developers, right? Totally cool. But they got caught in doing small optimizations, which for us as developers didn’t actually make sense. And we had to work with ’em. Go, Hey, I see what you’re trying to do with that small optimization, but it actually makes, it increases friction for me as a developer, right? What the antidote? We actually did some stuff that locally made sense, but globally convoluted the product sometimes. So what I learned, my team and I, we reflected look always at the end-to-end experience of the product, engage that beginner’s mindset.
So even as an expert or many of us have been, you know, in the industry for a while, being able to switch on, we’ve done all these experiments recently, we’ve changed the product. How would a beginner interact with this product? What’s their time to value? Does the, do the docs make sense? Right? Think about jobs to be done. Like classic one with the API gateway is can I route traffic to the backend? Can I do rate limiting? Can I do auth, can I do TLS? And it’s very easy to make that journey harder by doing experiments. Think end to end. That’s really, really key. Think jobs to be done and do regularly run through the signup, the activations and the aha, the wow moments, right? Because again, you can get caught in these local optimizations. You reach out to, you know, the product team, the eng team and say hey, I think what I’m seeing here is you’ve tried to optimize for something and created the wrong actual outcomes, right? And my little joke here right, is we had this a few times where like we’re like, Hey, optimize for this thing and then Ashley was bad. Things came out of it. All right? So engine, we’ve got you covered. Do short experiment and the Growth Eng team might be fair. Fantastic Ambassador Labs and it was more on us for not perhaps explaining the context around what we wanted to optimize for. You don’t wanna burn the house down for the sake of keeping everyone warm, right?
In terms of identifying value aha moments, and potential for virality dev, again, we are really tuned into how users get value our products. And that can be quite hard to understand if you’re not in this space. I’ve definitely had some variation chats with, with the sales folks. We are often the stakeholder closest to the community. I think that’s how I define DevRel, right? But sales can provide a lot of good value from users and buyers. Combine this with the support and CX folks and you’ve got magic, right? It’s very tempting just to say, Hey, DevRel sees this from the community. But we found the feedback we were getting from customers was actually very different to folks that we were engaging with in the community. Community skewed open source, right? They’re happy just doing their own thing. Happy knitting stuff together. Buyers were like, I want it working and I want it working yesterday.
And the support folks were seeing all manner things which pointed at hey we need to fix docs. We’ve made it harder for folks. And we also learned to create some blog posts. Blog posts, sorry, from some of the friction that the CX and the, the customer experience team were seeing. So combining all of our views led to a really rich kind of understanding of how to make the product better. Devrel can tell the story of the user’s path to value the, you know, we, we chatted with all these stakeholders but then we kinda mapped it back and said the what, where, when, why, and who gets the value? And critically, we, we worked with the data team and said, and this is how you measure that thing. Cause like it’s very tempting. You measure everything and understand nothing, right? So we measure, we said these are the things you wanna measure.
This is when the developer is happy. And that kind, or for one of a better phrase, that kind of thing. We looked a lot at friction. We talked, we heard that one mentioned today already. Again, as a developer with a developer hat on, we were like, this is clearly a friction based, this is not, that was super useful for the engineering team. And we talked a lot about getting to the wows, the aha moments and how to increase the virality of the product. Invite fellow, you know fellow community members, that kind of thing. I’ve got, but Dilbert comic on this one, I think it’s like we’ve got, you know, we, no, no pointy head bosses at Ambassador Labs, but I’ve definitely bumped into similar stories from my buddies in the community about, and I actually heard, someone mentioned it earlier on, didn’t I think in the panel about do focus on the path to value not monetization.
Because a few times folks in like in the chats were like, Hey, if we just do this thing, we can drive more revenue and like, yeah, maybe, but at the expense of long-term value for the users and devRel is the voice of the community, right? And while I was saying, hey, long term, I don’t think that’s gonna work and it’s, it’s a trade if I’m not saying I was right. It’s always a balance, right? But I raised that point, my team and I raised those points as in, hey, the path to value here is this monetization might come a bit later, right? So focus on the path to value for your users, not the money is my advice. Wrapping up, right? This is new. Like listen, if you aren’t, you aren’t doing it wrong If no one knows what you’re doing, that’s what I think with DevRel and PLG are all about at the moment, right?
We’re still learning, we are all in new territory is my pitch. You do need strong growth marketing leadership and I’m gonna shout Kelsey and the team and our leadership, our our C level leadership really support us here because it is kind of new this thing and there’s plenty of opportunities to make mistakes and that’s fine of course, right? But you’ve gotta learn very fast from those. So strong leadership someone having accountability for running the experiments, which in our case is Kelsey. She keeps us all honest. She coordinates us once a week meet, sorry, once a week to meet. And that’s made a massive difference why PLG I think has worked here and hasn’t worked well at other orgs. So my buddies I’ve chatted to you knew those clear goals, clear charter and common language when I was a consultant, sometimes I’d go into companies and the fact they’re all falling out was cuz they used the same words to mean different things.
So what does a PQL really mean? What does an MQL really mean for ambassador labs or your use case, right? Cross-Functional teams. I learned so much from all the teams in the mix there. Sales, product. Yeah, awesome. Love that. That’s where the DevOps thing kind of come, come together For me, I learned to embrace the scientific method more. Not to discount the DevRel superpower of community of empathy and engaging, but data is really interesting and the modern data science stack that we built in Ambassador Labs yeah, it’s just fantastic and there’s so much to learn from that. And finally, don’t forget to regularly retrospect obviously an agile principle a few times we, we sort of like skipped over and we made the same mistakes with our experiments. So I’ll put, I know it’s an obvious one, but I made that mistake.
We all make that mistake I think once, right? This is the, this is the key I think to success. I’m dangerous running outta time here, so I’ll just put a slide up again. I think PLG when done well really is key for, you know, you can use it as a tool, a DevRel tool to break down barriers across the org to drive that more adoption DevRel. The superpowers within PLG are empathizing with the user, thinking about their end-to-end developer experience and helping the rest of the team understand the aha moments, the user value, that kind of thing. But really, really key here, establishing that cross-functional team, common goals, strong leadership, common language and shared understanding is really key. Personally, I’m all about the DevOps loved it when it was coming out. I’m all about the prod led biz eng rel, but let’s just call it PLG. I think it’s just be easier, right? But it’s the kind of same thing. If you think about that, I’ll put this up. You welcome to contact me, be around the conference the next couple days for chats. These are awesome podcasts I’ve learned from Breezy and Wes amazing newsletters from ed and Lenny and Kelsey, myself and Adam, my buddy. We put together some stuff for the new stack on how we do PLG at Ambassador Labs. And at that point I shall say thank you for your time.
Matthew Revell:
Thank you Daniel. We have time probably for one question if anyone has one. Oh. All right. We’ll make it. So yeah, we’ll make it two because neither of you have asked a question today. So
Question asker 1:
So I have two questions, but I think they’re kind of related. The first one is, you said that in the ambassador labs you coming up with four or five tests a week.
Daniel Bryant:
Yeah.
Question asker 1:
Yeah. So that’s the first question is how yes,
Daniel Bryant:
They can be, oh, and I’ll ask, like they can be super simple. They literally can be changing the text of an instruction, changing a button placement or changing the reward for an action. So that like think small, small is beautiful here. Right?
Question asker 1:
Okay. And so basically it’s lead to the second one, which is how often you come up with hypothesis. Hypothesis,
Daniel Bryant:
Hypothesis, hypothesis. Yes. Tricky. Yeah. Yeah. Now I’m with you. How often do we come up with hypothesis? Oh, great question. We have like, sort of quarterly goals, like OKRs, KPIs sort of mapped down to some hypotheses. Then I’d say we have like monthly ones and then even like weekly ones. And it’s often driven by of late, it’s been like spikes in the data. So suddenly like something drops or something goes up crazily and we, whether it’s good or bad, we always wanna understand, right? That’s, we’ve learned that lesson like for a while. We’re like when it’s good don’t ask any questions, right? When it’s bad. Oh my god. So like we learned like, but we learned to ask questions on both the things. So a lot of the data now drives our hypotheses. It took a while to get us working, like chasing the business value, helping users. We’re pretty good at that. Now, now it’s more of a case of we release a new feature and we’ve trip over ourselves with bad docs or, or something like that, right? And then that drives the experiment. Should we create a like to riff on Kevin’s talk? Should we create a big demo project, which he’s done a few times, or should I create on like a, a small demo to prove this out? That kind of thing. Right?
Question asker 1:
Got it. Thank you.
Matthew Revell:
Okay, Phil,
Phil Leggetter:
Really quick one what tooling do you use for instrumentation and analysis of data?
Daniel Bryant:
Oh, what all? There’s, there’s lots of them. So we emit a lot of metrics via the product itself. So we use Golang primarily. We just emit metrics and we collect it in Metadatabase and we use D B T and a bunch of other stuff. I’ll be honest, it’s not fully my area of expertise. This one, the data team have built an amazing data stack and I’m hoping to get them presenting at some point. I’m more consumer of that data, I’m being honest. And I use metabase to consume the data and they built me some awesome webpages too. You’re not the skeleton. No, I’m not The skeleton, right, exactly. I was for a while, but no longer. Yeah. Yeah. Great question.
Matthew Revell:
Well, thank you very much Daniel. Let’s thank Daniel. Cheers.
See more from DevRelCon Prague 2022 here
