I see very few companies today that hold a strong, principled opinion about technology, about how it should shape the way we build and operate businesses at scale. Instead, what dominates is a kind of thoughtless momentum. Especially among new founders, there’s this impulse to chase whatever’s trending. MCP gets launched, and the industry rushes to slap it on anything remotely viable, regardless of whether it makes sense or whether the application is null and void. And to be blunt, MCP itself isn’t well-suited for most real-world scenarios beyond hobbyist tinkering.

Honestly, I’m disappointed.

There used to be a visible line between those who built technology with the right incentives, open source contributors, more mature companies solving real-world problems, and those caught up in hype cycles. But now the line is blurred. And it feels like we’re in a market where the ability for a fad to explode is 100 times what it was five years ago.

Why? Because the reach of a few voices is now exponentially amplified. We’ve created channels that allow hype to spread like wildfire. And we, both as a society and an industry, consume this media with alarming passivity, rarely stopping to think critically or to question.

What I see is a consolidation of influence. Large companies and VC funds have managed to monopolize the main platforms we use to share and discuss technology. Twitter (or X), LinkedIn, they’ve become echo chambers. And the result is a community that’s increasingly unwilling to question whether anything actually works. Whether these agents and lab models are genuinely useful for complex, real-world problems, or if it’s just smoke and mirrors, marketed to oblivion.

This doesn’t mean we need to be cynical. But we do need to be realistic.

Very few voices are speaking the truth about AI: that despite our excitement, despite the optimism, we haven’t yet unlocked true, meaningful efficiency gains. And the issue isn’t the tech, it’s how we’re using it.

I’ll go out on a limb and say this: the first company to discover real operational transformation through AI won’t do it with a massive, overhyped model. They’ll do it with something small. Focused. Elegant.

For my part, I’ve never really felt like I fit in the tech bubble. I moved to San Francisco over a decade ago with one purpose: to build value. To build software that enables people. I didn’t come for the politics, the VC narratives, or the noise. I came to solve problems that matter.

But those problems are increasingly ignored, pushed aside in favor of self-reinforcing, perverse incentives that reward hype over utility. So I find myself withdrawing from the loud spaces, Mainstream X, LinkedIn, and seeking out the quiet, dissenting voices. The ones called “party poopers,” “weirdos,” or, as OpenAI once labeled them, “haters.”

I’m not interested in sycophantism.

I’m interested in building.

If you are also interested in building and don’t care about hype, please DM me. I’m looking forward to meeting you and putting our minds together.

He passed our interviews, including our in-person interview in San Francisco. He had glowing references from other industry professionals in our network. As far as I know, most of his resume wasn’t actually fabricated. He passed both KYC for our EOR and our own background checks with Checkr.

This is no Catch Me If You Can story. This is the story of a technically able engineer who decided to pull a fast one on a bunch of companies. Probably ego, probably needed the money, probably both.

A disappointing industry: tech has become Idiocracy

The most disappointing thing isn’t that an engineer, bordering on sociopathic, decided to nuke his career for a stunt. He abused the confidence and trust we put in him. He also destroyed his prospects of coming to the US (we spent resources trying to sponsor him for an O-1 visa). I’ve learned to be selective about trust, and I’m simply not as disappointed in the situation.

In fact, we laughed about it as a team. He never had access to production systems and worked primarily on an ancillary project. We were just about to let him go after a bit working with us because his performance and quality of work were simply so bad. While he has garnered an apparent following over this stunt, and apparently secured offers from companies willing to destroy the due diligence process in their next funding round, I’m not surprised. Ultimately, he’s done more harm to himself than to us. It’s ridiculous. It’s silly.

The disappointment comes from the industry’s reaction. While I employed him for 3 months, and just terminated him, you have all fallen for his stunt. Podcasts giving him a platform for victimhood, tech people on X claiming he’s a Robin Hood, wishing him well.

Let me tell you my opinion straight up: you have all become a circus. You’re simply not serious operators. You now glorify con artists and the grift. You’ve blurred the lines between hustling and fraud. You’ve placed your priorities on a 20-something-year-old who, in his emotional immaturity, has made sure he’ll never hold a serious job for the rest of his career.

For the last year, I’ve noticed a shift in tech culture. The loss of morality. The loss of values. Incubators now openly encouraging their founders to bend the truth for a quick buck. Rounds being raised on fake logos. Engineers now being glorified for lying to multiple companies at the same time.

You simply are not serious people.

Who I am and what I’m made of

I told my wife 2 days ago that I was thinking of quitting “tech” after bem. My morals are simply not aligned with the rest of the industry anymore.

This has re-ignited my fire to build and ignore those who lie and cheat.

I am, however, not wavering. I will die before I allow my morals to be bent or broken. I have nothing but my word and my reputation, and I will never break either of them.

I believe in long-term value, beyond the fads and the hype, and I will continue working until the day I die to earn the trust of real customers, real people, and real businesses who use my products and services. I don’t lie, I don’t cheat. I just work.

And to all of you who enjoy this kind of stunt: we simply live in different worlds, and I no longer want to be part of yours.

This is about power.

This is the slow, inevitable formation of the American Zaibatsu, technology conglomerates that don’t just make software but own entire verticals through deep integration, acquisition, and distribution control.

Software is no longer enough

A few years ago, Salesforce was still trying to pitch itself as the number one CRM. Now, it calls itself the number one “AI CRM,” whatever that means. Everyone's putting AI lipstick on their old platforms. The problem is, AI doesn’t just need compute. It needs structured, contextual, governed data at enterprise scale. And Salesforce doesn’t have that. Nobody really does.

So Salesforce bought the stack. Again.

Data Cloud wasn't enough. MuleSoft wasn't enough. Tableau wasn't enough. They needed actual data management — metadata, MDM, lineage, governance. The plumbing. That’s Informatica’s game. Not sexy, but vital.

With this move, Salesforce is trying to become the system of record, the system of intelligence, and the system of execution. That’s not a platform anymore. That’s a state apparatus.

From products to empires

This isn’t just a tuck-in acquisition. This is about Salesforce building an operating system for the enterprise. One that doesn’t just store your customer data but decides how it’s processed, visualized, interpreted, and acted on. Autonomous agents? They’ll be plugged into this stack, top to bottom. Governance? Built-in. Identity? Tracked. Context? Provided.

This isn’t a feature play. This is a moat play. It’s vertical integration, Silicon Valley style.

The real story isn’t Salesforce buying Informatica. It’s what everyone else has to do next.

The American Zaibatsu thesis

Every tech company is converging on the same realization: there’s no future in being a one-trick pony. AI blew up the old GTM playbook, obliterated vertical SaaS, and devalued proprietary feature sets. You can’t win on product alone anymore.

Now, you need distribution. You need ecosystems. You need to own the whole pipe.

So companies are going full stack. Microsoft. Amazon. Oracle. Salesforce. They’re all building their own zaibatsus, complex, semi-autonomous, multi-vertical technology empires. AI is the excuse. Data is the lever. Control is the prize.

We’re not going back to small. The American tech giant is becoming what the Japanese industrial conglomerate was in the 20th century: a full spectrum player across infrastructure, services, data, and capital.

The Informatica deal is the canary

Salesforce knows its AI isn't enough. So it bought a company that’s been quietly organizing the data universe for two decades. Informatica is the kind of vendor most software engineers ignore but every CIO signs off on. Their entire business is being the boring part of the stack that makes the rest work.

In other words: infrastructure for trust.

You can’t run autonomous agents on garbage data. You can’t automate business processes with shadow IT. And you definitely can’t scale AI across the enterprise without knowing where your data came from and who touched it.

Salesforce is buying safety. Legitimacy. The right to operate AI at scale in regulated, risk averse, audit heavy environments. The only kind that actually makes money.

What this means for the market

This is the beginning of the end for the “pure” software startup. Nobody wants a point solution anymore. Not when the giants are bundling it all and embedding it directly into workflows. If your product doesn’t plug into someone’s zaibatsu, you’re already losing.

Expect more rollups. Expect more acquisitions. Expect every major platform company to start looking more like SAP in the 2000s, but faster and far more capable.

In this new model, value isn't created at the edge. It's orchestrated from the center. Control the core data layer, and you own the rest of the stack.

A warning to the bold

Snowflake, Databricks, and the rest of the rising data infrastructure players are inching toward the public markets, still structured like product companies. But the terrain has shifted beneath them.

They don’t have the luxury of a decade-long incubation like Alphabet did. Google had time to evolve into a conglomerate. These companies won't.

Salesforce is moving fast. So is Microsoft. So is Amazon. The giants are building full-stack ecosystems with ruthless vertical integration; not to win customers, but to make absorption impossible.

If you're not building defensibility across the full enterprise stack, from data layer to execution engine, you're not building a business. You're building an acquisition target.

This isn’t just about valuation multiples or IPO optics. It’s existential. Either structure yourself like an empire, or be ready to join one.

Parting thoughts

The old Salesforce was a product. The new Salesforce is a bureaucracy.

And that’s not a bad thing.

The market doesn’t reward elegance anymore. It rewards comprehensiveness. Vertical dominance. Full spectrum coverage. That’s what Salesforce is chasing, and they’re not alone.

The American Zaibatsu is here. It's not just a metaphor. It's a model. And if you're building software in 2025, you better pick a side.

Because this isn't a product war. It's an empire war.

Tech companies were once unique and exceptional because software served as a powerful tool for mechanizing labor and automating business logic. Very few people knew how to build it, giving those who could a massive advantage. In other words, the people buying software couldn't feasibly build their own. That era is over.

A new paradigm: all companies are becoming software companies

The concept of a software company is changing dramatically. Now more than ever, all companies are becoming software companies simply by virtue of using software. The key driver here is that the building blocks of software have improved dramatically; not only in automating work and business processes, but also in making it easier for more people to build their own solutions.

I'm not advocating that vibe coding platforms like Cursor or Lovable are going to replace traditional software development. What I'm actually pointing to is the emergence of higher-level abstractions that are much more powerful for building production-grade software. We still have not seen a production-grade code co-pilot that can consistently produce high-quality software for enterprise environments, which account for 99% of international commerce. What I am starting to see, however, is the rise of more modular platforms that leverage AI for ontology mapping and business process discovery. These tools are enabling a new class of builders to participate in software creation in a more meaningful way.

The impact on Software Engineering jobs

This shift means that, contrary to popular belief, demand for software engineers is set to grow. Companies like Klarna and Workday have tried to signal to the markets—mostly to support their stock price in a misguided attempt to appease the markets—that they no longer need as many people. But historically, every major leap in labor mechanization over the past century has created more jobs, not fewer. The market isn't zero-sum. Capitalism expands capacity for output, and that expansion creates new roles.

Companies will be able to generate significantly more economic output than before, and that will result in more employment. Of course, this will require some workforce re-skilling, but it's already happening. For the first time, at bem we're seeing even traditional and family-run service companies hiring CTOs, software engineers, and data scientists to build their own tools.

Services companies building software

My thesis is simple: service companies that once relied heavily on external software vendors are going to become software companies themselves—faster than today's software companies can adapt to this shift or remain relevant players in the market.

The decline of vertical SaaS

As a result, SaaS (especially vertical SaaS) is going to thin out. The most likely outcome is that vertical SaaS will largely disappear within the next five years. The original promise of SaaS was delivering software that customers couldn’t feasibly build themselves. But with improved primitives, that’s no longer the case. Customers now place less value on prebuilt software.

So the trend of building custom, in-house software is growing. And with the introduction of newer LLM and VLM technologies, companies are adopting a software-first mindset by default, not just as a fallback.

Another problem: vertical SaaS promised tailored workflows from small, nimble startups—but that promise has repeatedly failed to deliver. Unless vertical SaaS is extremely modular, it’s often no better than generic horizontal solutions.

The only vertical SaaS companies that will survive are those that use AI not out of FOMO or investor pressure, but by truly embedding it into their workflows. These platforms will succeed by becoming more modular and better adapted to the specific needs of companies—even within the same vertical. This includes leveraging AI to significantly reduce customer acquisition costs, implementation costs, and time, ultimately enabling the delivery of highly tailored software solutions with zero downtime or implementation lag.

The coming consolidation wave

We’re going to see a wave of consolidation. Many companies that raised hundreds of millions in VC funding will have to face the fact that much of that capital will evaporate in the coming years.

Some SaaS companies are already adapting. They’ve taken one of two paths: either raising funds to pursue private equity-style roll-ups, acquiring service businesses to become full-stack market players; or transforming their platforms into modular systems that allow customers to build on top of them. It's all about the packaging.

What this means for tech VC

For tech VCs, this new reality requires a serious strategic shift. The days of passive capital flowing into high-valuation software startups that promise eventual dominance are ending. The investment thesis has to evolve. VCs must begin evaluating companies based on operational integration, domain expertise, and their ability to embed deeply in real industries, not just their ability to scale user counts or feature velocity.

The next generation of successful investments will likely come from firms backing startups that actively participate in services, offer modular, domain-specific platforms, or execute intelligent roll-up strategies that give them end-to-end capabilities. It also means understanding the new dynamics of value creation, less about proprietary code and more about embedded execution, workflow precision, and outcome-driven design. It's all about the packaging.

The new GTM: packaging, friction, and distribution

In this new landscape, the companies that win won't just have great products, they'll have the best packaging. Go-to-market strategy is no longer about brute force sales ops or BDR/SDR armies. Crusty old outbound motions are evaporating. Truth is, they haven’t really worked since the end of the pandemic.

What works now is frictionless adoption, modularity, and clarity of value. If your software requires a multi-week implementation plan and a hand-holding team, you're losing. Speed, flexibility, and clear ROI are non-negotiable. The winners will be those who design distribution into their product, who can scale without needing armies of account reps or long sales cycles. It’s not just about building software; it’s about packaging it in a way that feels instantly useful, instantly customizable, and instantly scalable.

A changed market and a new playbook

In short, the era of the standalone software company, especially the software startup, is over. It’s now entirely feasible for service companies to develop production-grade tools in-house. The market has changed fundamentally.

Software exceptionalism is finished. Startups will need to rethink how they operate, get more involved in real service layers, and build modular, integrative solutions. For tech VCs, this means adapting as well. They must either accept lower valuation multiples and fewer liquid exits, or start investing in companies with tangible operational capacity, whether through functionality or equity-based roll-ups, that actually deliver value in today’s market.

Parting thoughts

None of this is theoretical anymore. It’s already happening. The infrastructure is here. The primitives are getting more mature. The market signals are clear. The companies that win in this new era won’t be the ones chasing the next shiny framework or marketing buzzword, they’ll be the ones closest to real workflows, solving real problems, with software that feels native to the business, not bolted on.

Software is no longer the moat. Execution is. Modularity is. Market understanding is. The distinction between a software company and a service company is dissolving. What matters now is who can build better, faster, and closer to the metal of their customers’ needs. It's all about the packaging.

Adapt, or become irrelevant.

But behind the spreadsheet magic, a lot of this revenue doesn’t stand up to scrutiny.

Over the last year, I’ve noticed four common tactics used to inflate ARR numbers. Some are misleading, others are borderline fraudulent, but all of them share a common goal: to turn what’s essentially a services business or a leaky funnel into something that looks like a SaaS rocket ship.

Here’s how companies are doing it—and how you can tell what’s real and what’s storytelling:

1. Churn-and-burn ARR

The easiest lie is still the most common: shovel money into customer acquisition, drive up your top-line ARR, and quietly lose 80 percent of it every quarter. The churn is hidden in plain sight, but often ignored in a rush to show growth.

How to spot it:
Look at cohort retention. If new revenue spikes but NRR (Net Revenue Retention) sits below 70 percent, you’re not looking at a business. You’re looking at a leaky bucket. No amount of logo growth can mask decaying cohorts. Dig into retention by month, not just by quarter, and insist on a view of revenue that's net of churn and downgrades.

2. ARR with a shadow engineering team

Another favorite: calling something "SaaS revenue" when in reality it's being propped up by a fleet of forward-deployed engineers. These engineers don’t work on the product. They work on the client’s product. Which makes them not engineers in the classic sense, but embedded services staff.

How to spot it:
If the company’s margin looks suspiciously low for a SaaS business, it probably isn’t a SaaS business. Look below the line—cost of services will be bloated. Headcount will skew technical but not product-focused. And when you ask about unit economics, you’ll hear stories about “strategic customers” that require “temporary” customization. Those customizations are permanent, and so is the burn.

3. Recording raised money as revenue

This one is rarer but more egregious. Some founders in early-stage companies have literally booked investment dollars as revenue. Not bookings. Not deferred revenue. Revenue.

How to spot it:
You shouldn’t have to. If this shows up in a diligence process, run. Not only is it dishonest, it’s illegal under GAAP. The second you hear “we counted a portion of the round as a customer commitment,” stop the conversation.

4. The pseudo-marketplace trick

The company claims to be a marketplace with huge top-line numbers, but they’re just acting as a passthrough. They take a transaction, claim the entire transaction volume as revenue, then quietly pay out 90 percent of it to the supplier or service provider on the backend.

How to spot it:
Gross margin will tell the story. If a company with $10 million in revenue only has $1 million in gross profit, they’re not building software. They’re arbitraging volume. That can work, but it’s not high-margin ARR. Check their revenue recognition policy and look closely at their COGS line—anything with high fulfillment cost doesn’t scale like software.

Closing Thoughts

Investors don’t fund revenue. They fund quality. ARR is a useful metric only when it's real, recurring, and high margin. Anything less is just a short-term trick.

As a founder, the pressure to inflate your numbers is real. But long-term companies are built on long-term trust. And the fastest way to earn that trust is to show your work, own your reality, and build something that holds up to scrutiny.

The truth is, most investors can spot the lie. The question is whether you’re the one telling it or the one getting sold.

bem, the company I founded with Upal Saha in 2023, is an AI startup. We’re deep in the trenches, but it feels like we’re doing it in a war zone, not against competitors but against grifters who’ve made “fake it till you make it” the default business model. I’m almost glad our product is so boring; it doesn’t make for flashy demos. Those who use it and pay for it get value out of it.

Software used to be about product, tech, and defensibility. Moats were things like network effects, switching costs, and proprietary models. Now? The moat is narrative manipulation. Reality distortion. Polished fiction. The ability to bend the truth just enough to get to the next round. The difference between Steve Jobs’s reality distortion field and that of current founders is that there was substance behind Apple’s releases. Today’s reality distortion field is just gaslighting.

The disheartening conclusion? It worked for a while. It worked extremely well. The house of cards is starting to crumble, though, and it’s looking uglier every day.

Schadenfreude

I thought I’d feel second-hand pleasure from seeing grifters get their time in the news, but I don’t.

When “just ship it” becomes “just sell it, whether it exists or not,” trust erodes across the entire industry, between builders and customers, between founders and investors, between capital and conviction. Most sales objections we receive today at bem are due to the distrust generated by bad actors. We’ve actually built our sales process to acknowledge the skepticism in the industry; everyone tries bem before signing a contract.

We’re not just talking about a few bad actors anymore. The volume is cranked up across the board. AI made it worse, not because the tech isn’t real, but because the buzz is. It’s become the perfect tool for vaporware, for faking scale, for demoing things that are literally impossible today. If the claims seem outlandish, they probably are.

This isn’t new; it’s just worse than ever before. In my 15 years building startups, I’ve lived through 3 tech hype cycles, and every cycle has gotten worse and worse. The first AI hype cycle 10 years ago was bad. The crypto hype cycle was a terrible waste of time and money. I wonder if people building true, valuable financial infrastructure with crypto felt like this back then? I wonder if they woke up in the morning saying, “Fuck NFTs; I’m building a way to make cross-border payments easily.” A bored ape makes for a much funnier demo than clicking a “Pay” button.

Call to arms: morality is not in the P&L

I get it. Being honest feels stupid today. I feel like a moron. I wonder how many people reading this are, very deep down, thinking that bending the truth to pass the hot potato to the next sucker is an acceptable moral compromise. It truly feels like the easiest thing to do today. As an investor, you get to report to your LPs their investment is on paper X% more valuable. As a founder, you get to continue building your company and skim some off the top in case the house of cards falls down.

I’ve done a lot of self-reflection lately. Building software and organizations around it is my profession. I plan to continue doing it until I die. I always play the long game. I want bem to outlive me. When you play such a long game, you simply can’t grift. It’s not that I don’t enjoy the finer things in life. Money unlocks tremendous lifestyles. Flying in a PJ to Tokyo seems like a sweet deal. I just get much more pleasure out of building in earnest. If I can ever afford to fly private, the journey to get there must be honest or non-existent.

I told Upal the other day that I finally realized what my job is in life. My job is to seek out the unjaded and the honest. In looking for partners, employees, customers, and investors. It’s all the same. There’s a group of people out there who are hungry for the right things: building and creating value, from carpentry to software. There’s people out there who will not cut corners or compromise their morality and values to practice their craft. Those people will die in peace, having rendered a positive output on our insignificant planet. I want to work with those people.

Am I jaded? Perhaps a little; but I’m also decided to continue operating how I operate. I rather die than compromise.

I was looking for the right title for this post, and Upal finally gave it to me this morning. He said to me “AI grifters are making our job harder”. I couldn’t agree more. But if that’s the fight we have to fight, then so be it.

Let’s take a step back and look at the history of how AI tools have been framed and used.

The RPA Era: The First Wave of AI

The first wave of AI-powered (or pseudo-AI) products was largely built around robotic process automation (RPA). Many companies successfully positioned themselves as RPA providers, offering tools designed to automate repetitive tasks. But here’s the thing: RPA, as a concept, doesn’t generalize well.

Take UiPath as an example. While they’ve built a name for themselves, the reality is that no RPA solution today can truly call itself self-onboardable or universally horizontal. Every implementation requires significant professional services work to integrate and maintain. Even then, these systems remain vulnerable to the quirks and volatility of human intervention and messy data.

This was the first era of AI abstraction—a time when many companies claimed to be AI-driven but, in reality, were more about clever automation than actual artificial intelligence.

The Agent Era: A New Wave with Old Habits

Now, we’re in the era of AI agents, and yet we’re making the same mistake. This time, the mistake is even more glaring because we’re anthropomorphizing these tools—treating them as if they were human.

AI agents, particularly those leveraging large language models (LLMs), have incredible capabilities, but they are not people. Humans reason. Humans engage in true chain-of-thought processes. Just because an AI system shows you a clever “loading” message or mimics reasoning with well-placed prompts doesn’t mean it’s thinking like a human.

And yet, this insistence on modeling AI in human terms is holding us back. Rather than using these systems for what they are—stochastic abstractions capable of delivering transformative insights and automation—we patch them to look and act like humans. This approach limits their potential and leads to overly complex, brittle solutions.

Rethink the Process, Not the AI

What we should be doing instead is rethinking our business logic from the ground up to fit this new AI paradigm. At BEM, this is exactly how we approach the problem. Instead of forcing AI to mimic human processes or reasoning, we focus on redefining workflows to take full advantage of its stochastic and probabilistic nature.

For example, consider how some companies approach AI’s ability to browse the web. Instead of embracing the unique capabilities of LLMs, they design solutions that force AI to act like a human reading a webpage—down to simulating how humans “think.” These are patches on patches, built around an outdated metaphor that AI needs to behave like us to be effective.

But what if we flipped this? What if, instead of anthropomorphizing AI, we allowed it to guide us in redesigning the process itself? When you stop forcing AI to fit into human-shaped boxes, you unlock its true potential to build scalable, production-ready systems that don’t crumble under the weight of human expectations.

A Call to Action

So, next time you’re building with AI, try this: step back and look at the process you’re trying to solve. Instead of asking, How can I make AI act like a human?, ask, How can I redesign this process to leverage AI as a stochastic abstraction?

You’ll find that by letting go of the need to anthropomorphize, you can create far more scalable, flexible, and innovative systems. AI isn’t human—and it doesn’t need to be. It’s something entirely new. Let’s start designing like it.

I digress, as usual. I came here to talk about software.

About 15 years ago, I emailed Hector García, a well-known blogger and software engineer living in Japan, expressing my frustrations about college, assuming he wouldn’t respond. I was in my first year of Computer Science, and I was disillusioned. In hindsight, it was a long email, but the TLDR is that I was disappointed in the lack of enthusiasm for computer science around me, the failure of 100-people lectures without any practical application, and my chief complaint: people are in this career for the wrong reasons.

To my surprise, he responded. His advice: punch through, finish your degree, eat shit, fuck, get scholarships, get out of Spain, travel, meet people, and more and more interesting things will happen to you. The important thing was to feel like your brain was being smashed, suffer, learn, and, after graduating, feel like you could do anything. I followed his advice. I got out of Spain as soon as I could, traveled, incurred debt to move to the US, and shot way above my horizon line. In the most masochistic way, I always prioritized the long-term investment of learning, rejecting every offer that came my way in the direction of a smooth toll highway and choosing the winding mountain path every single time.

Well, it’s been a while, and again, as a true masochist, it has never been easy. I founded the largest company I’ve worked for, and I’ve always started companies or worked for startups; the sooner, the better. I’ve joined companies with no name or strategy, just a glimpse of a vision, and I’ve ignored all the red flags when building partnerships, all in the spirit of learning. I’ve put my personal life on hold multiple times to grow professionally — my only regret. I’ve had terrible and not-so-terrible bosses, eaten mountains of shit, and have been told no continuously throughout my career.

Every time I’ve been told no, I’ve learned more, gotten more resilient, become more aware of my surroundings, learned more to value talent, learned about the fickle nature of adulation and loyalty, and cared less and less about what anyone has to say. Throughout my career, I hit a point of over-self-awareness, of impostor syndrome, that transformed into the ultimate realization: very few people actually know what they’re doing, and the game people are playing around me is to pretend they do. With the advent of “building in public”, this has become pervasive throughout the software industry. I’m not playing that game. I’ll sure get a lot of things wrong, but I won’t talk about what I don’t know about.

Well, you don’t know what software is, and it sure isn’t code, buddy

That’s a long introduction. I said I would talk about software, and I wouldn’t want you to feel like I’m goofing you around, so let’s dive into it.

Software isn’t code. In fact, I’ll do you one better. Every great bit of progress in software has been in the direction of depending less and less on code. Software is, after all, packaged computing abstractions reflecting business logic. That business logic is human in essence. Software is a way for computers to do what a human can do, just much, much faster and more accurately.

Code is just a communication abstraction. It serves two goals: for humans to communicate with each other about desired functionality, and for humans to communicate to a computer what it should do based on certain parameters. The first programming language, Lovelace and Babbage’s Analytical engine, was along the purest forms of communication we’ve built. IBM’s 12/80 punched card was a more mechanically compatible version of human-to-computer communication.

The creation of new abstractions has marked the last few decades. Abstractions are the reason we can move faster when building software. Abstractions are packaged pieces of computing and business logic. Whether there’s human readable code behind those abstractions or not is irrelevant. Good abstractions should be trusted and relied upon as black boxes; otherwise, they’re what we call “leaky” abstractions. Hardware and mechanical systems also have abstractions and good mechanical systems have modular components that communicate with each other as functions. As a frontend engineer, I can tell you most frontend frameworks are plagued with leaky abstractions that are poorly designed. I’m a big fan of abstractions, but you can end up in dependency hell — most systems today have too many dependencies, and their “stack” is too complicated.

Code screams in horror, with 2 conclusions

When I was building Silo, I started to notice something. It was by far the most complex system I had built, and as our system’s complexity grew, our team took longer and longer to build new features. I convinced myself that was philosophically impossible. After all, we were a great team of engineers and had progressively built abstractions to sustain our growth and further product development.

That wasn’t the problem. The problem is that humans aren’t perfect, and code inherently sucks. Big codebases become towers of babel, where teams start talking past each other in different languages to get anything done. Ensuring good communication between teams requires a herculean effort at architecture design, good software practices, and a resilient network of abstractions. I came to 2 conclusions that I continue to preach wherever I can:

1. We have to simplify tech stacks. Every few years, as a community, we should revisit our assumptions when building systems and prune intermediate layers. Not doing so is why companies have to literally stop their growth from fixing “tech debt.” Stripe produced a report 6 years ago called “The Developer Coefficient” that values global tech debt at $3 trillion. I’d be surprised if it weren’t double by today.

2. We have to write less code, and build reusable abstractions to do so. This is probably the most important conclusion I want to come across in this terrible contraption of a blog post you’re reading. Software has nothing to do with code and everything to do with the packaging of business logic. Our goal as a community of builders should be to write less and less code, instead building a universal collection of modular components that speak to each other, communicate as pure functions, and abstract raw computing power.

What is the outcome of this for users and businesses? Systems that fail continuously, are hard to use, and force thousands of people to learn and re-learn obscure ways of achieving very simple tasks.

Is AI being used the right way?

No. In fact, most AI companies are making things worse.

Simplifying tech stacks. Instead of changing the workflow paradigm, most companies today are building patches on top of flawed processes and stacks. The biggest culprit here is RPA. RPA is fundamentally the most flawed paradigm we’ve designed in the last 10 years. To top it off, AI companies are now creating a version of RPA+ they call “agents” that can browse the web and read PDFs. Instead of changing the access pattern to the underlying business logic and the abstractions, we’re creating parodies of humans, anthropomorphized processes that try to emulate humans doing their work, when the goal should be to allow the AI to run these processes as true abstractions that aren’t bound by the “human-esque” way of thinking.

Writing less code? Nope. Codegen is the hottest thing in the market and the usual talking heads in social media are selling us a future where no technical ability is required to code. “Code proliferation” is the name of the game. Codegen companies compete with each other in social media posts about the number of lines of code they’ve generated for their users that week. 1 million. 2 million. The big problem? That code must now be maintained, tested, and validated against requirements. I’ve yet to see true efficiency gains coming from codegen, aside from a marginal improvement in coding workflow. (This is especially painful to me, because I joined Kite as the first engineer years ago, where we built the first AI codegen tool ever).

Just because we’ve built models that write great code, doesn’t mean we use them for that purpose.

OK great then, so what do you propose?

Along the lines of the 2 conclusions above, I’m only excited about platforms that move in the following direction:

• Using AI to simplify tech stacks, not bloat them. Specifically, platforms that demystify software stacks that have gotten too fat, like ETL/ELT/Datalakes and Business process/BPM/Mining.

• Using AI to create abstractions. Companies and platforms whose goal is to allow their customers to delete code so their engineers can focus on designing systems and architectures, not on writing prompts to generate code no one will ever read or know how to debug. I’m especially interested in abstractions that help engineers build better software for their users, with the outcome being software that has great texture and UX, and speaks the users’ language.

I truly believe teams that build in this direction are poised to become the new generation of great computing companies to shape the next generation of software, business, and human-computer interaction.

This defines the what and why of bem. Our current wave of AI technology is one of the greatest technological gifts we’ve received, a once-in-100-year opportunity. I plan to squeeze every ounce of value out of it.

This defines my professional frustrations, passion, and learnings from the last 15 years. I plan to continue taking the mountain path, like the software masochist I am, and hopefully, in my next post, I can be just as crass but come bearing more learnings.

People don't want software. They want functionality, they want experiences. Software is just an unfortunate side effect of having to interface with a computerized system.

Similarly, people don't want carpentry or even a table. They want to have dinner with their friends, they want space to seat their loved ones and host them, they want space to put a vase with some flowers when not in use. Imagine buying a dinner table that'd require you to use a hammer every time you wanted to use it, and where the carpenter would remind you every week through a newsletter that you're using a carpentry product, and the importance of carpentry, wood, sanding, and varnishing. You could even imagine the carpenter organizing a conference about Carpentry Security, taking over a city for a week, and filling it with panels about all the esoteric ways you can prevent, fight, and punish thermites.

That's what we've done with software. We've failed the user. The promise of software was always to make people's lives easier. Anything software does, can be done by humans, just slower. Software was always going to be the means to an end, not the end. Instead, today, most software is horrible, broken, and hard to use. To top it off, because of competing interests and misalignment of incentives, all these terrible systems are incompatible and don't talk to each other. We've created yet another industry around making systems talk to each other.

We've made software the problem, not the solution. Now, most companies on Earth depend on at least 10 systems or software point solutions, decoupled from one another, integrated through scotch tape, spaghetti code, and interns. Again, because of competing interests, these cross-integrations are purposefully obtuse to the point that the end user can feel the competitive tensions between them through their difficulty. It's gotten so bad, now companies (and the people running them), have been gaslit into thinking they need more software, instead of well-designed, disciplined business processes.

It can't be that bad, you're a little much

It's bad. And invisible to most people. Good consumer software, especially entertainment, has been mostly spared. The UX bar for consumer software is incredibly high because consumer behavior is more impulsive and the goal is, well, entertainment. Terrible consumer apps are quickly criticized as they're more exposed to public opinion unless they have other elements in their value proposition. (I have a theory that most streaming today is failing and slowly dying because of its terrible UX, while they keep focusing on "content", but that's a topic for another day.).

If you insist it's not that bad, you haven't used or built enterprise software. The world, from our financial system to the supply chain, transportation, governance, and everything in between, is running on systems that are simply broken.

Most critical business processes are performed through forms, borrowed straight from a pencil-filled worksheet, where the user fills in information coming from other incompatible systems, human and computerized. This delays things and leads to human error. We've obsessively introduced bad software into every corner of every industry, making most business processes unnecessarily complicated, making communication unmanageable, and increasing the cost of doing business.

You may be under the impression that under first principles, if a piece of expensive enterprise software is failing, a company would be quick to remove it and the market would weed out bad software. Unfortunately, that's not what happens. Onboarding to enterprise software is incredibly expensive, both in the cost of the software itself and in change management. You have to train all your employees to begrudgingly use the new software, which takes weeks.

By the time you're onboarded and you realize the disaster, 2 things have happened. The software company is done with you, they've closed you and onboarded you, and multiple stakeholders from that company have passed each other the hot potato to successfully chuck it across the fence. That potato has landed on your face, splattering everywhere. You're too much of a chicken to go back to your board and explain to them that the 7-8 figure contract you just signed is a dud and the software sucks. You keep it to yourself (unless it's catastrophic). You leave in 3-4 years. Your employees will have to bear with it for 10. It's sunk-cost fallacy with a dash of misaligned incentives. Worst case scenario, the company never changes the system and loses $1 billion.

Why has this happened?

The potential of software is incredible, and with everything that has potential and hype, we tend to create lore and thought bubbles. We get so excited about the technology that we forget its application. Then we see we can make money off this technology and instead of focusing on what is making money (the underlying functionality), we focus, again, on the technology. We have now successfully built an entire industry, a software supply chain, and we can't stop talking about it.

We think so much about technology that we forget the essential: enterprise software is there to help the people running business processes and make their lives easier.

This is happening with AI. I've heard VCs ask out loud "Where's the application layer?" 15 times in the last 3 months. It's a good question. What they're asking, less politely, is "What does this actually do? And why?".

I'm done building software.

(From now on, I'm building business outcomes with software).

Your 50-year-old customer, owner of a regional light bulb distributor, doesn't care about software anymore. He's been burned by software enough times. He's done, and I'm done. He wants solutions to problems. He wants to increase his revenue by 15%.

His employees, the people using your product every day, don't care about software. They want to fulfill orders quickly. They want to understand the tools they use. They want those tools to adapt to their workflow, not the other way around. They want data to work. To get in and out of the system and do whatever it has to do. They want function, not form, and if there's a form, make it quick, painless, and easy. They want to go home to their children. They don't want to spend another hour of their day every day for months learning how to use your software.

Neither of them cares if your software uses AI. Or GPT-4. Or GPT 3.5-Turbo. Or if you fine-tuned your machine with a diesel-powered GPU. Or if it runs on Node or Python. It's not the technology, it's the function. Technology is form. Period. 200 years from now, we'll look at software the way we look at steam engines today: cool-beans way of mechanizing a process.

We can finally fulfill that promise

My cofounder Upal, a team of incredible engineers, and I are building bem to fulfill a promise that started with the Babbage machine in the 1820s.

We're not building you a UI AI agent or an RPA AI agent because we think those two concepts are part of the problem, not the solution. We're building the new building blocks for software and a new paradigm to go with it. We want your users to simply interact with systems seamlessly, and for those systems to talk seamlessly. We want you to have the tools to build this for them.

And for the rest of my life, I'm done building software. I'm building functionality and outcomes and using code as my hammer.

This rant is powered by coffee and Fred again.

These are, in my opinion, great uses of technology for good today. They solve problems that I think are paramount in society or are about to be.

Some of these may be good candidates for coop or shared ownership structures, as opposed to entirely profit-driven. That's not to say there wouldn't be a way to align shareholder value with society's value, but when the two are at odds, I'd prioritize the advancement of society. A lot of these are infrastructural and even if looked at from a selfish perspective, their success would mean a net positive economic outcome for the related industries.

Food: Decentralized, automated hydroponics and spirulina production to fix food insecurity

Problem: In October 2023, the USDA published a report that states that in the US alone, "44.2 million people lived in households that had difficulty getting enough food to feed everyone in 2022". This includes approximately 13 million children.

This shouldn't be a problem today; there are no excuses. We have the technology and the resources to get that number to zero. My proposal would be an organization that develops 2 important aspects to fix this:

1. The hardware and software necessary for an automated micro-farm that produces year-round vegetables suitable for hydroponics and fresh spirulina.

   1. This could include the software necessary to automate the distribution of these micro-farms and make them accessible to the community.

   2. To be determined whether they would be deployed directly in people's apartments or community zones. The goal here is to beat economies of scale with technology, but there's probably a local maximum of efficiency you can reach with per-home installations and it may not be enough to feed larger families. Community zones dedicated to this could be an interesting approach, provided there's engagement.

2. R&D. Lots.

   1. Hydroponics has a big issue: while theoretically, we can use technology to produce food in a distributed way, we can't beat energy and mass conversion. It's still more expensive than a farm. Hydroponics today can't reliably, at scale, produce enough biomass and become a #1 choice for nutrition. Research and experimentation will have to be done to either genetically or naturally select species suitable for our nutrition needs and hydroponic environments.

   2. Logistics. A tight supply chain has to be created for this to work. Seeds and chemicals need to steadily reach households continuously, and last-mile delivery is still an unsolved problem in logistics worldwide.

The R&D itself could render meaningful discoveries and processes that, licensed to other companies, could fund this initiative by itself. I'd design this as a platform for anyone, regardless of socioeconomic status, and special care should be taken to brand it as a universal food access tool.

Mental health is health: An integrated approach to mental health and personal growth

Problem: 1 in 5 US adults live with a mental illness. Most of them can't afford therapy. I strongly believe, and I've written about this before, that mental health is one of the greatest silent crises of our generation. We live in a fast-paced, unforgiving society that demands a lot from the individual, and we've sacrificed market productivity for health. If not fixed, this will cause mass social unhappiness and unrest, leading to our society's collapse.

There are many apps on mindfulness and meditation, and others promoting chat-based therapy with mixed results. However, I've yet to see a systematic approach to mental health that takes into account the physical and treats them as one. That's a shame since I firmly believe they are one and the same. Anecdotally, I've heard from many primary care physician friends that they find themselves doing rudimentary therapy for their patients while not being entirely trained to do so, because of the underlying cause of their conditions.

Solution: a platform that offers an integrated, full-spectrum approach to wellness:

• Nutrition tracking (and advice)

• Exercise tracking (and advice) – Exercise is one of the very few proven ways to reduce depression.

• Financial/professional tracking (and advice)

• Relationship tracking (and advice)

• Personal growth tracking.

• Automated CBT and integration with therapist's office – if the user doesn't have a therapist, the platform would offer one at a reasonable cost.

• Integration with PCP's office

The reason I keep repeating advice is because this is the crooks of the problem. When I was working on the design of the Fitbit years ago (RIP Jawbone), the hardest problem was transforming data into actionable advice and insights. If it's not immediately actionable, the user will ignore it. This means imperative, directional advice with specifics.

The goal of this platform is personal growth and balance. Most people won't do something they've never seen can be done. I'd like this platform to show people what is possible and available to them, what tools they can use to better themselves, and track their success. It can be a great complement to existing therapy, including scenarios where medication is needed.

Personal note: These aren't meant to be perfect, one-size-fits-all solutions for the problems I outlined. Food insecurity and mental health are both incredibly complex and rooted in deep societal inequities that this blog post can't do justice to. The true solution to their root causes is not tech or software, but a fairer and more equitable society that offers a truly level playing field to all of us, regardless of who we are in society. Consider the two proposals above ways to democratize access to food and personal growth while we continue working on a better society together.

Technology has a way of disintermediating markets, but it also tends to consolidate them. That's because the function of leverage through technology, just like capital, isn't linear, but exponential. When we talk about "economies of scale", we simply state that pooling resources is more advantageous than operating independently.

This isn't new. Humanity realized very early on that cooperation is greater than the sum of its parts, and created concepts to organize people around common goals systematically. The Babylonians called them tamkārum: the traders, the merchants, the moneylenders. Clay tablets suggest joint venture partnerships existed primarily for funding expeditions and seeking precious resources, with shareholders having different shares of the profits. Just like the merchant princes Asimov would write about five thousand years later, these merchants would pool resources and expertise to trade, craft, and sail around the world. And just like Asimov's — and today's merchants – they had the blessing of their governments to expand their reach, bring back wealth, and in the process, spread the hegemony of their cultures around the world.

The Phoenicians, and eventually Greeks, just perfected the codes around the behavior and function of these joint ventures. However, they still lacked legal identity or personhood (we'll talk about persons later). The Romans were perhaps the first to give clear distinctions, classes, and a modern legal code to the different types of partnerships. There were a few, some with more religious, collegiate, or social purpose, but we'll focus strictly on the commercial today: the publicani.

Venture of the past: Societas publicanorum

The publicans were born out of necessity: the Republic was expanding rapidly and the government couldn't manage its complexity. Turns out that collecting taxes across three different continents is no easy feat, especially when you have to ride by horse from town to town to collect in person. Something similar happened with public works projects: roads became longer and more intricate, thus it wasn't effective anymore to hire a single person to build them – and for that person to informally hire sub-contractors – or for the government to manage them. Most importantly, the problem with hiring individuals is that it is too risky for a single person to bear all the responsibility and liability of undertaking complex projects.

Limited liability enters the chat. It was, and still is, a partnership with the government. You undertake projects of public importance and, in return, we slightly alter the social contract so any collateral damage doesn't come back for your wealth. As you can imagine, this was very popular and the Roman Republic experienced a commercial explosion, blurring the lines between public and private for hundreds of years. Private organizations would bid for government contracts that ranged from building roads to extracting natural resources. Those bidding the lowest would win. Perhaps the most lucrative project was to collect taxes, especially from farming operations. It doesn't get more capitalist than privatizing the collection of taxes and the Romans were doing it thousands of years before Adam Smith set the foundations of free market theory.

Senators couldn't be publicani directly, but they could be shareholders (sounds familiar?). Hundreds of years would have to pass, but eventually the reign of publicani came to an end. The struggle for power between senators, their interests, and government contracts slowly degraded the concept and the rise of the Roman Empire was the final nail in the coffin. Emperors just found it much more profitable to run the projects themselves and replace the publicani with a network of pseudo-public servants, with of course a reasonable kickback. Any politics theorist will tell you that authoritarian governments can't sustain themselves just with fear: you need to grease a lot of palms. Augustus and his successors had large budgets to appease and enrich their appointees — not doing so would mean their downfall.

Venture of the present: organized risk management

I'm getting sidetracked, as usual. In essence, venture isn't new, and neither is the existence of risky investments with volatile outcomes. The lack of organization management meant that the spread of outcomes looked more like today's early-stage startup venture than the public markets. The chance of success of an expedition to the Anatolian peninsula in search of minerals was lower than, let's say, Colgate meeting earning expectations next quarter – but probably higher than a YC startup. (40% chance of the whole crew being eaten by lions vs 50% chance of a YC company raising their next round).

What is new, however, is venture capital as a function of capital aggregation and risk management. It's unacceptable nowadays for most holders of hard currency to deposit their assets directly in risky endeavors – either because they don't wish to, or because of politics, in the case of government-run funds. Venture capital firms exist as a proxy to aggregate capital and, to a limited extent, reduce the risk profile of the investments through domain expertise and mild diversification. That means the spread and access of capital to these markets has increased.

That's not to say that rich people in antiquity didn't have access to lucrative, closed investments. It was common for Roman senators and, later in imperial times, for members of the court, to have access to investments like real estate and lending opportunities. Seneca, as much as he was a stoic, was also an avid lender and famously caused the Bread and Circuses Riots of 58 AD when calling in a loan to Britannia. Historians disagree on whether he did it out of his own volition or was enforcing policy, but the fact of the matter is that average high-class (and not that royal) Romans had access to private markets before angel investors did in current times.

I won't delve into the validity of VC's current shape and form in modern times. If they exist today it's because there's a need for them. It's impractical for most startups to go directly to the Ontario Teacher's Pension Plan and ask for a $1M check. The function of capital aggregation on one side and talent aggregation on the other works most of the time. VC successful outcomes are less driven by optimizing that function and more just on focusing on the right investments, fully milking the VC's ability to go deeper into an industry and acquire domain expertise, and not spreading yourself into areas you aren't familiar with.

Venture of the future: back to basics and AI

To be frank, the "venture of the future" has been brewing over the last 10 years, with moderate success. I started seeing algorithmic VCs in 2013 that, on the surface, would use AI or pseudo-AI for different stages of their process. Some have been content using it for deal flow and CRM filling, and some have been bold enough to anthropomorphize them and give them names.

Regardless of the final shape and form, what I'm seeing is the Rise of Thin Orgs. This means the revolution happening in VC is also the revolution happening to general business and company building. In the next few years, we're going to see thinner and thinner organizations producing outcomes once only imagined by hundreds (or thousands) of employees.

Many organizations, as the years go by, get too wrapped up in their lore and vocabulary. They forget their original purpose and start becoming inward. They make overhead their purpose rather than an unfortunate consequence of scaling.

I think in the next few years we'll start seeing billion-dollar funds managed by smaller and smaller teams, and single GPs with hundreds of millions under management. Imagine a fund the size of the SoftBank Vision Fund being managed entirely by 1 or 2 people.

This also means VCs are going to have more time and energy to expand their horizons and become fully vertically integrated. Traditionally, VCs that have tried to play the hedge fund game have been burnt, soon discovering not all capital deployment is created equally. The opportunity here is a hybrid approach that improves substantially the private equity roll-up model, takes the best of VC, and turns it into a consolidation machine.

One of my bets in this direction is that vertical consolidation is going to be paramount for the rest of the decade, and seamless plug-and-play integration between systems will make this astronomically more cost-efficient, which is why I'm building bem.

I was running the numbers. I've interviewed between 700 and 1000 people in my life so far.

I started interviewing people very early in my career because the company I joined right out of college was hiring aggressively – perhaps too aggressively considering they folded a few months after I joined — and they didn't have many engineers to assess technical talent with. So here I was, a fresh, bright-eyed, severely underpaid 22-year-old engineer, interviewing engineers and designers who were at least 10 years my senior.

Since then, I've recruited and interviewed at every company I've been in, including of course the ones I've started, and every time I've learned more and more things about talent and human nature. I've interviewed people much less experienced than me and I've interviewed people that were getting their degrees while I was still in middle school playing The Sims. At different times, I've succeeded and failed at hiring good talent, in my ability to both assess the value of candidates and successfully hire them. This is an attempt to summarize my learnings over the last 10 years or so.

What's the goal?

Let's start from first principles. If you're hiring, the company you work for has the budget to increase its workforce. This means you're making money or your company has enough cash to burn and the person you're hiring will increase your chances of making money in the future. This is an incredibly shallow way of looking at the problem, and I will dive later into long-term value, but if you're not in one of these 2 camps, you probably shouldn't be hiring at all.

The reason I'm taking such a straw stance is to run through our first mental exercise: why are you hiring this person right now? Most teams I've met don't sit down and ask themselves this question. They either have a budget or, if the company is young enough, have recently raised capital and have the impending hunger to deploy it.

Understanding why you're hiring for a role is everything. It'll determine the skills you should be looking for, what this person will be doing with their time in your team, and the process you should run to find and recruit them. You have to ask yourself: what's the ideal, wand-waved, magical scenario? If this person joins the team, what's the result? What is it that you want them to do and what do you want the final result to be?

Qualities I look for in candidates

Technical qualities

I'll start with the most controversial first: hiring engineers.

I don't do leet code / algorithm-style interviews. After 10 years of interviewing engineers, I've come to the hard realization that whether a candidate can whiteboard an off-the-cuff bubble sort or write an A* algorithm in Python or not is irrelevant and gives me no signal on their prospective value to the company. I expect future engineers in my team to research things they don't know and figure out how to build them effectively at scale. That's it. I've always encouraged peer review with pull requests; if I see spaghetti code in your first PR, I'll show you how to do it better. If you continue doing it, the problem isn't being a bad programmer: you just don't know how to learn.

I'm looking for fundamentals. How good is the candidate at understanding problems and designing solutions based on first principles? How is their system-design thinking? At the end of the technical interview, the candidate should be able to produce the design for:

• Something that scales.

• Something simple; a clear answer to a clear question.

• Something that isn't over-engineered/over-designed for the needs (and constraints) of the context given.

See how these 3 qualities apply to virtually every role in a software company. I mostly have experience hiring what I am: engineers and designers. Designers, just like engineers, are divided into 2 categories:

• Need structure and frameworks, are very good at using the existing LEGO blocks to create something that has aggregate value. They can leverage existing systems to create something amazing.

• Don't need structure or frameworks and thrive in environments where they can create them from scratch. They can create systems.

Depending on the stage of your company, you may need either or both. In the first 2/3 years of your company, unfortunately, you don't have the time to create structures or manage people. You have to hire people who will present virtually no overhead to you or the team and can in fact build the structures for people to come.

That's not to say people who need structure aren't incredible designers and engineers. Just don't make the mistake of hiring them early on. They need a type of management you need to establish beforehand, and hiring them without it is irresponsible.

Cultural qualities

I need to work with people who can and want to learn. The best engineers and designers I've hired are in it for a longer-term purpose. I love hiring people who want to eventually start their own companies and projects, especially in the early stages of a company. They're hungry for something different in life and enjoy building from scratch.

Many people disagree with me, but there's nothing better than people you've hired eventually graduate out of your company, and go on to build the most amazing things. It's the most sincere form of flattery and demonstration that you can grow people from within. The best ambassadors of a company are the people that leave. They have an unbiased opinion of the company you've built. With no attached incentives, seek their feedback after they've left.

Going back to cultural qualities, because I'm getting sidetracked.

I'm looking for astronauts. NASA is well known for hiring and sending people into space who hold themselves and others accountable, eagerly accept responsibility, and have a self-aware sense of humor that keeps them cool in stressful situations.

Especially early on, I hire people who I know will correct me and speak up if I mess up. I don't need deference, I need peers. I need people who will speak up if we're building something stupid that no one, especially users, wants or needs. Sometimes it only takes one person in a room to voice the invisible – or to surface the quiet vox populi.

I look for a special kind of self-awareness. People who apply a small amount of paranoia in what they build, but with a sense of optimism. If something can't be achieved, let's find together what we can do to provide value to the user. My worst hires have been people with high technical skills but terrible attitudes: this can't be done and I won't give you alternatives. Stubbornness needs to be paired with optimism; otherwise, it becomes a terrible waste of time.

Last but definitely not least: a sense of pride in what they build. The product manager is breathing down your neck and the JIRA (yikes, but let's not get sidetracked) ticket states the deadline as today. You have the opportunity to sneak something past a PR that you know the person reviewing it will not notice. It will cause problems down the road for someone — not you most likely — but it gets you out of the ticket and everyone is temporarily happy. I don't want to work with someone who knowingly pushes a small bird poop in their code, with the only reason being to get out of it. I want to work with someone who will message the PM, come clean, and explain to them that it'll be ready tomorrow, not today, and it will be well done. Sometimes you have to eat shit to build a great product. The company will survive. Users will thank you.

Recruiting process

I try to be extremely transparent in our recruiting process: what we do, why we do it, who we are, steps, and compensation.

I worked in companies earlier in my career that stuffed their faces with Earth-saving missions that turned out to be untrue. They weaponized people's morality and used it as a weak point to recruit them. I don't believe in that. Since then, I've built companies that are much more utilitarian. We can be aspirational, and I certainly want bem to change how we build software, but I can't look at you in your face and tell you we're going to change the world forever. I can promise you an amazing place to work and develop your career. I can promise you it'll be hard, hard work, but also incredibly stimulating and fulfilling. I can't promise you we'll eradicate world hunger. Nobel Peace Prize-mission statements were created by consulting companies to charge billable hours and make you feel great about it.

I'm also very transparent regarding our funding, runway, and investors. I'm interviewing someone who may become a shareholder of the company, and they deserve that level of transparency.

I try to design interviews in a way they're conversational and respectful. In a market as liquid as tech, going into interviews with any superiority stemming from perceived – and misguided – market leverage is a terrible idea. If you really want to hire the candidate, be prepared to lower your ego and convince them you're worth it, your company is worth it. It's your job.

Conclusions and a personal note:

Finding truly great talent is the hardest thing you'll do. Harder than fundraising, surprisingly. It's very easy to hire, very hard to find and hire amazing people. Always err on the side of keeping a very high bar. I've made the worst hires in times when I felt desperate and pulled the trigger too soon. I've made my best hires while waiting for a local maximum and going all in.

I won't go into the next step in this post: company culture. However, I will say something important: the recruiting process is the face and first contact of people with your culture and values. The best recruiters are people who exude the best qualities of your culture. It changes everything.

Every year around this time I write a little retrospective on yearly highlights and learnings, but this is the first year since I have done it where I feel so much has happened, that one blog post won't be enough.

This year I've learned a lot more about myself, but mostly I've taken action on a lot of learnings from the previous year. I took a break of a few months between projects to breathe, tinker, and learn. I traveled a lot. I built new projects. I explored new technologies. I started a new company. I retired my trusty 10-year-old Thule backpack for a new Aer that I hope can last as long.

Most importantly, I feel it's the first year since I started the startup rat race where I've been able to do things on my terms, my way. In many ways, even if it sounds crazy, the last time I professionally did things my way was when I started my first serious tech blog at 15.

Back to the roots and doing things my way

I've had an intuition for years that I've never fulfilled. I felt if I had just a few months to myself, without commitments or direction, I could tinker my way into building something amazing. It would grow organically, as I tinkered more and more, into something actually useful. I just needed time (and enough money to pay rent for a few months). I had it in the back of my mind for so long until it finally became real. Earlier this year I left my baby Silo to take a much-needed break, travel, and tinker.

My first angel investor was and is, unsurprisingly, my wife. I remember watching last year a fireside chat with Infosys's founder where a member of the audience asked him if the need for financial stability inhibited founding the company, to which his wife, Sudha Murthy, interrupted saying "he had a working wife, no problem". Well, I feel very much identified. Without Sadel's hard work, I wouldn't have had the time or be able to afford to take a break, tinker, and start bem. After 18 years together, she continues believing in me – even my craziest ideas – but is also a fierce critic of my bullshit when need be.

And so I did. I took a break and played video games. Then I started driving myself up the walls needing to do things and build things. So I did. This is peak LLMs, so I tinkered precisely with that. I built my modern take on a text processor which you can only control and type with your voice, which I continue to use for my personal writing because it helps me get ideas out of my brain where I'd otherwise be stuck. I have to admit I was a little stuck when it came to problems to solve and mostly focused on the underlying technology, but I knew, I knew I just needed to keep coding and the ideas would come to me. And so they did.

🧠 Intelligently listen to your instinct

I should write a big blog post about this, because of the mistakes I've made in the last 10 years, this probably is the most egregious. Having an instinct and not listening to it is like having an open dictionary in front of you and instead trying to guess what words mean. Now I'm not saying the instinct is everything. The "intrusive thoughts" meme has become popular these days and for some reason: don't confuse compulsiveness with instinct. Instinct is just the inkling of an idea, that something may be right or wrong, that you're headed on the right or wrong path. It's not the full story.

I did hide my instinct for a very long time, though. Too long. San Francisco startup culture can be very enveloping and opinionated and I've made decisions (or lack thereof) in the past influenced by prevailing sentiment that in hindsight, I should've analyzed more critically. I've had a few of these moments over the years, especially when you see yellow or red flags about something or someone, but you let it slide. That's on me. You can't control what others do but you can control your decisions.

I started formulating theses in my head on how to use LLMs in a productive way that elevated humans and enabled companies. So my cofounder Upal and I started bem.

This is my 3rd company – 4th if I count Kite as my own (though not founder on paper, I was the first employee before we had a name or a product) – and I've never had more fun. They tell you to enjoy the journey, but I always found it very hard to do while worrying about every single thing.

Experience has taught me that in business, most things simply don't matter. Others do. A lot. But most don't. For those that don't, I've learned to make an informed decision efficiently and move on, so they don't transform into chronic distractions. For those that do, I've learned to give my utmost attention to detail.

What matters? Your team (this includes your investors). Your customers. Your product. That's it. Find an office that makes sense for your stage and is priced accordingly? Sign the lease and move in. Don't run a process. You know what else doesn't matter? Your logo. It pains me to say this as a designer, but it simply doesn't. Don't spend time and money hiring a designer to make you a logo. Something nice, something quick, something that doesn't suck. You'll have time in the future to improve it. Your customers couldn't care less. Most things that distract you from creating value are ego-driven projects that slightly increase your dopamine and make you feel busy and valuable. No. Screw that.

But for the things that matter, be obsessive. Make sure you run an exhaustive fundraising process to optimize to get the best investors in the mix. Fundraising is recruiting, and recruiting is about acquiring talent. Make sure your team has the resources, the support, and the culture to thrive, make mistakes, learn, and produce value. Make sure your customers are set up for success – when you become their vendor, you can either be a leech or become a rocket booster that propels their growth, propelling also yours in return.

I'm digressing. The ideas did come and the rest is history – a history that is very much starting now. SHAMELESS PLUG: If you want to be part of that history and are a software engineer, do come tinker with us. It's fun and it's getting better every day.

Traveling

I told you this post was going to be long.

I did a lot of traveling this year, which makes me incredibly happy. Every time I've followed Anthony Bourdain's advice on how to travel, I've had the best experiences. Every single time. Get a massage at the airport (doesn't need to be fancy, just good enough to un-knot the stress out of your contracted elder millennial muscles) and do not eat the airplane food. Arrive at your destination hungry, physically and mentally.

I was fortunate enough to travel to my beloved Spain, Ecuador, Colombia, Japan, and South Korea this year. The highlight, without a doubt, was Tokyo. I'm a suburbanite-turned-into-urbanite, and Tokyo was everything I wanted and expected. Imagine a city of 40 million people that runs efficiently, has great public transportation, and is clean. Visiting Tokyo made me understand better the Japanese obsession with good design and their concept of beauty. Do I have secret plans to go back as soon as possible? Absolutely.

Most recently I traveled to Colombia to visit Medellín on our way to Ecuador. How a city can go from the most dangerous on Earth to one of the most beautiful, clean, and safe cities in Latin America is beyond me.

Technology, politics, and social change

Let's go back to technology for a second.

In times of rapid technological change, there's usually a parallel and connected explosion of new philosophy. Many of us are still trying to figure out how AI fits into humanity and most importantly, which problems can it help us solve. A lot of people are attempting to dictate how AI should shape our society while not fully understanding how AI works or what LLMs are.

I haven't talked about it as strongly in this blog, only in person and after a couple of Manhattans. I love reading about history and I can't help but see parallels with the beginning of the 20th century, a period of rapid technological advancement paired with new philosophical and political currents such as futurism. Futurists in the 1900s, much like many optimists today, were enamored with the idea of advancing technological development by any means necessary. Futurism eventually devolved into the early innings of fascism and the subordination of individual rights for the benefit of the common industry.

Even if it is just a farewell to this post, I'll state my position on this. I firmly believe technology should be a tool to elevate humanity and to effect social change in the form of increasing equity, creativity, and the collective good. We should be thinking about how to use AI to reduce our rapidly growing inequality gap, create stronger safety nets for those who need it most, and provide opportunities.

I want to see more and more – and I will personally support – projects that use AI to guarantee a single mother of 2 doesn't cross the threshold into homelessness, someone working 8 hours a day can earn a livable wage and enjoy a healthy life, and mental health is treated as a first-class citizen. I've mentioned this before in this blog: I still maintain that the greatest crisis we'll have in the 2020s in Western society will be a crisis of lack of purpose and mental health. Millions of people have been playing by the rules for many years to realize their hard work isn't being rewarded and the economy they were asked to participate in is disenfranchising them. In many ways, the new economies tech has created have ignored and failed to reach the middle and lower economic classes. I'm convinced we can use technology, and AI specifically, to create new economies of scale that reach everyone.

Energy

I'm incredibly energized and optimistic. My life is completely different than it was a year ago as I was writing my retro 2022. I've learned a lot and most importantly, I feel I mustered the courage to apply a lot of those learnings.

2024 is going to be insane.

also titled "Do robots dream of electric COGS".

I'll keep this one short. I hope. This week's rant comes after years of working on B2B software. If you're building or investing in B2B software, hear me out. The 3 biggest pitfalls I've seen in B2B software companies in the last 10 years are:

- Lack of awareness of where the product fits in customers' P&L.
- Over-complicated pricing structures.
- Misalignment of incentives (product doesn't add enough value to the stakeholder paying the bill).

I've talked about the 3rd one in this humble blog. Today I'll talk about the 1st one.

I'm seeing more and more B2B software companies not ask themselves the question: where do they fit in their customers' P&L.  You'd think that's crazy because the checks come from somewhere. Still, not enough companies internally ask themselves where the checks actually come from.

So please do, and if you're an investor, ask your portfolio companies to do it. I guarantee you that an honest conversation about it will uncover critical aspects of your role in your customers' success. I see 2 ways of going about it, complementary to one another:

Whose budget is it coming from

Are you part of their marketing budget? Product? Engineering? Sales? Marketing and product?

This one is a little hard. Depending on the type of product you're building, it doesn't necessarily have to be a single team or department's budget, and sometimes it's not clear. Salesforce is an obvious one: it's usually in the Sales/Go-to-market team's budget unless they represent fringe value to adjacent teams.

This one is also that'll be slightly different for every customer. They should all be very similar, though, and you have to have an internal approximation of where you fit in that equation.

Why? This very much directly tells you where the checks are coming from. Your software is eating into a stakeholder's budget to execute a company function and the value you provide should be completely aligned with that.

It also tells you how fickle that budget will be. Notoriously, in times of skinny cows, one of the first budgets to be cut is marketing. If you're there, you need to increase your chances of staying and the only way to do that is by being as essential as possible.

Where in the P&L are you: revenue, COGS, OPEX, ...

This one is easier to determine and once you do, you're going to wish you had had this conversation with your team years ago. When thinking about a project or company financially, before investing or working on something, it is one of the first things I ask myself (and I ask of founders).

Sales: You're essential. You’re either enabling customer sales or directly bringing them more business. The more active role you take in this process, the more essential you are, because there’s nothing as essential as income for a business. 
The more your customers make, the more you make.

COGS: You’re your customers’ infrastructure. Without your service/product/good, they don’t function. Make sure you allow your customers to attain good margins, and provide them with excellent support and quality, and you’ll be there for a long time.

OPEX: You’re part of your customers’ operations but you’re replaceable. You need to over-index on great customer service and create differentiating value to avoid commoditizing yourself.

Loans: You’re probably a Fintech company. The good news: credit is essential to running a healthy business, so if you play your cards right, you’re essential. Now, where the magic happens: if you’re both here and in Sales/COGS, that’s a slam dunk. It means you’re as close as possible to your customers’ cash flow cycle and directly aligned with their revenue.

In conclusion, knowing where you fit in the structure above tells you how essential you are to your customers, how replaceable, and how

I love working on essential problems, and I love working on direct revenue enablers. It sets you up for a growth mindset from day 1 and you're always directly aligned with your customers' incentives and interests.

I also love businesses that situate themselves in COGS. They're very much infrastructural in nature, hard to build, and complex problem spaces. You just need to be careful and take care of your customers' margins. If the margins are affected, you're the first one out. (Tangentially, I wish more companies would venture into honest dialog with their customers about how much they should charge them. Honesty drives growth).

A very special mention to my fintech friends. There are 2 ways of situating yourself in the world of credit: by strictly being your customers' loan provider or by enabling their cash flow cycle. The future is in the latter. An incredible chunk of the global economy would be smoother if more companies had access to easier/cheaper cash flow buffers.

Now here's where the slam dunk comes: if you can situate yourself as both a cash flow enabler and take an active role in getting your customers more business, you have an absolute unit of an opportunity. The value over time is exponential.

End of rant.

Posts like this one are hard for me to write. I'm a romantic. I romanticize designing, coding, and building products. I think building a good product, a product people actually want to use, is closer to art than science. I've spent most of my career dissecting the minds of users and building experiences and functionalities that become critical to them as I only work on mission-critical products.

But every artist, even the most methodical UX designer, needs a scientist that grounds them. Our art only gets us thus far. We get tangled in the web of emotions and we start calling our product "our baby". We need data-oriented people who check our wildest facts and challenge our assumptions. We need revenue-oriented people who ask the tough questions.

So the tough question that I'm proposing to you today is "Why?". It took me years to discover this question in product-building, and a few more to muster the courage to be brutally honest with myself and with others when answering it.

Most people don't ask why

Most teams, companies, and organizations don't ask why. The most creative people ask why in petit comité and very few are brave enough to ask in group settings. If Zoom had an in-meeting "Why?" button, the global GDP would increase in a noninsignificant way.

Instead, we spend weeks, months, and years, building features, products, and systems that don't scale, are not needed, and no one wants. The worst part? That Hanlon's razor plays an important part: a lot of the times this happens, it's not for a perverse misalignment of incentives. It's just incompetence.

Why don't we ask why?

Most of the time, because no one wants to be the party pooper. The biggest cultural shock I experienced when I moved to San Francisco was that people didn't speak up. Ironically, this gets worse and worse the more positive and happy the company culture is. Being a "team player" means smiling and doing as you're told, following the prevailing team sentiment.

Mind you, no one is actively seating you down and asking you to keep quiet. It's a subtle cultural trait enforced via peer pressure and west-coast manners: dissenting opinions are often met with forced apathy, odd looks, and mobbing.

The best teams have realized that is the root of disaster. Doing things for "shits and giggles" or just because someone in a position of authority, having created a top-down culture, said so. I'm a firm believer that this is the reason why billions have been wasted on the most useless crypto projects, NFTs, and many more will be lost to vapid projects with no useful outcome, while real crypto infrastructure projects go unfunded.

"Why?" as a cultural trait

When I decide who to work with or who to invest in, I always choose people who ask why, especially people who don't mind others asking why and challenging their assumptions. It takes a significant amount of self-awareness and tamed ego to be brutally honest with yourself. That's the people I will spend my time with. Those are the people shaping the future.

Not all is lost. If you work in a team that doesn't ask why and is just building mindless features, don't wait till tomorrow. Ask people to speak up, ask why rhetorically. Create a culture where no one is afraid of being the "party pooper". Party poopers save companies. They save teams from working on garbage. If you work at a company that refuses change: leave. There's no more stagnant place, and no bigger waste of professional time, than somewhere you're not learning by asking the tough questions. Talented people need a challenge.

The "Why? Ok, so?" framework to build better products

The most pretentious thing I've done this week is calling this a framework. So we'll call it a "2-question reality checker". Think of it as the kryptonite to most reality distortion fields. Even the most charismatic people can't escape from it.

Users, like suspects in a Hercule Poirot novel, have to have motives. There must be a reason why they want to use your product. Next time you're designing a new feature or product, please ask yourself, and your users, why they'd want to use it. I kid you not, most companies don't do this. Run it as an exercise team internally. Do it with different types of stakeholders.

Example: Our new amazing, slick, product magically connects shippers with freight brokers, creates a BOL, sends a request, and schedules a truck.
"Cool. Why do users need this?"
Well, our UX is incredible, much better than incumbent old systems.
"No, I understand the UX is better, but why would the user care?"
Oh, because they can book loads faster.
"Ok, so? Why is that important?"
Well, if they book loads faster and better, they can get better prices and have more time to keep selling.
"Ah, so their revenue increases and they also save costs?"
Yes.

One more thing: B2B software

Hopefully a small tidbit. I plan another post to dive a little deeper into this "framework" of sorts, some common examples I've run into, and most importantly: how not to collectively fall for fake explanations. It's very easy to lie to yourself and convince others that your product will do X, Y, and Z when it does neither of those things.

For now, I'll leave you with one last thought: in my humble opinion, every final answer of the "why? ok, so?" back and forth should end with the words "revenue" or "costs" if you're working on B2B. If the ultimate explanation of your B2B product's existence isn't defined by either of those 2 things or a measure connected to cash flow, then you're doomed.

Business employees need well-designed, well-structured software. Businesses need to increase revenue or cut costs. (I'm personally less interested in building things that cut costs down, as I prefer building software for people with growth mindset in non-zero-sum spaces, but that's a whole different rant)

If you have a product or service and you're starting to build the organization that will support its growth, you've probably wondered how you should compensate the people working in it. This is what this post is about.

Don't expect specific OTE breakdowns, templates, or buzzwords; there are plenty online. Here I discuss the basic principles I've seen work when incentivizing people to do their best work and hit their goals as you build (and they help you build) an organization.

I've tried to stay on the topic of incentives, but you'll see I talk a lot about goal setting as well. Goals deserve their own post, but it's hard to discuss incentive alignment without mentioning the goals behind them.

1. You need goals.

You'd be surprised by the amount of companies that create incentive plans without actually setting goals behind them first. The reality is that without goals, incentive plans are prone to be misguided and misaligned with the rest of the company's needs. So heed my advice and learn from my mistakes: you need goals first. And the more specific and reasonable those goals are, the better. They will guide the way you actually plan incentives. Think about it from first principles: incentives are a way to compensate people for fulfilling the goals of an organization. It doesn't really get more simple than that.

Again, as I mentioned before, I'll talk about goals in a separate post because they deserve their own book. The key to creating amazing goal structures is to think about the most important metrics that make your company default alive – and if you're already default alive, congratulations –, increase revenue, reduce costs, and create long-term value.

2. Align incentives directly to company goals (and make those goals span all teams)

Well, we've covered the fact that incentive plans without goals are very difficult to guide and fulfill. Now let's talk about how to create those goals. In my opinion, the best goal structures are structures that are shared across entire companies. The art of creating team-specific goal structures is very nuanced and has to be done carefully to avoid misaligning different teams.

If you are running a mature organization with hundreds to thousands of employees, by any means, go ahead and create team-specific goals. You will need them, they're necessary. It is very, very difficult to run a big organization just on company-wide goals. However, if you are a small to medium-sized company, still probably in the hundreds of people, you need to base everything you do on dead-simple, easy to explain, easy to remember, goals.

The best company-wide goal structures are centered around revenue, customer satisfaction, and long-term value. Those goals need to be simple, easy to explain, attainable, and easy to measure.

Run the following experiment: create a goal structure, present it to your team, and three months later, ask a random member of your team to, off the cuff, say what the goals are for the year. If they don't remember, then you're making one of two mistakes. You are either making your goals too complicated, or you're making them not relatable enough to your team.

The other clear advantage of having teams share goals across the entire company is that you're never going to run into fiefdoms. Fiefdoms and small areas of privilege and power are created by small teams creating their own little goals in isolation. Forcing teams to share goals means they need to sit at the table and work together to understand how each of them can help fulfill that goal. It means everyone is bought in. It also means everyone is rallying towards the same objective.

The typical joke of sales, product, and engineering being at odds with each other is not uncommon. The only reason why this happens is because each of these teams is incentivized differently from one another and probably has different goals altogether. If you are running into this particular example, it probably means that you're incentivizing sales to push a product that is not ready yet, or that product and engineering cannot build fast enough.

Destroy misalignments by forcing people to sit at the table and work together. Destroy fiefdoms by aligning them with the same goals, even if you incentivize them slightly differently, and have them rally against the same objective. Make salespeople product experts and product and engineering people sales experts.

3. Beware of incentives based on proxy metrics: revenue is king

A lot of companies that generate revenue based on transactional value are tempted to measure their success against proxy metrics of their own choosing. Those proxy metrics are very different depending on the type of industry, but if you have worked or work currently on SaaS, marketplaces, or fintech, I'm sure you're familiar with them. You have probably seen things like gross market value, daily active users, number of users, and average session duration.

These metrics, these proxy metrics inevitably are a promise to stakeholders and investors that you will be able to convert them to revenue. However, you don't make money based on premises.

Proxy metrics are fine when you're starting out. They are a way to educate investors and other stakeholders about how you're not making much money right now and promise you will be able to convert, at some ratio, part of those metrics into revenue.

The problem with aligning incentive plans to proxy metrics is that generally incentive plans are paid in cash and proxy metrics are not cash. You may end up in a position where you're paying enormous amounts of money to your team for metrics that are actually not driving the success of the company. That's called burning money.

Generally, I recommend basing cash incentive plans on real actual revenue and when I mean real actual revenue I mean closed finalized, and paid revenue.

4. Invest in long-term value through equity

One common mistake I've seen made in sales organizations is to focus too much on cash incentives and not enough on the company's equity.

Think about it from first principles. You want this salesperson to think about not just the immediate revenue of the company, but long-term value as well. Incentivize them only with cash, and they'll focus only on making a quick buck for the company, even if it's at the expense of forcing other areas of the company to be under pressure. Incentivize them handsomely with equity, and they will, on top of generating revenue, think also about how to select the best customers and become experts to make the entire company better. Make every single person in your company an owner of that company.

5. Fulfill personal goals

Not everything is money, and a lot of what we do professionally is thinking about the long-term plan. For a lot of people, that long-term professional plan means advancing in their careers and learning new skills. Make sure that you provide the right management structure for people to feel like they're fulfilling their own personal/professional goals in a meaningful amount of time. Make sure that there are clear career ladders in your company so that you can grow people, not just hire people.

Let me insist on it one more time, the best way to ensure that you fulfill your people's career goals is to foster a company culture of growing and nurturing skill sets and professional value within your company. If you're in doubt, always grow people, not just hire people.

6. Set people up for success

Okay, so now you have a set of goals for your company, perhaps smaller goals for your team if you're mature enough. You also have an amazing incentive plan. You're ready to go. One important thing that a lot of people miss: you need to make sure that your team can fulfill those goals and they're set up for success to actually squeeze their incentive plan. You actually want to be in a position where you're paying out their full incentive plan plus extras, plus bonus, plus everything.

The best way to set people up for success is for them to have the resources they need. Make sure that your product and engineering teams have the toolset and the management structure that they need to just focus on thinking critically and build their best work. Make sure that your sales team has an amazing sales tool set with the best software, great sales enablement, and an amazing pipeline with clearly defined targets and target markets that they can actually attain.

7. Extra: Viral cultures and people actually wanting to do their best work

Finally, let's talk about company culture. The reality is that all the money in the world is not going to make someone do better work or faster work. You want to be in a place where your team members wake up in the morning actually wanting to do really, really good work.

Create a company culture where you are doing everything we discussed above. Create a company culture where people wake up in the morning and they completely understand the goals of the company. Everyone has the same goals across the entire organization. They understand exactly how their incentive plan is aligned with those goals, and they have a vested interest in the long-term value of the company. And finally, most importantly, make sure to understand that these team members are real people with real personal goals. Create a structure in your company that ensures these people are in it for the long run, that they see a career ladder, and that they see a way to learn new skills and advance.

If you have managers already, congratulations, make sure that they are bought into this company culture in a way that it becomes viral and they are stewards of this culture itself.

also titled Do Androids Dream of Vectorized Ontologies?

A recurring conversation I've had with friends building in the AI space is how to get started using LLMs in enterprise environments. The use cases are extensive, from transcribing and summarizing large amounts of data to drawing conclusions and sparking insight. (More on sparking later). What's clear is that in order to extract value from AI, we need to dissect a company's ontology, not just its data.

Recap: LLMs with large data sets

In other words, not everything fits in a single, short, simple ChatGPT prompt. There are 2 main paths to feed LLMs large amounts of data today:

• You feed it the entire data set in prompt time. This is akin to copy-pasting the entire data set relevant to the questions you want to ask. For many use cases, this is impractical and expensive. Anthropic's Claude model has context windows of up to 100k tokens, i.e. you can feed it about 5 hours of text. (This would cost you $0.16 on their lighter model and $1.10 on their superior one, per call).  This is also called "few-shot learning".

• You store the data and retrieve it in prompt time. This is where vector databases come into play. The idea is that you take your data, separate it into semantically meaningful chunks, get a vector for each that represents its position in the semantic space of your choice, and store the vector results. When the user submits a prompt, you pass on the prompt to the vector database and retrieve results semantically connected to the prompt, then feed them to the LLM and ask it the question you want. Some well-known vector DBs today are Pinecone, Weaviate, Qdrant, and Chroma.
  
  Example:
  - McDonald's wants to generate an executive summary for the board about customer reviews regarding the cancelation of all-day breakfast. (They have 450k worldwide reviews from the last quarter)
  - They vectorize all reviews and store them in a vector database.
  - They ask for "reviews about all-day breakfast canceled" to the vector database and get the first 100 results.
  - They feed them into ChatGPT, then ask it to generate an executive summary from the extracted reviews.

Neither of these 2 alternatives is the panacea. As I mentioned, feeding all 450k reviews to an LLM in prompt time is impractical and expensive (also for most models, not possible yet). On the other hand, vector database workflows slow things down and also force you to narrow down the problem: you may have seen in the example above we're retrieving only the top N results. Also, what happens if we miss things? We made a conscious choice to chunk out data in the storage step, so we don't get a full picture of our entire data set and neither will the LLM.

There's a 3rd choice, the ideal fantasy in my opinion, which is to custom-train an LLM with your own data. This is only feasible if: a) you know how to do that, and b) you have the budget for it. Good news: you're McDonald's. You fire up Mosaic. You can spend $200k-$500k training your own LLM with company data on top of open-source data sets. However, you do need to progressively update it with new data, so that's another $200k every time you update it. Not terrible for a company with millions of daily customers but unattainable for most companies on Earth, even at enterprise levels.

Ultimately, I think vector databases will become an intermediate tool to train your own LLMs, rather than an isolated tool you use to extract information for the purposes of few-shot learning. For this to happen we need the costs of ML computing to significantly go down – but if this happens, we may encounter LLMs with contexts of millions of tokens be extremely cheap.

As of today, the best option for most cases is to leverage vector databases.

Enterprise AI will be about ontologies, not just data

A problem I've been working on for some time now is: how do you weave everything together? LLMs are static black boxes and the output's value will be proportional to the quality of the data and the prompt.

I've seen companies starting to tinker with it in isolated processes, such as customer support communication and code, but the real value will come when we tie everything together. One thing is for sure, though: you can't express a company just with data. If we want to extract all the juice we can, we need to express a company in its ontological components:

• Concepts: Franchises, Menu items, Orders, Customers

• Relationships: Orders contain menu items, how concepts and instances are related to one another

• Functions: Purchasing, Frying (abstractable modular business processes)

• Instances: Individuals of concepts, such as Diet Coke or Bacon Cheeseburger

• Axioms: Statements that are asserted to be true in the company's domain

The thing is, ontology as a branch of metaphysics is incredibly powerful at describing sources of truth. A company is incorporeal but terribly complex. This is not very different from BPM, as I mentioned in a previous post, where you express business processes and stakeholders as a function of inputs, decisions, and expected outcomes. It's another perspective.

There are ways to express an ontology in a standardized way, such as OWL. When you read about Tim Berners-Lee's thoughts on the Semantic Web, you sense a slight regret in which the original Web was built. I have opinions on this that are probably worth a long rant in a separate post.

I mentioned in a previous post that I strongly think most companies' time is spent structuring and destructuring data for different purposes and that the lowest-hanging fruit is to stop people from spending their time doing this so they can spend it on making decisions and doing higher quality work. Well, I think to do that, we need to start mapping out companies through their ontologies, not just their data, and using that to drive LLMs.

The metadata

I'm arguing that instead of overloading prompt engineering for functions and axioms in your company, such as verbose explanations of your company's processes, we should standardize company ontologies and express them in data, metadata, and heavily store and vectorize them. In other words, you express business processes, functions, and relationships in the vectorized data itself, so it's ready for retrieval and usage.

The first response I've gotten is: this is a lot of work and we don't have time for this. I agree. There's a silver lining: to the extent that LLMs represent an abstraction of intelligence, they're very good at extracting ontologies from unstructured data. In other words, AI can help you discover the best data structure to better use AI.

One more thought

As I write this, OpenAI just announced they now support fine-tuning their GPT 3.5 - Turbo model.  In their own words, this doesn't replace the retrieval of data (via vector DBs or otherwise). It does simplify expressing axioms and functions in your company processes. As always, I encourage tinkering. I know I'll be playing with it this week.

Additional notes after publishing:

• Another limitation of vectorizing semantics is understanding what those semantics are, to begin with. The mainstream approach of just using a widely available model to vectorize is good, but very specific use cases may require custom vectorizing models. Even the best model can't replace an in-depth analysis of what should be vectorized, and what can just be stored plainly.

also titled "Elevating business processes with AI and surviving to see the rewards".

The start-up's cardinal sin is confusing improvisation with experimentation. It's simply too hard for teams of people to learn collectively and move fast while they improvise; there are too many variables and outputs. The beauty of diligent experimentation is that you can iterate your parameters until you get the output you're looking for. For that to happen, you need to: 1) Record your parameters, 2) Record the conditions of the experiment. I've seen too many companies do neither of these things and get frustrated when they realize the curve of their operational costs grows faster than their revenue.

This extends to much smaller endeavors, from product design decisions to making changes to GTM strategies and motions. Next time someone in your team argues for a change "for shits and giggles", shiver with fear.

How is AI related to this? I firmly believe AI, and LLMs more specifically, can and will change the way we do business. However, the value you get from AI is proportional to your level of sophistication. It's hard improving a business process you don't have thoroughly mapped out, whose stakeholders shift, with volatile outputs. Under pressure, I've seen companies quickly and very publicly boast about the benefits of AI in their business, but the benefits are so shallow and the costs so poorly calculated.

Lowest value out of AI: automating SDR emails

I've seen a few dozen companies do this, and another few creating startups around this notion.

Sure, ChatGPT writes decent emails and text – it is a language model after all —, but it's such a low-value effort, with such a lack of defensibility. Anyone with access to OpenAI's web interface can do it; SDRs can do it themselves. Someone with a few weeks of coding experience can even enhance this with better workflows, Linkedin scraping, semantic analysis of the conversation so far, etc., and create a Gmail plugin.

Think about cost savings/revenue opportunities. You're taking a job that is largely already automated and templatized and adding another lazy layer of automation on top. You may be crazy, or greedy, enough to increase your SDR's quotas because you gave them access to a glorified letter writer.

Highest value out of AI: structuring fuzzy inputs, navigating, and executing business processes

Hot take: most of a company's time is spent structuring data, translating semantics, communicating those semantics, re-translating them, and transforming structured data into other types of structured data. In other words, most teams are just an old-school inbox and an outbox with some process in between.

Chances are you have a talented, intelligent person in your team who's doing menial, tedious processing work all day. That's a shame. The goal of AI should not be to get that person fired. It should be to transform that person into the architect and supervisor of that process, letting AI do the tedious work, and allocating their time to higher-value tasks and decision-making.

The next generation of business process management (or BPM)

Every business process in your company, from small tasks like approving expenses to larger ones like designing a new software feature and doing user research on it, should be properly designed, modeled, and mapped out. It's not hard. There are many ways to do it: from informally expressing the process as a series of bullet points, with stakeholders, inputs, and outputs for each step, to using established techniques such as BPM or Six Sigma.

I can feel a few readers scrunching their noses and thinking: well, you're just not going to move fast. This isn't agile. This is how IBM did business in the 40s. My counter-argument is that you're going to move faster by lightly modeling your processes than by improvising them every time you hit an obstacle. Trust me, I'm a startup cowboy; I've felt the pain. My instinct is always going to be to improvise, write quick spaghetti code, iterate very quickly. One day I stopped improvising and my experiments moved faster and better. Especially those of you in the early stages: if your goal right now is to research and learn, your business processes are most likely completely unscalable and unsustainable. That's a good thing, but you'll need to scale them at some point. It's going to be really hard if you didn't document them.

OK, so what is BPM? For those who are not familiar, BPM is one of many disciplines that focuses on modeling your company's business processes. After modeling them, it helps you analyze and measure them, optimize them, and ultimately automate them, which is where AI enters the chat.

The example above is a typical BPM diagram for an HR-related process. The inputs and outputs are self-explanatory.

This is simple enough. How quickly and painlessly stakeholders go through this process today depends on how easy it is to fill out the form, submit it, and evaluate it.

I'm arguing anything in a diagram of this type that involves the words "fill", "submit", or "evaluate", should be automated by LLMs. However, the only way to do it is to first map out very well your processes, inputs, and outputs as a company.

ChatGPT

Example of simple data structuring - filling in a form.

This is obviously an extremely simple example (that saved the user 15 min of their time). More complex processes will require proper orchestration, validation of inputs and outputs, database lookups, and others.

Orchestration here is the key: LLM usage needs to be narrow in scope and modularizing and connecting different functionalities is the key to a successful process. The idea is that the resulting structures are transparent to the human users, so proper supervision can be done.

Using AI as an abstract thinker to model

If you're in the situation of most companies, who don't have properly modeled processes, fret not. The beauty of an LLM is its ability to extract semantics out of abstract thoughts and structure them.

ChatGPT

Example of a meta-request modeling business process after natural language

As mentioned before, a simple example for illustration purposes, but an interesting starting point. You can use an LLM to structure a business process from a simple explanation.

Putting the horse before the cart

If the two examples above seem simple, it's because they are. Companies are a complex web of requirements, expectations, parameters, and most importantly, stakeholders. However, from first principles, proper orchestration will allow us to build progressively more complex automation if processes are properly modeled and documented.

AI is the human-computer interaction model we've been dreaming of since the idea of automation crossed our minds. It will not only replace ubiquitous interaction concepts like the mouse but also render 80% of today's software obsolete. GIGO: Garbage in, garbage out, is dead. That's a good thing.

Before modern computers, before Babbage's analytical engine, the question was always: how can humans interact with a device that automates or mechanizes what otherwise would take time and effort?

This is an old, old dream. Homer defined the gates of heaven in the Iliad as αὐτόμαται (automata), self-moving, driven by divine power. Every technological step we've taken for the last 3,000 years has been in pursuit of those pearly, self-opening gates. The dream of a self-driven process, with our thoughts and desires as the primary drivers, is what has driven the excitement for new technological progress. So here we are. Well, where are we exactly?

Of mice and computers

It's serendipitous that it's been almost exactly 50 years since the invention of the graphical user interface by Engelbart and the team at Xerox PARC. 5 years before, Engelbart presented what we today have nicknamed The Mother of All Demos, an introduction to the NLS - or oN-Line System -, a suite of tools that today are ubiquitous: hypertext links, raster graphics, windows, and the mouse.  

Windows, and graphical interfaces, were created for 2 purposes: increasing the density of displayed information and contextualizing user input. Before that, information density was limited to character compositions, and user input's context was limited to the directory they were navigating and the vocabulary allowed by the system. Graphical interfaces allowed for symbols, structures, information hierarchy, and eventually colors, that present abstractions with higher information embedded in them. The mouse allowed for user input connected to the location of this information, with more intuitive expected outcomes and, again, a considerable amount of context.

Eventually, we invented touch screens – first resistive and then, thank God, capacitive – to minimize the amount of space, muscle memory, and motor skills needed to interact with buttons and other visual cues.

The perfect user of an ERP is a robot, not a human

Things are easy to use when the system is simple. No one struggles with Solitaire or Minesweeper because the inputs and the outputs are simple. Very few people struggle with word processors because again, the mission is as clear as the interaction model: you write, click around, to fill a virtual blank canvas with words.

The problem comes with complex systems: those highly relational, business process-dependent, software suites that make the business world run. CRMs, ERPs, CMSs. They are hard to use because they contain vast amounts of knowledge organized in complex ontologies. The perfect user of an ERP is a robot, not a human. The amount of context required to perform a business process efficiently in a modern ERP or CRM is vast and interconnected.

Well-designed complex systems rely on visual cues and information hierarchy to: tell the user where they are, the information they need, and the expected outcome of their task. The problem is that most software systems are not well-designed. There's an undue emphasis on the visual and teams forget the strictly functional and situational. If form follows function, function follows situation, especially when we're talking about SaaS and B2B in general. Not all users are concentrated, focused, and sitting at a desk. Some are running, at a warehouse, in noisy environments, on their feet, without surface area for a mouse or patience for a touch screen.

AI, the fuzzy input interface

OpenAI may have inadvertently, or not, launched an AI product that is advanced and functional enough to become the next interface paradigm for software. In fuzzy environments like the ones I described above, it simply is too difficult to design the perfect UX model, with a UI that has the right information architecture and hierarchy for all the user needs and permutations.

Most business processes are too complex to begin with, which is something I've been studying for a very long time and I'm excited to one day write about. To summarize, imagine poorly translating the requirements of a business process into a graphical abstraction of data that is highly relational, to begin with. There's a whole industry dedicated to re-skinning mainstream systems like SAP and Jira, albeit some do it quite poorly.

I think it's that simple: AI is the solution to replace 15 clicks, 4 buttons, and 3 poorly implemented text searches. I've seen a lot of excitement in the last few weeks about using AI as a backend to processes, but in my opinion, the real potential right now is using it as a frontend.

The goal of UX should be to make the translation between our desires and a mechanized environment as seamless and simple as possible. There are no gotchas here. This is why command palettes work. LLMs are the perfect translation layer between thoughts and expected outcomes in environments where the user can express input in language, whether written or spoken. If you could create a rule-based environment with thousands of parameters, you would certainly improve the UX of a complex system, but now you don't need to: LLMs are effectively environments with billions of rules, complex enough to extrapolate between fuzzy inputs and deterministic outputs.

The example above is overly simplified, of course. LLM outputs don't replace the density of screens, so consider an LLM in this use case the replacement for a mouse and a keyboard.

Caveats

Not everything is roses, and there are a few caveats to this approach that technology should hopefully resolve with time and patience.

• Information density: as just mentioned, textual language expression doesn't contain as much density or speed as a graphical interface. The speed at which the user can process spoken or read information is much slower than a properly designed UI. That's why I don't think LLM outputs, as of yet, replace a traditional UI but complement it.

• Context/knowledge retention: the LLM, or the system enveloping it, needs enough context for the example above to work. LLMs by definition don't know who your customers are. They are strictly stateless. There are ways, some more sophisticated than others, to introduce stateful context:
  
  Few-shot learning: in other words, the knowledge retained by the LLM is spontaneous, session-limited, and strictly contextual. The LLM needs to be fed all possibilities of relevant context on every request, and that is computationally expensive. OpenAI charges per token, which makes this approach impractical at enterprise scales and very expensive. As things progress, I'm sure we'll be able to fine-tune LLMs like Chat GPT-4, and I'm certain the future of LLMs in mainstream business is knowledge and process specialization, but for now, we're limited. You can, however, fine-tune other OpenAI models and the results in complex environments are limited. There's a clear difference between training a model with user-specific data vs. with system-wide data all users can leverage.
  
  Symbolic representations: Without getting into too much detail, LLMs are particularly well suited for symbolic language. They're, after all, compression engines. The personality of an LLM, if that's a concept we're willing to concede, would be that of a Gestalt system.  LLMs are configurationist automata, extremely good at a cloze test. Using symbolic references allows us to embed more information in system/behavior design prompts. The LLM outputs from these symbolic representations can be then fed back into a database lookup to fetch only the strictly relevant information. It is slow, though.
  
  Knowledge retention is essential and by far the biggest limitation in these systems. Some companies are working on this, with varied results, being the easiest approach using calculated few-shot learning.

• LLMs are not intelligent: there's a joke concept in Spain called a cuñado – a brother-in-law – a know-it-all who confidently parrots back things they've read on the Internet, some of them frequently wrong. LLMs are cuñados. Their intelligence is limited to drawing extrapolations from language and symbols. We perceive them as intelligent because humans tend to express their intelligence through the use of language. Proof of this is that LLMs frequently "hallucinate", especially in environments with poor context and a lot of entropy.

The potential is incredible // and a sneak peek of a hobby project

I'm personally focusing my interest in AI in human-computer interaction. I still think LLMs are incredible frontend machines if designed correctly, and technology is only going to make them more coherent and faster.

I wrote this very article with a little hobby project I've been building using Chat GPT and Whisper. I use this for writing articles and emails because I can write much better when I'm dictating.

1×

If you're building something amazing, hit me up. I love brainstorming ideas. And remember, stay away from the noise: real progress is achieved through discipline and perseverance, not tweets.

Note: throughout this post, when I refer to backlog, I mean backlog in the general sense of the word, not strictly the process behind a purist Scrum backlog, so interpret it also a product backburner. I'll probably dedicate a whole other post on why I think small companies should avoid a purist approach to agile or Scrum.

In the industry of creating products – whether you're a startup or a big company – we get wrapped up too much in the solution, in the product, and in creating the perfect product with the perfect process. The reality is that the user will never care about any of this. The user will care about something that fixes their problem.

I've received lots of questions from peers recently about backlogs and processes in general, and my advice is uniform and based on experience: kill the backlog. Kill it with fire. Kill it fast.

Let's be honest with each other. The backlog is, by definition, an accumulation of lower-priority items. If those tasks were high priority, they would've been done, completed, and released. Every time you hear "we'll add it to the backlog", remember you're saving trash in your storage unit. Unless you're a 50-year-old company with products under maintenance, you should never have a backlog. Marie Kondo sheds tears in COBOL every time you stash another task in the backlog.

If something matters to your users, just build it

If it sounds simple, it's because it is. If it doesn't, don't. The only thing that matters in the nth iteration of your product is the current state of your product, and whether it fits your user's needs. If you do that, and ship fast, and ship good, backlogs become stale, hopeless dreams of someone from the past that didn't know what your product would look like 3 months ago.

What about "improvements"? Let's talk about improvements. Depending on your type of product, improvements may not only contribute to retention but also growth. At Silo we experienced this ourselves: word of mouth is powerful when you work in vertical SaaS and you need to always continue improving your product. The power of a happy user is stronger than most sales teams, and it's always great when an existing customer is an ambassador free of charge. The cost of not doing so is users rightfully spreading contempt for your product in the community.

So where do you put improvements if not in a backlog? Put them on a proper track of work, with allocated resources, with iterations, documentation, and constant user feedback. Improvements in a backlog won't get done, again, unless you're a large-scale organization with discipline and someone on product operations that is pushing it to be done, pruning them continuously. It's possible that by the time those improvements are ready to be completed, they're no longer relevant. Your customer success team gets pissed, and rightfully so since they get yelled at way before you do. Well, apply some intentionality to it. IF improving your product is a key element of your strategy, then have a team with a roadmap horizon of no more than a month continuously works on those improvements, and talk to users at every step of the process – everyone in the team, including engineers.

Continuous user feedback and final remarks

The solution here is to never have a situation where you'd need to "stash" something unimportant because you're busy building what really matters. The only way to do this is to get user feedback early and often. The only way for this to work is for everyone in a product development team to be exposed to users: PMs, designers, engineers – lead or not — , need to have direct contact with users and prospects. It's the only way to have enough context. If you do this well, they'll weed out bad tasks themselves because they understand what needs to be accomplished.

Otherwise, the danger is your team using backlogs to roadmap. I've seen this at every company I've been to. It's easy. You don't need to talk to users to just pull ideas out of the stale compost bag and start throwing black banana peels into the board until something sticks.

If this little post seems to have some stream of consciousness it's because it does. This is something I've seen too often. Backlogs are the death of small and medium size software companies. If something matters – and the only deciding factor here is the user –,  apply intentionality to it, build it, and ship it fast. Why fast? Because the faster you ship, the faster you learn, and the sooner you build what your user needs.

Backlogs are bureaucracy. Backlogs are lists of has-been-never-done tasks. Say no to hoarding. Kill it with fire.