Tag: Productivity

  • What “AI-native” actually means for a founder-led firm

    What “AI-native” actually means for a founder-led firm

    A recent paper from INSEAD and Harvard looked at close to 3,000 startups and found something that should interest anyone running a small firm. Matched like-for-like, same industry, same age, the ones built around AI ran about a quarter smaller than the ones that weren’t. In services, the gap reached roughly 70%. Fewer people, the same kind of work, and not because they were starving themselves of staff.

    A smaller firm that is worth more

    Across eleven startup batches from 2020 to 2024, the AI-native firms ran leaner and flatter, carried more senior people and fewer managers, and still raised more money and held higher valuations per head than their peers. The smaller size was buying more output per person, not papering over weaker companies. The effect was largest, near 70%, in services firms, the advisory-and-delivery work many of us sell. If your firm sells judgment rather than a shipped product, that number is aimed at you.

    One example makes the shape concrete. An AI slide-deck company reached around $50M of annual revenue in about two years with a team of roughly 30, because making a deck became something the customer does inside the product instead of a job that lands in someone’s queue. A small team, a lot of output, because the work itself moved.

    A fair caveat, which the paper makes and most write-ups drop: a leaner firm need not mean fewer jobs overall. Cheaper output tends to pull in more demand for it (the Jevons paradox: make something cheaper and we usually use far more of it), so the economy can end up with more firms and more total work even as each one shrinks.

    The most telling result is one that didn’t show up the way you might expect. The AI-native firms in the study were about 2.6 times more likely than the rest to name worker-facing tools (ChatGPT, coding assistants, and the like) in their job ads, yet that heavier tool use predicted none of the structural differences: not the smaller size, not the flatter hierarchy. As the authors put it, “equipping workers with ChatGPT, Copilot, or Cursor does not, on its own, predict smaller firms.”

    A large MIT study in 2025 found the mirror image: around 95% of corporate AI pilots delivered no measurable impact, with the failures traced to organisations bolting AI onto existing workflows rather than to the technology itself. Both point the same way. The gains come from redesigning the work, and the licence count barely matters.

    What did track with firm size was where the AI sat. Used inside the firm to speed up work people already do, it moved the structure very little. Built into what the firm sells, so the customer generates the output directly, it tracked with the shrinkage. It is the same move Ben Thompson called an unbundling: the firms that pull ahead fold the act of making something real into the product, rather than keeping it a step their staff perform.

    Governed delegation

    What makes a firm AI-native, then, is how far it has rebuilt its work around what AI can do reliably and what still needs a person watching. Call it governed delegation: you hand the work to AI while keeping your hands on the rules, the boundaries, and the checking. Think of a restaurant that buys a dishwasher but keeps everyone rinsing each plate by hand first. It has added a machine and kept the old routine, so all it has really bought is cost. The gain shows up only when the workflow is rebuilt around what the machine does well.

    Most of this conversation stays inside software teams, which is why the wider point gets missed. The same logic runs straight into sales, marketing, and operations, which is where I have spent the past several months testing it. I run most of OrchestratorAI’s own go-to-market this way: agents handle well-defined pieces of work, and my job is to set the rules and check the output rather than produce each piece by hand. Each group of agents runs in one of two modes, either nothing leaves the building until I have looked at it, or it runs on its own, shows me a sample, and escalates the exceptions. A task earns its way from the first mode to the second only after it stops throwing up things to fix, and some never do. Drafting a note to a high-value prospect stays under review; filling in a basic company profile from public sources does not need me hovering.

    Running it this way taught me something the paper doesn’t quite reach: almost none of the governance had to be invented. We have spent decades building ways to govern people at work: audit trails and compliance checks, standard operating procedures, the maker-and-checker split in finance, code review and the ceremonies of Agile. In a human-only firm a lot of this sits heavy. It adds layers and breeds box-ticking, because people dislike being audited and tire of the checklist, so the control gets watered down to what the organisation or regulators will tolerate.

    Point the same practices at AI agents and the weight largely lifts. An LLM is trained on how people work, so it takes direction roughly the way a person does, and the structure of the playbook carries over. The agent doesn’t resent the audit log or cut the SOP short when it’s busy, so a check that was costly to run on people is cheap to run on an agent. The procedures that were overhead in a human firm become the guardrails of an AI-native one. The autonomous SDLC (the software build-and-ship cycle, increasingly run by agents) is the clearest case I’ve come across: code review, the test gate, the staged rollout that always slowed teams down are exactly what lets an agent ship without a human reading every line.

    The one catch here is that agents fail differently from people. They don’t commit fraud or get bored; they fabricate confidently and come apart on inputs a person would laugh off. So the controls transfer in shape, not in detail: you keep the independent check and the earned trust, but you point them at hallucination and weak grounding rather than at fatigue and dishonesty. Those rough edges are being ironed out quickly. Coding is the clearest case, where agents have grown markedly more reliable over the past year, and making AI broadly more dependable and harder to misuse is a major focus at the frontier labs, still some way from solved. The upshot is that there is already plenty an agent can be trusted to do well today, and the list keeps growing.

    What it means if you run a small firm

    The paper names the real bottleneck, and it isn’t access to AI, which everyone now has at much the same price. It is the mapping problem: working out where, in your particular business, AI actually pays off. That has no generic answer, and finding it is the work that’s left.

    For a founder, the practical shift is that your scarce time moves from production toward direction and judgment, deciding where AI-handled work ends and where human review is non-negotiable. The closer you sit to pure services, the sharper that shift, which is presumably why the services number ran to 70%. Autonomy has to be earned, too: moving a task from supervised to self-running is a track record you build through logging and spot-checks, not a switch you flip. So the key question to put to your own firm is not which AI tools to buy, but which parts of the work can be governed at the boundary, and which still need a person on every output.

    None of this is settled, and the unsettled part is the interesting one: deciding when a piece of work has earned its autonomy, and building the checks so you aren’t flying blind once it runs alone. Strikingly few firms in the data had actually managed it, which makes “AI-native” more aspiration than description for now, even among the companies wearing the label. That is the encouraging part. The tools are here and roughly evenly spread, so the advantage goes to whoever does the slow, unglamorous work of deciding what to hand over and what to keep a hand on.

  • The Law of Leaky Abstractions & the Unexpected Slowdown

    The Law of Leaky Abstractions & the Unexpected Slowdown

    If the first rush of agentic/vibe coding feels like having a team of superhuman developers, the second phase is a reality check—one that every software builder and AI enthusiast needs to understand.

    Why “Vibe Coding” Alone Can’t Scale

    The further I got into building real-world prototypes with AI agents, the clearer it became: Joel Spolsky’s law of leaky abstractions is alive and well.

    You can’t just vibe code your way to a robust app—because underneath the magic, the cracks start to show fast. AI-generated coding is an abstraction, and like all abstractions, it leaks. When it leaks, you need to know what’s really happening underneath.

    My Experience: Hallucinations, Context Loss, and Broken Promises

    I lost count of the times an agent “forgot” what I was trying to do, changed underlying logic mid-stream, or hallucinated code that simply didn’t run. Sometimes it wrote beautiful test suites and then… broke the underlying logic with a “fix” I never asked for. It was like having a junior developer who could code at blazing speed—but with almost no institutional memory or sense for what mattered.

    The “context elephant” is real. As sessions get longer, agents lose track of goals and start generating output that’s more confusing than helpful. That’s why my own best practices quickly became non-negotiable:

    • Frequent commits and clear commit messages
    • Dev context files to anchor each session
    • Separate dev/QA/prod environments to avoid catastrophic rollbacks (especially with database changes)

    What the Research Shows: AI Can Actually Slow Down Experienced Devs

    Here’s the kicker—my frustration isn’t unique.

    A recent research paper, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, found that experienced developers actually worked slower with AI on real-world tasks. That’s right—AI tools didn’t just fail to deliver the expected productivity boost, they created friction.

    Why?

    • Only about 44% of AI-generated code was accepted
    • Developers lost time reviewing, debugging, and correcting “bad” generations
    • Context loss and reliability issues forced more manual intervention, not less

    This matches my experience exactly. For all the hype, these tools introduce new bottlenecks—especially if you’re expecting them to “just work” out of the box.

    Lessons from the Frontlines (and from Agent Week)

    I’m not alone. In the article What I Learned Trying Seven Coding Agents, Timothy B. Lee finds similar headaches:

    • Agents get stuck
    • Complex tasks routinely stump even the best models
    • Human-in-the-loop review isn’t going anywhere

    But the tools are still useful—they’re not a dead end. You just need to treat them like a constantly rotating team of interns, not fully autonomous engineers.

    Best Practices: How to Keep AI Agents Under Control

    So how do you avoid the worst pitfalls?

    The answer is surprisingly old-school:

    • Human supervision for every critical change
    • Sandboxing and least privilege for agent actions
    • Version control and regular context refreshers

    Again, Lee’s article Keeping AI agents under control doesn’t seem very hard nails it:

    Classic engineering controls—proven in decades of team-based software—work just as well for AI. “Doomer” fears are overblown, but so is the hype about autonomy.

    Conclusion: The Hidden Cost of Abstraction

    Vibe coding with agents is like riding a rocket with no seatbelt—exhilarating, but you’ll need to learn to steer, brake, and fix things mid-flight.

    If you ignore the leaky abstractions, you’ll pay the price in lost time, broken prototypes, and hidden tech debt.

    But with the right mix of skepticism and software discipline, you can harness the magic and avoid the mess.

    In my next post, I’ll zoom out to the economics—where cost, scaling, and the future of developer work come into play.

    To be continued…

  • From Productivity to Progress: What the New MIT-Stanford AI Study Really Tells Us About the Future of Work

    From Productivity to Progress: What the New MIT-Stanford AI Study Really Tells Us About the Future of Work

    A new study from MIT and Stanford just rewrote the AI-in-the-workplace narrative.

    Published in Fortune this week, the research shows that generative AI tools — specifically chatbots — are not only boosting productivity by up to 14%, but they’re also raising earnings without reducing work hours.

    “Rather than displacing workers, AI adoption led to higher earnings, especially for lower-performing employees.”

    Let that sink in.


    🧠 AI as a Floor-Raiser, Not a Ceiling-Breaker

    The most surprising finding?
    AI’s greatest impact was seen not among the top performers, but among lower-skilled or newer workers.

    In customer service teams, the AI tools essentially became real-time coaches — suggesting responses, guiding tone, and summarizing queries. The result: a productivity uplift and quality improvement that evened out performance levels across the team.

    This is a quiet revolution in workforce design.

    In many traditional orgs, productivity initiatives often widen the gap between high and average performers. But with AI augmentation, we’re seeing the inverse — a democratization of capability.


    💼 What This Means for Enterprise Leaders

    This research confirms a pattern I’ve observed firsthand in consulting:
    The impact of AI is not just technical, it’s organizational.

    To translate AI gains into business value, leaders need to:

    ✅ 1. Shift from Efficiency to Enablement

    Don’t chase cost-cutting alone. Use AI to empower more team members to operate at higher skill levels.

    ✅ 2. Invest in Workflow Design

    Tool adoption isn’t enough. Embed AI into daily rituals — response writing, research, meeting prep — where the marginal gains accumulate.

    ✅ 3. Reframe KPIs

    Move beyond “time saved” metrics. Start tracking value added — better resolutions, improved CSAT, faster ramp-up for new hires.


    🔄 A Playbook for Augmented Teams

    From piloting GPT agents to reimagining onboarding flows, I’ve worked with startups and enterprise teams navigating this shift. The ones who succeed typically follow this arc:

    1. Pilot AI in a high-volume, low-risk function
    2. Co-create use cases with users (not for them)
    3. Build layered systems: AI support + human escalation
    4. Train managers to interpret, not just supervise, AI-led work
    5. Feed learnings back into process improvement loops

    🔚 Not AI vs Jobs. AI Plus Better Jobs.

    The real story here isn’t about productivity stats. It’s about potential unlocked.

    AI is no longer a futuristic experiment. It’s a present-day differentiator — especially for teams willing to rethink how work gets done.

    As leaders, we now face a simple choice:

    Will we augment the talent we have, or continue to chase the talent we can’t find?

    Your answer will shape the next 3 years of your business.


    🔗 Read the original article here:

    Fortune: AI chatbots boost earnings and hours, not job loss


    Want to go deeper? I’m working on a new AI augmentation playbook — DM me or sign up for updates.

    #AI #FutureOfWork #EnterpriseStrategy #GTM #DigitalTransformation #Chatbots #Productivity #ConsultingInsights

  • University 2.0 ideas

    In the last few weeks, I’ve come across quite a few presentations regarding University 2.0 (links: 1 2). They seek to make use of several Web 2.0 technologies, that have become popular in the last 2-3 years, for educational institutions. This idea seems quite interesting to me, especially because I was trying to get some of those technologies like wikis and blogs implemented for our b-school. I have another year and a half of my course remaining, and I hope to implement as many of them as I can with help of my classmates and others from the school.

    So, here’s a a basic outline of the ideas:

    LinkedIn profiles

    LinkedIn has become a standard in professional social networks, and it is quite important for professionals to have an up to date LinkedIn profile. My idea is to get everyone to set up their profiles and put the links on our school student profile pages.

    Student & Faculty introduction videos

    This will make the profiles richer, and should definitely look better than having just static photographs. There are several online video sharing sites, and any of them could be used for this purpose. It could be done initially for the students who are part of different committees, and later expanded for the others depending on the response.

    Social network groups

    There are several social networks out there like orkut, facebook etc, and our school has a group on each of them. They need to be streamlined a bit and kept up to date. The links to the groups could also be placed on the official school site to gain better visibility.

    Online magazine

    We have a school magazine L!VE that is published both physically and electronically. However, the electronic version is in a pdf form with only a few of the articles being published in html form. My intention is to make use of  a blogging platform to publish our magazine online. This will not only increase the visibility of the magazine, but also facilitate interaction on the articles and get the content indexed on search engines. WordPress seems to be an ideal platform for this purpose, and there are quite a lot of magazine themes for this purpose.

    School blog

    Currently we do not have a blog for our school. However, we do make use of blogs during our annual b-school fest like we did for AVENUES 08 this time. The idea here is to make blogging a continuous phenomenon. This should again facilitate interaction, increase visibility, and keeps notifications up to date.

    Wiki

    I had already started a wiki some time back, and did manage to put up some content on it. Over time, it can become a very important knowledge repository with different kinds of information on our school.

    Once set up, these avenues should definitely help the school from different aspects. Moreover, most of these services can be setup or for free. There are of course several other services that can be used in addition to the ones mentioned here like photo sharing, social bookmarking etc. So, the main investment required will be time, which is quite an important commodity in management courses :-).

    However, there are several challenges and constraints to be overcome before these become a reality, the biggest of which is going to be getting participation and garnering critical mass from the various stakeholders so that this initiative can be sustained in the long run.

  • Do education institutes need wikis?

    Now that many companies have adopted wikis internally and are beginning to understand their power, why should education institutes be left behind. After all, the knowledge density in education institutes is bound to be as high as, if not higher, than in most companies. Moreover, content creation is part of any education process, and a wiki is an ideal medium for refining the content and making it available to a wide audience. So, what are the stumbling blocks in the widespread adoption of wiki or any knowledge/content management system for that matter?

    Challenges

    IBM has WikiCentral, an internal deployment of the Confluence wiki, and I was one of its 125,000+ users. We had wikis for our project, our team and various initiatives. In fact most of the documentation, FAQs etc of our project were on the wiki. So, we could easily refer to them and keep them up to date at the same time.

    However, I have found a couple of limitations in wikis during my stint with IBM. Firstly, a wiki (barring wikipedia) is not the reference source (no prizes for guess the first) which means that even if we manage to aggregate a wealth of information, not too many people are going to actually refer to it. This can be tackled in some ways through publicity, which is precisely what was done in IBM. The second and biggest problem is the content creation part which is due to the lack sufficient contributors. Even wikipedia faces this problem (different scales though). I have ended up being one of the handful of contributors to quite a few wikis.

    Wiki for SJMSOM

    Finding the critical mass of contributors to sustain a wiki is the toughest challenge, and it gets even tougher with a tiny user base. However, I have not yet given up on wikis :-), and now that I am back to being a student, I find that a wiki is an ideal fit for this environment. There is a lot of information that is exchanged among students, and most of this would be of value in the future too. However, this information in the form of emails and verbal communication which makes the persistence quite low. So, a wiki with its persistence and ease of editing is an ideal medium to store all this information.

    I did some exploration of different wiki options on the internet, and found two that were well suited: Wikia and Zoho. In fact, Wikia already has a section for students. However, Zoho has better access control (supports domain level access control), and I chose it as the platform for my b-school wiki. Of course an internal wiki deployment would have been ideal, but I’m just doing this as an experiment to see if it works out.

    I have been doing some work on it, and the support for HTML embeds is quite handy for adding different widgets on pages. I have currently kept the wiki visible to the public with the ability to add comments. However, editing is restricted to students from SJMSOM (my b-school). It is currently a work in progress, and I am still trying to find the tipping point of contributors 🙂 . So, if you have any comments or suggestions, do share them with me.

    P.S. My father has blogged on a similar topic “How Important Is Technology For Knowledge Management?”, and it doesn’t seem to be very encouraging for my experiment 🙂

  • Productivity 2.0 (non-serious)

    I came across a humorous post from thedailywtf.com on an “innovative” way to measure productivity through SVN check-ins, which of course met with expected results, with some employees increasing their productivity by over 600%. It also led to the development of a nice little reusable asset that could be used to increase productivity:

    Still, it irked Milo that he wasn’t reaching his full productivity potential. He was wasting a lot of time writing code; time that should be spent checking code in….

    …..

    With his script, dubbed “PHLEGM” (Programmer’s Helper for Literally Engaging in General Machination, named by one of his colleagues), he could stretch what would usually be one checkin to 20-30 commits. It’s evolved like an open source project with his fellow team members adding new features.

    The post also led me to an old Joel post on productivity related to Amazon’s attempt to measure customer service productivity based on number of calls logged:

    “Thank you for calling Amazon.com, may I help you?” Then — Click! You’re cut off. That’s annoying. You just waited 10 minutes to get through to a human and you mysteriously got disconnected right away.

    Or is it mysterious? According to Mike Daisey, Amazon rated their customer service representatives based on the number of calls taken per hour. The best way to get your performance rating up was to hang up on customers, thus increasing the number of calls you can take every hour.

    Joel’s also been quite critical of productivity measurement and incentive based systems at work before. However, I can’t think of a better alternative to the usual rating systems used in companies, especially large ones with tens of thousands of employees. Can you?