Pablo Fernandez

Category: Business

Business related posts, about running companies, entrepreneurship, etc.

  • Your competitive advantage is your agency

    , , ,

    I see a lot of grandiose statements floating around:

    You will not be replaced by AI, you’ll be replaced by someone using AI.

    AI won’t replace your creativity.

    AI can’t do THIS or THAT.

    AI will never be able to do THIS or THAT.

    And many more.

    My take: maybe. Who knows! LLMs are getting better at an alarming rate and they behave in unexpected ways. They make the simplest mistakes but at the same time, they have solved some of the hardest math problems. This is well know as the jagged edge. The future is extremely hard to predict and every day it’s getting harder.

    But here’s what AI can’t do now and probably won’t for a while: have true agency.

    ChatGPT and Claude do nothing until someone tell them what to do. Same for all LLMs. Even the ones that seem to be always up, like OpenClaw, are just LLMs triggered on a timer. Without the timer, nothing happens.

    In concrete terms, no LLM is waking up one day and deciding to start a company. Some people have experimented with putting an LLM in the CEO seat, but those experiments would not have happened without a human applying their agency first. A human starting the company and prompting an LLM to make the decisions. The agency there belonged to the human, not the LLM.

    So the question is: what do you do when nobody tells you what to do?

    I think people tend to divide into two categories here. Those that wait and those that find something to do. Those that wait may be safe for a while when their specific skills don’t transfer well to an LLM yet. But given enough time, AI will likely acquire all the skills. And then their jobs are at risk.

    Those that find something to do are irreplaceable.

    One expression of that is deciding to start a company. But it shows up everywhere. Deciding to paint a picture or write a poem. Deciding what they’ll be about, what their aesthetics will be. Those decisions will continue to be irreplaceable.

    Well… they’ll be the last thing to be replaced. Because you can only replace them with an entity that is always active (LLMs wake up on a prompt) and that wants things. The moment we have AI that is always active and that wants things, we have bigger problems than our jobs. We’ve created a new species that will eventually be better at everything than us. Hopefully it’ll be friendly.

    The purpose of this post is not to dream or be scared about that future. It’s to convey the fact that deciding to do something with no inputs is the final frontier.

    If you want your job to be safe, find a way for it to not require inputs. If you need a ticket to write code, you are at risk of being replaced by an LLM that can write the code from the ticket. If instead you write the ticket then you are much harder to replace.

    This is why the profession of PM, the Product Manager, is flourishing in the era of AI. Of all the roles at a company is the one that is the most open, the one that has no or very few inputs (finding and deciding what inputs to use is part of the job). All building jobs will be a lot more like a PM in the future (or will have been replaced by an LLM).

    Having that agency to do something when nobody asks sets you apart.

  • The SaaSpocalypse is real, but not for the reasons you think

    , , ,

    SaaS valuations dropped. The narrative is simple: AI lets anyone build anything, so why pay for software? They’re calling it the SaaSpocalypse.

    I think part of it makes sense. But a big part of it doesn’t.

    You don’t buy code, you buy decisions

    When you buy a piece of software you’re not just buying the code. You’re buying the decisions that shaped that code. What to build, what not to build, how to model the domain, which tradeoffs to make. Those decisions were valuable before AI and they are still valuable today.

    This is why I think we’re entering the era of product managers. They are the ones making those decisions. And those decisions require deep domain knowledge. Gaining that domain knowledge is not trivial.

    The Fusion test

    Let me make this concrete. I do 3D design for 3D printing. It’s a hobby, not my life’s work. I use Autodesk Fusion.

    Should I vibe code my own 3D design tool instead?

    Vibe coding something equivalent would cost far more in my time and token spend than the Fusion subscription. But cost isn’t even the main problem. The main problem is that I don’t know the domain.

    Fusion has a specific set of tools for creating 3D designs. It starts with parameterized 2D sketches, from which you build parameterized 3D shapes. Choosing the right set of primitives to manipulate 3D geometry inside a computer — flexible enough to be useful, constrained enough to be learnable — is not trivial. It probably took the industry years of trial and error to get here. I remember the primitive AutoCAD of the 90s. We came a long way. I would have to replicate that trial and error, and that is not cheap.

    Technically, I could ask an AI to clone Fusion. But that is only possible because Fusion exists. You could argue that’s fine, it exists today. But next year, Fusion will have evolved. Without Fusion pushing the domain forward, there is nothing to clone.

    And no matter how good I am at building Fusion with AI, the people at Autodesk would be better at it. They have the same AI tools, but more domain knowledge.

    This generalizes

    Pick any domain and you’ll find the same thing. I wouldn’t want to vibe code my accountancy software, or my email client, or my calendar. Don’t believe me? Think about how you would represent recurring calendar entries where each recurrence can be individually rescheduled. This is not a trivial problem.

    For some tools, the domain is trivial, and the code was the moat. That moat is gone. The drop in valuation for those companies makes sense. But when the moat is decisions, taste, or domain knowledge, it’s still there.

    The real SaaSpocalypse

    The real SaaSpocalypse is not customers vibe coding their own tools instead of buying them. It’s the new startup that vibe codes a competitor.

    The real danger to Autodesk is not me building my own Fusion. It’s someone who dedicates their life to 3D design building a competitor with AI.

    That newcomer would have an AI-friendly codebase from day one. If they invest in keeping it that way, they would add features much faster than Autodesk can on top of decades of tech debt.

    The real SaaSpocalypse is that you can now catch up to and surpass incumbents with less effort, fewer people, less investment. And the incumbents, to fight that off, will need to rebuild their internals to be AI-friendly. At some point — as crazy as it sounds — it might be faster to start from scratch than to evolve an old, tech-debt-laden codebase.

    Buy vs. build still applies

    At work we recently needed a tool. It was going to cost us tens of thousands of dollars. An engineer proposed we vibe code it instead. I seriously considered it. We understand this domain much better than I understand 3D design, and for internal tools you can move fast when security constraints are lighter.

    But it would have taken us 2 to 3 weeks. And during those weeks we would not have been developing our core product. Our unique differentiator is our own product, not a tool we can buy and use off the shelf. Our competitors can buy that same tool and have it running in hours. We shouldn’t spend weeks to get there. Focusing on our core product was the right call.

  • Culture goals should be achievable

    ,
    , , ,

    A company’s overall goals can shape its culture. Take the popular “Employee of the Month” idea, when employees see it as meaningful, it becomes ingrained in the culture and can motivate higher performance.

    But these goals need to be achievable, and sometimes making them achievable is a small matter of phrasing. Let me show you an example. For Canva, where I work, tenure is important. One way to celebrate tenure would be by marking when people joined. For example, a company can choose to give hoodies like this:

    Person wearing a gray hoodie with 'CLASS OF 2023' printed in white on the front, standing against a plain background.

    The problem with this approach is that it would be impossible for someone to improve in this dimension. Anyone that was hired in 2024 will never achieve having been hired in 2023 no matter what they do.

    Instead, Canva celebrates Canvaversary (your anniversary of having joined Canva). It still transmit the same information: “tenure is valuable, tenure is important”. But the big difference is that every time you see someone display a Canvaversary badge with a number bigger than yours, it is a badge that you can acquire by staying around long enough. It is an achievable goal.

    My laptop now has these stickers:

    Stickers on a laptop showing '1' and '2' for Canvaversary celebrations, along with a Pexels logo.

    And I also have this beautiful pin:

    A commemorative Canvaversary badge featuring the text 'Happy Canvaversary' and the number '2', displayed on a blue background with decorative designs.

    Oh, and at the five year mark they make a poster of you. They are really good. I’m looking forward to my 5 years at Canva poster.

  • A better monetization model for LLM applications

    , ,

    Bring your own keys into an affiliate relationship

    I’m starting to observe a problem where a lot of LLM-enhanced apps are starting to pop up. For coding you have Cursor, but now there’s also a terminal called Warp and it costs $15/month. For individuals, consultants, small and even medium sized companies, this isn’t a workable pricing model. All apps were already turning into subscriptions and the cost of LLMs is accelerating that.

    What compounds the problem is that, because everyone feels uncomfortable with the potential surprise high bill of pay-for-what-you-use, many of these apps are charging a single monthly fee. A simple single flat fee, except that the cost of the LLMs is not flat. It grows linear with usage. This means having to throttle the LLM usage to stay within the margin of the flat fee and have a chance at a profit. That means using cheaper models, which yield worse result on average.

    I think this is why when I compare Cursor to Claude Code I find Claude Code to be better: I’m giving Anthropic a lot more money than Cursor. But also, I’m happy with that, because I can use Claude in many other ways, where Cursor is a single-use application.

    I think from now on, for each LLM powered application, I either want to be able to put my own keys in, or have pay-as-you-go with a lot of transparency. When I need it to work, I want it to work well. When I’m not using it, I want it to cost nothing.

    There’s another solution though. LLM providers could have affiliate systems where other companies get a commission for the token usage they generate. Using Warp as an example, Warp wouldn’t ask me for $15/month. Warp would ask me for my Claude API key. Warp would identify all those requests as caused by Warp, and then Anthropic would pay Warp a proportional fee for the usage generated.

    This is a win-win-win: Anthropic gets more token usage (more customer expansion), Warp gets more customers (I’m not paying $15/month, but I would plug in my key), and the user gets to have another LLM tool that otherwise they would not.

  • close up photography of yellow green red and brown plastic cones on white lined surface

    The role of CTO should have no job description

    I’ve been thinking about this one for a while. Imagine you are the CEO of a company and your competitors are getting ahead of you because they started to use ChatGPT to build their tech. You ask the CTO what’s going on and the CTO says “ChatGPT was not on my job description, so I ignored it”. How would you feel as the CEO? Would you think “Ok, fair enough for not putting it in the job description” or would your thoughts be a bit more… colorful?

    The CEO has no job description other than: “Making the company successful“. The CEO is responsible for everything. If tech fails, it is the CEO’s fault, if accounting is done wrong, it is the CEO’s fault, if marketing wastes money, it is the CEO’s fault. The buck stops there for everything.

    The CTO’s role is exactly that, but just the tech part. The job description should be “Do anything and everything in the tech domain to make the company successful“. Are the servers down? It is the CTO’s fault. Marketing doesn’t have the features they need for a campaign, it is the CTO’s fault. Ransomware destroys operations, it is the CTO’s fault. Tech is spending too much money, it is the CTO’s fault. Too much technical debt, too little, not delivering fast enough, having the wrong kind of skills on the devs, devs are unhappy. Again… it all falls on the CTO’s shoulders. At least this is how I take on the role when I carry the title of CTO.

    This means the CTO is responsible for problems that nobody ever assigned to them. That’s one of the reasons this role is hard. And to be able to do such a role, the CTO needs autonomy, information, access, etc.

    Autonomy is achieved through budget authority. The CTO presents a budget to the CEO and CFO, who approve it and then executes on it. Ideally, then the CTO receives periodic updates from the CFO comparing expenses to budgets, and whether the company has the revenue to back that budget up. If the CTO overspends beyond the tech budget, that’s a problem, but if the company shrinks, that’s a problem too. In both cases the CTO should be proactively thinking about how to cut cost and manage the expenses (before hitting a wall, having a massive layoff, etc).

    Information and access is achieved through having a strong exec team. An exec team that is all on the same page. Including a clear vision from the CEO, a clear understanding on how all other departments are achieving their goals, and how tech helps or hinders them.

    So if there is a job description at all, it should be not for the role of the CTO, but rather for the company itself: what it means to achieve, and how it behaves to empower its C-Suite to further their ambitions.

  • red apple

    The ultimate developer perk that’ll let you hire anyone you want

    , ,

    To convince people to come work for you you offer them, aside from compensation, perks. And you try to have better perks than your competitors (other employers). Brainstorming with my friend Justin a few years ago I came up with what I believe is the ultimate perk and since then I’ve been desperatly trying to find a place to deploy it. I haven’t found a place where I feel even comfortable bringing it up, that’s how far I am from deploying it, so I’m sharing it with the world. If I was running my own company, I’d deploy it in an instance, not giving it a second thought.

    This is the perk: every developer gets a confidentiality-bound personal assistant. There wouldn’t be one PA per developer, because they don’t need nor have enough work that can be delegated to keep one person fully occupied. Instead there would be one for all of the developers (or two, or three… or whatever you need depending on how many devs you have).

    First, I don’t think this would be a very expensive perk, because actually delegating work to a PA is a skill that you have to learn and most developers will not have it. Most developers will not know where to start. But most developers will likely enjoy saying “I have a PA” or “I have a secretary”. Having said that, I would actually run courses for the developers to learn to delegate because…

    It’s a perk that pays for itself. You might think you are paying for extra employees or contractors, but your developers are likely the most expensive salaries in your books. So if they can pass a task to someone else, you are saving money, not spending money. Let’s say a developer needs to arrange a call with a vendor to discuss a technical mater. They have to search for the right person, their contact details, go back and forth over emails. Imagine if the developer just tells their PA “Can you arrange that call?” over a Slack message and that’s the end of it. Back to coding!

    Think about making reservations, making doctors appointments, running errands, making phone calls in general (this is why they should be confidential). Developers tend to hate phone calls. Imagine if they could delegate to someone complaining about a flight ticket that got canceled! I once had a coworker who spent half a day on hold while pretending to code.

    It’s a perk that generates retention: you know why Google pays for food, haircuts, laundry, doctors on-site, etc? It’s because that generates a lot of retention. When you quit Google, you not only need a job, you also need to find a hairdresser, a place to clean your clothes and make doctor’s appointments. They treat you like children and you became as dependent as you were on your parents. I’m not exactly sure where the ethical boundary is here, but offering a free PA feels on the good side of things.

    It’s unique: nobody is doing and I bet nobody will start, even after it’s been proven successful. It’s like private offices: we have the studies to prove that developers need silence to focus and yet we cram them in open office buildings. Private offices, and PAs, are for the three-piece suit executives, not for the lowly developer, so it’s not a perk likely to get devalued when everybody picks it up, because nobody will.

    It’s loud. Imagine when the developer is hanging out with other developers and jokingly says

    Have your people call my people to arrange it

    Oh… you don’t have people? I do… this email address and phone number is my PA, just call them… and if you want a PA, come work for us.

    I’d love to try this some day… 

  • woman with hands on her face in front of a laptop

    You should not send rejection emails to job candidates when…

    , ,

    You should not send rejection emails to job candidates when there was no interaction. For example, in the case of rejecting someone just from the application, without a screening call.

    There’s a mantra that good recruiters and hiring managers take on the difficult task of sending rejection emails instead of just ghosting candidates. But I don’t think this should be a black and white decision. Do you agree? Disagree? Please leave a comment with your point of view, I’m intrigued.

    When you had a screening call with the candidate, then the candidate will likely be wondering about the next step, so if the rejection happens at this or any other later stage, then yes, ghosting is extremely rude and you should always send a rejection email and possibly some feedback for the candidate to improve. More on that later.

    If there hasn’t been any interaction, you shouldn’t have your only interaction with the candidate be a rejection. The reason for this is that most of us have, at some point, been desperate, and started applying to lots of jobs hoping that someone would pay us some attention, hoping we may accidentally open a door, and because being homeless is worse that shotgunning job ads. And actually, when the job ads are anonymous bland indistinguishable walls of text, there’s not a lot you can do other than hit apply and move on, so don’t hold it against the candidate.

    The problem is that then this candidate might have hundreds of applications that result in tens of rejections emails. Rejections for roles the candidate forgot about 10 seconds after hitting apply (how long can you remember a non-descript job post about an anonymous company anyway?), so all you are doing by sending the rejection is reminding the candidate that they didn’t get something they forgot they tried to get. When you get tens of these, one after another, it’s emotionally debilitating. It’s no wonder that a candidate might snap at one too many rejections.

    Oh, and about feedback: if you have nothing to say, don’t say anything. If you are going to give feedback, give actionable feedback. Giving someone impossible feedback is a slap in the face. For example, for a few years, I’ve been wanting to have an engineer manager position at a big scale-up or at a big company. When I get rejected and I ask for feedback, most of the time it boils down to “You haven’t been an engineer manager at a big company before”. What am I going to do with that? They might as well tell me “Have you tried being a different person? Have you tried having been born in a different country?” It’s useless and infuriating.

  • Stack of copies of How to Hire and Manage Remote Teams

    I renamed my book on hiring and managing remote teams, it was painful

    ,

    Originally my book was called “Building and Managing Distributed Teams“. I loved that title and people in my social circle loved it too. A friend of mine even told me something along the lines of “I’m so envious I wish I had that title”. And for the two years or so that it took me to write, abandon, restart, abandon again, restart and finally finish the book, I was happy about the title.

    I had three different people ask me what I meant by “distributed”. The first time I ignored it, the third time I panicked.

    As I finished writing the book and it went into proof reading phase, I thought I should try to market it a bit. I’m self publishing, doing everything, including promotion and marketing (hint: I can use your help in getting the word out). During conversations I had three different people ask me what I meant by “distributed”. The first time I ignored it, the third time I panicked.

    I’ve been working from home since the early 2000s. I’ve been building remote/distributed teams and companies since 2011 or so. At the beginning we were called and we called ourselves remote workers. But that soon started to carry a stigma. Companies would have in-office workers and remote workers and remote workers were second class citizens.

    This created a division between being a remote worker and working for a distributed company. The latter was much better.

    The companies that wanted everybody to be remote, the companies that were remote-first, the companies were being remote didn’t mean second class citizen started calling themselves distributed. This created a division between being a remote worker and working for a distributed company. The latter was much better. The movement of distributed work was growing, Automattic, Github, and many other companies were charging ahead… and then the pandemic happened.

    I don’t think the amount of people using the term “distributed” changed during the Covid pandemic, but the amount of people using the term “remote” did and might have turned “distributed” into a rounding error. The natural change of title for my book would have been from:

    Building and Managing Distributed Teams

    to

    Building and Managing Remote Teams

    I wanted to measure this, but I couldn’t find any way to do it. I tried Google Ads but I couldn’t make it work and no other method seemed to even be feasible. One of the problems I had is that I believe polls would be useless, because once you give context to “distributed”, I think everybody understands it, and it might sound better. I wanted to see how they behave in isolation. At any rate, “remote” won in polls, but not overwhelmingly.

    Since I was going to change the title, I may as well consider any and all possible titles, not just a single word change, right? My friend, Justin Megawarne, came up with a very important point: the title doesn’t contain the value proposition. Think of the book “The Four Hour Work Week” by Tim Ferris. If it would have had a descriptive title, like “How to Delegate Work”, he would not have been a bestseller author.

    I tried to find a value proposition name for my book and I gave up

    I tried to find a value proposition title for my book. Companies struggle to hire, grow and manage in-office teams. This is a pain that exists. My friend and advisor works with many companies like that, he wants to recommend them my book, but he knows they don’t believe a book by that title has the solution to their problems. I tried to find a value proposition name for my book and I gave up.

    If I remember correctly it took Tim Ferris weeks of research to come up with the title and cover of his book. I don’t have weeks to dedicate to this, in part because even with the perfect title and cover, without an editor and publisher, with just my own ability to market, it’s not going to have a positive return on investment. And thus, the new title was selected:

    How to Hire and Manage Remote Work

    I did introduce some extra changes. From the conversation with Justin I switched “Building” for “Hiring”, to have the keyword of the pain point a lot of companies are going through. I also asked Ana Bibikova for her opinion since she’s both a marketer and an author. She advised me to switch from imperative phrasing to “How to”. I’m not sure what the effect will be, I don’t have a strong opinion and I trust hers.

    And now, the list of explored and abandoned titles:

    • Building and Managing Distributed Teams (current)
    • Building and Managing Remote Teams
    • Hiring and Managing Remote Teams
    • Find the Best Talent Everywhere
    • Hire the Best and Keep Them
    • Stop Struggling to Hire and Managing Remote Teams
    • Hire Remote: Manage Remote: Stay Remote
    • Hire Remote, Manage Remote, Stay Remote
    • Doing It Better Remotely
    • Hire, Manage, Stay: Remote Working and What It Should Look Like
    • Do Better: Hiring and Managing your Remote Team
    • Remote Teams Done Really Badly (A How Not To)

    I think some of those might come back as titles of blog posts.

  • How to feel more productive after moving from coder to manager

    , , ,

    I started coding when I was 7 years old and until I was 29 or so, my whole professional life was coding. Then, the startup I co-founded had to hire some people because it was doing well and I became a manager. I discovered I love managing as much as coding, but there was an ongoing issue: at the end of a day coding, I could look back at my code and feel productive, whereas at the end of a day managing, mostly meetings, I felt exhausted and with nothing to show for.

    I highly recommend it to all managers: write down notes.

    I’ve been managing for 10 years, taking over and building teams from scratch, being hands on and hands off and that feeling of not being productive is rarely there and I think there’s one habit that I have that helps a lot and I highly recommend it to all managers: write down notes.

    I go into every meeting with some note taking tool. If the meeting is face to face, I prefer to stick to pen and paper, because a computer can stablish a divide. The other person doesn’t know what I’m typing, I may be chatting with a friend. With pen and paper it’s immediately obvious I’m taking notes and there’s no wall (the screen) between me and the other person.

    But now we are all remote, and the notes are digital. This is so much better because it cuts down (but doesn’t completely remove) the need to process notes post-meeting. Depending on the type of meeting, I even share my screen so the other person can look at the notes I’m writing. You have no idea how many misunderstandings were caught this way. They said something, I misunderstood them, wrote it down in front of them and they corrected me. If you are not sharing notes, repeat what you wrote to the other person to have the same effect. This is similar to active listening.

    There are a few more things that I do with my notes that I highly recommend.

    I try to make all my meetings 50 minutes long, with 10 minutes to review and action notes. If we reach the 50 minute mark, ideally, I want to just book another one to continue. Having meetings overrun and everybody being late to the next meeting is very bad to the morale of a company but being the only person enforcing the strict end of meetings can be hard.

    When I review the notes, if the meeting was just the two of us or sensitive, I write them down on an email and I send them to the other people in the meeting. This helps have a shared record of what happened. Otherwise I write them down on a public record in a centralized documentation system, like Confluence or Notion.

    Looking at my written notes gives me the same feeling of accomplishment than looking at my written code. I’ve done something.

    Once a week I go through my week worth of notes to see if I have missed something. If they are written on paper this is when I digitize them for permanent record. This also informs the report to my boss about what happened that week. Looking at my written notes gives me the same feeling of accomplishment than looking at my written code. I’ve done something.

    If you found this valuable, you may be interested in my book: Building and Managing Distributed Teams.

  • When raising prices is easier than lowering them

    , , ,

    When you are building a B2B SaaS product it’s very hard to know what the appropriate price for your product is. Even if you magically found the correct one, it might not be the correct one next month when you made the product better and you are providing new values. That’s why you need to be constant experimenting with prices on your app.

    When I started my career I was afraid of raising prices, of having to justify why they went up (I wasn’t even aware of grandfathering). When I started to learn that most entrepreneurs set their prices too low, my partner and I decided to set the price too high and then lower it if it was necessary. Without realizing we painted ourselves to a corner.

    We didn’t want to just lower prices, we wanted to experiment with prices (switching from per-user to 3 plans, things like that). The problem was that anything we would come would cost a different amount for each customer. For some customers it would go up, and that wasn’t a problem, because we would grandfather them in. But for some customers it would plummet.

    There were two options for those customers:

    • Lower their prices according to the new plans and lose the revenue.
    • Don’t lower their prices and risk them being very angry about overpaying.

    Because we were a bootstrapped startup living month to month, every time we discussed this we would get stuck in a cycle of what-ifs one or the other situation. Eventually one day we made a rule of forbidding talking about pricing (trying to get some work done, because we would spend days and days discussing pricing).

    Eventually I found myself wishing that instead of starting with a high price and lowering it for experimentation, that we started with a low price and raising it for experimentation. We would have experimented much more. There’s another obvious solution which is not depend on the sweet revenue of those high prices. But even though it’s simple, I don’t think it’s easy… like sitting in front a pizza and not having a slide. Yeah… right!

    Next time I want to increment prices over time and even then try to give myself room for experimentation.