At one point, we organised rugby tickets for a customer. I think the original tickets went to an address where they couldn’t get them before the match. One of the support agents got two more tickets and got into a taxi across Dublin trying to find the customer. That agent never had any permission to book a taxi or leave the office or go and deliver the tickets. She did it because she felt it was the right thing to do. When she came back, we were delighted and celebrated what she’d done. She understood that putting customers first and going the extra mile was what we stood for.

Last week I was in a meeting about AI in customer support and I started trying to work out exactly what we are automating away. In the meeting everyone was rushing to the conclusion that we can reduce headcount by leveraging more AI. Just because we can do something doesn’t always mean it’s a good idea. Yes I know bots are cheaper, faster and always on, never take breaks and they handle the boring stuff freeing up us humans to be more creative. That’s the pitch, and for boring or easy tickets it is mostly true. I’m perfectly happy to ask an AI bot how to find my statements or reset my password as I don’t need a person for that and I don’t want to wait for one either.

But the best support is often when someone uses common sense and decides that following the normal process is the wrong thing to do in the situation. This takes common sense and also takes some courage. I’m not sure how you can ever build that into an AI bot.

There’s no way companies will give AI agents the permission to use common sense. Well, for a start they don’t have any and it would be extremely risky to try giving AI bots too much wriggle room especially for regulated businesses.

AI agents follow pre-defined rules and best practices. In banking and payments, these rules exist for a good reason to stop fraud and protect customers. You don’t want an AI agent deciding that one of those rules is getting in the way of a good customer experience. This would give bad actors an opportunity to exploit the AI bot. Try explaining to the regulator that your AI bot thought it was a good idea to leak account details to strangers.

AI agents will have no trouble answering structured questions but when it comes to situations where judgement is needed, thats a different story. That doesn’t mean a person needs to deal with every single question. It just means there needs to be a very smart orchestration layer between what support is routed to humans and what support is routed to AI agents.

My worry is human support will become a luxury product. A status symbol for VIP and premium customers. Klarna’s CEO even called human customer service a VIP thing.

I expect both worlds will coexist, but I’d imagine the one that gets most traction is the simplistic status version. It’s an easy sell inside any company to justify why elite customers need human support. Plus, it’s easy to rank customers by revenue and status. But I believe companies that are more customer oriented and have a bit of a rebellious spirit will look for more sophisticated ways to route by key human moments rather than doing it only on customer status.

Give the login question to the bot and the frozen account call to a person, regardless of how much that person spends with you. Whoever cracks that will be using humans at the right moments, rather than trying to put a person behind every interaction.

I’m more than happy to get agent support for a lot of tasks. But there are certain times where, if I feel my account has been hacked or something serious has happened, I really want to speak to someone who is competent and knows what they are doing. Someone with common sense ideally.

P.S. This week’s soundtrack is Human by The Killers.

Now I was fully paying attention but not to the meeting.

My heart started racing. I tried to see if I could down grade on the product dashboard but it has no such option so I quickly emailed the saas vendor telling them what had happened. Then radio silence. I messaged them on X. Still nothing. Then I decided to contact my bank, and after being put on hold for 30 mins they said I needed to raise a dispute. They shared the form and I had to fill it out, It was like something from the 1980s but I was glad, it was at least a way of getting my money back.

Two months later I got my money back. It was slow, painful, annoying, frustrating and far more work than it should have ever been. But who cares I got my money back. If I had done this transaction with stablecoins, I would’ve lost $30k and I’d be now living homeless.

The reason businesses are excited by stablecoins is the very fact that there’s no chargeback process and the stablecoin transaction fees are far lower than standard Visa or Mastercard card transactions. A stablecoin transfer doesn’t have a chargeback policy and once the transaction is completed, that’s it, it’s done. Finito.

So who the hell pays when a stablecoin transaction goes wrong? If you put in the same protections around stablecoins for consumer payments, then all the Stablecoin benefits get eaten away. This is why I believe stablecoin payments are a bad fit for many everyday purchases. But there’s a way for both the businesses and customers to both win.

The customer can pay by card while stablecoins move the money behind the scenes. This approach makes far more sense to me. The buyer gets a familiar checkout and dispute process while businesses get faster settlements.

But there are use cases where stablecoin payments make sense. If the local currency is losing value or cross border payments barely work. Then in these situations a stablecoin payment that is final and awkward can still be better than the alternative.

Stablecoins could also become the default currency for machines and micro payments. The average rate for card payments is 3% plus a few cent. That makes a 1 cent card payment ridiculous. Tiny purchases forces a person to stop and decide if it’s worth it. The attention costs more than the purchase.

A company can fund a stablecoin wallet, set limits, approve sellers, and allow software to pay for data or computing without a person authorising each cent.

Software can also make a $30k mistake much faster than I did.

I knew my entire team had been running personal subs for years so it was time to setup a team subscription. A day or two later I got sent some social posts and a blog to review and sign off. One had the phrase seamless payments in it. Which I hate as everyone in payments over uses it and I’ve told this team specifically not to use it. The blog said we were quietly innovating. Yes mga cringe. Every AI model now spits out the word quietly for some reason. It’s up there with load-bearing and em dashes.

My first reaction wasn’t even about the AI. It was you know the brand guidelines so why didn’t you just fix this before sharing it?

I’m not sure exactly how it happened because the team did use the right briefing with the AI. They are aware of the AI guidelines, but I think they just assumed that whatever the team AI came back with had to be the right answer or more likely, I felt that they just didn’t apply the same brain power to the reviewing as they would normally if they’d written posts themselves.

This got me thinking.

We needed some way to centralise the quality, but not centralise every decision within the team. Centralising every decision would drive everyone nuts.

Centralising the decision means one person or one committee approves everything. Nobody wants that level of straight jacket. And every founder’s right to be scared of that as it’s slower than doing nothing. Plus it kills morale and the will to live. What I actually mean is the company owns the truth.

New roles will fall out of this. Nobody had a digital marketing manager or social media manager job title in 2004. They arrived a few years later, once someone had to actually own it and the CEO needed to know who to blame when it went wrong. I think the same happens here with jobs such as an AI content controller appearing or even something like a truth seeker, whose actual job is getting what’s in people’s heads onto a page before it disappears when they leave.

And by truth I mean the stuff that should be written down and not just live in whoever’s head that’s been there the longest. I mean the brand guidelines, product information, customer insights and all other meta data that describes every aspect of the company.

Centralising control means the company owns the truth and if centralise all this company information, then you can create agents that act as quality controllers. But what stays individual is the judgement. You know the call in the moment such as deciding whether a Sam Altman joke lands or understanding what is happening culturally. That’s the human part.

Get it right though, and who knows, maybe you actually fix the thing that’s broken at every company I’ve worked at.

But centralising control at a company level is going to be extremely challenging. Ask anyone who has worked in digital transformation. The technology is the easy part, but dealing with messy humans sends some people to early retirement. That’s why I think it’s best to start this at department level. If each department head owns their own department’s memory first, before anyone tries to solve the whole company, you’d get most of the value. Start small and don’t try to boil the ocean.

P.S. This week’s soundtrack “Everything In Its Right Place” by Radiohead.

Most hotels removed their doormen years ago as the math to replace them always made sense. You get to save around $50k a year per door, give or take. An automated sensor never calls in sick and works 24/7. But nobody wrote a memo about what was being lost, because on paper nothing was being lost. A salary line went to zero and the spreadsheet looked great. But the spreadsheet has no clue of the value the doorman brings to the hotel. The doorman reads situations, brings a warmth and humour no automated system could dream of but who cares if you ca save some money right? This is why the quality of service in many industries has dropped significantly. It’s because unless you can attach a number to it in a spreadsheet, it’s very difficult to defend in boardrooms or company meetings when accountants and CFOs are challenging it.

Rory Sutherland wrote about this years ago. He called it the Doorman Fallacy And it’s all about how many organisations measure and over optimise the wrong items, leading to an inferior experience or a loss of trust.

The first time I watched it happen, I was working on Ireland’s first digital bank. Two-factor authentication then meant a small device that looked like a pocket calculator. From a product point of view it was friction. I hated it. It was a horrible experience and added cost. I wanted it gone. Then we asked customers what they thought, and they told us, clearly and repeatedly, that they liked it being annoying. This was their savings account. Most of them put money in at the start of the month and pulled it out by the end. The device gave them a few seconds to think. Many even lost it and never looked for a replacement because it meant they could never access their savings, so their savings kept accumulating. The device was making it harder for people to spend their savings. We ended up running marketing campaigns that made this annoying calculator device a feature, as it placed money at arm’s length.

Events play a big role in fintech and B2B. The attribution is tricky and never straightforward to measure especially for products with long buying cycles. Almost no deal could be tracked back to a stand without some serious pseudoscience. This made it easy for finance teams to always question the value of events. But what we kept finding was that businesses we’d met at events came back 6-12 months later, after a number of conversations that started because they’d seen us there. The act of investing to be present was in itself a trust signal that built credibility.

I also experienced this when I worked in real estate in Dubai. We tried to build a platform to sell property online. The goal was to speed up the buying lifecycle. It sounded amazing on paper and it also looked good on a slide. But it was dumb and it didn’t work at full ticket sizes. People didn’t click buy on a house. No one was willing to potentially spend their life savings or a large chunk of their savings on a property that they hadn’t visited or spoken to someone knowledgeable about. The version that did work was a hybrid, a deposit online, with a window to come and see the place in person before committing. We had to put some friction back in.

You’re probably in meetings this week getting a demo of a new voice AI bot with a generic voice that will replace the friendly human onboarding call or the generic writing automation that will take care of new marketing blog posts. I’ve even sat in a meeting where someone proposed AI to interview all new candidates. Some of those teams are going to find out, in 18 months, what was actually keeping the customer there or what was attracting top talent.

P.S. My writing soundtrack The Doors - Break On Through

Subscribe now

OpenClaw started as a side project by Peter Steinberger, once it started to get popular Peter got dragged through a trademark fight, renamed it twice, then it’s popularity exploded after it was featured on some tech podcasts such as TBPN.

I set it up on an EC2 server in Feb because I thought it would be an interesting chatbot. I called it Frank and I spent the next month figuring out what to do with it. But you need to manage your expectations as this product is pretty raw still and my week one is total frustration. By month one I was doing some experimenting and by the end of month three I kind of knew what I actually wanted my agent to do.

Every morning at 8am Openclaw sends me morning briefing on Telegram with an update on Liverpool fixtures, injury news, MENA fintech headlines, what happened in AI overnight, and an FPL deadline reminder if one’s coming. Plus anything interesting it thinks I should know about, such as Project Hail Mary being in the cinema. Frank also has a vector database with everything I’ve given it such as my daily notes, my profile and interests, project updates, some video or meeting transcripts. When I ask about anything it searches that first. For the first month I mostly ignored the briefings. Honestly, it was just another thing pinging me. I already get enough Slack notifications from work. Then it flagged something I’d totally missed. It connected a transcript I’d forgotten I saved to a project I was mid-way through and pointed out a gap I’d missed. I hadn’t asked it to look, that’s the bit that’s actually new and this is what makes OpenClaw far more useful than a bast chatbot.

My relationship with APIs is the same as my relationship with plumbing. I understand how it works until it doesn’t. But the amazing thing using an agent like OpenClaw is you can ask it to install, fix, or update its own APIs. So this is a product that fixes and upgrades itself as you’re using it. OpenClaw has full access to your computer so Whatever you can do in the computer, OpenClock can do the same. For example it can reads files, writes files, runs code, calls APIs, browses the web and lots more.

You don’t need to be an engineer to run this. But you do need to think like one as it breaks often. One of my cron jobs hallucinated a Liverpool vs Bayern Munich fixture for three straight days. Then when I looked into it, it wasn’t actually OpenClaw’s fault. There was something weird about that fixture, as when I tried it on other AI models, they had the same hallucination. A Google Calendar integration never properly worked But after a couple hours of debugging, I eventually got there. One tip I can give you Let’s create two agents, and therefore if anything breaks on your main agent, you can use the other agent to fix or debug it. Plus, you can also paste the errors into Claude or ChatGPT and get them to explain what needs to be done.

So right now it’s messy to set up and it breaks more than it should. That’ll change. Soon these things will be one-click installs. But if you like testing things before they’re ready, you’ll have fun with OpenClaw. Right now I’m teaching Frank what films I watch and what I’m reading. Plus what I want to learn next. It’s starting to know me. I think that’s the bit that could compounds. The part where it just starts getting context and noticing connections in your life and work that otherwise might never surface.

P.S. My writing soundtrack Madonna Into The Groove (Live Aid 1985)

And they could…That’s the annoying part. They produced words quickly and felt empowered. Like anyone in that situation, I felt a bit threatened and impostor syndrome quickly kicks in. Am I going to be exposed? Will the HR team tell the founder that we don’t need marketing anymore? But this fear quickly disappeared once I’d seen the new job descriptions they had produced with AI. It was total crap, totally cheesy, cringy, and sounded the same as every other major corporate brand entity.

AI had given them the ability to make copy but it hadn’t given them the ability to know if the copy was any good.

Earlier in my career I made a TV ad in Slovenia for a digital bank in Ireland that featured a homeless guy. It’s a long story, but it kind of was a lesson in what can go wrong when you don’t hire a specialist. And this guy ended up homeless. I thought this ad was really clever and hilarious. It tested well even.

The problem wasn’t that I couldn’t make an ad. Clearly I could as the other two ads I created did really well. The problem was that I didn’t yet know enough to see what when something had crossed a line.

But as soon as it went live, the phones in the office went mental. Every homeless charity in Ireland rang in, totally disgusted and looking back I don’t blame them. I learned a valuable lesson the expensive way, in public, in about two hours. I don’t want to think about how much that ad cost to create.

My guilty pleasure is Downton Abbey. If you’ve ever watched the show, there are two different worlds happening in parallel. There’s the world upstairs, living in luxury, dealing with life’s trivialities. Then there’s the world downstairs, the domestic service, working, trying to scratch out a living. Domestic service around 1900 was one of the biggest employers in the UK. This included butlers, cooks, laundresses, housemaids and whole economies were built on the fact some jobs just needed a person with specific skills doing them.

None of them thought a machine was going to come along and take part of their job. If you’d asked a housemaid what threatened her livelihood, she’d probably have imagined another person who could do it cheaper or faster.

Then the washing machine arrived.

But the washing machine didn’t convince everyone else in the house that they suddenly knew how to be a housemaid.

AI is different.

A washing machine did one thing better than a person. What’s arriving now can have a go at almost any knowledge job. That creates a different problem. It doesn’t only threaten the person doing the job, it makes everyone around them think they might be able to do it too.

Copywriters and accountants keep getting named as the exposed ones. Maybe they are. But I think this is bigger and stranger than a list of jobs disappearing.

Even I catch myself thinking I could code a website or mark up a set of accounts.

And that’s the trap. With AI I can get surprisingly far. Far enough that I can start confusing access to the output with possession of the skill. But I’m nowhere near a skilled developer or accountant. I don’t know what I don’t know. And because the output can look convincing, I will not even realise when something is wrong.

If I can fall for that, plenty of people with even less experience will too.

Here’s the split I think actually opens up. People with experience get better because they know enough to catch AI when it’s wrong. Inexperienced people get faster. But speed can look a lot like competence when the output is polished. They haven’t built the eye yet. They haven’t made enough mistakes to know where the bodies are buried. They haven’t had the career defining failed TV ad.

And AI lets them skip straight past the years when that judgement would normally have been built.

I don’t know how this plays out. Nobody does. All you can do is place a bet, and mine is this. When producing the work gets cheap, knowing what good looks like becomes more valuable. So I wouldn’t go narrower. AI is frighteningly good at narrow. Go broad instead. Learn some philosophy, design, economics, code, copy, whatever you can stand to learn. Stay genuinely deep in one or two things, but know enough about the rest to ask good questions and spot BS. Because AI can make you feel competent at almost anything. The useful skill might be knowing when you’re not.

The challenge was no one really knew how it worked. I had to spend hours every day trying to figure it out by consuming the latest insights from related forums and blog posts. I studied both black hat and white hat tactics. Blackhat tactics were cheat codes for getting ranked. People in the early days would hide keywords as background text. For example, if the website had a white background, people would add keywords as white font. Kinda like how people are keyword stuffing CVs today, so AI detectors choose their CV.

AI sits between the business and the buyer. This means when someone is asking ChatGPT or Claude what to buy or which vendor to consider. The AI will research a set of options and bring back a shortlist. The person may make the final call, but businesses who are not on this shortlist are invisible and will never be considered. It’s the same as not being on the first page on Google search when search was one of the main drivers of business.

OpenAI is already asking merchants for structured product feeds so ChatGPT can understand what they sell and keep prices current. Google is building protocols that allow agents to move through discovery, buying and payment.

I work in payments, so of course my mind went straight to the digital transaction. Google has built a payments protocol that lets people give an agent a budget and rules for what it can buy. .

An AI system has to work out what you sell, where you operate, how you compare and whether there is proof behind the big claims you make. It may compare your website with case studies, reviews and what other companies say about you. It needs to figure out what is legit and what is just vaporware. Because if the recommendations that come back in the chat are low quality, it’s like Google returning search results that were low quality. It’s bad for business.

We will still need to deeply understand the human side of marketing. In fact this will grow in importance as the logical science side of marketing will also be machine driven. Understanding customer psychology, culture, story and all the strange reasons why people make buying is how many business will differentiate themselves from bland machine driven competitors. But someone will also need to understand how AI systems work.

I don’t think every marketer needs to become an AI techie. But you will need to be fluent in AI.

I’d imagine the machine side of marketing starts in a similar messy way to SEO, spread across many functions like product marketing, data and some early adopter that notices the problem first. Knowing marketing, we will probably invent a terrible acronym and act like it has existed for years.

What they almost never see is what happens when they leave the room.

The side conversations.
The doubt.
The quiet “let’s park this.”
The Slack message that just says “thoughts?” with no follow-up.

Loretta lived in that room for ten years at Google evaluating vendor partnerships. She saw over 100 pitches. Maybe 10 survived. The other 90 probably still think the demo went well.

When I read her piece, it felt familiar. It maps onto the same patterns I keep coming back to here.

Can they repeat what you do.
Can they prove it.
What happens when it breaks.
And what happens after the meeting.

There’s a story in here about a vendor who bypassed the actual decision maker three times to reach someone more senior. It went about as well as you’d expect. Don’t skim that part.

I’ll hand it over to Loretta.

Subscribe now

For years, I was the gatekeeper.

Startups would pitch me their SaaS tools, creative agencies, measurement platforms, all hoping to get access to Google’s app developer ecosystem. I decided whether they got to work with our customers or got politely archived.

Out of 100+ partnership pitches I reviewed, maybe 10 made it through. The gap between success and failure? It wasn’t the product. It was how they approached the sale.

If you’re trying to crack an enterprise deal with Google or similar corporations, here’s what actually works.

The org chart problem

One of the biggest challenges shared with me by my partners is how complex it is to navigate the organisation.

Unlike startups, where you have a very flat culture and people can easily connect you with the person in charge, at corporations like Google, it can be difficult to navigate, even internally.

To give a very simple example, at Google, there are entirely different organisations for Google Cloud, Google Play, YouTube, Google Ads, etc.; and within each organisation, they have their own sales, analysts, research, partnerships, marketing, and finance teams.

In my own role, I could easily have 100+ stakeholders just internally. Instead of talking to whoever is working in the company and hoping that they can connect you with a person who could help, what you need to do is really map your product into the organisation and see which teams or departments are going to be your best allies.

Easier said than done.

Here are some quick tips:

• Read the company’s statement to understand their OpEx and organisational structure

• Research whom your competitors interact with through press releases, LinkedIn updates, etc.

• Check with your industry connections to see if they can share insights

Your goal is to gather enough information about the organisation and how it’s structured, so that you can identify which teams are most interested in your products. Reach out to one team at a time, because with each interaction, the knowledge you have gained might actually influence your research afterwards.

• Research LinkedIn to find people in certain positions or teams. Note their locations, identify the reporting line, and try to map out the org chart.

• Review LinkedIn and job descriptions to gain more context about what each role does.

• Finally, reach out and talk to people, a lot of them. See if they can help you paint the remaining picture.

Finding the real decision maker

After narrowing your target to the correct teams, the next step is to identify the decision makers. Note that it’s plural, because in a lot of situations, signing an enterprise deal requires several teams’ collaboration:

• Users: who are actually going to use the product

• Budget owner (POC): the person owning all these external deals, subscriptions, and partnerships

• Budget approver: the person and team that advise on the budget of the team as a whole, controlling the budget cycle, and approving budget requests, etc.

In a very typical scenario, you will need to speak to all the parties above. Connect with the users on different occasions to gauge their demand for the product, and get an ally who can then help you make a case to the person-in-charge; who, hopefully, will be keen to collaborate, and help you fast-track the necessary administrative processes with the pocket owner.

A quick tip because a lot of people get this wrong: the decision maker is not always at headquarters.

I had a vendor bypass me repeatedly to reach my director in Americas, when I am actually the budget owner for global partnerships. After the third bypass, despite positive product feedback from our teams, we never signed.

If you can’t navigate our organisation respectfully during sales, how could you handle the partnership?

Understand who owns the decision, and work with them, not around them.

What the winning pitches did differently

Identifying the owners is not going to guarantee you the deal unless you have the right pitch, and nailing that is a lot more challenging than you might have imagined.

I’ve interacted with different vendors, and here’s how the ones that got the deals did it:

• Start with questions: understand the team (users’) goals, challenges, and day-to-day, the tools (ie competitors) they use, and team size & organisation chart, etc.

• Explain how the product could solve the users’ problems: how it could save their time, improve workflow, etc. You are only able to make concrete examples when you have learnt enough about your users

• Resolve their concerns: even when a product is demonstrating proven value to the team, the POC often has some concerns about its credibility, or its experience in working with big corporations. This is essential for the partner to ease these concerns before they are asked: your existing relationships, if any, with the company; enterprise customer cases; experience working with their competitors (extremely important); whether you have international exposure (offices, teams, customers)

• Put together a tailored trial for the users: very rarely can a corporation sign an enterprise deal without trying. Propose a trial, get help from the POC to share and communicate it to the power users. Host training sessions for power users to help them understand why your product is important. Monitor trial activity metrics and identify insights, reach out to the users so you can provide support, answer feedback, and gauge interest. Your goal is to prove how your product can deliver the value you promise, make a case, and have the users advocate for you.

Why timing kills more deals than product

Okay, let’s say you’ve nailed all of the above. It doesn’t mean that you can sign the deal right now. The thing is, every organisation or team has a very different finance cycle.

For my team, we determined the ultimate budgets for the broader team at the beginning of the year. That often meant we might not have a lot of leeway to make in-year adjustments. In your communication with the POC, understand the budget cycle. This can give you a lot of clarity regarding what budget they can give and when they can give it.

Ideally, you want to come in at the right timing so you can help the POC put together a budget request to the budget owner (such as the finance or sales operations teams) before the next annual budget cycle is approved.

However, if the conversation happens mid-year, you can explore whether you could start with a smaller deal by tapping into unused budget from the current year. This allows you to establish a footprint with the hope of expanding into a larger deal for the following year. This can be a good strategy because for most enterprises, renewing a deal requires significantly fewer layers of approval than approving an entirely new deal.

All these circumstances will then influence the product proposal which you put together for the POC and the subsequent decision and budget approval.

As you might have realised, the company POC needs to be your best friend because they’re the person that determines whether they want to go through the additional administrative processes for you, which often takes up extra time for them.

After the deal (or the rejection)

Let’s say you have done everything you can. Chances are either the company will happily sign the deal with you and bring you on board as their first enterprise partner, or there is a possibility that they like the product but not enough to actually pay for the services right now. So, what do you do next?

If you have signed the deal, maintain regular contact with the POC, even if the relationship is officially passed over to the account management team. The POC is very likely to provide updates, such as changes in team structure, layoffs, etc., which you want to be the first to know so that you have extra time to prepare for the next renewal cycle.

Also, if your product has helped the POC successfully prove their work, reach out to them and see if they can connect you with other users in the company. An internal advocate with a pre-existing deal makes it much easier to expand your product subscription to new teams or departments.

However, if your POC is not able to sign the deal with you right now, ask questions to understand the real reason behind it. Is it because of current budget constraints, product limitations, lack of enterprise customer endorsement, or is it just not the right team? Continue to warm the lead and wait for a time when they might be able to convert. Meanwhile, continue to explore other teams that could be a better fit given the new information you’ve obtained about this company.

If the issue is about the budget cycle, help identify the right time to re-engage so you can ensure they put you in the first request. The goal is to continue cultivating relationships with enterprises through different touchpoints. You need to ensure your product remains top of mind, while slowly helping them develop the required trust before they are finally ready to onboard.

Enterprise sales is hard.

For each company, you’re dealing with 10+ stakeholders, 6-12 month cycles, and layers of bureaucracy. Most vendors give up because they underestimate the time investment or overestimate their product’s appeal.

But here’s what I learned watching the ones who succeeded: they treated it like a partnership from day one. They genuinely helped our teams solve problems, respected our processes, and played the long game.

The companies that cracked Google weren’t necessarily the ones with the best product. They were the ones who built trust, understood our constraints, and made our lives easier.

About Loretta

I spent a decade at Google working across digital marketing, strategic partnerships, and app development with thousands of companies worldwide. I helped thousands of companies globally from scrappy startups to Fortune 500s grow their businesses, and I am a passionate mentor at Google for Startups, Techstars etc.

Now I help bootstrap founders and marketers cut through the noise with practical, proven strategies through my newsletterMarketing Proven. I also offer mentorship sessions for founders growing their businesses, navigating enterprise sales, or simply workers struggling with their careers.

Early in my career, I ran a digital consultancy. We pitched for a large tender with an international company. We had two meetings and they loved us. Loved our ideas and our approach. The vibe in the room was electric and if I’m honest we were already spending the tender money in our heads. A week later, we found out we didn’t get the work.

When I asked why, they told me they loved what we did. They loved our strategy. But they worried we were too small for them. Too inexperienced but I think they really meant too young. They were worried we might not be around long enough to support them. Might not have the experience to handle the challenges of an account their size. Every one of those concerns could have been addressed if we had one more meeting with them. But we never got the chance. The first two meetings went so well, we didn’t think we needed to address these concerns. But the decision happened without us in the room.

There’s a massive gap between a great meeting and a closed deal. Most founders I’ve worked with obsess over the pitch. Making sure they showcase a perfect demo and hours practicing what happens in the room when they’re presenting.

But most complex deals don’t die in the meeting. They die in the meeting you’re not invited to. The meeting where your champion has to explain to their boss or their boss’s boss, why they’re recommending you. The one where someone asks an awkward question your champion can’t answer and the one where the person who could answer it decides to stay silent instead of speaking up.

74% of B2B buying teams experience unhealthy conflict during decisions. People getting overruled by decision-makers who weren’t even in your meeting. And 51% of customers who are willing to buy are not willing to stand up for you internally. Liking you is free but fighting for you is not free. Fighting for you is risky politically. This means half of your champions won’t fight for you, they like you and they want you to win. But when the meeting gets a bit tricky or heated, they stay quiet.

I’ve been on the other side of this too. At one company, I was building a digital arm inside a traditional business. The tech stack was legacy. Really old. I wanted to move to cloud-based tools. Salesforce Marketing Cloud, HubSpot, Mutiny. Tools that would let us do sophisticated lead generation, data analysis, proper funnel optimisation.The IT team wanted to keep the non-cloud version of Salesforce. It was next to impossible to integrate any third party tools with. It was hard to get the data we needed. But it was what they knew. They had vested interests. They wanted to keep doing things the way they’d always done them. They didn’t want extra work.

To change anything, I needed CEO level approval. And I was stuck between a rock and a hard place. The company wanted results on day one. Showing results on day two. But the strategic work of upgrading the stack needed time. Time I didn’t have. Political capital I hadn’t built.

In hindsight, I should have been more aggressive. More persuasive in showing the benefit of migrating faster. But I was the champion for those tools, and I couldn’t close the internal sale. Many of the third-party vendors I was speaking to couldn’t understand why. It’s hard to understand unless you’re on the inside. That’s what it feels like to be your own champion who can’t sell internally and if you’re selling to enterprises, that’s what your champion feels like too.

Most people get champions wrong. A champion who loves your product and a champion who’ll risk their neck for it are two very different people. Don;t be naive as champions don’t fight for you, they fight for themselves. They need to believe that getting you on board is in their best interest. That your solution makes them look good and protects their job. Maybe it even advances their career.

It’s not charity. It’s not about how much they liked your slick demo or banter. They need to believe if I don’t get this vendor or solution, my job is at risk. That’s a much higher bar than I think these folks are great.

Only 44% of those no-decisions are because the buyer prefers the status quo. The other 56%? Indecision. Fear. The buyer wants to change, but can’t pull the trigger, they’re not scared of missing out.But plenty got fired for one that didn’t so the safe choice is no choice.

These are the questions you should ask yourself before leaving any pitch

Can they repeat what you do in one sentence?

Do they have proof they can point to?

Can they answer the fear question?

The big question you need to ask yourself is whether you’ve armed your champion to win the one meeting you’re not in.

My writing soundtrack this week is “End of the Beginning“ by Djo.

A newsletter about going places before there’s a map.

I didn’t know that when I started it. It took me over a year to figure out what I was doing. Honestly, I almost quit twice.

uncharted is simple. I write about what happens when technology changes faster than people do and what that means for people trying to build, sell, and decide in the real world. What’s working. What isn’t. What nobody wants to say out loud.

Don't expect polished takes, those are fairytales. This is something else.

Thank you for showing up. For the replies that made me rethink things. For forwarding the uncomfortable ones to people who needed to hear them. For not unsubscribing when I wrote something dumb.

Agentic Vibe Marketing Is Already Here was my biggest post this year. One smart marketer can now outwork a team of five mids. Most companies still haven’t noticed.

Compound Engineering With Claude Code showed what AI-native engineering looks like in the hands of a pro. Two engineers, six agents, features from voice commands. Very few know how to hire or manage for this yet.

Every Startup Needs a Designated Hater remains a favorite. Someone who rips bad ideas before they escape. Every team needs one.

If My Work Looks Simple, I’m Replaceable hit on something nobody says out loud. People make work look complicated to stay important. This is job security through controlled complexity.

When to Hire Humans vs Hand It to AI touched a nerve I wasn’t expecting. Big Tech cut grad hiring by 25%. Banks slashed junior roles. Nobody has a clean answer. Including me.

You Can’t Prompt Your Way to Production said what the AI hype machine won’t. If you don’t understand your AI-generated code, you’re building something that breaks when paying customers show up.

AI is Stealing Everyone’s Voice was about staying human when it’s getting easier not to. Still the thing I care about most.

Next year won’t be any clearer. Good. That’s where I work best.

See you out there.

Martin

P.S. If there’s a topic you want me to tackle in 2026, reply to this email. I read everything.

Gregory Kennedy has one of the cleanest frameworks I’ve seen for fixing this. He is a fractional CMO in the San Francisco startup scene, with experience at InMobi, NextRoll and Sojern, and we have been trading notes on messy go to market problems for a while. He also claims Irish roots. I’ll believe it when I see the paperwork.

Over to Gregory.

A founder’s guide to marketing budgeting

Founders always ask me

How much should I spend on marketing?

That is the wrong question.

The better question is

What actually matters at our stage?

I have seen pre seed startups spend $5,000 a month on Google Ads when they did not even have a functional sign up page. I have watched seed companies hire a full time content person before they knew what content they needed, never mind what converted. I have also seen a Series A startup run an expensive outdoor campaign aimed at developers when the company could not explain the product clearly in a 30 minute Zoom call.

Your budget is not only about how much you spend. It is about what you are trying to prove and where the next dollar has the best chance of helping.

These figures are starting points, not rules. The detailed spreadsheet lets you adapt them to your business.

Pre seed at $10,000 a month

At pre seed, you are not really doing marketing. You are running science experiments with a credit card. Your job is to find out whether anyone wants what you are building before you run out of money.

A sample split looks like this:

• Content marketing: 40%, or $4,000
• Digital foundation: 25%, or $2,500
• Lead generation and events: 20%, or $2,000
• Brand development: 15%, or $1,500

The aim is to get the website and tracking working, sharpen the message, create useful content and run small tests. You are not trying to look like a large company. You are trying to learn which customers care, what they respond to and where your assumptions are wrong.

Seed at $35,000 a month

You have raised some money. Congratulations. Now comes the hard part: spending it so it has an impact.

At seed, you have enough traction to be dangerous. The focus shifts towards amplifying the messages and channels that show early promise.

A sample split is:

• Growth marketing: 45%, or $15,700
• Content marketing: 21%, or $7,300
• Marketing technology: 13%, or $4,500
• Digital foundation: 11%, or $4,000
• Brand development: 10%, or $3,500

This is where paid media, events, newsletters, partnerships and referral experiments can start doing more work. But the budget should amplify evidence, not compensate for confusion. More distribution will not rescue a message customers do not understand.

Series A $100K/month (or building the machine)

At Series A, you have real traction. The job is to operationalise go to market and build systems, processes and predictability around what already works.

A sample split is:

• Growth marketing: 45%, or $45,000
• Brand development: 20%, or $20,000
• Content marketing: 20%, or $20,000
• Marketing operations: 15%, or $15,000

This is where you invest more seriously in paid acquisition, search, brand, content, automation, CRM, analytics and testing. You are building a machine, but it should be based on real customer behaviour rather than a spreadsheet that looked convincing at the board meeting.

These budgets are not rigid rules

The best founders I work with know there is no prize for following a template precisely. They use it as a starting point, then adapt it based on what is working.

Maybe most of the budget should go into paid advertising. Maybe your market moves through events, technical communities or hackathons. Maybe the website and messaging need more work before you increase distribution.

The point is to understand what matters now, invest in the fundamentals and make every dollar count.

Martin again.

The framework is Gregory’s. The underlying truth is one I keep seeing too. Most early stage companies have a clarity problem dressed up as a budget problem.

At pre seed, money should help you learn. At seed, it should help you test whether early traction can be repeated. At Series A, it should help turn evidence into a system.

A larger budget can make a good strategy move faster. It can also make confusion considerably more expensive.

Big thanks to Gregory for putting this together. Follow him on X or subscribe to Vibe Your SaaS.

See you out there.

Martin

If you want more from Gregory, follow him on X or subscribe to Vibe Your SaaS.

I can spot it in the first 10 minutes of the dreaded Monday morning standup. Someone’s waffling about why something simple took three days. Honestly, they’re not stupid. They’re scared.

Most roles don’t have clear metrics, if any metrics at all. So people deconstruct existing processes, rebuild them in more complex ways, and present that complexity as proof of value. What’s worse is managers buy it.

If my work looks simple, I’m replaceable. If it looks complicated, I’m essential.

So people add unnecessary steps. They create dependencies. They become the one-eyed visionary in the land of the blind, the only person who understands the complex system they just built. This is job security through controlled complexity.

I’ve watched it destroy momentum and the will to live over and over.

It’s not malice. It’s fear. Nobody wants to be the person whose job looks easy because easy jobs get cut first. So they make it look hard.

The marketing manager could update the site in 10 minutes but writes a three-page brief. The PM schedules a workshop instead of making a call. The analyst builds a model to prove what they already know. All symptoms of the same disease.

The problem isn’t people. It’s what the system rewards.

Performance reviews celebrate completed projects, not killed ones. More dashboards. More process. More noise. Complexity becomes career insurance.

So people build layers. More process. More dashboards. More meetings. Not to make things better, but to make themselves harder to remove. They are products of the system.

Clarity is dangerous. It pinpoints who’s actually moving the needle and who’s just orbiting around it. Complexity keeps everyone safe.

In most companies, complexity equals job security and that’s rational behavior in a broken system.

Once you see it, you can’t unsee it.

How to spot it in your own company

Marketing gives a tour of the stack. Slides, logos, arrows everywhere. It looks like a nuclear control room. Then you ask which tool created revenue last month?

Silence.

There’s probably no right answer, but the silence highlights the thought didn’t even cross their mind. It was never the objective.

The stack keeps growing. The results don’t. But at least, the integrations map looks impressive in the deck.

Then there’s the dashboard nobody opens. You know the one. The attribution model nobody understands. Months of work that change nothing.

I’ve watched a fintech startup spend four months building dashboards with 200+ metrics. Interactive filters. Color codes. Drill-downs. The execs stood up and clapped.

Nobody opened it again.

They needed 3 numbers, revenue, churn, CAC. Four months of work. Zero decisions made. The analytics team still got promoted. In most companies, effort is the product. The actual product is just proof you were busy.

Ask someone to explain their impact in one sentence. If they need a slide deck, they don’t have impact. They have activity. Activity looks like a job. Impact looks like you did less than you did. So people choose activity.

Same story in product.

We tested 40+ button shades. We never fixed onboarding. This is perfect optimisation of the wrong problem.

Everyone’s working hard but nobody’s making progress.

Simplicity doesn’t look sophisticated. And nobody gets fired for looking busy, they get fired for looking idle. So you get dashboards. Reports. Meetings. A full calendar that hides an empty impact.

Does any of it change what we do tomorrow? Of course not.

I’ve seen companies with 3 revenue streams and 15 ways to measure them. The measurement becomes the work.

Complexity is how companies hide failure. The more broken the system, the fancier the charts. Every mess hides behind a prettier dashboard.

The saddest part is most of the people doing this mean well. They think showing how simple it could be makes them disposable.

But in startups, the people who make things simpler are the ones everyone remembers.

Why complexity wins, even when it loses

Complexity is visible.

You can show the org chart. The process map. The dashboard. Look at all this work.

Simplicity is invisible. “We track 3 metrics now instead of 50.” Sounds like you did less work. Even if those 3 metrics actually drive decisions and the 50 didn’t.

Busy is far safer.

Knowing what matters requires being right.

So how do you spot the people who’ve figured this out?

Mastery is knowing what to ignore

The data team that shows 3 numbers instead of 50. The marketer who kills 10 campaigns to focus on one channel. The analyst who matches emails instead of building multi-touch attribution.

Mastery is making it look easy. Which means people undervalue it.

That’s the tax on being good at your job, you make it look like there was no job to do.

Good companies recognise this tax and refuse to charge it. They promote the person who deleted useless metrics, not the one who added them. They reward the designer who removed three steps from onboarding, not the one who redesigned the same page four times.

Your north star

If your work is easy to explain, people assume it’s easy to do. If your work is complex to explain, people assume it’s valuable.

This is totally backwards. But it’s also reality and it’s why teams default to complexity.

The hardest part about simplicity is it leaves you nowhere to hide. No dashboards to point to. No process maps to walk through. No busy work to mistake for progress.

Just results. Or the lack of them. Most people can’t handle that level of clarity.

Which is exactly why the people who can are the ones you want to keep.

The people who make things simpler are rare.

Don’t punish them for it.

Martin

P.S. If you’ve seen this pattern in your own team (or caught yourself doing it), reply and tell me. I’m curious how common this actually is.

Find me on X

This week’s track is Experience by Ludovico Einaudi.

“Respice post te. Hominem te esse memento. Memento mori.”

meaning

“Look behind you. Remember you are a man. Remember you will die”

2,000 years ago they already understood that success makes people stupid.

In 1628, Sweden launched the most expensive warship ever built. The Vasa. It sank in 20 minutes. Too many cannons, too tall, and every single person involved in the build knew the design was unstable. Nobody told the king.

Nearly four hundred years later, McDonald’s CEO shot a video about the Big Arch that was so bad it felt like a parody. Sam Altman took a public jab at Anthropic that made him look rattled, not confident.

In both cases, someone in the building knew. They just didn’t say anything.

This is possibly the oldest problem in management.

And we keep trying to fix it with the wrong thing. More process. More approvals. More committees. None of that works because the problem was never process. The problem is that telling your boss their idea is bad feels like a career decision.

Most companies die from the inside out. From bad judgment disguised as creativity. From the “clever” ad nobody asked for. From the rebrand that made customers wonder if you’d lost the plot. Not from competitors. Not from the market. From the room going quiet when it shouldn’t have.

I’ve been in rooms like that and the pattern is always the same. The boss talks. Everyone nods because disagreeing doesn’t feel like an option.

That’s how dumb ideas survive long enough to go live.

Sometimes it’s not even fear.

You’ve spent three weeks on something. You hate it now, but killing it means admitting you were wrong. So you push it out anyway and hope nobody notices. Or it’s just conformity. You don’t want to be the difficult one. So you smile, pretend to like it, hit publish, and watch something you knew was bad land in front of customers.

Most of what gets called “shipping fast” is actually just nobody having the guts to kill something slow.

The higher you climb as a founder, the less truth you hear. And most companies have no structural fix for that.

You end up trapped in your own certainty, mistaking polite nods for consensus.

In 1970, Avis CEO Robert Townsend proposed a simple idea.

Hire someone whose entire job is to tell the CEO what is actually broken. Not a committee. A person.

He was half joking. He was also completely right.

Every company needs what I’d call a designated hater.

One person with explicit permission to say “this is bad, please stop” before it ships.

Not a “brand guardian” with a 100 slide deck. One person who says what the room is thinking and then goes back to sipping their flat white.

I’ve worked in companies that had this person, whether the title existed or not. The ones where they left or got managed out shipped noticeably worse work within a few months.

The person who says “wait, prove it” before you waste 3 months on something nobody wanted.

People love talking about psychological safety. Usually what they mean is everyone being nice to each other. That’s comfort. Actual safety is knowing you can say “this doesn’t work” without it showing up in your performance review.

Every founder or CEO thinks they want honesty until they get it.

People assume the person who says no kills morale.

I’ve watched the opposite happen.

Watching something stupid go live when everyone in the room knew it was stupid, and knowing you could have stopped it. That’s what actually kills morale.

The Romans gave someone the job of saying “you’re not as good as you think.”

Most companies still haven’t.

This week’s track is Fashion by David Bowie.

“Men wanted for hazardous journey. Low wages, bitter cold, long months of complete darkness, constant danger, safe return doubtful. Honour and recognition in case of success.”

Legend says Ernest Shackleton recruited for his 1914 Antarctic expedition with an advert promising low wages, bitter cold, months of darkness and a doubtful return. Historians have searched newspaper archives without finding convincing evidence that it ever ran. Shackleton did write that almost 5,000 people applied after he announced the expedition, but the famous wording may be the best recruitment copy nobody actually wrote.

Startup founders love it anyway.

It turns low pay, long hours and uncertainty into a test of character. Put the word mission around a difficult employment deal and suddenly the missing processes feel heroic.

The useful lesson is not to sell the suffering. It is to tell the truth.

Most startup job ads are fan fiction. Not malicious fiction, but something more dangerous. Aspirational fiction. Founders describe the company they are hoping to build, not the one they are running today. The ad promises clear ownership, fast decisions and meaningful autonomy. The new hire arrives and finds priorities changing after every customer call, three people owning the same decision and a founder who considers delegation an interesting theory.

The mismatch attracts people to the imagined company. Then, when they struggle inside the real one, the company decides they could not handle startup life.

Sometimes that is true.

Sometimes they accepted a different job.

A good job ad should explain the trade before asking someone to make it. Say that priorities will change. Say that the person will have to build processes while delivering the work. Say where the founder remains involved, which decisions the hire can make and what support does not yet exist.

But honesty has to work in both directions.

When you describe the pressure, explain why it is worth taking. What authority comes with the responsibility? What will the person learn? Who will coach them? What resources are committed? What does success look like after 90 days?

When the salary is below market, say so. Explain the equity in numbers rather than adjectives. Meaningful equity has funded many imaginary retirements.

Expect chaos is an unfinished sentence.

There is a more credible Shackleton lesson. The expedition physicist Reginald James later recalled being asked about his teeth, varicose veins and whether he could sing. Shackleton was choosing people who might have to live together under extreme pressure, so technical ability was only part of the job.

You should not copy his interview questions unless your startup has taken an unexpected turn towards polar exploration. But you should hire for the conditions people will actually face.

Ask candidates about a time the brief changed halfway through. Ask what they did when a senior leader rejected work they believed was right. Ask how they created structure when none existed. Then tell them how often those situations happen in your company.

An interview should allow both sides to assess the same reality.

This is where brutal honesty often goes wrong. Some founders use it as edgy branding for poor management. They boast about weekend work, low salaries and impossible targets as if exhaustion proves ambition.

Hardship is not the product.

Working late once because a customer system failed is part of responsibility. Working late every week because nobody can prioritise is a management problem. When production failures happen often enough to feature in the job ad, perhaps the next hire should be an infrastructure engineer.

The aim is not to attract people who enjoy suffering. It is to attract people who understand the constraints, believe the opportunity justifies them and have the experience to operate well inside them.

Tell candidates what is broken. Tell them what they will own. Tell them what the company can offer now, rather than what might exist after the next funding round. A smaller number of informed applicants is better than hundreds of people responding to a company that lives only in the founder’s head.

See you out there.

Martin

I thought I had a decent handle on it.

Then I watched how the engineering team at Every worked. Two engineers were running six agents, turning spoken feature ideas into research, implementation plans, working code, tests, and documentation. Features seemed to materialise from voice commands while the humans moved between agents, reviewed decisions, and kept the whole thing pointed in roughly the right direction.

That was when I realised I had misunderstood the important part. I was using Claude Code as a faster pair of hands. Every was building an engineering system around it. Kieran Klaassen, a senior engineer at Every who works on its email product Cora, calls this approach compound engineering.

The phrase sounds like something an AI consultant would put on a slide immediately before charging you $40k, but the idea behind it is useful.

Each piece of work should make the next piece of work easier.

Most people use AI to complete a task. They ask for code, review the output, fix what is wrong, and move on. When the next task begins, the agent often starts with the same incomplete context and makes many of the same mistakes.

Compound engineering treats each correction as reusable knowledge. The feature gets built, but the lesson also gets recorded in the project instructions, tests, documentation, or review process.

The work does not merely get finished. The system gets slightly better at doing similar work again.

Subscribe now

What compound engineering actually means

Imagine Claude builds a new login flow using the wrong authentication pattern.

You catch the mistake, explain the correct approach, and ask it to rebuild the feature. In a normal AI workflow, the problem is fixed and everyone moves on with their lives. The next agent session may make exactly the same mistake because it has no memory of what happened.

In a compound workflow, the correction becomes part of the engineering system. The team documents the correct authentication pattern, adds an automated check, updates the project instructions, or creates a reusable workflow that future agents can follow.

The bug gets fixed once. The entire category of mistake becomes harder to repeat.

That is where the compounding happens.

Every did not arrive at this system neatly. The team moved through Copilot, Cursor, Windsurf, and other tools, hitting limits as the technology evolved. Claude Code became important because it could take on a larger unit of work. It could inspect the codebase, edit files, run commands, work with Git, test the result, and keep going without waiting for someone to approve every line.

The visible breakthrough was the ability to run several agents at once. One could work on the front end while another handled the back end. A third could write tests and another could update documentation.

But opening six terminals is not the same as managing six productive agents. Without a good plan, you have simply created six confident interns with access to production code.

Why Claude Code feels different

The first generation of AI coding tools mostly helped developers complete the line in front of them. They suggested functions, found errors, and saved time on repetitive work.

Claude Code can be given responsibility for a much larger outcome. Instead of asking it to write a function, you can ask it to investigate a problem, understand how the existing system works, make changes across several files, run the tests, and prepare the work for review.

The unit of delegation has changed.

That creates real leverage, but it also creates a much larger blast radius. An autocomplete tool might suggest one bad line. An autonomous agent can make a bad architectural assumption, spread it across twenty files, update the tests to approve it, and then write a beautifully structured explanation of why everything went so well.

The output often looks convincing long before it is correct.

That is why the engineer’s role does not disappear. It moves towards the parts of engineering that were always hardest to automate. Understanding the real problem. Choosing the architecture. Spotting hidden risks. Knowing which compromises are acceptable. Recognising when something technically works but creates a terrible product.

Claude can handle more implementation. The engineer still decides whether the feature deserves to exist, what could break, and what good looks like.

The typing may shrink while the responsibility expands.

The stack is not the advantage

It is tempting to turn this into another tool list.

Buy Claude Code Max. Install a voice tool. Open six terminals. Connect GitHub. Download someone’s prompt library. Announce on LinkedIn that you are now a 100x engineer.

The actual setup is surprisingly ordinary.

Claude Code, isolated workspaces, strong project instructions, useful tests, and perhaps voice input if speaking is faster than typing for you.

The advantage comes from the operating discipline around those tools. The team has to define work clearly, separate tasks properly, review output carefully, and capture what it learns. Without that discipline, more agents create more noise. With it, a small number of capable engineers can produce an extraordinary amount of work.

This is what makes the Every example so interesting. The story is not simply that two engineers can produce the output of fifteen. The deeper point is that engineering output is beginning to separate from engineering headcount.

For decades, companies estimated capacity by counting people. Ten engineers could normally build more than two because ten people had more hands, more hours, and more total coding ability.

Agents weaken that relationship. Two engineers with strong judgment and a well designed AI system may now outperform a much larger team that still works in a traditional way.

Most companies have no idea how to plan around that.

Hiring has not caught up

Technical hiring still places enormous weight on how well someone writes code by hand. Candidates are asked to solve abstract problems on a whiteboard or produce clean code while several strangers silently watch them through a video call.

Those skills still tell you something. They no longer tell you enough.

An engineer working effectively with agents needs to know how to frame a problem, provide the right context, divide the work, evaluate competing approaches, and detect plausible nonsense. They also need the taste to reject output that passes every test but still makes the product worse.

A more useful interview would give the candidate a real but safe codebase and a small feature to build using whatever AI tools they normally use. Ask them to explain the plan before they begin. Watch what they delegate, what they keep for themselves, and what questions they ask.

Then ask them to show one piece of agent output they rejected and explain why. Finally, see whether they leave behind an instruction, test, or document that makes the next similar task easier.

The final code matters, but the process reveals far more.

Did they understand the problem before building?

Did they spot the dangerous assumptions?

Did they know when the agent was bluffing?

Did they leave the engineering system stronger than they found it?

That begins to look more like the job these people will actually be doing.

The junior engineer problem

There is an uncomfortable consequence hiding inside all this productivity.

Founders will inevitably look at a senior engineer supervising five agents and see labour arbitrage. If one experienced person can produce the work of an entire team, why keep hiring junior developers?

That may save money in the next budget cycle. It may also create a serious talent problem several years later.

Junior engineers were never only cheap people who completed routine tasks. Those tasks were how they learned. They developed judgment by writing code, breaking things, reviewing mistakes, debugging systems, and gradually understanding why senior engineers made certain decisions.

If agents take over most of that implementation work, companies need a new way to create experienced engineers. You cannot expect someone to review complex AI generated systems if they never had the opportunity to build and break simpler systems themselves.

“No junior developer required” sounds clever in a product demo.

It is a terrible workforce strategy.

The companies that solve this apprenticeship problem will have a major advantage. They will use agents to increase productivity while still giving less experienced engineers enough real responsibility to develop judgment.

The companies that stop hiring juniors altogether may eventually discover that they also stopped producing seniors.

This reaches beyond engineering

The same change is already moving through marketing, design, analysis, and operations.

A marketer can ask AI for 50 campaign ideas in a few minutes. That output used to feel valuable because producing 50 ideas took time. Now the ideas themselves are abundant, and most of them sound like they were written by an enthusiastic committee that has never met a customer.

The valuable marketer builds a system that understands the company’s voice, customer objections, competitive position, legal constraints, previous performance, and the difference between a bold idea and something that will get everyone invited to an emergency meeting.

The same is true in design. Generating screens becomes easier, while deciding which experience makes sense remains difficult. Analysts can produce reports faster, but someone still has to question the data, examine the assumptions, and recognise when a beautiful chart is confidently explaining something that never happened.

First drafts are becoming abundant.

Coherence is still expensive.

The people who benefit most from AI will not simply be those who generate the highest volume of work. They will be the ones who build systems that produce consistent work, learn from mistakes, and remain aligned with what the company is actually trying to do.

What a great engineer looks like now

The argument about whether AI will replace engineers is already too simplistic.

It will replace parts of engineering work. Routine implementation, boilerplate code, documentation, testing, and basic debugging are becoming easier to delegate. Some roles will shrink and some teams will get smaller.

At the same time, good judgment becomes more valuable because one person’s decisions can now be executed across several agents at once. An engineer who understands architecture, product, risk, and context can direct far more work than before.

That is the real lesson from Every.

Two engineers producing the work of fifteen is not only a productivity story. It is a warning that the way companies hire, manage, and evaluate engineers is falling behind the way software is now being built.

I started using Claude Code as a coding tool. I now see it as something closer to a management layer for software creation. The strongest engineers will know how to create clear systems, teach agents how the company works, review output ruthlessly, and recognise when speed is making the wrong problem worse.

The best engineer in the room may soon write the least code.

They will still carry the most responsibility.

See you out there.

Martin

p.s. this is a must-watch

It’s closer to astrology.

I’ve run $20M+ in performance marketing campaigns where every click had to earn its keep. And I’ve run brand campaigns where you’re flying blind and hoping for signs.

The stuff I couldn’t measure often worked the best.

But most marketers still worship dashboards. We’ve built million-dollar strategies off metrics that wouldn’t pass a school science project.

Dashboards don’t lie. They just leave out nearly everything that matters.

The fairytale is simple, track every click and you’ll know what works. If it’s not in the data, it didn’t happen.

Most sharing is invisible.

Dark social accounts for roughly 77% of all content sharing, and none of it shows up in your analytics. iOS 14.5 gutted tracking so badly that the attribution numbers most marketers rely on are essentially made up. Your dashboard shows you what’s easy to count, not what’s true.

And that might be the best thing that’s happened to marketing in a decade.

Because once obsessive attribution dies, you have to ask better questions. Do people remember you? Are they talking about you? Are they coming back on their own, without a discount code dragging them in?

That’s marketing. The dashboard just showed you the part that was easy to measure.

I believe most attribution is fiction.

But pretending you don’t need any numbers is stupid too.

Try walking into a board meeting with no data, just vibes.

Let me know how that goes.

You need numbers.

The mistake is treating them as truth instead of what they are: a rough signal. A hunch dressed up in a spreadsheet.

If you starve your brand just because it’s hard to measure, you’re killing demand. I’ve seen this happen. A campaign is working, people are talking, pipeline is filling up, but the dashboard can’t prove the connection. So someone pulls the budget. Six months later the pipeline dries up and nobody connects the dots.

Ryanair gets this. Their TikTok content is chaotic, unfiltered, and impossible to tie directly to bookings. But they estimate earned media value and compare it against paid spend. The CFO gets a number. The number is imperfect. The brand keeps growing.

Attribution’s a hunch. Treat it like one.

The honest approach is incrementality testing. Instead of asking “which channel gets credit,” you ask “did this channel actually change anything?” Run a channel for two weeks. Pause it for two weeks. Measure the difference. That’s your real impact. It doesn’t need cookies, pixels, or creepy tracking. It just needs patience and a willingness to find out that some of your spend is doing nothing.

Most marketers would rather not know. The dashboard lets you tell a story. Incrementality testing might wreck it.

First-party data is the only data that matters now. If you don’t own the relationship, you don’t own the result. Attribution models built on third-party data are dead. Email lists, direct traffic, customer accounts, branded search. These are your actual signals. They’re messy and incomplete, but at least they’re yours.

Tracking is worse. Budgets are tighter. Every founder I talk to secretly knows that half their attribution report is a well-designed lie.

I still use dashboards. Of course I do. But I’ve stopped treating them like gospel. The problem was never the dashboards. It was how much we believed them.

The best marketing I’ve done couldn’t be measured at the time. It showed up later. Repeat customers. Word of mouth. Deals that closed because someone remembered something they couldn’t trace back to a campaign.

If you need a pixel to prove you did your job, you probably didn’t.

Until next time

Martin

P.S. this week’s track is Enjoy The Silence by Depeche mode

It hides the blemishes until it runs out.

I’ve spent money both ways. $20M+ in performance campaigns where every click had to earn its keep. And brand campaigns where you’re flying blind and hoping for signs. The stuff I couldn’t measure often worked the best. But the stuff that taught me the most was the times when there was no money to waste.

The fairytale is that more money means better decisions.

Proper market research before you ship. A/B testing every variation. Hiring the perfect cultural fit. Building the brand that authentically represents your values.

Sounds responsible.

In practice, it’s expensive procrastination.

When you’ve got $5k left, you can’t A/B test your feelings. User research gets very simple very fast. Build for who’ll pay you tomorrow. Not some imaginary persona named Ryan who “likes artisanal coffee and SaaS dashboards.”

You ship the ugly thing that works instead of perfecting something nobody wants. You hire whoever ships fast, not whoever nails the culture fit interview. Payroll’s a hell of a project manager.

Constraints kill the BS.

CB Insights looked at 76 startups that raised at least $50 million before failing. The average total funding was $180.7 million. Most of that money was burned right before collapse. They failed because the cash let them avoid finding out what was real.

This tracks with what researchers have found about constraints and creativity. Too few constraints and you get waste. Too many and you stifle action. Somewhere in the middle, where you’re forced to be honest about what matters, that’s where the good work happens.

I’m not romanticising being broke. Money is better than no money. Obviously.

But constraints don’t hold you back from building a real business. They stop you from pretending you’re building one when it’s actually an expensive hobby.

Before spending a dollar, there’s one question worth asking does this directly solve a customer problem someone will pay for? If the answer isn’t an immediate yes, cut it. No brand guidelines. No team retreats. No perfect office setup. Just customer problems and solutions.

When money is tight, you talk to customers. Not in a “let’s schedule some user research” way. In a “talk to ten people this week or we’re dead” way. Funded teams schedule research. Broke teams are already in the room, because they have no choice. There’s a difference.

Perfection is just procrastination wearing designer clothes. If you can’t ship a working version in 48 to 72 hours, you’re overthinking it. The version that ships and gets feedback beats the version that’s still being polished in a Figma file nobody asked for.

A funded startup can spend six months debating product direction. A bootstrapped team has six weeks or they’re done. One of them is going to find out much sooner whether anyone actually wants what they’re making.

Next time you wish for more funding, ask yourself would it buy progress, or just buy you more time to avoid the hard questions?

No fairytales required.

Martin

The org chart improves immediately. The problem often does not.

Sometimes the company needs a full time executive. Sometimes it needs three months of senior judgement, a few difficult decisions and a system that someone inside the business can continue running. Hiring a permanent leader for a temporary problem can be an expensive way to avoid defining the problem properly.

That is where a fractional executive can work. The best ones arrive with pattern recognition. They have seen the pricing mess, the failed channel, the finance model built on optimism, or the technology decision that will become painful at scale. They can diagnose the issue, challenge the founder and build the first version of what comes next.

Then they can leave before the HR system remembers their birthday.

This works best when the problem has an edge around it. A company may need a finance leader to prepare for a funding round and introduce proper reporting. It may need a marketing leader to sharpen the customer, positioning and channel plan before hiring a team. It may need technical judgement before committing to an architecture that will be expensive to reverse.

In each case, the company is buying experience at the moment it matters most. It is not buying a smaller version of a full time executive.

That distinction gets lost in the excitement around fractional work. The pitch often suggests a company can hire a CMO for one day a week and receive five days of leadership at a discount. It cannot. A fractional executive has less time, context and authority. When the brief is vague, they spend their limited hours attending meetings, collecting opinions and producing a strategy nobody inside the company owns.

Very senior wallpaper is still wallpaper.

Fractional leadership works when the problem is clear, the outcome can be measured and the founder gives the person real access. Someone inside the company must also carry the work after the engagement ends.

Remove that internal owner and the advice usually fades. The deck is sensible. Everyone agrees. Three weeks later, the old decisions return because nobody had the time or authority to make the new ones stick.

This is where full time executives earn their cost. A permanent leader does more than provide clever answers. They recruit the team, manage performance, fight for budget, absorb context, build relationships and live with the consequences of their decisions. They notice the small signals because they are present when those signals appear.

That work cannot always be compressed into ten hours a week.

Full time becomes the better choice when the company needs continuous ownership. The function is central to the business. Decisions happen daily. A team needs leadership. The executive must align people who disagree, make tradeoffs across quarters and remain accountable when the first plan fails.

Fractional arrangements can also become a way to postpone commitment. A company can rotate senior advisers through the business while the same unresolved decisions wait for someone inside to own them.

The opposite mistake is hiring too early. I have seen founders collect executives like Pokémon cards, then wonder why the company burns cash while every decision requires another leadership meeting. Senior people create value when the company has senior problems. A title does not turn confusion into scale.

Before choosing, ask what must be different six months from now. If the answer is a decision, a plan, a system or a successful transition, a fractional executive may fit. If the answer is someone needs to own this function every day, hire full time.

A good fractional executive should know when their own role has expired. Their final contribution may be helping the founder define the permanent job, recruit the right person and leave without creating a dependency.

Fractional executives are not second rate leaders. Full time executives are not bloated luxuries. They solve different shapes of problem.

See you out there.

Martin

I started out as a web dev, but that feels like another life.

Then I became the marketer waiting three weeks for a button change. “Urgent” meant nothing. Every A/B test? Blocked. Every landing page tweak? Delayed.

So I jumped to no-code. Built everything myself. Zapier, Make, Webflow, all of it.

Then Replit dropped AI agents. Cursor followed. Suddenly my dusty 10% of coding knowledge actually mattered again.

But I also hit wall after wall of bugs and crashes. After burning weeks debugging AI-generated spaghetti code, that’s when it hit me.

You can't prompt your way to production.

Vibe coding works. But it’s not magic.

Everyone’s selling the same story “Just describe your idea and AI will build it. No skills needed. Anyone can launch a SaaS in a weekend.”

What they don’t mention is that 82% of developers now use AI for writing code, but 45% say AI is “bad or very bad” at handling complex tasks. GitHub reports 88% productivity gains for developers using AI tools, but those gains are “unevenly distributed.” The biggest winners? Developers who already understood how systems work before they asked AI to write anything.

Cursor hit $100M ARR in under two years. Proof that vibe coding works. But they had 60 people who understood systems. Replit can build a 2D game from a single prompt, but it takes someone who knows debugging to make it production-ready.

The pattern is consistent across every case study I’ve seen. AI amplifies what you already know.

If you understand system architecture, AI becomes a superpower. If you don’t, you’ll spend weeks rebuilding what you thought was done.

Most people building with AI can’t fix their own products when they break. Your customers don’t care that “AI got it wrong.” They see a broken app and a builder who can’t fix it.

Think like a systems architect for your AI built app

You don’t need to become a full-stack developer. But you do need to understand how the pieces fit.

1. Frontend: what users see
   Buttons, pages, screens. What they click, tap, scroll.

2. Backend: the brain
   Handles logic, processes requests, runs the show.

3. Database: the memory
   Where all your user data, settings, and content live.

Vibe coding tools can now write all three. But if you don’t know how they connect? You’ll burn weeks fixing things that never worked properly in the first place.

Don’t learn syntax. Learn how the machine works.

Think in components.
Every feature is just smaller blocks stacked together. A signup flow is a form plus input fields plus submit logic plus error messages.

State management.
How data moves and where it lives. Click a button, update profile, change state, re-render UI.

API basics.
GET reads data. POST creates it. PUT updates it. DELETE removes it.

Debugging.
Stuff breaks. Paste the error into ChatGPT and ask what’s wrong.

Data relationships.
Users have accounts. Accounts store settings. Products connect to orders.

Fast start stack

Once you get these core concepts, here’s the stack I recommend.

Coding Platform (Where You Build)

• Start with: Replit or Lovable (no setup, in-browser)

• Level up with: Cursor (AI + real dev power)

• Others: Lovable, v0.dev

Frontend

• Use = Next.js (React-based, easy to scale)

• Styling = Tailwind + Shadcn (Professional UI, no custom CSS hell)

Authentication

• Use: Clerk (Free to start, $25/month for 10K users)

• Covers everything from logins to social sign-in without the setup headache.

Backend & Database

• Go-to pick: Supabase

• Everything you need without juggling five different services

• Pricing: Free for 500MB, $25/month for production

Email

• Use: Resend (Free for 3k & $20/month for 100K emails)

• Confirmations, Notifications, Invites)

• Simple email setup that just works.

Hosting = where your app lives

• Use: Vercel

• Works great with Next.js & One-click deploy

• Pricing: Free for hobby projects, $20/month for production

Version Control (Save + Track Code)

• Use: Git + GitHub (free)

• Save versions, rollback mistakes, collaborate

Vibe coding = fast iteration + smart systems thinking.

Understand the parts. Use the right tools and you’ll ship something useful.

Learning these fundamentals takes weeks, not minutes.

You'll hit walls. You'll feel like giving up when a "simple" feature breaks everything.

You'll wonder if it's worth it.

The question isn’t whether you can build something with AI. It’s whether you can keep it running when your first hundred customers show up.

No fairytales required.

Martin

Hiring the same team again would have meant rebuilding around work that had already changed.

The usual debate asks whether AI can replace a person. That makes for good conference panels and terrible management decisions. A job is a bundle of tasks, and those tasks do not change at the same speed. AI may handle the research while a person decides what matters. It may draft the proposal while someone else takes responsibility for the promise inside it.

The useful question is where judgement enters the work.

AI is most useful when the task is clear, the output is easy to inspect and a mistake can be reversed before it reaches a customer. Summaries, research briefs, first drafts, routine analysis and content variations fit that description. A capable person can give the system direction, review the result and move much faster than before. That does not make the person optional. It changes what you are paying them to do.

The value moves away from producing every word and towards deciding which words deserve to exist. The human frames the problem, provides context, rejects the plausible answer and notices when the work is technically correct but commercially useless. AI makes production cheaper. It makes weak judgement easier to distribute too.

The line becomes clearer when the work carries consequences. A model can help prepare an enterprise proposal. It cannot sit in the meeting and notice that the procurement objection is really fear about implementation. It can generate a campaign. It cannot own the reputational cost when the message lands badly. It can recommend a decision. It does not have to explain that decision to the board six months later.

Use AI heavily where the work is reversible and reviewable. Hire a person where the company needs context, trust, accountability and decisions under uncertainty.

There is another part of this argument that founders tend to avoid. Junior roles contain plenty of repetitive work, which makes them obvious targets for automation. They are also where people learn how good work is made. The first drafts, basic analyses and customer calls that look inefficient from a spreadsheet are often the apprenticeship that produces future judgement.

Remove every junior task and the economics look excellent for a while. A few years later, the company may wonder why nobody has the experience required to become senior.

Keeping busywork for sentimental reasons solves nothing. Junior roles should change. Give people AI from the start, then move their learning closer to the customer and the decision. Let them review outputs, test assumptions, sit in difficult meetings and understand why one answer works while another merely sounds polished. A junior employee using AI well can become useful faster. AI operating without anyone learning from the work leaves the company with output and no bench.

Before opening a role, break it into its actual tasks. Which parts are predictable? Which mistakes are cheap? Where does the work depend on private company context? Who will judge the output? Who owns the result when it goes wrong?

That last question matters most. When nobody inside the company can tell whether the answer is good, AI is not saving money. It is producing unsupervised risk at impressive speed.

Sometimes the answer will still be a full time hire. The function needs daily ownership, relationships must be built, decisions arrive constantly and someone has to live with the consequences. Sometimes a smaller team with better tools will do more than the old structure. Sometimes the work should disappear rather than be automated or rehired.

When my team changed, I was not choosing between people and software. I was deciding which work still needed to exist, which parts could be handed over and where judgement had become more valuable.

AI will reduce the number of people required for some tasks. It will also make it easier to hollow out the path through which people learn. The mistake is counting the salaries removed without asking who will own the difficult decisions and who is learning to make them next.

That is the hiring decision AI cannot make for you.

See you out there.

Martin