If I can be known for one thing, it's like preventing the graveyard of, like, great products because of, like, bad business. 10 times more open source and, like, 10 times more happy engineers just because, like, everyone's just much more massively profitable.

Today's episode is with Angelo from Railway. What I really love about Angelo is he has this real strong business mindset combined with technical skills, and he just writes, like, incredible articles about very technical things in sales, like Slack automations and stuff. And in today's episode, we talk about how they've been able to, like, massively increase response rates from their customers, have enterprises just sign up and start paying with their Brex account. This conversation was very, very fun for me, and I think it'll be fun for you as well.

You know, I joined Railway as a support engineer because I was a very active and avid user of the product, and I was the closest thing to, like, a nontechnical hire because I was interacting with customers all the time. And then we start getting emails from people being like, oh, crap. Can you talk about railway to my boss? Can you start, you know, like, at we're getting questions about not about the product, but how railway is as a company. And I think that's kinda when I realized, alright.

This we're gonna have to deal with sales eventually. And that was a beginning of a very long and painful journey of, like, learning a bunch of different mannerisms and things of being able to, like, just land a product into a company. So, yeah, that's kind of that's kinda where we're at. Yeah. There's a few threads that I'm, like, right now kind of going through my head.

One is whenever you join a startup, you join a startup because there's a strong vision about how things should be done. Right? Railway's point of view in the world is that infrastructure should work, and it should be beautiful. Right? So that was the original vision that got me on the board.

However, you know, many people who join a startup live in this really weird dreamy fantasy world of the future, and then you start talking to customers and leads, and they're living in the very dreadful reality. And you have to do a lot of work to get them out of their usual day to day cynicism, which is fair, by the way, to start buying into the way you do things.

So yeah. And I guess there's also, like, some of it is, like, when you're building the you're trying to build the product and the vision, you've got like, I think when I interviewed Jay before, like, was saying this is, the hardest problem that you guys are working on the hardest technical problem. So I imagine there was also, like, just, like, a lot of figuring things out as well, like, at the beginning.

Oh, absolutely. And the worst part is, like, I I mean, I think Jake would disagree, but I think, like, our customers don't care. You know? Like, oh, like, I I I don't you know? Oh, so what?

You're dealing with, you know, like, weird object storage limitations. I just want the thing to work. Right? Yeah. So, you know, I think the number one thing that when my initial assumptions whenever I started to moving towards sales was that, you know, I would just be going in front of customers, getting them invoices, signing kind of LOIs or signing these deals, and then the actual practice was, alright.

I'd be going into these demos with these, like, really high aspirational kind of, like, this is the, you know, Canvas. And, you know, you can deploy minutes and not days. But then when the actual pain points that our customers were experiencing were much more pragmatic and much more, like, you know, heck, even emotional in some cases. Like, will this tool that I implement at this company get me promoted? Right?

Those are concerns that I even didn't consider at all whenever working with those accounts. And that was a whole different entirely skill set that I had to learn to be able to kind of navigate that. So meanwhile and then, again, you know, you you should listen to Jake episode if you can. You know, he's out here in the, you know, in the high minded dream world and trying to make dreams reality. And, you know, my you know, You know?

People are complaining to

me You're about taking out the bungees.

Do I make Terraform work? Yeah. Yeah. Right? It's like, customer's s word, give me better Terraform.

He's like, we're not doing that. You know? So you know? And then going back and forth with with Jake. You know?

Yeah. Like, Zara, I was going sidetracked. Like, do people literally say to you, like, this will get me I care about my promotion, or is it something that you kinda have to, like

No. It's something that you have to be really good at, like, teasing out of people. So I think, like, you know, to kind of perface this. So I I moved into, you know, revenue side at Railway, I would say, probably two years into my journey. So for context, I've been at Railway now for four years and three months.

And, you know, the latter half of that has been mostly focused on compliance and revenue stuff. And and, arguably, the compliance stuff is the same side of the same coin, right, when it comes to revenue conversations. And the problem with, like, I would say, technical sales is that a lot of engineers are sometimes bad at indicating what they want, if that makes sense. So I I'll I'll use I'll use a, like, a really hard example. So, you know, we get an ask from a lot of customers about, like, infrastructure as code.

It's, like, quite a big ask. And it makes sense because a lot of them have been trained through a variety of, I would say, existing material, either through your boss or through the Google SRE manual, that all changes, like, should be versioned within a file and then sort of in Git. Right? And there's a lot of benefits to this world that we live in, and, arguably, you know, it made the cloud revolution possible. However, right, what IAC kinda struggles with is, like, how can I audit the whole chain of changes between an infrastructure organization and, let's say, like, a product team?

Right? So, like, if I'm a product organization and I'm building a new product, I now have to interface with this, like, weird YAML y API, and no no shame to YAML, in order for me to, like, get my infrastructure provisioned just so I can, you know, deploy new product initiative number two. Right? And now I have to go speak this entire new language to this, you know, separate team. So the infrastructure like, the way it looks like to the infrastructure organization when we talk to Railway is, like, give me better IAC.

Can you make it so that these product teams can speak IAC? The product engineer absolutely does not care about that. Right? They're just like, I have this GitHub repo. I need it to be live.

Can you help me with handling the political process internally so I can actually get the resources that I need to actually go out there? So, like, you know, I'm already, like, two minutes into this explanation. If you take them at their face value, give IAC, but then if I peel the layers back, no. Why do you want this? What's actually your upper level goal?

What is your true intention? Then we're able to kinda peel back the layers of their intent, then we're able to have a much more substantive conversation. Whereas really bad and I don't wanna, like, knock any SDR that you probably have experienced. Right? But sometimes the SDR on the other side of the line is not an engineer, and they're not able to intuit these things.

So they hear, I need IAC, and then they run to the engineering organization, be like, give me x feature. And then there's this, like, whole other internal battle between what sales thinks that they needs to be built for a company and what actually is your true product vision of your company and then practicing that. And it's a whole, you know, separate conversation.

Scaling DevTools is sponsored by WorkOS. At some point, you'll land a customer who needs enterprise features like audit trails, SSO, role based access control. You could spend ages tearing your hair out, building these things yourself, or you could use WorkOS. Let's hear from Uplal from digger.dev.

I can speak for open source companies because I think that's where I have the most experience personally. If you're open source and you're doing enterprise first, the minute you think about monetization is when you should think about WorkOS. How it's designed is that you can start as early as day zero. But for us, it wasn't day zero. It was closer to when we first started monetizing because we didn't have a sign up at all.

People could just anonymously use our tool. To be honest, if we do that again, I think we'd think about that on day zero, to be honest. Because, like, we should have done it on day zero ideally. Anonymous usage should be permitted, but you should know who's using your tool. It should be opt in 100%.

But it'd be great to have auth from day zero. So, yeah. That's what I think.

Thanks, Work OS. Back to the episode. Because I guess at some point, like, even if you're actually, like, technical, you know, if the salesperson's technical, it's like I guess like the the world that Railway is living in, it's get it gets very technical very fast. Like even if you hire like extremely technical salespeople, it's like, how do you kind of tie that up? Yeah.

It's like

There's there's a so I think the best way to kinda describe it is through, like, a narrative, right, between how Railway kind of, I would say, upmarket and rather swimmed upmarket, and then how I would say most companies like, if anyone else was listening to this and you're not Railway, right, how would they kinda, like, take this advice and apply it to their advice as they're scaling company from a from seed series a and beyond? So, like, Railway is unabashedly a product led growth company. Right? Mhmm. We make it insanely easy for you to, like, type in dev.new into your, you know, browser and, like, have at it.

Right? Yeah. And so, like, for us, the upmarket motion was basically a lot of engineers shadow IT ing railway to a company and then us having to explain post facto to an organization, no. We're actually can be trusted within your network boundary. And those are, like, you know, I would say good, but very difficult conversation to have, especially when you're a company that is very prideful, and I mean this, like, in a good way, about leverage within the organization.

And what that means is that, like, you know, at most companies and, you know, most sales organizations, the way a sales motion is kinda structured is I have, like, this pyramid of people. Right? I have, like, SDR, you know, from one through eight. It's kinda like a Kubernetes, like, you know, little pod structure. And then, like, I have, like, you know, all these eight SDRs assigned to, like, the Eastern Half Of The United States.

Right? And, like, depending on if these, like, quote, unquote, like, pods are healthy or not, I'm gonna call them and, like, fire them, and then we'll replace them with, like, better in you know, infrastructure. Railway, we don't necessarily have that privilege. Right? Because, like, a technical resource at Railway is, like, one, very hard to hire, and it's also very even harder to hire a technical resource that understands, like, how to interface with a company.

So, like, for us, you know, for example, I'll I'll, like, highlight my colleague David Echo, who joined us from GitHub. David, you know, when he works for accounts, he's a highly technical resource. With that said, at a more traditional enterprise company, there would be, like, a forking of a code base, they and would customize that code base to kinda fit, like, a large bank or a large customer. And then that one large customer would provide, like, 90% of your revenue. At our very start of Railway, Jake was very firm that we would not go off and do, like, engineering side quests to secure revenue.

Right? We wanted to make it so that we whenever we built features that moved upmarket, it needed to be extraordinarily painful. And I and I when I say painful, like, I'm probably underselling it. You know, I was never yelling internally, but there were times where I'm sitting on the across the proverbial desk between me and Jake being like, look. If we like, you are blocking 8 figures of revenue by you saying no to this.

Why? Right? And he's just like, we just need to wait. We just need to make sure that we have a proper story so that when we do ship the thing, you know, it's like a like, it's like an unabashed flood of revenue coming in. But that's a very different company that you're building, a very, like, linear like company versus, let's say, like, you know, like, a a Clickhouse style company or, like, a Cilla or, like, you know, that type of dev tool, which, to be fair, is a perfectly valid go to market motion.

But the caveat of that is that usually the sales organization and the engineering product organization are at complete total opposite ends of the table. That's a very long explanation, but that's like, you know, I would say argue that the two different types of sales organizations you kinda see at a DevTools company. So it's kind of

like how you solve this issue is either your way, which is basically sales have to fight tooth and nail and maybe don't get their way, basically.

The way we kinda look at it is that the sales organization in in our cases, I would say arguably subservient, right, to the product vision of the company. Right?

Yeah. Or, like, extension even. So

Yeah. Right. So, like, the way sales comes in is that, like, our job is to basically unblock the deal by dealing with, I would say, organizational hurdles between adopting railway and then building wherever we need to to overcome those organizational hurdles. But we are not necessarily in a situation where, you know, we will, like, fork railway and have, like, railway private on prem. You know?

I'm not saying that there's a world that will not happen, but I'm saying that, like, usually, the biggest mistake that I kinda see is companies who try to move upmarket is that they would say they fork the product too early. And then what they do what I call, I would say, the the the tent of suffering of of of of, like, enterprise motions, where you have, like, a forked version of your product, like a your cloud hosted version of the product, and then you have, like, a, quote, unquote, open source or, like, you know, core community version of that product. And then what ends up happening is there's, like, a consternation, which you've probably seen with the whole Redis changes where, you know, it's like, oh, cool. I've had this, like, pseudo free product distribution in a bunch of these organizations, and then a company gets a series c or series d. And the way they monetize is so different than how the product is distributed, then they just, like, piss off all the core user base.

Right? And, you know, Redis walked that back, but there's, like, a bunch of, you know, tons of case studies you can kinda point to where the open source distribution model of a company just consistently is at odds of a way how a company monetizes. And we didn't wanna be a company where we would, like, offer something for free or offer something that wouldn't provide proportional value, and then we would go try to charge for it. And then, you know, we would have a bunch of angry DMs saying, oh, you, you know, you you pulled the rug from under us. I would even go as far as to say that the one slightly dangerous thing from open source, which is this is probably gonna get me flamed on Twitter, is that it sets the effective labor value to zero.

Right? And, like, you're kinda seeing this with, like, the Carpathi repo and, like, I think, like, Mitchell Hashimoto has been pointing, you know, pointing out this out about, you know, the ghosty repos. It is a bunch of, like, really low effort PRs that are done on, you know, on on pieces of software that a maintainer has to go and, like, automatically filter. Now, you know, Mitchell can do this because, you know, he, I think, is, like, you know, post Hasher Corp and whatnot. But imagine you're trying to build a profitable business, and imagine you're trying to, like, keep a community happy.

Yes. They're offering value in terms of distribution, but it's very difficult for companies to defend the core value of a product and, like, charge, let's say, like, 5 to 6 to 7 figures for that product when, you know, an engineer can kinda point to you and say, no. It's it's for free on this GitHub repo. I have a right to pay nothing for it. And that's the biggest tension that a lot of companies are facing.

Yeah. That's that's true. And then the opposite approach that you did explain, but just to sum it up is that you would fork. Like, you would have versions almost for every different use case and you just it just sprawls out into this massive massive undertaking just to keep things going and hire tons of people.

Yeah. The like, you know, I I don't wanna name specific company names, but, you know, whenever a lot of dev tools companies are commercialization, I would say, of, like, profoundly groundbreaking research that gets commercialized. And, you know, I'm a little bit biased. You know, I have a a meetup that we invite these researchers, and they talk about their creations, and they talk about how they you know? Like, we don't they don't talk about the businesses of it, but thinking in the back of my mind is like, okay.

You know, how would you commercialize this? And then they focus so much on the engineering that they don't think about the business. And then they're, you know, what is it? Seed, series a, series b, you know, early customers go by really quickly and easily. Then you get to series c, and then, you know, it's very unfortunate they get fired and replaced with professional CEO.

Right? And that's because, you know, the same way how there's, like, tech debt, there's, like, sales debt or, like, business debt that usually isn't at the forefront of these companies that, you know, you're when you're answering to a board or when you're trying to, like, actually commercialize a company, you're gonna get asked a lot of questions about, you know, what's your net dollar retention looking like. So, yeah, I mean, what you mentioned, there the downside of focusing too much on product and not even thinking about your commercialization and how you think about your go to market is that, well, you know, if you don't think about it entirely and you have a really bad year, you know, your company's gonna shut down or worse, right, since it's like a husk of a company. You get replaced with a professional CEO, and then the whole weird vision of why you even started doing this thing, you know, gets sold off by the wayside. And there's there's some things like, I'm not saying not being CEO is a is a bad thing.

Right? Like, I think to different strokes, different With that said, I would I would probably wager that if you started a company, you would probably wanna imprint your vision on the world somehow. So, like, why not do the thing that will help you imprint that vision on the world by, you know, maintaining control of your company.

You know? Yeah. Because it's not just about the money.

Yeah. I'm I'm of the belief that that founders, think, are the correct amount of lionization actually. Because it's really it's really miserable for for, you know, for most of the period.

Yeah. So they as in you think that they should be looked up to because it is a pretty hard job.

I this is such a bootlicker take coming from me. Yeah. But I I think

I You you wanna send

a message to Jake? Yeah. Yeah. Not not even not even for for for Jake, but I I think in general, like, look. I I used to be a founder way back in the day.

And you you know, you you yourself as well. Right? It it is so hard to make something and get it out there. It is even harder to get money for what you make and then exceptionally harder to have a great business. Right?

So, you know, like, I feel like I do what I do because I'm still kinda, like, trying to get revenge for BlackBerry. Like, they made the BlackBerry playbook, which with the most perfect operating system of all time, and it was, like, you know, just destroyed by Apple, right, for you know, because the people up, you know, Canada couldn't figure out how to commercialize that thing. Right? But, like, every every everything around me, right, has been destroyed because things were fundamentally bad businesses despite they were, like, great products. Right?

Yeah.

And, like, if if I can be known for one thing, it's like preventing the graveyard of, like, great products because of, like, bad business. Right? Like, I'm I'm my number one advocacy is, like, if you can just think about how you sell something just for, like, five minutes a day. I'm not asking for much. Right?

We can live in a world where, like, you know, you yeah. I I agree. Like, 10 times more open source and, like, 10 times more happy engineers just because, like, everyone's just much more massively profitable, and we don't have to live in a world of, like, I don't know, private equity slop. So, you know, that's that's my that's that's kinda my view of the world. You know?

Yeah. I think it's a fair ask, Angelo. I think it is.

So yeah. So so yeah. You know? Maybe maybe I'm pro founder. You know?

So what?

That's amazing. I wanna get on to some automation stuff because I think there's some very practical things for people. But before that, you did we have a very quick sidetrack onto this. There's a guy Monza Monza. Not the the bank in The UK, at Mongo, MongoDB.

He I know you're a big fan of. I don't if he's still there, but like, we had this whole like Twitter DMs thing about how he's really good at value extraction. And I I felt like it's the kind of thing we could do a whole episode on. But maybe you could just give a quick headlines about like people that are very good at getting money out of DevTools.

Yeah. So I think for for your listeners, right, the context was there was, I think, a tweet that was quite popular where it's like, I can't believe we used this. And it was a picture of the MongoDB logo. And, you know, I I I'm not gonna I think Mongo is good technology. I'm not gonna go insult it.

I think it's fine. But I think MongoDB is actually a really great example of technology that in some not my opinion, but in some people's eyes is subpar technology. Right? But it was massively commercialized well because of this gentleman named John McMahon. And I I think from my understanding right now, I think he's kinda pseudo retired.

He's, like, a five time chief revenue officer, just a board adviser of a lot of companies that we know of, Snowflake, ServiceNow, MongoDB, like, the true undisputed goat of of sales. And, you know, he's just a very polished gentleman and has a really great knack for, like, navigating people. He's not necessarily technical, but he has usually done technical sales. Now the thing is that, like, at some point whenever you operate sales or sales organizations at, like, a really high level, at some point, you don't necessarily really need to know. Like, you're mostly managing kind of this organizational psychology.

With that said, a lot of people who don't understand is that, you know, MongoDB was commercialized because they had a really good understanding of what's called ICP. You probably hear this all the time in a bunch of startup advice, you know, ideal customer profile. And, you know, I don't wanna recount really painful memories of anyone who currently works at MongoDB, but there was a meme way back in the day, right, MongoDB's web scale, and it was said tongue in cheek rather ironically because the way they got their benchmarks was by writing your data to dev null. So, you know, how do you sell a database that had a reputation of, you know, data inconsistency? Well, you find companies where they are moving on the leading edge of, you know, say, software development and who, I think, were necessarily I mean, Postgres and ORNs, right, was a much different time today.

Like, Prisma wasn't really in use in 2010. Right? So, you know, they sold primarily to enterprising web developers and game companies, video game companies. Right? Because if I'm storing a bunch of metadata about, you know, whatever Unreal or Unity is kinda spewing out, I didn't necessarily care too much about the schema, and the schema was changing quite a bit.

And that was kind of, like, their first, I would say, like, 50,000,000, right, of revenue just by finding out really core customer preferences despite, you know, I would argue, very vociferous developers who you know, look. I'm one. I'm quite cat like. You know? I look at things.

I can't tell you why I hate it. Right? But it just just kinda is. Right? It's a selling to developers is, like, one of the hardest customer segments you can sell into.

So the fact that, like, this man, who is not a database guy at all, is able to kinda suss out the different preferences between the whole, I would say, preferences of a different developer base and is able to, you know, make MongoDB into a, you know, multibillion dollar company. You know, again, deserves my respect. So, you know, if whenever anyone posts MongoDB stuff slander on the page, look. I'll put a picture of John McMahon up on a reply. You know now you know why.

And that's kinda the source of him. And he has a a a canon of books, I would actually argue, that I think anyone, even if you weren't in sales, probably should read.

Yeah. I mean, 26,000,000,000 market cap right now. I know it's down

That's impressive.

Overall for over five years. But yeah. And on the terrorist

I pay him anything, you know, in this market, you know, I he he you know, I'm pretty sure he's he's in a ski ridge loft somewhere.

Well,

maybe not now, but, you know.

You you mentioned, like, not to spend a whole episode, but you said that he was able to, like, suss out and figure out all this. Like, do you think there's do you have any inkling into how what he did that might be a bit different to what other people do to figure out their ICPs?

Very wholeheartedly. I think most advice that startups will tell you or rather, like, most VC firms will tell you about, like, finding your ICP are not wrong out of malice, but mostly wrong because it's, like, you know, the same way, like, reading the Google SRE handbook out of context would, like, cause you to implement a bunch of stuff that's, like, way above, right, like, the standard of your engineering organization. Like, it's not, like, it's not bad advice. It's just not contextually applied. But, you know so, like, to kinda tie it to, like, my own my own personal narrative.

Right? When railway was kind of moving up market and by the way, like, you know, I I was a product manager for three years before before this and a software engineer before then. It's not like I was, like, coming in cold without, like, you know, enterprise awareness. However, you know, Wind and Railway clearly had to start making significantly more money than we are today, and, you know, we we are, I think, in a really good spot. You know?

So it can at least you know, I think we're good there. But, you know, we're kind of at the point where and Jake talks about this where, you know, we're burning, like like, I think, a crazy amount of money for every dollar we brought in. So if we did nothing, right, railway would not exist today. We would just simply have ran out of runway. So you re you know, I wasn't necessarily panicking, but I'm like, okay.

We have to do something about this. And a lot of the kinda conventional advice about ICP is, alright. Well, you know, they have, like, this, like, Clayton Christensen kind of view of the ICP where it's like, find the most, you know, forward thinking, forward looking customer segment that's, like, willing to risk it all and use your technology, and those are your true believers. Well, guess what? Those people, and I don't mean to insult them, usually don't have money.

Right? They're very vocal. And if you listen to that segment, I think, a little bit too much, they'll actually kind of take you off segment and away from the customers that you really do want to sell to.

Mhmm.

So what John McMahon talks about in in in his books is that he's really good at separating what he calls, and I think what now people have accepted as a proper term, champions and actual decision makers who are able to buy your software. So a lot of early startups, whenever they make something new, will confuse, you know, like, 50,000 users as, like, genuine market fit. Fit. Right? But if those 50,000 users of, like, your hypothetical thing that you're building aren't necessarily, like, kind of charging or, like, have their credit card in hand and willing to pay for it, those are not the customers that you really should be building for.

So whenever again, this book was, I think, written, I think, in 2015. I might be wrong. Right? But, like, the book assumes that you're kind of having this, like, you know, custom style software, custom style solution that you wanna sell. You know?

I think POG companies can kinda modify it, I think, to whatever they would like to do. But what John really emphasizes within the book that we've been able to kind of apply successfully is just, like, whenever we're on a call or whenever we're on a call for any sort of demo, we're listening to every single objection that we can get. And we're just obsessive about the amount of feedback that we get. And usually from those objections, you can kinda figure out and suss out what someone is something willing to pay for versus, like, what causes someone to, like, I don't know, browse your offerings or browse your product set to to even have this conversation. For example Mhmm.

You know, Railway you know, like, I can say, in dispute, like, companies ship faster on Railway than they do on any other cloud platform. That is, like, one of the advantages that you have why we would pick us versus, like, you know, using AWS. AWS. Right? However, right, velocity is fine and all, but, you know, usually, the types of workloads that are that require velocity usually are, I would say, newer products that require a lot of iteration and go to go to go to market.

The workloads that usually are core to someone's business are not necessarily shipping, let's say, every single day. And there's a lot of DevOps practices out there that I you know, some organizations are, like, cutting releases, like, once every week. Right? Because there is a fair paranoia around, like, the protectiveness of, you know, of that software. Right?

So, like, just because someone finds your core value proposition quite, like, enticing, if you ever have these, like, deep conversations with some customers and they're, like, saying, look. That's this this little piece of software here is nice and all, and this is cool. But the thing I really care about is this, like, big, massive behemoth monolith that, you know, we only check-in code once every, you know, Tuesday. Right? And in those conversations and those discoveries, we later realize, yes.

This person who got us in the door is important. We wanna make sure that we serve him. That's that's our champion. But the real person that we really have to make happy is, you know, VP of infra of x organization here. Right?

And then you kinda figure out what does Railway have today or what does your product have today that'll actually make them happy. And then if they actually do or are necessarily really into your core value prop, then that's the sweet spot. Then you find your ICP. But the problem is that a lot of the ICP advice is kinda just out there. It's kinda divorced from, like, the context of where it comes from, which is just like listening and investigative context and not just like spraying and praying and like, oh, you're early users.

Listen to them. It's there's lot more nuance than that.

Like, guess if you assign to Google, there's probably like teams that will be much more nimble. And then like, if you're if you're like, it's the very core of the business, like search, whatever, it's probably like completely different. But the team that does search, then like, you're probably gonna make like infinitely more money doing that.

Yeah. I I can't name names, but there's, like, some ironic companies that have signed up for Railway where they will, like, complain to us about the internal politics about even shipping stuff, internally because said, like, moneymaker team has a lot of say over the platform resources.

Mhmm.

Right? So, like, the rest of the business is kinda starved because, unfortunately and this is, like, a weird quirk of United States tax code. You can write off r and d expenses for software engineers, but you can't write off r and d expenses for DevOps engineers. So yeah. I know.

Fun fun thing. And as as partially as a result, actually, that's one of the reasons, not the only reason why, like, I would say platform engineering resources are just so metered. The other thing is in is this this, like, pervasive kind of view at a lot of companies that platform engineering is a cost center, not a value generator. So, like, it's usually, like, you know, one to two people stuffed in a server closet who have to, like, deliver for the entire organization, and they're fighting fires all the time, and their lives are absolutely miserable. Right?

And, like, you know, we have to be very careful to whenever we sell railway that, like, our value prop is not to replace their jobs. Right? Like because there's a lot of companies out there who their marketing will be like, we wanna kill and end DevOps. Like, first off, DevOps is a suite of practices, right, that you need to do to institute uptime. Right?

Where no one's killing DevOps anytime soon. With that said, I in my opinion, you know, no one is truly selling painkillers to those folks. Right? So, like, our goal, right, is to, like, not antagonize them, is actually to truly and properly serve them. With that said, right, and then we talk, you know, back to the whole ICP question that you mentioned, they talk rather differently to what the expectations of product engineer has.

Right? And, unfortunately, because of the constraint of the resources of a lot of a lot of an engineering organization, again, there's a lot of, I would say, fair but unnecessary tension between, again, like, a VP of infra and a VP of, like, you know, engineering. Right? They have, like, two different goals. And sales is knowing to distinguish the the difference between the two of them.

What's the actual reality of, like, selling into a cost center versus, a profit center from a sales perspective?

So there are different motions that a company can take when building out their funnel, if that makes sense. So, like, if we're you know, I'm I'm coming up with, a sector agnostic company. Like, I I'm assuming any sort of size. Right? Sometimes, depending on your value proposition as a company, very often, there's, like, products out there that I don't know.

Like, the best way I can kinda describe is, like, a FinOps company. Right? They're, like, promises, like, financial observability into, like, your infrastructure or your resources. Right? So I'd you know, I'll put a pin on it.

I think that's ridiculous, but that's a separate separate, you know, separate. Right? But but if if I was trying to sell that, right, like, usually, my mindset is a very defensive mindset. Right? Right?

Like, Like, I have a concern about budget. Right? And then that type of profile of who I would target, that's assuming that I wasn't I didn't have, like, a lot of demand. I would, like, start reaching into what I would think are decision makers who do have control over the budget. Right?

Partially your VP of infra, but partially, like, your CFOs or your controllers at different these companies who are trying to look for space in areas that they don't have space before. Right? So, like, you know, the way a CFO views the world is much different than, like, how a CIO or CTO views the world. So if you are trying to sell, you know, I would say, defensive software, usually, you're gonna be trying to make your value prop much different that appeals to their world. Now the difference of whether or not your software lands or not is, okay.

The decision may be the CFO, but end of the day, the engineer has to use it, that's the actual user I have to make happy. Then you're gonna have to kinda nuance your way, right, from that, like, top down sale. Right? Some pieces of software, right, with, like, the value generation pieces of software, I would actually argue, are sold bottom up. Right?

Because you have this kind of problem, and you are kind of growing or expanding into this problem space. So you really wanna be that tool set that you're kinda picked up and constantly, right, whenever you're doing that, which is actually why I'll argue, like, why Cursor has been, you know, up here. Like, I I I have no insight into, like, how they operate their business. But partially the reason why Cursor has been so successful is that, like, when you're reaching for a tool, they're kind of been the most, like, available to it. Right?

Whereas Copilot and, you know, like, I some people, if I get up, follow me, you know, no offense, but, like, the interface to get to Copilot is Versus Code. Right? So if I'm, like, in this quote, unquote, like, value generation mindset, there's this kind of, like, two door entry way for me to pick that tool, therefore preventing me from being top of mind whenever I make that decision and or that value generation decision. Right? So, like, you're selling any sort of value or rather like a a very positive go to market motion, it is my it is of my opinion that you really should be kind of like going bottoms up rather than top down.

And sorry.

And the Versus Code thing, you're saying that, like, if someone's used Copilot, they first have to use Versus Code and then use Copilot. Whereas Cursor is like, you hear about Cursor, you go get Cursor.

Yeah. Yeah. And and and not only you hear about Cursor, but, like, anchoring themselves to, like, the act of creation. Right? So it's like, if you were to look at, like, productivity tools out there, like your Figma's or Kirsch's of the world, right, they're trying their best to, you know, I would say, shoehorn themselves, right, into, like, that bottoms up yeah.

Keeping railway as well. Right? Dude, that new and whatnot. Basically be like, here's this, like, palette of or tool set that I have. Let me go make the thing.

And then usually down the line, like, those enterprise motions are kind of built after the fact because there's such, like, a groundswell of this user's user base, and then they kind of deal with the big company concerns after. Whereas, like, again, cost center conversations, in my opinion, or rather just my observations, right, from seeing those products and even seeing how it's sold, it's very easy to go to, like, a big decision maker who is swinging a big giant axe, right, and say, hey. Look. Here's this bigger and shinier axe that you can use to free up budget. You know?

Whereas, you know, I don't know. Like, I don't know. Ask around, like like, well, the line engineer is not necessarily doing cost cutting. Right? Yeah.

It's usually That's what I was

just thinking in my head. Like, I don't think you ever it ever occurs to you, you know, to cut costs. You don't. I mean, I just joined a startup player code and of course, I wanna use their money why wisely. But like

Yeah. Yeah. Yeah.

I don't think about like I just think, how do I do my job better? I don't care if it costs if a software costs $99 a month or $30 a month or it's free, really, if it, like Right.

Does the job better. Where where you do care, right, is like, okay, you know, and this kinda goes back into the whole, think, like, stuff we mentioned, you know, a little bit at the beginning. Right? Is that, like, software or rather product can embarrass you. Right?

Like, you mentioned I'll kinda turn turn you know, to you just joined this company. Would you feel comfortable asking for, you know, leadership for software that cost $10,000 a month when you first joined?

Would have to be a pretty big yeah. Like Right. It's a high bar.

So for for listeners, right, who are listening, like, on an audio only platform. Right? Like, I don't wanna embarrass Jack here, but, like, there was a there was a facial reaction there. Right? That Yeah.

He's like, oh, I'll let you know.

Probably a whole physical recoil. Yeah. Yeah. It would be tough.

Right. So so mean, you'd

have to be selling, like, really, like, transformate. You know. It's like, it's got it would have to be like a Devon that is actually just gonna just, like, legitimately Right? Yeah. Just crush, like yeah.

It's like a CTO, basically.

Yeah. Exactly. Right? So so, like, if you were to kind of, like, have a defensive product or rather a cost cutting product be sold bottoms up, the way you would do it, and this is kinda where we're getting to, like, funny little psychology world, is, like, you need to make it so that the line engineer or, you know, whatever motivations of the user makes them look really good to their boss. Right?

Like, hey. By using this thing, I have already freed up $20,000 of x spend. Right? And, again, you know, they're not gonna get promoted, right, as a result of doing that instantly. But any sort of tool or product that aligns the incentives of leadership and the line engineering core is a great tool for that.

Right? And that's, like, like, a good interesting way to, like, you know, do a hypothesis. However, with that said, there's there's a reason why it's not done, and that's, again, what what you kinda mentioned. Right? Where, you know, I think, like, there's, like, a lot of value prop to, you know, the advantages of the world, but it's not like and, you know, I'm pretty sure Ben might have a different view of what I have.

But, like, it's not like a a line engineer is, like, clamoring to implement this thing bottoms up. Right? It's usually like, hey. I I have this, like, big world of machines that I need to have a a handle on. I need to implement my view of the world, which is a world where I spend less on machines.

Implement that for me. We aren't pay 10 k. Right?

Yep. Yeah. I see what you mean. So bottoms up has an extra argument to it rather than just being Yeah.

Anyone who says PLG is dead has never done real PLG is is my argument.

So, yeah.

Although I do feel like You

can't yeah. I just no. The one thing I will say is I feel like I don't know. It's not anymore, but I was talking to someone about this today. I was like, that there was this like especially a few years ago, there was this kind of like kind of cult of PLG, and especially, like, anti sales PLG, whereas,

like Yeah.

Sales but it feels like now it's, a bit more, like, you know, you can have some sales, which is what we're gonna get onto a little bit, which is, like Yeah. If you have time, I want to ask you still about the automations Yeah. That you've been

Yeah. You know, it's been written to death on Beehive newsletters across the world, so I I don't necessarily need to rehash this argument. But I I think my my final kinda note about and this actually ties right to the automations, is that, like, this, like, post pandemic weird reality for, like, two years, people were just, like, giving stuff away for free and then being like, oh, that's my customer. Like, I have to serve that customer. That's, like, you know, real and it's like it's like this entire, like, margin blind view of the world that, like, makes entirely no sense.

Right? Which is, like, how companies, like, just run headfirst into extinction. Extinction. So I think that's, like, kind of, like, my my my big nuisance about I would say, like, oh, like, the only way to defend the value of a product is to set up a bunch of these meetings, right, to justify the value of the product. Mhmm.

To me is a name. So, like, pulling out. Right? People don't necessarily hate POG or people don't necessarily hate SalesLed. What people genuinely hate is a sales experience that is so inane that you are just, like, so frustrated at the end of it that you don't even wanna give them money.

Right? And there's a bunch of, like and actually just ties right into the automation stuff. Like okay. Imagine, you know, you're using Railway, and, like, before we let you deploy, right, you have to, like, book a call with me. Right?

And don't get me wrong. I'm a wonderful person. Right? But, like, you have better things to do, right, than, like, look at my inane schedule, right, and just, like, figure out, you know, my I'm sorry

about that.

Right. Right. And and then, yeah, and then you're gonna be so happy to use what I have. And then, okay. You know, I'm gonna sweeten the deal.

After the call that you have with me, I'm gonna go check-in with you every day. I'm gonna go email you and be in your inbox and be like, hey, Jack. You know? You you are probably busy. Have you gotten on this thing?

I I would rather jump off a bridge. Alright? And many developers would rather so so anyway

I I feel like not to mention. You're also I feel like you're also gonna give me, like, a one month trial where I could try my deployment. And if I don't deploy, you're also gonna email me and say, oh, you would you like me to extend the trial to where you can try out the deployment?

And again, this is this is the whole same thing that, like, my gripe with, like, this, like, general advice misapplied at scale ham fisted. Right? Like, what what developers dislike is that they dislike not being allowed to get their problem solved on their own and being trusted to do so. With that said, there is a like, the problem is that with a lot of dev tools is that you can't live in a world where you're not defending the value of the product. Right?

Like, there's this, like, world where a lot of engineers who, you know, let's say, for example, uses open source tool. They have a genuinely custom use case. They spam the PR or issue things with their, like, very clearly, obviously corporate use case. That line that you skirt, right, between, you know, what is, like, I'm I'm playing around and testing this versus, like, no. This is actually ready for engineering prime time is a very, very, very, like, precise line to walk.

And this is actually reason why Railway has actually invested a lot in, like, I would say, our sales automation pipelines. Because we want people to, like, get as much value out of Railway as much as possible. But then what would happen inevitably, right, is that we'll have, you know, Fortune 500 customer just, like, using it for prime time, and they would not tell us that it's for prime time. And then we would not mark their workload with the proper SLA, and then we would do something inevitably because we didn't know it was an actual real customer, and then knock it offline because we would migrate their workload because there's different SLAs. Right?

Like, if you're Yeah. If you're a trial and hobby, we we move it around. Right? Like, that's how we, you know, we get the margins. If you're pro in enterprise, we don't touch that workload, or we try our best not to touch that workload as much as possible.

So there have been times where I would get a very angry email to our joint, you know, our shared inbox being like, you fools. This thing is so important. You know? Why did you touch this? Don't I and this is, like, like, like, we would get this hundreds of times at this time before we had to actually implement this.

So then we were like, look. All of these sales, like, outreach stuff that I would do for customers who would sign up with, like, a corporate email are not working. Right? They just fundamentally don't work. And then, you know, I was I went through this, like, moment of walking in the desert, and and it's really hard to take it not personally, right, whenever no one answers your sales outreach email.

You know? It's like, is there something wrong with me? Right? You start thinking a bunch of your wacky, crazy stuff. But, no, when when

you actually emails?

Yeah. You're right. No. It was exactly that. There there was there was some pretty passive aggressive copy that I did not ship that I was like, you know

That's what matters.

But right. But Yeah. And and by the way, I try my best to respond to everyone that that by the way, like, when you do see it from Railway, right, it it is from the team properly. Anyway, tying it back together, we learned, right, through the whole product led growth process is that what we need to do is that any sort of, I would say, corporate or support use case, we need to make that door as open as possible so we can allow the graceful kind of, like, up leveling of a customer from, let's say, like, a $100 to a thousand to 10,000, if that makes sense. And the the if we apply the traditional advice onto Railway or, you know, to most of the companies, is to start gating the product.

It's to start demo gating a bunch of these different features, and then you have to start, like, you know, protecting again these, quote, unquote, more valuable areas of the product. Mhmm. The insight that we saw is that, look. Like, we're gonna hand these SKUs to you. We want you we we trust you to to, you know, like, charge yourself.

And there's also a bunch of other macro factors that have made this possible. Right? Ten years ago, you know, it was very rare for aligned employees to have a corporate spend card. Now Brexit and ramps are

Yeah.

You know, prevalent everywhere. That was also another, like, innovation that we've been able to take advantage of. But even outside of that Interesting. By keeping the door open, right, we've better found that, you know, large companies are more than willing to talk to us and be happy to talk to us since we've made that process easy as possible. So that again, I'm I'm gonna put a little bow on it.

We've now made it so that, you know, if you are if I detect that you're part of a Fortune 500 company and I detect a bunch of customers who are onto the platform, I'll just start sending Slack invites on day zero. Right? And we're trying to create the surface area of conversation to really kind of, you know, pull out any sort of concerns ahead of time so we're not on the back foot. Because the problem is that if you're on the back foot, that pressure goes to the support organization, not your sales team, and that is a much harder sales conversation to have when they're dealing with an outage, which is not impossible versus you kind of rolling out the red carpet and making sure that they feel hurting and and their concerns are are are properly addressed.

So okay. So I'm just playing that back to make sure people get this because I feel like this is just gold. So it's like like, usually, like, a platform might say, okay, this feature, let's say like I'm Jamaican something up, but like, say you want a static IP on this resource. It's like only enterprise customers can have this and you have to like call us up if you want to. So you're just gonna like, that's exposed.

Like you can do anything in Railway. But the downside of that is that you're not necessarily knowing if someone's like an enterprise use case or not. But what you're doing is like, you're letting them do anything, but then you're also making it very easy to get in touch with you and doing some automation so that you know you could maybe figure out from like the the domain and stuff that they are enterprise customer and that you should get them on the right plan and get them on the appropriate SLAs and all that sort of stuff and build them properly. And

Yeah. I know I know you were making up a use case. Right? But that's actually a very accurate use case. Right?

Like, whenever anyone presses the the static IP button on Railway, the sales organization at Railway gets a webhook, and it gets put into Adio and says, we need to start talking to this person. This looks legitimate.

It's I think I pulled that out because I think Vanta, I went through, like, we had to go through SOC what is it? SOC two compliance and like Vanta, one of the things they flag and like, I think we're using digitalization was like, it has to be like static IP and so maybe that's why.

Yeah. Okay. Yeah. It's exactly that. Right?

Like another So so the other thing that we, you know, we're I think we're quite open and honest about is that, like, you know, if you use certain features, we call them no offense to our Canadians out there, but we call them Canadian limits. Right? We'll just let you use it. But, like, you know, we'll we'll, like as soon as you kinda cross different thresholds or different shapes of what we kind of seen through a bunch of heuristics of, like, what looks like legitimate use cases, then we start putting you on the email drip. Right?

And then, like, some this is on the blog post I think I've written and put this in the show notes is that, like, regular cold outreach emails, we were getting, like, a point zero one seven response rate, like, something abysmal. By the way, industry standard is, like, point three. So, like, you know, if we were spraying and praying emails, it was, like, horrible. Right? So so but, like, we found that these targeted emails, right, depending on the different feature use cases, like, you know, again, I don't have the hex dashboard up and running, but, like, you know, I'm I can tell you probably it's like response rates are usually at, like, three to 4%, which are actually very good when it comes to, like, you know, pulling out those concerns from those customers.

And then because railway is a consumption based business, right, the way we kinda structure the you know, a deal, quote unquote, like, get a committed spend, that's what we kinda consider success on our side, is, okay. What are all the different workloads that you have either on Railway or off Railway that we have to bring to you to like, to bring to the platform for you to feel like you wanna, like, really get a proper SLA or really feel like you need to support SLO, that type of stuff. And then those conversations take six months, and I think one of the moments of arrogance that I had, and I'm I'm willing to put this on the podcast, is, like, you know, I thought we can, like, turn that six month sales process to one month. Like, you know, when I first started getting in the job, was like, look. The same thing that we did to to deployments, can do for sales.

Can make people yeah. Yeah. Yeah. Like, we can make people sign contracts as soon as they sign up. Wrong.

There's a bunch of there's a bunch of, I would say, like, out of product concerns that I think Railway had to kind of grow up now that we've kinda finally hit that now we can kind of empower engineers or engineering teams to kinda go to, you know, their security organization and be like, look. We do all the right stuff here. You know, the other thing as well, since I'm kind of already rambling, right, is, like, you know, moving into our own data centers as well. Right? You know, a lot of people think that was, like, a great move, and it paid off.

We're recording this, I think, the day after the egress unfortunate outage and how it all affected. But, you know, when we first did that migration, a lot of our Fortune five hundred customer segment was raising their eyebrow at us and being like, you what? You know? Like, we like the fact that you're on GCP. That was a a bunch of guarantees that we got by virtue of that.

So there was a a bunch of other additional resources that we had to do to even, you know, do the traditional sales cycle, and that's a a one that I'm happy to talk about as well.

Yeah. That would be interesting. I feel like we could I I don't wanna keep you on this because I felt like

No. I'm I'm I'm I'm it's such a big topic. Just like being able to explore all the stuff.

Yeah. I think it'd be interesting maybe to do like a whole episode on like the business of like urine data centers. I mean, that was like, we did talk about that on the episode with Jake. But I think it'd

There's another person who probably can speak more authentically to it, who is, as we speak right now in Equinix, just sweating or freezing. You know? Like Yeah.

That'll be that'll be

great. If if he was to take the call or the podcast from the data center, right, you just hear fans.

It's just like Nice. Oh, yeah. I should just go there. It'll be like, cool background. Actually but so the last closing thing is I think that we use Slack connects.

And I think now that this is not I feel like two years ago, three years ago, this was like a kind of thing that people were like, hey, you should use everyone knows Slack Connect's really good, I feel like now. But the automation part of it was like quite interesting. I think your people should see your blog post about how you did it and like, I think like you've just ran in a lot of detail how you built this whole like custom automation there. I don't know if you wanna just give like a very like high level overview of what you did and Yeah. Still recommend people doing this.

I well, thankfully, now there's vendors, I think, who finally caught up. I think the problem Okay. Yeah. Yeah. The problem Railway has is that we keep running into issues before other vendors or our competitors running into those issues, which I guess is a blessing in disguise.

So for example, like, one of the weird pathologies that we have, right, is, like, we wanna talk to every user, right, as much as possible because, you know, I I used to work for this, like, really sleepy enterprise company called Citrix. And I remember back when I was a PM, I would email people, and no one would reply to me, hence, spilling like like, triggering the whole existential, like, wandering the desert phase. Right? Like, what's wrong with me? You know?

And by way, these are people who pay, like, $6.07 figures, like, about on on software, just for the record. Like, they're paying you a lot of money, and then you reach out to them, and they don't wanna talk to you, which is, like, insane to me. Right? So Mhmm. That aside.

So, like, when I, you know, left product management for reasons and became a support engineer, the first concern that we had was like, okay. Like, how can we talk to all of our users as much as possible? So we built a bunch of, like, Discord bot automations that you know, for example, if we launched a beta feature, we will, like, tag the the beta flight group and, you know, it kinda turns into, like, a Twitch chat whenever we launch a feature. It's actually kind of really energizing for our engineers because it's it's like they're playing to a crowd. So that was kinda how that started.

And then when we started moving towards more upmarket customers and, you know, I think I tweeted about this before, but we've had, like, a major travel company company CTO in our Discord being like, hey, guys. How do I get a demo? Yes. Oh, yes. And yeah.

Yeah. And and then, you know, we're I was just embarrassed. So I think that was kinda when we realized, okay. We needed to actually start changing the channel that we're having discussions on. Now I I I wanted to put this in the blog post, but my editor took it out.

But I think it he deserves his his plot. It's you know, like, the Slack connect stuff arguably was pioneered by Michael Greenwich at Work OS. Shout out. So Shout out.

Sponsoring Slack's game. Yeah.

Yeah. Yeah. Exactly. Yeah. I I was not intended, but, you know, you but just wanna put this out there.

You know? It it was it was really from him. Right? So I don't know how they did it, but I think it was manual on their I don't know. I'm I'm you have to get the story from him.

But I remember when I signed up, he invited me to a Slack connect channel, like, almost instantly and started working me. Right? Now with that said, I'm I'm not I'm not the decision maker. Right? So I I couldn't, you know, I couldn't implement it.

Right? So, you know, I I just wanna you know? But long story short is is, you know, we we like, I would say, from a intent perspective, right, we had a very similar philosophy because, like, in Discord back when we were using it, we would even have private channels with our customers then. So we were just kind of transposing that concept into a separate channel. But the issue was is that at the time, we were using a support vendor that I think was pivoting its core value proposition because they initially their first initial proposition was, like, we're gonna be an API first support system.

And I think their customer base was like, look. We you know, we're not using a support vendor for us to rebuild our own support tool. Just give a support tool. And the issue that we had was we needed to be able to kind of conditionally, like, spin up channels up and down depending on their customer relationship with us. And we had, like, two different kind of warehouses of data between our source of truth of, like, what the railway customers actually were versus, like, if a customer was, I think, facing an issue.

And I think at the time, I'm not sure. I I don't wanna misrepresent their product road map. We couldn't ad hoc spin up channels for those customers. So what what end up happening is I would have to spin up the channel manually in Slack, add the bot, and then, you know, even if they would join, which is a whole separate issue. So at Railway, we have this kind of philosophy about support engineering and rather, like, what we call logistics engineering, where, like, we treat nonproduct interactions like sales, like support as its own product with its own road map because we want it to be considered.

Like, I make this joke all the time to my friends. You know, if I want us to be like, you know how people are like, oh, we're like the cursor for x. Like, I wanna be known as the Chick fil A of infrastructure. Right? I want us to be known of, like, having the best service with a smile and, like, a damn good sandwich or a damn good server.

Right?

So We need a can we have a Chick fil A is like we don't have it. So what's the

Oh, that's sorry. Yeah.

Is there

like Sorry. Sorry.

Yeah. Is there a, like, McDonald's? Is that I'm not do it slide?

No. No. It's like a premium okay.

So Okay.

For your non US listeners, Chick Chick fil fil A is a sandwich chain in usually known in the in the American South that is known for its, like, southern hospitality. Right? So, like, when you go to a Chick fil A restaurant, they have, like and and I'm not I'm not kidding. They have operations researchers on staff that learn how to, like, maximally queue people for the best experience possible. So when you're in a queue and if it's, like, too long, they will just have the person take your order while in line so that when you are at the at the at the counter, you actually just pick up your order.

Chick fil A also has is also known for its, like, what is it, distributed Kubernetes DevOps organization. Like, they will run Kubernetes, like, pods and clusters, like, per restaurant. There's, like, a whole talk about it you can put in show notes. Really? Yeah.

Yeah. So it's it's a sandwich chain with software mart I'm just kidding. Not with software margins, but, like like, it's a company that is, like, just absolutely dedicated to delivering a good sandwich at a semi reasonable price, like, slightly above. But just it's one of those, like, remarkable experiences where not only the sandwich, but the whole process of even getting your sandwich considered. For me, right, this, like and, again, I have, like, some wacky cuckoo ideas.

Right? Like, when I joined Railway, I wanted to kind of allow us to put this practice of, like, hospitality. Luckily, have a boss that kinda supports that. And, you know, the way we kinda process our whole sales process is part of that. Right?

So that's the reason why we put a lot of engineering time. So when we were trying out different support vendors for the Slack experience and we couldn't get it the way that we wanted to, that was the reason why we went off in and built the system ourselves. So that's like a lot of context of, like, why we're kind of proud of this.

And it seems like you can you can I haven't actually had to do it, I think, really? But by the way, like a side point on it, I have used it. I've I've, like I'm a I am actually a paying customer. I got an invoice today.

Oh.

Yeah. It's great. Anyway, I pretty sure I said this earlier than, like, one hour into the episode. Anyway, better late, never. It's it's like when you do a support message, you can like select the resource and stuff like that as well.

Right? Like, that seems like super nice.

Right. And that that came out of that came out of our frustration with Zendesk. Right? Like, we were like, when I was in support, we you know, like, I remember maybe they changed it. I'm not sure.

I remember, like, responding to customers and pressing Zendesk and, like, waiting five seconds for, like, the the state of the front end to change. And, again, like, I have, like, this weird DHH, like, impatience of like, for, like, shit software. You might have to put that. I'm sorry. But, like yeah.

So so so, like, this whole experience was, like, so frustrating where, like, my colleague Ray and I were like, we how hard is it to build our own, you know, support? Like, how, you know, like like like, how really, like, difficult is this really? But and it took a lot of, like, things like internal justification. To be fair, was also partially skeptical. But, like, we were churning through two support vendors.

We were not gonna go try a third. We're at that point. We're just kind of exasperated, and we just kinda built it ourselves. And then, yeah, as you mentioned, yeah, like, if if anyone has any issues, you can click on the resource that you're having a problem with. And then the admin on the railway side, the support person on railway side has all the context, so we're not going back and forth.

You know? Oh, what's my invoice number? Oh, what's this? Oh, what's you know? It it saves us massive massive time where, you know, I'm not sure if we can publish those numbers just yet, but we can process, like, a lot of tickets with minimal support resources where our customers don't necessarily feel that, you know, it's just one or two people behind this screen, if that makes sense.

It just feels that expansive. And that's what Leverage is.

The scale that you guys are at just because for people, you've got two people in support. And there's, 20 So 26 people or something at Raleigh?

Yeah. So we're at 27 people. We have a support engineering team of four. And then now we're starting to expand proper CSEs, like customer support engineers. But, yeah, we only have two people on support rotation every week, like, in l one and l two.

And, you know, they get paged. They have they hold a pager. I think there's, like, a a blog post probably to be written about, like, how we structure, I would say, like, you know, paging and operations and whatnot. But, like, if a if a, like, a a really expensive enterprise customer needs to wake up the support l one, they hold the pager duty, like, just like anyone else. And then they they they do the escalation, and and the the priority comes from there.

With that said, we're now at the point where we have like, we're just now starting to cross the Rubicon of, like, actually starting to have, like, full time, I would say, like, success folks just for that whole customer segment because I think and not to toot our own horn, but, like, we've just had, like, a massive expansion in terms of, like, committed, I would say, contracts on the platform. And then we're now starting to run into the whole you know, we kind of had alluded to at the start of this conversation. What does the market kind of expect, which is, like, this idea of, like, a a dedicated account resource versus this, like, floating account resources that we were able to kinda get by with, like, the last five years?

They wanna see the same person every time.

Yeah. Or at least, like, the same group of people. Like, the prominent now that we're running into is, like, if you have a really long running account and a long running ask and you're kind of passing on the baton to different support resources, it's like, we can do all the AI summarizations as much as you want. It's not the same as having one person really understanding an account.

It just feels weird. Yeah. Yeah. Doesn't feel like Chick fil A, they wouldn't do that. Right?

They would not. Probably not. But I yeah. I'm pretty sure they have With shifts in staffing. Yeah.

Well, maybe. I don't know. The the idea the idea is that, like, you have a standard of excellence so high. Right? It doesn't matter who's behind the chair, if that makes sense.

Right? Like like, the the problem the problem that, you know, most companies have is that and this is, like, whole separate with my obsession about football, which I know is not cool for British technical folks. But, like, as an American, it's cool and, you know, like, interesting.

I have no idea.

Yeah. Right. Right. So, like like, it shouldn't matter like, the identity of a team should be imprinted where it doesn't necessarily matter who's on the field. Everyone knows how to play that way.

And then you're not having to deal with, like, having to rely on your superstars, if that makes sense. Which is a whole separate, I would say, like, engineering and organizational psychology thing, which which is part of one of my unfortunately many and

You're saying but you're saying, like, you wanna keep if the everyone's good, then it doesn't matter.

Yeah. Yeah. But but not not I would say, like, a little bit reductive because, like, every company like, you ever ask a company, oh, like, do you hire the best people? Of course, they're like, yes. Of course.

Right? Yeah. It's one of those, like, ice cream questions.

Either they would even if they would believe they hire the best people or if they don't believe it, then why would they say they don't?

Yeah. Right. No companies out there being like, we hire the the worst. Right? And we're proud.

You know? Like like, this is not a sentence that people say.

Reasonable people, but like

Yeah. We'll we'll take whatever yeah. We can But but on that note, right, like, I'm not I'm not necessarily the type of person who is like, I don't know, so psychopathic where it's like, I only work with a players and, you know, screw b players. It's I I think the an ideal organization, whenever you build any sort of company or any sort of org, is you have a standard. Right?

And you're very clear about that standard up front. Right? And not like this, like, in a weird nine nine six way where, like, oh, we work a lot of hours. But, like, the one thing that Railway looks for is we look for a standard of care into whatever this person does. Right?

And there's a a battery of questions that we have that try to suss that out from the person, whoever is in any sort of interview process, such that any sort of problem that you give them because they care and because they have, you know, reasonable work ethic, they're gonna be able to, like, give you above average, if not excellent results in what they do. Right? Whereas, like, a lot of, I would say, hiring practices out there are kind of, like, weirdly, like, just signal gathering for, like, signifiers of status or just like, oh, you were at big company here and, like, you moved random numbers, so that means you must be good. But then, like, you actually work with them and, like, actually talk with them, it it doesn't really line up. Right?

Like, you know, there's a lot of again, I'm I'm probably getting myself in trouble with this. There's a lot of, like, big company executives out there, right, who, like, with a straight face, take credit for, like, you know, three times revenue growth. And then, like, you really dig in with their actual accomplishments, and it's like, you didn't actually do that. Right? So, like, I would much rather work with someone who is, like, slight you know, slightly insane, kind.

Right? Like, you know, you can't you can't be weird and you can't you can't be and rude at the same time. But someone

Yeah. That's

true. There's a budget. Right? But, like, again, I would I would argue that anyone at Railway or really anyone who wants to build a high performance organization, I think, has those traits, where it's like, there's this kind of, like, team identity that again, if you were to swap maybe one person or two people out and assuming it's, like, a group of eight people, the people the new hires that do join are able to kinda intuit explicitly and implicitly from the standards of the culture of that organization, and they're able to kind of show up. Mhmm.

Which, again, is a whole other sales issue as well because a lot of sales organizations usually are kind of built in this, like, churn and burn fashion, which I think is a a very big gripe I have with with the sales industry or rather the sales profession.

That's true. Yeah. It's Oh, you didn't get you didn't

hit your quota. Bye. You know? It's just like, what you know? Yeah.

It's it's a it's a weird it's a weird dynamic. I I don't necessarily think, like, they do this out of, like, this, like, masochistic desire to just, like, fire people. Right? In a in a perfect world, you know, your sales organization is on fire and is just, like, ripping through without any issues. Right?

And, of course, there's gonna be, like, you know, some management issues as it is with any sort of role. I think the issue is is that when I think when Railway was faced with that exact same kind of juncture point, right, where, you know, a lot of the advice that we were getting was, hey. Look. It's time to start maybe not jumping to territory managers. Right?

Because that would be, like, I don't know, a way overkill from where we were at. But there was kind of this idea that, like, you can kinda do this, like, paint by numbers support thing, and you can just, like, paint by numbers sales process. For us, we were just basically kind of intuiting, like, look. What can we do to make the purchasing process as automatic as possible such that, you know, the sales experience is an enjoyable process from start to finish, which is requires, like, a a radical reimagining of, like, how sales organization is done.

It's not optimized for revenue. It's optimized for experience.

Oh, don't get me wrong. It is optimized for revenue. But yeah. I guess the thing is, like, if you give someone a really good experience. Right?

Again, the, you know, show up and take my money aspect of it is automatic, not necessarily you have to, like, induce it into into your customer.

Yeah. I guess this is, a different stage of, like, optimization and that you're optimizing the bigger picture rather than, like, just the immediate, like, revenue generation. Angelo, we're getting dangerously close into, like, longest episode ever territory.

No. Which I think

Adam Franco is currently the holder of.

Yeah. Your your editor is gonna need a lot of help.

And so far I have really enjoyed this. I think people won't know this, but we've been like kind of DM buddies for ages but never actually met and this has been incredible. I could ask you stuff all day and I think would love to have you back on again getting premature premature here. But thank you so much. That was brilliant.

Thank you, Jack. And it's a pleasure to be here. And hopefully, yeah, your listeners get value out of this out of this conversation.

And by the way, do you have any like shout outs that you wanna direct people to?

Railway.com. Oh, man. Yeah. You know, if if you have code that you would like live, railway.com is there. But also, I think yeah.

I would I think it's probably my my my first and only shout out. And then I think I have like a few, I think, books of note. If anyone wants to kind of like read the literature, think, behind this stuff, I think it's a fascinating world. If you wanna dive into, I can pass those things on to to your listeners.

Yeah. That'd be amazing. We'll fill out the show notes and there's a lot of stuff. Thank you, Angelo. Really appreciate it.

Thanks everyone for listening. If you made it this far, send us send us a message. Let us know.