A few weeks ago I introduced Lutchet, a project I’ve been building to teach math and CS the way I wish I’d learned it: problem first, concept second, history as the through-line. We dug into Alan Turing and the Bayes Theorem, and Claude Shannon and Information Theory. For the next installment, I got a tad ambitious and explored Graph Theory. And learnt so much!

Here’s the thing about Graph Theory: it doesn’t look like a big deal when you first encounter it. Nodes. Edges. Paths. It feels like a warmup exercise.

But it’s the invisible architecture of almost everything.

Every packet you send traverses a graph. Every route you drive. Every recommendation you get. And increasingly, every fact a language model retrieves. The whole modern internet, GPS navigation, Google’s original PageRank algorithm, the way LLMs reduce hallucination through knowledge graphs: all of it sits on a mathematical foundation that began as a parlour puzzle in a Prussian city in 1736.

Leonhard Euler was one of the most prolific mathematicians in history. In 1736 he turned his attention to a question the residents of Königsberg had been arguing about for years: could you walk across all seven bridges of the city without crossing any one of them twice?

Euler’s insight was that the answer had nothing to do with the map. It didn’t matter where the bridges were, how long they were, or what they looked like. All that mattered was how the pieces connected. He stripped the problem down to its abstract structure, proved the walk was impossible, and in doing so accidentally invented a new branch of mathematics.

Nobody fully appreciated what he’d done for another two centuries.

That gap is one of the things I find most fascinating about this story. Graph Theory developed quietly, mostly inside academic circles, largely unnoticed. Dénes König wrote the first proper textbook on it in 1936. Eight years later, the Allies were planning the largest amphibious invasion in history at Normandy, facing exactly the kinds of network problems graph theory could have helped solve. The formal tools didn’t exist yet in the right hands. They improvised. They won anyway.

A decade after that, American analysts at RAND were studying the Soviet rail network, trying to figure out which rail lines to sever to cut off supply lines. The mathematical answer, max-flow/min-cut, was being developed one floor away at the same time. The war Normandy ended had created the urgency to finally build the tools Normandy needed.

The Lutchet Graph Theory module tells four stories across three centuries:

Königsberg in 1736, where Euler stops looking at the map and sees only the connections. Amsterdam in 1956, where Edsger Dijkstra sketches an algorithm over coffee, without a pencil, in twenty minutes, and produces the routing logic that still moves packets across the internet today. RAND in 1955, where a classified targeting study and a math problem collide. And Stanford in 1998, where a random walk on the web graph becomes Google, and the same idea turns up again thirty years later as the frontier for making language models less confabulatory.

Same idea. Different century. Still running.

Each story has three layers: the narrative (no equations, readable by anyone), the mathematics (rigorous, but earned), and Python notebooks you can run yourself.

If you’ve been meaning to look and haven’t yet, now’s a good time.

And if you know someone who’s curious about how the internet actually works, or why Google was different, or what the Allies were doing the night before D-Day: send this to them. That’s exactly who I built it for.

More topics coming. The code is on GitHub. Feedback always welcome.

I’ve been thinking about this for a long time.

Not building it, thinking about it. The itch goes back to high school and IIT Delhi, where I spent many years being handed definitions, theorems, and proofs in that order. Memorize the abstraction. Apply it to a contrived example. Pass the exam. Move on.

And I did move on. Into a career built almost entirely on applied mathematics: optimization, probability, information theory, machine learning. The very things I was taught as inert academic objects turned out to be the most powerful tools I’d ever use.

But here’s what bothered me: I didn’t really understand them until I needed them. Until there was a problem in front of me that demanded a solution and the math showed up as the only natural answer.

That’s backwards from how we teach it. And I think it does a lot of damage.

Bayes’ Theorem is a perfect example.

In a textbook, it looks like this: a formula, a definition of conditional probability, a few toy examples about colored balls in urns. It feels like a curiosity.

Here’s what it actually is: Alan Turing, Bletchley Park, 1941. The German Navy is sinking Allied convoys faster than they can be replaced. Turing has 10²³ possible Enigma cipher settings and roughly eighteen hours to eliminate all but one of them before the next transmission. Without a systematic way to update his beliefs as each intercept came in, the war at sea is probably lost. Bayes’ Theorem isn’t a formula in that room. It’s the only tool that works.

That context doesn’t make the math easier. It makes it matter. And when math matters, you remember it, not as a thing to be recalled on an exam, but as a tool with a history and a reason for existing.

Same story with Information Theory. Claude Shannon didn’t sit down one day and decide to invent a mathematical definition of information. The U.S. government needed to send Roosevelt’s voice across the Atlantic without the Nazis intercepting it. Shannon had to figure out what “information” actually was before he could figure out how to protect it. The math that followed, entropy, channel capacity, compression, emerged as the natural answer to a question that had genuine stakes.

That’s the animating idea behind Lutchet, which I launched this week.

Every topic starts with a real historical problem, one where getting the math wrong had consequences. The concept emerges as the only natural solution to that problem. Then we follow it forward to show where it lives in the world today.

Each topic has three layers: the Story (history and people, no equations, readable by anyone), the Learn (the mathematics, derived from the problem, rigorous but motivated first), and the Code (Python notebooks that build the solution from scratch, run it, break it, make it yours).

The first two topics are live: Bayes’ Theorem through Turing and Enigma, and Information Theory through Shannon and the scrambled telephone line that connected Roosevelt to Churchill. A narrative page connects them, because Turing and Shannon actually met in 1943, and that conversation is one of the great “what were they talking about?” moments in the history of science.

Why “Lutchet”?

A lutchet is a deck fitting that allows a ship’s mast to pivot and pass under a bridge. The mast doesn’t shrink. The ship keeps moving.

That felt right. The goal isn’t to make the math smaller or easier. It’s to give people a way through the thing that’s been blocking them.

If you have a kid learning math or CS, a friend who bounced off calculus or statistics and never went back, or you’re just someone who always suspected the textbook was leaving something out, go take a look.

And if this resonates with you, forward it to someone. The kind of person who learned to code but never quite trusted the math underneath it. The kind of person who aced the exam and still walked away feeling like they’d missed something.

That’s exactly who I built this for.

Lutchet is open source. The code is on GitHub. More topics coming.

To say that a lot has changed in the last 6-9 months would be an understatement. Today, every company I talk to is building agents, shipping copilots, and integrating LLMs into production systems. The speed of adoption has been staggering. But here’s what I keep seeing: the demo works, the CEO is excited, the board is bought in — and then it hits production, and nobody can explain the invoice.

I’ve written before about why CTOs should care about gross margins and cost-to-serve. At Krux, we built a culture of frugality around AWS costs. CTS was a first-class citizen — a product feature, not an afterthought. We could tell you exactly what it cost to serve each customer and why. We used Spot instances before most people knew they existed. We redesigned core algorithms to make fewer passes over data. Every engineer on my team cared about margins, not just the platform team.

That playbook assumed a world where your cost-to-serve was primarily cloud infrastructure: compute, storage, bandwidth. Predictable. Optimizable. Measurable.

LLMs broke that model.

The New Cost-to-Serve Problem

Unlike SaaS, where you benefitted from economies of scale (costs-to-serve don’t go up linearly with number of customers), an AI-native application results in a non-linear increase in costs with the number of customers. Moreover, these expensive LLM API calls are also your least observable. A single LLM call can cost a dollar. Multiply that across features, users, and experiments, and suddenly AI spend is one of the fastest-growing line items on the P&L — and nobody knows which team, feature, or experiment is driving it.

At Krux, I could look at our AWS bill and trace every dollar back to a processing job, a customer, a product decision. With LLM calls? Total darkness.

It gets worse. Most teams hardcode a model (“Anthropic just shipped Claude Sonnet 4.6, and we’re using it everywhere!”) and apply it to every task regardless of complexity. Classification that returns one of five labels? Sonnet. Extracting a date from an email? Sonnet. Summarizing a paragraph? Sonnet. It works, but it’s like using a Ferrari to go get groceries.

And when that single provider goes down, is slow, or hits a rate limit? Your application stops working. No failover, no fallback, no recourse.

This isn’t a hypothetical. Across the super{set} portfolio, we kept running into the same three gaps:

The attribution gap. You can see aggregate spend on your provider dashboard. You can’t see which feature, workflow, or customer is driving it. Knowing you spent $2,400 on Anthropic last month doesn’t tell you what to do differently.

The optimization gap. You suspect a cheaper model could handle 80% of your calls. But you have no way to test that hypothesis with your actual production data and prompts. You’re guessing based on benchmarks, not evidence.

The resilience gap. Single provider, single point of failure. No automatic failover, no policy enforcement.

We built observability for everything else — databases, micro-services, API endpoints. Your LLM calls deserve the same.

Introducing Majordomo

So we built Majordomo: an open-source control plane for your AI stack. It gives you visibility and control over every LLM call: cost attribution, multi-provider routing, cascade failover, and the data you need to actually optimize model selection.

Majordomo is two composable projects, each usable independently or together:

The Gateway is a lightweight API proxy written in Go. Deploy it once, point your existing LLM calls at it, and you get automatic cost calculation, full request/response logging, and custom metadata tagging. Tag every call with the feature, user, team, or experiment that triggered it. No SDK changes, no code refactoring — one header added to your existing HTTP calls.

The LLM Library is a Python async client that gives you a unified interface across providers (OpenAI, Anthropic, Gemini, DeepSeek, Cohere) with per-request cost tracking baked into every response object. It also gives you cascade failover: define a priority list of provider-model pairs, and if your primary errors out, Majordomo automatically tries the next one.

The real payoff is what you can do once you have this data. Majordomo includes a replay tool that lets you take logged production requests, replay them against a different model, and compare outputs — including an LLM-as-judge for semantic equivalence. If Haiku agrees with Sonnet 98% of the time on your document classification task, you switch and save 90% on that feature’s LLM costs. If it doesn’t, you know exactly where and why. You’re testing with your actual data, not someone else’s benchmark.

Everything is open source under the MIT license. Details, docs, and code are at majordomo.superset.com. For the full technical walkthrough, read Your AI Stack Needs a Control Plane on the Majordomo blog.

Why Open Source, and Why Now

Majordomo is an open-source project from super{set}, not a company. We built it because we needed it across our own portfolio, and we think every team building with LLMs needs something like it. The operational gap is too wide and too universal to keep proprietary.

But Majordomo is just one piece of the puzzle. A control plane gives you visibility and cost discipline for your model operations. It doesn’t solve the harder enterprise-grade AI challenges: how you architect your data layer, how you build a knowledge graph that compounds over time, how you handle governance and auditability in regulated environments, how you manage the boundary between AI autonomy and human oversight.

Those are the topics I’ll be tackling in the next posts in this series. Stay tuned.

During that chat, I was reminded again of how much luck has played such an integral role in my entire journey.  

Today, I want to re-share a piece I wrote a few years ago that tells the story of how luck (and some “gumption”) helped me find Rapt and first meet Tom Chavez.

“Luck and timing. The success of your startup has as much, if not more, to do with luck and timing in addition to your blood, sweat, and tears. Always remember that.” 

That was how Harpal Sandhu, CEO at Integral Development Corp, opened his fireside chat with Tom Chavez at our recent Show N’ Tell at super{set}. 

It was a great reminder of what’s become one of my top 3 interview questions: “Do you consider yourself lucky? Or, how has luck played a role in getting you where you are?” 

An answer I got has stuck with me: “I consider myself extremely lucky to have been born in the family that I was born in.” 

That certainly is true for me too (the subject of another post). As I reflect on my life, there is a long list of things that I put down to plain old luck. And timing. Because without the two, I would’ve never met Tom and I probably wouldn’t be where I am right now.

Joining Rapt Technologies and finding Tom Chavez

I moved to the Bay Area in June 1998 from Denver to join a young start-up called Imparto Software. Java was all the rage back then, but 14 months in there was talk at Imparto about changing the tech stack to Microsoft COM. Impressionable, passionate, naïve young me didn’t want anything to do with Microsoft so I started looking for another gig. 

Now, I am a bit more pragmatic and Microsoft has made a lot of progress so I can happily consider using Azure. To keep things interesting and mix things up — ‘cuz why not — I decided to look for jobs in San Francisco, Boston, and Denver.

Finding recently funded, early stage startups wasn’t as easy in the late 90s as it is now. 

I spent a lot of time on Craigslist and through that I found a couple of companies in Boston that I liked. 

One of my ex-professors connected me with a company in Denver that was doing some interesting work building auction based marketplaces for petroleum markets. The other strategy I came up with was to visit the portfolio pages of VC firms like Accel, Kleiner Perkins, Sequoia, Mayfield, Benchmark, etc. and identify newly funded companies. Given my background in Math and CS, I was looking for companies that were building enterprise software anchored in Math. Today, such companies are dime-a-dozen — in fact there’s an entire category of such companies. 

But back then, it was slim pickings.

After many, many hours of surfing, I came across a company called Rapt Technologies on the Accel website. 

And I really liked what I read — Rapt was building software that would help companies like Sun Microsystems optimize their supply chain for components like memory boards, hard disks and processors that were used (shared) in the assembly of Sun servers and workstations. 

The challenge was to compute procurement plans for components with long (~13 weeks) lead times to meet future demand for servers and workstations where the demand was described by a probability distribution. 

Fun, right? 

Today, Rapt would be positioned as a Data/AI/ML company. 

In 1998/99, the term Data Science hadn’t even been coined. Better yet, Spark didn’t exist. Neither did Hadoop. As usual, I digress.

Tom Chavez was one of the founders and the CEO of Rapt. 

At the time, I found them on Accel’s website, the company didn’t have any other employees other than the founders — everyone else was a contractor.

I wrote to Tom on a Wednesday afternoon, waxing eloquent about how my background in Math and CS would be perfect for the company, etc., etc. 

He responded on Thursday and asked me to come in for an interview on Sunday afternoon. Sunday afternoon found me at Rapt’s offices — a one-bedroom apartment in Potrero Hill that had been converted to an office where ½ of a wall was just stacked up with empty Pizza boxes and right across from the apartment was a tennis court in the apartment complex itself. 

And I thought to myself — pay dirt! Coding, pizza, and tennis — the perfect early-stage startup experience. I wanted this job!

I was interviewed by Tom and Adam Galper, co-founder and CTO. 

My interview lasted roughly 90 minutes and luckily for them (and me), Rapt was not using Microsoft COM. 

When the interview ended, Tom drove me to an alley called Ritch Street in SOMA and showed me Rapt’s new offices — in a small warehouse-like building on 324 Ritch Street. 

My mind was racing with all sorts of questions — why is he showing me around the new offices, did I crack the interview and do I already have a job — I was confused. 

As I was trying to make sense of all this, Tom said, “look, I don’t know where you are in your job search but it’s clear to me that you have a lot of gumption when it comes to problem solving and early stage company building and I’d like you to come work with us at Rapt.” 

My first (internal) reaction was, “gumption? Really? People use GRE words in day to day conversations?” 

I did summon the good sense finally to express my gratitude for the offer and that I’d get back as soon as possible.

Along the way, I had interviewed with and also received offers from companies in Boston, Mountain View, and Denver. 

Somehow the idea of moving to Boston or Denver was more appealing before I started my job search than after I had concluded it. 

Ultimately, inertia won, and I accepted the job offer from Rapt.

So, what about luck and timing then? 

Well, I would later find out that the day I found Rapt on Accel’s website was the day after the portfolio page was updated to include Rapt and it was a week after Rapt had closed their Series A with Accel.

What luck! And timing! 

Yes, inertia and gumption helped too. 

I don’t know what would’ve happened had I not been on Accel’s website that day and found Rapt. 

What I do know is that I wouldn’t be where I am today were it not for the perfect alignment of the sun, moon, and the stars — otherwise known as luck — that began my partnership and friendship with Tom.

Work With Me: Apply to super{set} VECTOR

A 12-week fully-paid launchpad for technical product leaders based in San Francisco to receive direction, build magnitude, and co-explore company creation alongside super{set} - Apply at superset.com/vector

Work with me! Apply to super{set} VECTOR

Links worth reading (plus my IIT Delhi interview)

Check out my full interview from IIT Delhi here, along with a few links to some other, related posts—including Tom’s chat with his brother Marty Chavez.

You can listen to the full audio on Spotify here:

Tomisms

What Bono Can Teach Us About Entrepreneurship

This week, we’re talking: How the skills that make for a good executive are often antithetical to the skills required of a good entrepreneur (and vice-versa) 👩‍💼≠👨‍💼 Vermont’s Privacy Law may have been killed with a veto but we haven’t seen the end of it 🔐 ⚖️ 🚫…

Read more

2 years ago · 4 likes · Tom Chavez

The Ethical Tech Project

Why Brands Must Do More to Protect Consumers' Personal Information

Note: This editorial previously appeared in the May edition of AdAge For some years now, we've been predicting a tipping point in consumer awareness that would motivate brands to adopt responsible data practices. We have long understood that consumers deeply value their privacy. However, there was a nagging question about their seeming apathy toward the …

Read more

2 years ago · 7 likes · JJ

• No-code, full control: introducing Ketch Privacy Experiences

• Perplexity is a bullshit machine

• Chat GPT is bullshit

This Apple x OpenAI announcement (and Elon’s response) reminded me of the conversation I had almost exactly 1 year ago with Brian Christian — an acclaimed researcher who studied psychology and computational neuroscience at Oxford, and author of “The Alignment Problem.” Brian’s work explores the human implications of computer science, and “The Alignment Problem” is his latest work.

Some questions we addressed: 

• What does AI “alignment” actually mean? 

• What philosophical principles can we apply to make AI less biased?

• What is “reinforcement learning” and how does it contribute to AI’s unpredictability? 

• What is AI’s “frame problem,” and how does that problem affect its ability to understand and respond to specific objects? 

• What role does human feedback play in ML/AI fine-tuning? What does this mean for AI alignment? 

I’m (re)sharing this talk with Brian, especially in the wake of the recent Apple x OpenAI news, because his perspective—which integrates ethics, philosophy, and computer science—is one of the best for mapping the questions + challenges that confront AI in the future.

Share

Understanding The AI “Alignment Problem”

In the realm of technology, the intersection of human desires and the unforeseen consequences of artificial intelligence can lead to some serious collisions. This is the heart of what author Brian Christian calls the “alignment problem”. 

I recently had a chance to talk to Brian about his books and his career as a programmer and researcher when he stopped by our second annual super{summit} in New Orleans in May 2023. 

The conversation was particularly timely, given the interest in AI in both engineering circles and the broader public. In business, well-meaning executives are pressuring their tech teams to build and train models to interpret data without realizing the challenges inherent in asking AI to “act human.” Afterall, AI doesn’t “think” like we do and if we aren’t extremely careful about spelling out what we want it to do, it can behave in unexpected and harmful ways. 

The Problem with AI

Here’s one tragic example: 

Autonomous vehicles are designed to navigate through bustling city streets, guided by complex algorithms designed to prioritize passenger safety above all else. But, what happens when a situation arises that the systems have not been trained to identify? Well, this is what happened with one of Uber’s autonomous vehicles in a 2018 fatal accident.

As Brian explained it, in the system that Uber was using, the motion planning system controlling the car was designed to identify pedestrians, cyclists, other cars, and  debris – but not a pedestrian walking a bicycle across the street, which is how the object presented. When something doesn’t fit into one of the categories of the object classifier, it can’t make a decision. And because the motion planning system was waiting for the object classifier to tell it what to do, it never decided to apply the brakes.

This is the heart of the alignment problem. It’s perpetuated not by human misunderstanding per se but by human overestimation of the quality of the data upon which they are building their models.

Take for instance ChatGPT, which relies on imitation to observe and predict human behavior in order to assist us. However, AI systems are not bound by the same constraints and limits as humans, leading to misinterpretations of our intentions and what is truly beneficial for us. One of the key issues with AI imitation is that instead of protecting us from our bad habits, these systems tend to amplify them. Moreover,  they can push us towards acquiring the bad habits of others, ultimately reinforcing negative behaviors.

Aligning AI

So how do we realign ourselves? Reinforcement learning from human feedback (RLHF) is, as Brian said, “one of the most technically and philosophically significant things to emerge in AI in the last 10 years.” Simply put, RLHF involves humans “grading” AI responses, and the AI in turn learning from its mistakes. For example, humans can rank summaries of articles generated by AI systems. By incorporating human preferences into the reward model, we can shift the objective of AI systems from simply predicting the next token to generating texts that people prefer. 

This is a topic I’m particularly interested in, especially in my role as CEO of MarkovML, one of our portfolio companies that is building tools for AI, including tools to assess data health and model quality in a given application. MarkovML is among a handful of the first companies to focus on how you train your models to account for the noisiness in the data (and the labels!) that is used to train the underlying neural network that forms the core of the model. In fact, I’d like to think we are part of the solution to Brian’s alignment problem.

In the weeks since super{summit}, I had been thinking about Brian’s keynote and how the field of machine learning has made remarkable strides - bringing us closer to the creation of intelligent machines. However, it's still essential to recognize the challenges we face in achieving human-level intelligence and ensuring the alignment of AI systems with human values. It’s something we think about every day as a data+AI startup studio hoping to solve persistent problems with innovative technology while also managing ethical considerations and best-in-class data privacy protocols.

Many thanks to Brian for participating in the super{summit} and all of the ways we’ve continued to collaborate since.

Share

👂Brian Christian also appeared on my podcast, The {Closed} Session! Listen Here

Work With Me: Apply to super{set} VECTOR

A 12-week fully-paid launchpad for technical product leaders based in San Francisco to receive direction, build magnitude, and co-explore company creation alongside super{set} - Apply at superset.com/vector

So, what are the different personas of folks who show up at a booth? Below is my “Booth Visitor Taxonomy”:

1. The Know-it-all: this is the person who starts the conversation by telling you what your company does (they’re often wrong) and then asking you a bunch of unrelated questions. Their goal is to demonstrate how smart they think they are. Try to end these conversations as quickly as possible.

2. The Skeptic: this is the person who is going to tell all the ways in which what you are doing is wrong - the problem is not real, or your solution is too simplistic and won’t scale, or there is no business to be built here. I engage with Skeptics with an open mind, ask them lots of “what makes you say that” questions that often lead to left field insights, but disengage if they become too combative.

   

3. The Job Seeker: this is mostly a fresh grad, a university student looking for an internship, or someone who has just been laid off. Try to be as helpful to them as possible - connect with them on LinkedIn, give them advice on how to approach their job search and finally, if you are hiring, do a mini interview to assess whether they could be a good fit for your company. I’ve seen some amazing examples of hustle with this persona at the conferences I’ve been to recently.

4. The Name Dropper: my least favorite persona 😜. Suffering from an inflated sense of self, they will tell you all the ways in which they are awesome and drop names of everyone they ostensibly know. Get out of these conversations as quickly as possible!

   Thank you for reading The Problem Is.... Please consider sharing this post if you like it!

   Share

5. The Reverse Pitcher: my second favorite persona 😃! Why? It’s a great example of hustle! They attend the conference because their ICP is going to be manning the booths on the conference expo floor! I engage with this persona because I always learn a thing or two from the conversations.

6. The Curious Learner: while not a prospect, they are genuinely curious about what your company does, what problems you solve and for whom. They listen to what you are saying and ask thoughtful questions. Engage with them because this is an opportunity for you to get feedback on various aspects of your business.

7. The Genuine Lead: and last but not least, there is the genuine lead! My favorite persona - obviously! This is why you attend the conference in the first place. Finding genuine leads takes patience but boy, there is no better feeling than landing a demo meeting with a lead at a conference!

Any personas I missed? Share your favorite stories in the comments below!

Work With Me: Apply to super{set} VECTOR

A 12-week fully-paid launchpad for technical product leaders based in San Francisco to receive direction, build magnitude, and co-explore company creation alongside super{set} - Apply at superset.com/vector

🔗 Links Worth A Read

• The Ethical Tech Project: The Impact of a Federal Privacy Law

• Noema Magazine: The Future Of AI, According To Former Google CEO Eric Schmidt

• Tomisms: Lunar Kittens & the Benefits of Nuclear War

• VentureBeat: The future of financial analysis: How GPT-4 is disrupting the industry, according to new research

• The Information: How Lacework Went From Cybersecurity Stardom to Fire Sale Talks

• super{set}: Investing and AI with R. Martin Chavez

Discover More at superset.com

Join Me At Scale Smartly: Building the Optimal DevEx for Your Startup

My company Kapstan, in collaboration with super{set}, is hosting a meetup in San Francisco on June 13th from 5pm-8pm. Come chat building DevEx and optimizing your cloud spend with fellow startup CTOs! Learn more here.

Join Me At Scale Smartly

As AI reshapes the business landscape, the true kingmakers are not the models themselves, but the quality and exclusivity of the data powering them. A tech revolution like AI unleashes rapid change, and not every firm or job will survive.

While the large firms creating massive AI models, such as OpenAI and Anthropic, undoubtedly have a good shot at success, the rest of the businesses that innovate, compete, and profit from this revolution will be the ones with the best data and not the best models.

What defines “better” data? That is entirely subjective. Better data for your company is confidential, copyrighted, personal, or otherwise exclusive and tailored for your industry or use case. We call this “proprietary data,” and it is nothing new.

Subscribe now

I’ve been an entrepreneur and CTO since the dotcom era when machine learning (ML) was synonymous with statistics, and proprietary data has always been at the heart of my business models.

One lesson I’ve learned from successfully building multiple data+AI companies is that simply owning a proprietary data asset is not enough. For example, a medical institution may use its proprietary patient data, medical records, and treatment outcomes to build Generative AI applications to assist clinicians. Publishing companies may create personalized learning applications using their proprietary content available in books, articles, and images.

Read Me in CDO Magazine

Time and time again, I come back to famed computer scientist Peter Norvig’s axiom:

It’s time business leaders take this to heart, too.

The most competitive firms in the age of AI will have “better data.” They will understand and segment data by quality before feeding it into a model and evaluate the new model's performance after the fact. Crucially, a collaborative culture will elevate a firm's capacity to fully exploit proprietary data in this evolving landscape of data-centric AI.

Stakeholders must stay aligned toward the business goal while ensuring the AI solution is robust, ethical, and unbiased.

Share

Proprietary Data in the age of AI

The rapid adoption of generative AI has accelerated the transition of AI and ML product development from model-centric AI to data-centric AI. Business leaders have to keep up. Instead of blindly launching a search for the “right model,” leaders should put first things first and ask themselves, “Do we have the right data?”

Here is an easy way to understand the distinction between the two:

Instead of asking how to adjust the model to deal with the noise in a particular dataset, we should ask how we can understand, modify, and improve the data so trained models deliver the desired business outcome.

Why does this matter?

Foundation models, or Large Language Models (LLMs) are trained mainly on publicly available internet data and excel at expressing general topics. What these large models can do is impressive, but they fall short on tasks that require leveraging confidential, copyrighted, personal, or exclusive data.

It’s like expecting a high school graduate to ace a graduate-level calculus test without any preparation. Unfortunately, it is precisely this type of data that is so important for businesses and customers. But there are methods to take an off-the-shelf foundational model from the likes of OpenAI, Anthropic, or Meta and fine-tune it for specific needs.

Read More Like This on superset.com

What is Fine-tuning in Generative AI?

When a foundational model needs to learn from a proprietary dataset, we use a technique known as "fine-tuning.” This process trains the model on a smaller, high-quality, and task-specific proprietary dataset to complement its broader general knowledge with specialized information to handle specific use cases. It is as if we gave personalized 1:1 tutoring to someone who has only ever attended massive lecture classes.

The difficult part of fine-tuning almost always lies with the data used to train the model. Fine-tuning is as much about the quality of the underlying data as it is about the model itself. By identifying high-quality diverse data points in the dataset used to train the model, models generalize better to unseen inputs and deliver accurate outcomes.

However, managing data for machine learning involves optimizing computational resources, understanding data distributions, and preventing overfitting while adapting to new data distributions.

When fine-tuning, companies must identify which parts of the proprietary data asset are representative and high-quality for the model. We call this “data evaluation;” while it requires effort up front, that work pays off by significantly reducing model training time and cost.

Think of data evaluation as an essential step so that better models can be trained to derive desired value from AI. The outcome of the data evaluation process is a new, high-quality version of the original dataset that is ready for action.

Listen to my podcast on AI Alignment

AI is a team sport

Implementing AI to transform your business extends beyond merely choosing an off-the-shelf tool. It's an interdisciplinary endeavor that spans algorithms, data engineering, domain expertise, ethics, and user experience.

Generative models are powerful, but the flip side of that power is a weakness. The wide range of possible responses makes it difficult to exhaustively evaluate model behavior across all potential inputs. Traditional model-centric metrics, such as accuracy or loss, do not capture the nuances of generative tasks.

The checks a firm needs are task-specific to ensure correctness, appropriateness, and truthfulness. The highly tailored, precise nature of proprietary knowledge means that, on top of data evaluation, firms must also ensure quality at the latter end of the process before a model reaches its end users. Aligning the business and technical stakeholders across this end-to-end process demands unprecedented cross-functional collaboration.

The bottom line: AI is a team sport with multiple players across product, data science, engineering, and the knowledge workers who are often the end users. Leaders must enable practitioners with systems of intelligence and organizational knowledge that allow them to improve data.

In this new AI landscape, those who harness the potential of proprietary data and foster a culture of collaboration will lead the way—those who don't risk obsolescence.

Work With Me: Apply to super{set} VECTOR

A 12-week fully-paid launchpad for technical product leaders based in San Francisco to receive direction, build magnitude, and co-explore company creation alongside super{set} - Apply at superset.com/vector

🔗 Links Worth A Read

• Tech Crunch: Why RAG won’t solve generative AI’s hallucination problem

• Tomisms: Don’t Bury Your Piles of Gold

• The Ethical Tech Project: Brick by (Lego) Brick We Can Build Transparent Tech

• Kapstan: Introducing GCP support

• Information Week: Data Privacy in the Age of AI Means Moving Beyond Buzzwords

• Merci Victoria Grace via LinkedIn: Some controversial takeaways from Not Finding Product/Market Fit...

• NY Times: Meta Says It Plans to Spend Billions More on A.I.

Discover More @ superset.com

Join The Ethical Tech Project at the SF Privacy Technologists Meetup on Tuesday, 5/21

​The Ethical Tech Project has a killer line-up with:

• Nandita Rao Narla (Head of Technical Privacy & Governance @ DoorDash / Ethical Tech Project Board Member)

• Chitra Dharmarajan (Vice President, Security & Privacy Engineering @ Okta)

• Sam Alexander (Data Privacy Engineer @ Ketch / Data Ethics Nerd)

​Join us for a casual conversation on privacy tech, networking, and plenty of food and drinks - Register Here: https://lu.ma/sf-privacy-technologist-meetup

Register for the 5/21 SF Meetup

PS: There is no AI

Above all else, America’s role as the most innovative country on the planet has come down to one thing: people. For decades America has been the undisputed destination for the world’s top talent to do their best work. 

Subscribe now

We see this repeatedly in the tech industry. More than half of our country’s billion-dollar startups had an immigrant founder, fueling our economies’ growth and creating hundreds of thousands of jobs. High-skilled immigrants are so important that President Biden dedicated an entire section of his AI executive order to immigration reforms that would streamline visas for foreign AI talent.

Yet now, at a critical moment, America’s self-inflicted wounds have resulted in America losing its status as a global leader for talent. Whereas just twenty years ago America attracted more inventors than every other country combined, last year Canada replaced America as the top destination for employment-based migration.

Share

I empathize with high-skilled immigrants moving to Canada, as I was almost forced to do the same. Twenty years ago, my wife and I experienced the unsettling stress and uncertainty of not knowing whether we would receive a green card before our visa expired, which would have required us to leave the country for a year before we could get a shot at coming back to the US. It got to the point where we filled out the paperwork to immigrate to Canada, just in case. Thankfully, my green card came through just in time, which meant we could stay, build a family, and I got to stay and work as the CTO of a startup that was acquired by Microsoft 3 years later. 

I was one of the lucky ones, as the ballooning backlog for visas in recent years means my green card would most likely not have come through. The U.S. has all-time-high of more than 1.8 million people waiting for employment-based green cards, over half of whom have advanced degrees. Thanks to rules restricting each country’s share of green cards, more populous countries like my home country of India bear the greatest burden. The problem is so bad that an estimated 400,000 Indians will die before getting their employment-based green card (assuming they do not lose their job and leave the country first). 

What is frustrating is that common sense solutions exist. We simply lack political leaders with the will to act. Bipartisan legislation to address the issue has included proposals to:

• Relax or eliminate the per-country cap so that immigrants’ chance of a green card does not depend on their country of birth. 

• Keep families together by allowing a pathway for minors who turn 18 to stay in the country. 

• Exempt spouses and children from the cap to let more people stay. 

• Exempt talent with advanced STEM degrees from green card caps, as outlined in the America COMPETES Act, so that we keep top technical talent in the country.

• Clear the backlog by recapturing unused visas from the past 30 years. 

A life spent waiting for a green card is dehumanizing. I see it in my employees and peers, some of whom have spent over a decade in green card limbo. Major life decisions like whether to buy a house, build a business, or start a family are complicated by not knowing how long a person has until they are forced to leave. Spending years on employment-based visas also gives employers unfair power over their teams, as getting fired or laid off could force you to leave the country. 

I am grateful to be in America, where I have built and sold three startups totalling over a billion dollars, created thousands of jobs, and established a future for my family. Now, as the leader of a startup studio, I interact with hundreds of brilliant, hungry, entrepreneurial immigrants looking to contribute to America’s own future, if only our broken immigration system would let them. 

America’s future is only as bright as its people. Now, what we need more than ever, is leaders willing to uphold our country’s legacy as the top destination for global talent. Not only will these reforms build a more humane immigration system, they will also ensure the world’s most ambitious people continue to build the future right here in America.

Work With Me: Apply to super{set} VECTOR

A 12-week fully-paid launchpad for technical product leaders based in San Francisco to receive direction, build magnitude, and co-explore company creation alongside super{set} - Apply at superset.com/vector

🔗 Links Worth A Read

• CalMatters: Why visa reforms benefit not just California’s tech sector but the economy overall

• The {Closed} Session: Habu Co-founders Matt Kilmartin & Mike Moreau On Selling for $200M

• Pavilion: RevAmp at Pavilion’s Demo Day

Discover More @ superset.com

Read About Habu's $200 M Acquisition

For those that aren’t familiar, Habu is a leader in the data collaboration category with innovative data clean room technology. Habu enables companies to share, make sense of, and act on insights on decentralized data without compromising privacy or data ownership – enabling companies to realize the full value of their data regardless of where it resides.

At the time of the exit, I said:

“When Habu started, data clean rooms weren’t on the radar of major brands, and the category was largely undefined. I’m incredibly proud of the spectacular work Matt Kilmartin and Mike Moreau have done to see the solution through, and I’m excited to see how Habu continues to evolve in its next phase as part of the LiveRamp universe.”

Since the exit, I’ve had a chance to reflect a bit on the successful build-out at Habu, and I unearthed a February 2020 post (4 years ago!) that I wrote about the origins of Habu. Comparing this post from the early days, it’s amazing how much of the problem we had fully scoped out so early in the build (although later we steered away from the ‘operating system’ language), and how much Habu achieved in so little time.

Congratulations again to the Habu team - and without further ado, check out my blog post “Habu — the why and the what of the industry’s first Marketing Data OS” - reprinted below!

Subscribe now

Habu — the why and the what of the industry’s first Marketing Data OS

This blog post was originally posted on February 12, 2020 and reflects an early stage of Habu’s build-out.

“Another one?” “Really? “. That was my inner monologue as we were discussing whether to jump in the fray — again — and launch yet another MarTech / AdTech company. When Tom and I started super{set}, we set ourselves the ambitious goal of creating category disrupting companies in multiple verticals leveraging our expertise in building AI/ML driven software services and applications and we wanted to flex our muscles in verticals beyond AdTech and MarTech.

Read About Habu's $200 M Exit

When Matt Kilmartin and Mike Moreau raised their hands and were ready to come on board at super{set}, we revisited the possibility of another MarTech company. Matt brought with him a lot of informed perspective from his ~3 years at Salesforce in the Marketing Cloud sales organization, especially from his role as Chief Customer Officer for the Consumer Engagement Platform. And we were extremely fortunate to have worked with a large group of people who were (and continue to be) very generous with their time and input on the challenges they continue to face in their myriad jobs in Marketing and MarTech. As I compared notes with industry friends, colleagues, and former clients, five themes kept coming up consistently:

1. The last 10 years saw the arrival (and in some cases, departure) of a plethora of marketing / advertising platforms and/or marketing clouds with lofty and ambitious promises of customer/consumer data unification and seamless integration and interoperability. And while a lot of progress has been made, customer and/or consumer data still sits in siloed systems and the various marketing / advertising systems don’t talk to each other as effectively or efficiently as they could or should.

2. Cross-channel orchestration remains an illusory goal. One repeated example that came as a surprise to me was around the integration of email and website channels. A customer signs up for a newsletter with a Brand resulting in the customer’s email address being added to the Brand’s CRM or Email Marketing System. Soon enough, the customer receives the first newsletter which contains a list of offers and recommendations from the Brand that are (supposedly) personalized for the customer. The next day, the same customer shows up to the Brand’s website and you would think that the customer would be presented with the same set of offers as the ones sent in email. But what I heard was that this is a challenge for most of the brands that I spoke to.

3. A very significant portion of a brand’s media budget gets allocated to Google, Facebook, and Amazon. Extracting intelligence from the vast amounts of data generated through those paid advertising is an ongoing challenge for a variety of reasons — some technical, some operational.

4. All the device graph companies from the last 8 years or so have come and gone and yet brands and media companies have not been able to effectively deploy and implement “Identity Graphs” at scale to solve their most pressing business problems beyond Onboarding and activation of PII based datasets into Facebook, Google, etc. An earlier — younger — version of me would have said, “Great! Let’s build a better Identity Graph and companion solutions and compete with the well-established vendors!”. That wouldn’t have necessarily solved the business problems though. Brands don’t need another Identity Graph — they need plumbing and connectors to take advantage of the already excellent ones that are out there and integrate those Identity Graphs into solutions for their business problems. A case in point is the example above (#2) where the offers presented in the email channel are not connected to the web channel.

5. And finally, Privacy. GDPR has come and gone, CCPA too. Most marketing and advertising platforms do not have consent management and privacy by design embedded into them on the ground floor as first class citizens. Brands and media companies need to pay special attention to this because CCPA is just the beginning and data protection regulatory frameworks from 14 more states are imminent.

Share

A sixth theme emerged from conversations with brands and mid to large scale media companies with large technology organizations. I discovered that these companies have spent significant resources to build their own tech stacks to solve some of their business problems related to marketing and advertising. But they had some gaps in their respective solutions and they were looking to fill some of those gaps using a partner. In this scenario, deploying a new mar-tech platform that required all the data to be moved out of the first party data center (private/public/hybrid cloud) into the new platform’s public cloud infrastructure was simply not going to be feasible. Instead, all auxiliary services that filled the solution gaps would have to be deployed in the first party data center.

At Habu, we decided to adopt a fundamentally different approach in order to address these challenges. We realized that we wanted to provide technology to brands to enhance consumer experiences but do it in a way where, if needed, we could operate as an extension of an existing marketing technology stack / platform. The need for a collection of services that could be assembled together into a platform while being modular enough to be deployed independently has resulted in the creation of the Habu Marketing Data Operating System (MDOS).

I am a technologist first and sometimes I get cute with (and am quite proud of) my analogies. We’ve embraced micro-services as a core software architecture pattern and just like our API services, MDOS is modular, not monolithic and is designed as a layered collection of services and applications. We speak Docker and Kubernetes and our services and applications can run seamlessly on AWS, GCP, and Azure. A customer has complete flexibility in choosing what services and applications they want to use — all services can be deployed in headless mode and integrated with upstream applications using APIs.

We’re extremely encouraged by the feedback we’re getting from every conversation we have in the market and our early customer deployments. We’ve also realized that you need a diverse blend of skills and expertise in AdTech and MarTech in order to build solutions that can address the challenges facing our industry today. The Habu team has been doing just that for the last 20 years at Salesforce, Microsoft, Google, Facebook, IBM, and Akamai.

So, yeah. Habu. Another Mar-tech company. Not the platform you were not looking for though.

Work With Me: Apply to super{set} VECTOR

A 12-week fully-paid launchpad for technical product leaders based in San Francisco to receive direction, build magnitude, and co-explore company creation alongside super{set} - Apply at superset.com/vector

🔗 Links Worth A Read

• Railway: Scale Not Sales: Automating Revenue So Graph Go Up

• Conversations in Ethical Tech: Exploring Data Privacy & AI

• Forbes: Rubrik’s $5.6 Billion IPO Is Latest Win For The 'IIT Mafia'

• Tomisms: A Taxonomy Of VC’s

Discover More @ superset.com

PS: Listen to My Conversation with Habu Co-founders Matt and Mike on How They Built It

Not on Spotify? Listen to the podcast on your favorite provider here.

We had just started to hit our stride; the revenue engine was humming, and we were getting questions from the Board about how we would grow and scale revenue profitably.  Until then, I hadn’t fully appreciated or understood the impact that decisions made by me and my team had on gross margin.

That was a turning point for me, and there are three critical takeaways from my Krux experience that I now bring to all super{set} companies:

• Prioritize Cost-to-Serve: Cost-to-Serve (CTS) must be a first-class citizen for the CTO and be ingrained into the company’s culture right from day one.

• Build Joint Accountability: Product, Engineering, and Platform Engineering (PE) [or DevOps] teams are jointly responsible and accountable for CTS. It is a huge mistake just to hold the PE team accountable for CTS.

• Own Product: An org structure where Product Management reports to the CTO, especially at a start-up, creates a lot of flexibility and provides leverage in making product decisions related to CTS.

What is Gross Margin?

The formula for Gross Margin is simple:

Gross Margin = (100.0 * (Revenue - Cost)) / Revenue

where

• Revenue is what your customers pay you for all the software and services you’ve sold to them

• Cost is what it takes for you to serve those customers (Cost-to-Serve or CTS)

For a SaaS business, gross margin is a great indicator of a company’s financial health. It helps you evaluate whether you can grow and scale your business profitably.

Share

Benchmarking Gross Margin

The benchmarks for a SaaS start-up depend on the stage, but generally speaking, once you have crossed the $5M ARR mark, you should evaluate your gross margin using the following:

• 80% ⇒ Excellent! Keep doing what you’re doing, and don’t relent!

• 65% - 80% ⇒ You’re doing okay, but improving CTS should be on your 3-month product roadmap

• < 65% ⇒ Fix it! Improving CTS should be on your near-term, urgent product roadmap

While you should always focus on operating your infrastructure in a cost-effective manner, it’s okay to operate at lower gross margins - 45-50% - if your ARR is less than $5M. It’s OK for your gross margins to be even lower if your ARR is lower. At this stage, the board understands that you need to spend more money to stand up cloud infrastructure. Still, you have to be careful about your technical design choices - you don’t want your infrastructure costs to scale linearly with the number of customers!

Subscribe now

Case Study: Krux

For us at Krux, two significant factors contributed to CTS:

• Infrastructure (Cloud) Costs: primarily AWS and Fastly (our CDN)

• Compensation (Salary & Bonus) for our integrations & implementation team that helped implement Krux for our customers and built any customer-specific integrations with the ad-tech/mar-tech ecosystem.

As CTO of Krux, I managed five teams: (Application or Product) Engineering, Platform Engineering, Data Science, Product Management, and Integrations & Implementation (I&I). Some folks may find it surprising that Product Management and I&I reported to me. I’d like to say that while this wasn’t a carefully considered decision, in hindsight, this turned out to be one of many things we got right at Krux. This organizational structure has many advantages, but the main one from my perspective was that the buck stopped with me for CTS. My team and I could play offense and defense to improve our gross margin by lowering our CTS as part of our work.

For example, we redesigned the core segment processing algorithm using a two-phase approach, which only required making one pass over the raw user data logs. Similarly, we used Spot instances in our data processing pipelines; we were one of the very early adopters of Spot instances in AWS. On the offensive side, we implemented new self-serve product capabilities that allowed customers to do more for themselves, obviating the need to hire more I&I engineers – and increasing customer volume.

Each choice required us to make trade-offs, but I had more control over outcomes since it was within my team. Of course, we partnered with Sales and Customer Success as needed, but I didn’t have to seek approval from anyone else in the organization to make these decisions. CTS (or improving it) became a product feature, an item on our product roadmap that (a) had strategic value and (b) improved our customer satisfaction.

Another benefit of this organizational structure was that we instilled a culture of frugality when it came to Cloud (AWS) costs across the entire team - Product, Engineering, Data Science, Platform Engineering, and I&I. CTS and gross margin became metrics that everyone on my team - not just Platform Engineering - cared about and were held accountable for. I would beam with pride whenever I overheard things like, “But if we do it this other way, we can solve the problem at a third of the cost. Can we speak to our customers and help them understand the trade-offs?” Often, I see companies where the Platform Engineering (or DevOps) team is left holding the bag for cloud costs. But that is a massive mistake, in my opinion. The engineering team should be held equally, if not more, responsible and accountable for CTS.

CTOs can and should be involved in these decisions. I’ve coined the term “Product-Centric CTO” to describe them. I believe product-centric CTOs can drive growth and success for the companies and teams they lead beyond the purely technical – and they are key to future growth.

Work With Me: Apply to super{set} VECTOR

A 12-week fully-paid launchpad for technical product leaders to receive direction, build magnitude, and co-explore company creation alongside super{set} - Apply at superset.com/vector

🔗 Links Worth A Read

• The Register: Stability AI reportedly ran out of cash to pay its bills for rented cloudy GPUs - we’ve only just begun!

• super{set}: Jeremy Klein on Leading super{set}'s Data-Driven $90 Million Fund II - great interview with super{set} GP Jeremy!

• WSJ: Where Does the Best Innovation Happen? Not in Stand-Alone Labs, Some Companies Say

• Tomisms: How To Quit Your Job

Discover More @ superset.com

PS: The difference between a new and experienced cloud engineer...

Watch the super{set} Bengaluru Meetup Sizzle Reel

Here’s a taste of the event:

Tech is Accelerating in India

When I moved to the US in the mid-1990s, you could count the number of start-ups in India on one hand. What a difference 25 years makes! In Bengaluru, residential neighborhoods that once had a relaxed, retirement-town vibe transformed into vibrant start-up hubs that are building tomorrow’s technology today. The culture in Bengaluru today is eerily similar to that of San Francisco - coffee shops and bars filled with young, aspiring entrepreneurs talking about the problems their start-ups are solving (or will solve), the technologies used, and the promise the future holds for them.

Several initiatives have driven this shift in mindset and growth of the start-up ecosystem. Aadhar, the world’s largest biometric identity system,  launched in 2010 and covers nearly all Indian citizens. UPI (Unified Payments Interface), a protocol and instant payment system that facilitates inter-bank peer-to-peer and person-to-merchant transactions, is widely adopted. You can pay your local vegetable grocer or make donations to your local temple, mosque, or church via UPI. A standard set of APIs for digital identity verification, payments, and data sharing has enabled many start-ups to build creative solutions that make life easier for consumers in India.

India recently surpassed China as the world’s most populous country with an overwhelmingly digital-native population. Over 50% of India’s population is under 30, and the median age is 28. Additionally, India has 751.5 million Internet users—almost equal to the total population of the US and EU combined!

Today, India's most significant weakness is its lack of world-class infrastructure (physical, not cloud). Bengaluru is plagued with traffic congestion and water issues. Significant Investments are being made in transportation, clean energy, and real estate, but the rate of change is not consistent. I hope these investments will bear fruit and have a positive impact in the next five years.

 So what does this mean for super{set}? The availability of high-quality technical talent, a bold, fearless, and thriving entrepreneurial community, and the ability to build capital-efficient teams that know when to strategically use jugaad make me more bullish than ever about building global companies in India!

Why Build Globally?

Here’s what I learned from our recent meetup and why super{set} will continue to advance entrepreneurship across the planet with global teams:

1. There’s an immense well of engineering talent.

There will always be diffuse technical talent across the globe, but India, more than anywhere else, has a density of top-notch technical talent across a diverse set of domains. There are two reasons for this: 

(a) more and more US-based companies, large and small, have established product engineering teams in India

(b) more importantly, many start-ups have been built from the ground up in India, serving the Indian market. If you’re building a B2C or Consumer Fintech start-up in India, a 1% penetration results in a user base of 14 Million users (that’s ~40% of the US population!). So, even “small” start-ups have to deal with scaling issues much earlier than their US counterparts! 

Our experience at the Bengaluru meetup only reinforced our perception of talent density. For outsiders, Bengaluru is the “Silicon Valley of India.” It is India's new startup hub, and it has a hilly landscape and mild climate that rivals San Francisco. Building teams in Bengaluru isn’t just about finding a co-founder or a few key players but about assembling a powerhouse team of tigers that can execute on a global stage from day one. For that, the density of engineering talent can’t be beat.

2. The risk appetite for talent has changed.

In recent years, I've observed a palpable shift in the motivation and hunger of the Indian startup ecosystem. Gone are the days of cautious career moves and playing it safe. Today, Indian professionals are more willing than ever to bet on startups and embrace the uncertainties and opportunities that come with them. The talent we met and interacted with in Bengaluru displayed an evident readiness to take on risk in exchange for high-velocity personal growth - showing that the ecosystem is maturing in a way that aligns with our vision of fostering entrepreneurship worldwide.

3. Startups can pull off a global presence like never before.

The first-ever team that super{set} built out in India came at the insistence of Pankaj Rajan, co-founder at MarkovML. At the time, we had a few qualms about having one team sitting across two continents, but we trusted Pankaj and bet on the immense benefits that would come with the global team. We found many of the challenges we expected: communication, culture, and overcoming the “short-order-cook” mindset.

With some plain talk and seeing things as they are, not as we wish them to be, we built up the super{set} playbook for global collaboration. We found a good rhythm for stand-ups and asynchronous communication. We leaned into the super{set} culture playbook and evangelized a strong shared identity. And we fostered a sense of ownership and grit for our teams, wherever they sit, to deeply engage with the customer, the product, and each other. Today, there are teams led by MarkovML’s Varun Srivastava, Kapstan’s Harshil Vyas, Headlamp Health’s Manaswini Sugatoor, and SuperCMO’s Amit Gupta - not to mention the hub of our super{set} People and Culture efforts in India, Global People Architect Ila Sharma (Thanks Ila for organizing the meetup!).

I can easily see many people I met at our recent Bengaluru meet-up sitting at the whiteboard in a super{set} office - in India or San Francisco. We have the playbook to make them successful team members wherever they sit.

See What I'm Building @ super{set}

There’s Never Been A Better Time to Build Globally

Building cross-border isn’t for every startup. There’s a reason why in my two previous build-outs before starting super{set} - Rapt (sold to Microsoft) and Krux (sold to Salesforce) - we avoided building a global team. Building a geographically distributed team requires a significant shift in mindset, embracing a culture of asynchronous communication and comprehensive documentation. I wouldn’t say we’ve cracked the code entirely. Still, by hiring leaders like Varun, Manaswini, Harshil, and Amit, who’ve done this before, we’re learning fast and building playbooks that future super{set} companies can use. The late-night and early-morning calls don’t go away, so that’s another thing to get used to.

Even still, with a changing Indian workforce and expanding startup ecosystem, combined with the super{set} playbook for scaling global teams sitting in the U.S., India, Israel, or wherever, is too powerful an opportunity to ignore. There’s never been a better time to build, and I can’t wait for the next super{set} meetup in India.

Let me know in the comments: what challenges have you faced in leading or working for a global team, wherever you are based?

Subscribe now

🔗 Links Worth A Read

• NY Times: “Think Bangalore, not South China”  Poor Nations Are Writing a New Handbook for Getting Rich

• Tech Crunch: Boutique startup studio super{set} gets another $90 million to co-found data and AI companies

• Kapstan.io: Kapstan Changelog #03 | Cron Applications | AWS ECR Support

• WSJ: For Data-Guzzling AI Companies, the Internet Is Too Small

• Tomisms: Startup Studio Myths, Busted

Discover More Content @ superset.com

PS: Why did the DevOps engineer need glasses?

Because they couldn’t C#

Read Our Fund II Announcement Here

super{set} is an incredibly simple but powerful concept: focus on building in the data+AI space we know best, collect lessons learned across startups to move up the learning curve and make each build better than the next, and bring in as many amazing people as possible to co-found alongside us.

Indeed, four years ago, super{set} was only a concept, a dream, just a sparkle in my eye. Back then, the company I had started in 2010, Krux, had been acquired by Salesforce and I had just completed a tenure as CTO of Salesforce Marketing Cloud. I even wrote a book. 

I learned a lot about myself and what really drives me during the buildout at Krux and it came down to two simple things: 

(a) I love working with people and helping them achieve milestones that they didn’t think they were capable of, and 

(b) I genuinely enjoy solving hard problems, especially in the data+AI space. 

Enter super{set} Fund I and the 16 companies we’ve started out of super{set} in the last four years.

So why super{set} Fund II? Why now? Fund II brings our committed capital in active funds to $176M and comes on the heels of super{set}’s first exit: the acquisition of leading data collaboration company Habu for $200 million in January 2024. At the same time, the world has tilted in our favor - the data+AI companies we’ve specialized in since inception are now the hot topic du jour, (thankfully) crowding out the crypto mania. We’re revved up to kick-off Fund II with the next wave of investment.

Learn About Our VECTOR Program

We only build data+AI companies.

Every company we start at super{set}, and every company we will start with Fund II, stems from our technical prowess in data+AI. We are product-led and believe in proprietary technical advantage stemming from data management. Our companies generate, capture, orchestrate, analyze, and activate data to transform a data source into a data use. 

In 2024, it doesn’t seem unusual for a new fund to be focused on AI - but don’t get it twisted, the last thing we are doing is following a trend. We’ve built companies with data+AI at the core for the last 25 years leading to multiple exits in the category. The trend has followed us.

Learn About Our Process

We never die in the same ditch twice.

Taking a step back, I’m astonished to realize that I’ve founded over sixteen companies in the last four years. The exponential growth is astounding—as is the corresponding learning curve that comes with it. Each company is its own beast and brings its own challenges, but we now steer clear of obstacles and pain points that I wish I had known about in my first start-up.

Fundamentally, at super{set} we view company building as a reproducible craft where accumulating knowledge across startups produces stronger outcomes. This is a deliberate process and we manifest our craft in our playbooks. Some playbooks are practical, applied knowledge: like shared infrastructure (one of our companies, Kapstan, shows how practical wisdom can become a new startup opportunity). Other playbooks are strategic: such as how to approach product-led go-to-market.  Tying it all together are shared mindsets, mantras, and culture.

Ultimately, what’s valuable about the super{set} startup studio isn’t the shared office space and back-office accounting, it’s the culture of collaboration and shared insights that ties our portfolio together during the roughest, earliest stages of company building. At super{set}, you never build alone.

See Our Portfolio

We invest in people, not pedigree.

At super{set}, we talk a lot about joy. Building an early-stage company is mind-numbingly, hair-pullingly, and teeth-grindingly hard. So why do it? For us, the answer always comes down to the exceptional people that we build alongside.

Ask any founder what their #1 challenge is, and they will tell you that hiring is the hardest thing they do. It’s the same for us, but since we’ve done so much of it over the last four years, we have our own proprietary method for unearthing who has the right mix of grit, humility, organized thinking, and clock speed to co-found alongside us. We write a People Memo for every hire, helping us look past pedigree and find co-founders, whether they are from Big Tech or another startup.

Learn About Co-founding With Us

We’ve already started - join us.

Fund II is still only the beginning. We’ve started two companies already, and have a bunch of “boring but bountiful” ideas in the pipeline. I’m exhilarated at the fantastic opportunities emerging in the data+AI space and thrilled we have this new round of capital to power super{set} forward.

Want to get involved with us at super{set}? Here are three ways:

• Join us at a meetup! We have regular meetups at our San Francisco headquarters, in addition to global meetups such as one we just had in Bangalore. Follow our calendar here: https://lu.ma/superset-studio 

• Join a portfolio company! We have open roles from every company in our portfolio aggregated at careers.superset.com -  if you don’t see an open role now, scroll down the page and input your email address to get alerts.

• Become a co-founder! We’re launching a new way to become a co-founder - introducing super{set} VECTOR, a 12-week launchpad for technical product leaders to co-explore company creation opportunities rooted in AI alongside super{set}. Learn more and apply at superset.com/vector

Now, let’s build.

Vivek

P.S. - Here’s our amazing coverage in Tech Crunch!

However, startups have a comparative advantage if you optimize for growth and learning. It’s not that one won’t grow or learn in big tech; the velocity of personal growth in startups is 10x faster.

The choice is up to you, but personally, I’d take the high-velocity route, with the learning and development it brings, any day of the week. In my career choices, I’ve bet on personal growth and found that startups have the edge. That’s a bet I’ve made not just once but again and again in my career.

Subscribe now

Interviewing with a startup? Here’s my advice

Before you hop on an interview with me to work at one of super{set}’s early-stage startups, here are a few pieces of advice for you to consider:

1.Come prepared with questions. Think about the impact you want to have.

I always make it a point to leave time in interviews for the candidates to ask me questions.  I always appreciate it when candidates ask me about the hard problems that are still to be solved at the company they are interviewing for.  Ask me about what makes these problems hard, what solutions have been explored, and most importantly, what role you can (or will) play in solving these problems!

2.There is no right path. Have an idea about your ideal.

Not just an idea about your preference for big tech versus startups, but other vectors: location, the problem being solved, the size of the team, B2B vs. B2C, etc. You won’t be able to learn and grow if the role is missing something important to you. Don’t over-idealize the supposed glamor of the entrepreneur because that hype doesn’t match the reality - be honest about what’s important and what’s not to guide your path. 

3.People and culture are deal breakers. Bet on the people before betting on the product.

If a role checks all your boxes, but you don’t like the people or the context in which you’re working, you won’t be successful. That’s why we spend much time at super{set} thinking about our performance culture. It’s that simple, but you’d be amazed how many people lose sight of this.

Subscribe now

4.Startups are built to solve a market need. Think problems, not product.

Sometimes, I notice people enamored with a particular sector - yesterday, it was Crypto, today it is Generative AI. But the fact is, we build startups in response to markets and customers. As a builder, what should excite you is the nature of the problem facing the end customer and how you can solve it through technology. I saw this first-hand at Rapt - if I had over-idealized supply chain tech, I wouldn’t have made it through our crazy pivot to ad tech that we had to make to address a more urgent market need.

5.There’s no place to hide in a startup. Everyone earns their keep.

In startups, you’re either doing the thing or aren’t. You can’t skate by and wait until the following performance review. A high velocity of personal growth is only achieved through a high velocity of output: things don’t just happen to you: You make them so.

Share

6.Ask ‘So what?’. Horizontally scale yourself.

I love this metaphor of “horizontally scaling yourself,” which means taking the engineering concept of horizontal vs. vertical scaling and applying the same thought process to one’s career. Meaning, think about adjacent areas to your role - like marketing, product management, and even putting yourself in your customer's shoes. Ask the profound why, what, and so what behind the work. In Big Tech, you’ll never get to spread your wings and peek over on someone else’s patch. In a startup, the pace and limited resources demand that you horizontally scale and grow accordingly.

7.Experience can trump cash. Accept a fair deal.

Finally, the point that made me write this piece in the first place: the cash compensation that a startup offers you will be less than you can earn in big tech. Don’t let this leave a bad taste in your mouth after you receive an offer - nobody is pulling the wool over your eyes, at least in a company with a fair and transparent culture. On a risk-adjusted basis considering equity, the startup deal is probably comparable to a big tech company because markets are efficient. But think of how you value the other variables—namely, growth and learning—and ensure they factor into your comparison.

Share

Join Us in Early Stage Company Building

Working at a startup can be the best investment you will ever make.  While big tech is cutting compensation in this downturn, there is a great luxury of being focused on building at a startup, where the leverage from being in the early stage, ready to ride the next wave of investment and growth, supercharges our collective prospects as entrepreneurs. 

While there is no one-size-fits-all “right path,” if you sleep on my advice and wake up tomorrow morning still eager to build in the early stage, come and join us at a super{set} company.

Readers, what is your interview advice? What pitfalls and traps should you avoid, and what other best practices should you adopt? Let me know in the comments below!

🔗 Links Worth A Read

• OpenAI should be copying journalists’ principles, not just their content - The Ethical Tech Project’s Chair Jennie Baird (Chief Product Officer at BBC) makes a compelling case in Fortune for what tech can learn from journalism when it comes to ethical approaches to AI.

• Knowing When To Quit: Winners sometimes quit and quitters sometimes win - My co-founder Tom Chavez has 3 succinct pieces of advice for when a startup should burn the boats and continue on, and when a founder should shut it down.

• May Habib via LinkedIn: "PSA — the trough of disillusionment for generative AI is finally here!" - Where do you think we are at in the AI Hype Cycle?

• The State of AI Infrastructure at Scale 2024 - good reading for a better understanding of the backbone of AI's evolution - infra.

PS: here’s how NOT to interview 😉

“How would I describe myself? Three words: hardworking, alpha male, jackhammer."

I always tell them, “The answer to the can question is almost always yes, but first, tell me, what problem are you trying to solve?”

Entrepreneurship isn't about solving problems for the problem's sake. It's about creatively solving the right problems.

As engineers, our default mode is to match problems with solutions. We like to dive in headfirst, concoct a remedy, and be on our way. It could be a quick fix or a bit of hackery. It could be an elegant innovation that will stand the test of time. Either way, that effort won’t matter if you aren’t solving the right problem.

Startups, above all, are challenged by people milling around and solving the wrong problem to the detriment of the larger mission. I see a few reasons for why this happens and why it is such a problem in what I call “The Three Paradoxes:”

Subscribe now

1.) The Paradox of Efficiency.

A startup’s maximizing function is to use its resources smartly to reach the next stage of product-market fit and growth. Even well-funded startups are ticking time bombs beholden to the Power Law1 - so solving problems that enable the company’s success is crucially important!

Unfortunately, sometimes startup employees try to efficiently tackle problems as they appear, rather than focusing on the highest impact problems. Ask, “What problem are we trying to solve?” and you might see that you are in a death-by-a-thousand-cuts situation of bug squashing versus prioritizing what matters.

2.) The Paradox of Ambiguity.

Startups are, by their very nature, incredibly ambiguous. Maybe it is a new market with an emerging customer base that doesn’t quite know what they need yet. Maybe it’s a novel application of technology in the solution, and we don’t quite know how the pieces fit together yet. Maybe it’s everything, everywhere, all at once.

When startup employees see ambiguity, sometimes the default reaction is action. Sometimes, bias for action is the correct response! When faced with many uncertain choices, picking one first and knocking it off the list is entirely rational. The paradox is that, within ambiguity, are we solving the right set of problems to turn ambiguity into clarity?

Going deep into building a complete solution for a customer challenge that might reflect a niche circumstance, not the market as a whole, is an example of solving the wrong problem within ambiguity. Ask, “Why did we choose this path?” and you might see that it’s the wrong problem in the first place.

Share

3.) The Paradox of Creativity.

All startups think of themselves as creative. Most are merely clever.

Engineers often default to clever. A clever person takes the constraints of a specific problem and devises a solution that works. But when you aren’t solving the right problem, this leads to solutions in search of a problem. If you discover this too late in your startup’s journey, you are dead in the water.

Creativity is more than clever input maximization: it is taking on a new perspective to understand the contours of the customer you are serving. Paradoxically, creativity requires space to approach a problem obliquely rather than head-on. How often have you banged your head against your keyboard at the office, only to have a moment of enlightenment later on in the shower after a run?

Ask, “What is the impact on the end-user and customer?” and you will be farther along in solving the right problem creatively than most.

Software is complex. Customers and people are complex. Building a company is complex. Life is complex. The more that we hyper-focus on the how—getting it done, going from point A to point B—the more we lose sight of the forest for the trees, potentially solve the wrong problem, and miss out on the creative breakthroughs, deep insights, and more that just come if you can state what the problem is…

🔗 Links Worth A Read

• Why We Built A System of AI Agents to Automate E2E Testing - “the next major wave of innovation will come from task-specific LLM-based systems that connect and orchestrate multiple expert models and techniques to achieve a certain goal”

• The Folly of Hunting Enterprise Whales - In enterprise SaaS, which would you rather have - 1 deal for $500k, or 10 deals for $50k each?

• Why visa reforms benefit not just California’s tech sector but the economy overall - Read my Op-Ed in CalMatters calling for immigration reform

• Large Language Models: A Survey - a thorough comparison of the LLMs currently on the market

• Ethan Aaron via LinkedIn “Here's what's happened with Snowflake, and where it's going” - I couldn't have summarized the whole Snowflake situation better

PS: here’s a great example of Simpson’s Paradox 😉

“You’re damned if you do and damned if you don’t.”