This post was so in-line with her writing that I was really expecting it to turn into an ad for Honeycomb at the end. I was pretty surprised with it turned out the author was unaffiliated!
> Selling to businesses is very easy. You go to a business and you say "hey, you like making money?" And the business will say "why yes, I do like making money" and you will say "great, I can help you make more money.
This is so wrong it hurts. You'd be amazed at how often "I will save you $X, guaranteed, or your money back" is a non-starter when selling to companies.
I've spent a career very slowly gaining respect for enterprise sales people - going from "Ugh, sales people are all snakeoil salesmen" to "I can't believe what they do is even possible, much less regularly done" over about 20 years.
Selling software to large organizations involves finding a champion within the org, then figuring out the power structure within the org via an impressive sort of kremlinology. You have to figure out who loves your product in the org, who hates it, who can make the buying decision, whose approval is needed, who's handling the details of the contract, and so on. You need to understand the constellation of people across engineering, procurement, legal, leadership, and finance – and then understand the incentive structures for each.
Then you have to actually operate this whole complex political machine to get them to buy something. Even if it's self-evidently in the interest of the whole organization to do so, it's not an easy thing to do.
Anyway, all that to say: "b2b sales are easy" is... naive... to say the least.
I've been watching this process with a keen eye as a technical consultant, and one thing I've learnt is that naive models of large organisations as Profit=Revenue-Costs is totally inadequate for enterprise sales. Yes, it is true that saving money anywhere will improve profits, but you can only sell that to an individual who's personal KPI needles move because of this! If the cost is in dept X but the profit is recorded in dept Y, then don't bother. You won't get a sale, even if it's tens of millions of dollars of saved costs or increased revenue. At best, you can find their common manager and try to sell it to that person, but even that has pits of failure you can all too easily fall into.
Yes. But that's like saying "a racecar would gain a competitive advantage by being faster."
Getting your internal structures right and aligning your incentives is one of the main challenges of building and running a large company! If it were easy, you wouldn't see nearly so many massively-inefficient corporate giants. :)
A big part of that is “I will save you X” is a non-starter. That is not making the business more money. If you have something that will actually make the business more money then they will go “Great if I pay you twice as much will it make me 2X?” and if the answer is yes, that will be a sale every time.
Given how much some companies spend on their cloud services bills without batting an eye, I definitely believe this. They care about making more money, not so much about spending less, even though both are ways to increase profits.
yes, and I think one big reason enterprise might not buy your product even if it is guaranteed to make/save $X is $ is often NOT most important thing to the people make buying decision, specially when it is not your own money to save or gain
This is very true. Look no farther than the perennial problem of department heads spending all their budget to keep their budget. Decision makers rarely care about saving money in isolation.
I might be overstating it, but here's what I see at my company. "Sell" is very different in all of these situations.
- Sell to the champion.
- Sell to the rest of the org.
- Sell to procurement.
- Sell to the implementation project team.
- Sell to the users and get adoption up.
Then constantly demonstrate that you're providing value in whatever terms that department / org thinks is valuable that year.
This is what I’ve seen; it’s hard work, and if you fail to make any one of those sales, it can all fall apart. And you didn’t even mention getting your foot in the door in the first place. I used to chat with our business development guy in the lunchroom. He spent hours on the phone every day getting told no. It took a ton of work just to get from “no” to “maybe later,” and that’s when they didn’t just hang up in him. I think he understood what made our company tick better than anybody else, better than the CEO.
> going from "Ugh, sales people are all snakeoil salesmen" to "I can't believe what they do is even possible, much less regularly done" over about 20 years.
I mean, it still sounds like snake oil salesmen. It's just that that's what it takes these days to even get noticed (let alone make a pitch). rubbing hands trumps a quality product 99% of the time.
Can confirm. At one point in my career (after reflection on the situation) I realized I had been made a champion by a subsidiary of IBM for one of their products. I found myself in some really bizarre meetings with our execs and their executive sales people that left me feeling like a puppet that was made to tell our CEO that we needed this. They really took us apart, It was all very slimy.
This is one of my next learning goals: getting a better feel for which models to use when. "100% claude 4 Sonnet" worked pretty well, but I want to keep pushing myself out of local maxima.
It's niche, but I wasn't really able to find anything else like it. I wanted to project our some retirement scenarios and my options seemed to be:
- Any of a few dozen "retirement calculators," each consisting of 6 fields and very simple outputs
- Building out a series of buggy spreadsheets
- Projection Lab
After messing around for it a bit, it was a "shut up and take my money" situation. It was cheap, it was powerful, it was nice to use, and it has been the foundation for my personal financial strategy for the last few years!
1. D&D mechanics, like all games, are a simplification of the real world using primitives like "firing a bow" and "passing an item" and "downing a potion"
2. The real world is fractaly deep and uses primitives like "plank length" and "quark spin"
3. Therefore there will always be places where the real world and the simplification don't line up. Finding those gaps might be a fun meme, but it's not an exploit. We play with the simplification's primitives, not the real-world physics'.
My approach is that there is a tension between three things:
1. The "combat simulator" built into the rules. I run this according to the spirit of the rules, so that players' investments in classes and feats pays off as expected. Otherwise my players feel cheated.
2. The simulation of the world. This is important because it makes the world feel real and believable (and because as DM, I get many of my plot ideas by "simulating" consequences).
3. The story. The campaign should ideally tell a story. Sometimes this means involving what I think of as "the Rule of Cool (But It's Only Cool the First Time)."
The "peasant railgun", unfortunately, fails all three tests. It isn't really part of the intended combat rules. It doesn't make sense when simulating the world. And it probably doesn't fit into the campaign's narrative because it's too weird.
On the other hand, if a player proposes something really cool that fits into the logic of the world, and that also fits into the story, then I'll look for ways to make it happen.
Let's say the PCs find 200 peasant archers, and set them up on a high hill, and have them all rain down arrows on a single target. That seems like it ought to work, plus it's a great story about bringing the villagers together to save the day. So in this case, I'll happily handwave a bunch of rules, and declare "rain of arrows" to be a stupidly powerful AoE.
But different tables like different things, so this isn't one-size-fits-all advice!
Enough peasants should be devastating, right? Get a couple thousand and at least some will crit per round. Rolling it might be hard. Against a sufficiently armored enemy, might make more sense to just do “expected number of crits per round” or something…
To me this is one of the better things about combat in Dwarf Fortress and one of my least favorite things about most rule sets. It doesn't matter how "high level" you are; outside of specific edge cases a ridiculous number of opponents all landing hits simultaneously ought to do anyone in. Unfortunately most rule sets seem to stop at "lol high AC" with little to no nuance.
Considering a crit always hits in a lot of systems, I don't see how a swarm of weak enemies couldn't overwhelm high level players given enough numbers.
I'm going to be that guy - because I love being that guy, and I won't apologize for it - and point out that we're not even sure if those are primitives!
Haha, yeah, I, I was considering putting some disclaimers around those. "What actually are the true, base-level primitives of physics?" has been an ongoing project for centuries. :)
Yep. Clickhouse is absolutely great for tons of production use cases.
Unless you try to join tables in it, in which case it will immediately explode.
More seriously, it's a columnar data store, not a relational database. It'll definitely pretend to be "postgres but faster", but that's a very thin and very leaky facade. You want to do massively a complex set of selects and conditional sums over one table with 3b rows and tb of data? You'll get a result in tens of seconds without optimization. You want to join two tables that postgres could handle easily? You'll OOM a machine with TB of memory.
So: good for very specific use cases. If you have those usecases, it's great! If you don't, use something else. Many large companies have those use cases.
The majority of our queries have joins (plus our core logic often depends on fact table expansion with `arrayJoin()`s) before aggregations and we're doing fine. AFAIK whenever we hit memory issues, they are mostly due to high-cardinality aggregations (especially with uniqExact), not joins. But I'm sure it can depend on the specifics.
Definitely agree with this, I think ClickHouse can do a lot with joins if you don't implement them naively. Keeping the server up-to-date is a part of it too.
They've made strides in the last year or two to implement more join algorithms, and re-order your joins automatically (including whats on the "left" and "right" of the join, relating to performance of the algorithm).
Their release notes cover a lot of the highlights, and they have dedicated documentation regarding joins[1]. But we've made improvements by an order-of-magnitude before by just reordering our joins to align with how ClickHouse processes them.
> More seriously, it's a columnar data store, not a relational database.
Could you explain why you don't think ClickHouse is relational? The storage is an implementation detail. It affects how fast queries run but not the query model. Joins have already improved substantially and will continue to do so in future.
The storage is not just an implementation detail because it affects how fast things run, which affects which tasks it's better or worse for. There's a reason people reach for a columnar datastore for some tasks and something like postgres or mysql for other tasks, even though both are technically capable of nearly the same queries.
Honestly, it's been pretty great at my tiny startup. The designer has a list of tweaks he wants that I could do pretty quickly... once I'm done with my current thing in a day or two. Or he can just throw claude at it. We've got CI, we've got visual diff testing, and I'll review his simple `margin-left: 12px;`->`margin-left: 16px;`.
But we're unlocking:
A) more dev capacity by having non-devs do simple tasks
B) a much tighter feedback loop between "designer wants a thing" and "thing exists in product"
C) more time for devs like me to focus on deeper, more involved work
reply