What we "want" and what businesses will demand are very different things. I can tell you from 40 years build software, all companies care about is functional software. They don't care about code quality, maintainability, or tech debt. Never seen a single CTO say, "Let's carve out 20% of our sprints for tech debt," even though as architects we recommend something like that all the time.
I think we are both saying similar things here (believe it or not). Sales leaders turnover with surprising frequency - 18-24 months. About the time the sales team tells you what they “want” and you fine tune it, they will be gone. The next person will come in and probably scrap 50-75% of what the prior leader did. New requirements.
Meanwhile, besides functionality, you’ll want/need to plug in the latest and greatest go to market tools for marketing -and demand gen. But… that’ll be a custom effort, too.
Along the way you’ll also realize that you’re missing out on the most common practices in the industry because you built some idiosyncratic tool that only is relevant to your company.
History may very well prove me wrong, but I think you’re underestimating the expertise that underlies these products and platforms. It’s not just code, and the costs of getting it wrong are more than just an engineer’s time. When you waste time in GTM the impacts on the business and valuation are not linear, they’re exponential.
Agreed. We went from “internalise your core business and contract what doesn't give you an edge” to “actually just build everything in-house with AI”. Maybe that’ll be the better option in the end, but for now it looks like tons of wasted effort. 100x developers working on the wrong thing.
I wish I could upvote this more than once. The author gets it, you have to sell outcomes. Not features. Seems like every open source company that doesn’t market an outcome to buyers will face a similar threat. And this particular go to market strategy was “brittle” before AI.
It’s sort of difficult to understand why this is even a question - LLM-based / judgment dependent workflows vs script-based / deterministic workflows.
In mapping out the problems that need to be solved with internal workflows, it’s wise to clarify where probabilistic judgments are helpful / required vs. not upfront. If the process is fixed and requires determinism why not just write scripts (code-gen’ed, of course).
This bothered me at first but I think it's about ease of implementation.
If you've built a good harness with access to lots of tools, it's very easy to plug in a request like "if the linked PR is approved, please react to the slack message with :checkmark:". For a lot of things I can see how it'd actually be harder to generate a script that uses the APIs correctly than to rely on the LLM to figure it out, and maybe that lets you figure out if it's worth spending an hour automating properly.
Of course the specific example in the post seems like it could be one-shotted pretty easily, so it's a strange motivating example.
It seems easier but in my experience building an internal agent it’s not actually easier long term just slow and error prone and you will find yourself trying to solve prompt and context problems for something that should be both reliable and instantaneous
These days I do everything I can to do straightforward automation and only get the agent involved when it’s impossible to move forward without it
My gmail address is first.last@gmail.com. From time to time (and for years) I get someone else’s at firstlast@gmail.com. I thought that a Gmail account that was first.last@gmail also allowed for email sent to firstlast@gmail (no period) to reach my inbox as well.
I’ve received some sensitive/PII content over the years.
I’ve wondered if this person has access to any of my information?
Not necessarily related to this post, but wonder why and how this could happen.
> I’ve wondered if this person has access to any of my information?
No. They have just told someone your email address and that someone has sent you stuff. Anyone can do that, if they dream up your email address. People having the same name are a lot more likely to do that.
Happened to me as well. I was the first one of the 50 people or so carrying my name to register "first[.]last@gmail.com" back in 2004. At least two of my namesakes have since mistakenly used my email address. Some people just aren't very detail-oriented.
I have a first.lastname@gmail.com, and my namesake has firstmlastname@gmail.com (with middle initial, and I think they originally created the GMail username without periods).
So, I sometimes receive emails intended for him, by people who saw firstmlastname and think it's firstlastname.
Maybe around a hundred emails so far, over the years.
I've gotten good at telling at a glance that an email is for him, without reading it, and forwarding and deleting.
Fortunately, my namesake is a very accomplished good-guy, so I'm happy to help.
I still control my first name @gmail.com from very early on, but have never been able to put it to use because of the relentless torrent of misdelivered email.
Maybe their email is lastfirst@gmail.com, and people occasionally misremember your address and send your correspondence to them. In that case, yes.
More likely their email address is firstlastnumber@gmail.com or firstlast@otherprovider.com though, in which cases the types of mistakes people make are likely asymmetric.
No, I think what's happening is someone else is confused what their email address is. With Gmail, dots are not significant; any email address with dots is equivalent to the email address without any dots. (So you may have signed up as first.last@, but your email address under the hood is really firstlast. You can also send mail to your f.i.r.s.t.l.a.s.t@gmail.com, and it will be delivered to you.)
I expect that someone else with the same name as you occasionally (or all the time) forgets that their actual email address is flast@gmail.com or lastfirst@gmail.com or some other similar combo, and enters your email into signup forms. Or has friends who guessed their email address and got it wrong. Or something.
That other person doesn't have access to your information.
Handy tip for software testing - Gmail ignores everything after a “+” in the address. So when you’re testing different accounts in your software you can use <youremail>+1@gmail.com, <youremail>+2@gmail.com, <youremail>+3@gmail.com etc. to create many different accounts in the software that all go to the same email address.
There are revenue recognition rules that govern what Revenue is on the P&L. Same with costs/expenses. But I would say if anything, profits are easier to manipulate than revenue.
Had me hooked right up to this point: “When we get the check, we pay a commission to this representative. Assume the commission is $500.”
I’ve never seen a software company pay 50% commissions on a software sale. I know it’s and example but the percentages are wrong even for the perpetually licensed days. Should be closer to 8-15%.
Totally sales and marketing spend could indeed be higher in this model because autodesk moved to direct positioning with end buyers rather than distributors.
Commissions were different back then. I worked part time selling computers around 1990 and a little earlier, margin on computers was moving down, but was as high as 50%, I recall it moving down to 30% and stabilising there for a while. I don't remember software margins, but it could have been about the same. I used to get 50% of the margin as commission.
When I sold Windows 2.1 at Egghead Software, my spiff was an extra 30% for the first month as a promo. I always assumed that was a loss leader by Microsoft to push extra copies on release.
I'm pretty sure this is a roughly accurate breakdown of AutoCAD's cost structure 34 years ago. How long have you been in the business, and what was the highest-sticker-price software you were selling?
I can tell you with near-100% certainty. This isn’t what you want to happen. Disaster in the making.
Just because you can doesn’t mean you should. There is very little competitive advantage to be gained from this type of effort in most companies.
reply