Tag: Work

  • Turning 42, and Coming Full Circle

    Turning 42, and Coming Full Circle

    I turned 42 this year. I don’t usually attach much meaning to birthdays, but this one did trigger a quiet pause—not a reinvention, not a reset, just a sense of recognition. A feeling that certain instincts and interests I’ve carried for a long time were finally meeting the right conditions to be acted upon.

    In many ways, it felt like coming full circle. Post–IIT Bombay, I had toyed with the idea of building something of my own more than once, but the timing never really worked. The cost of experimentation was high, the downside felt asymmetric, and meaningful execution required a kind of commitment—in time, capital, and headspace—that didn’t quite align with where life was then. AI didn’t create those ambitions. It removed enough friction that acting on them no longer felt irresponsible.

    There’s a popular mental model floating for AI—the Star Trek computer. Voice interface, simple commands, complex tasks executed seamlessly. It’s appealing: tell the AI what you want, and it handles the messy details. But we don’t have that yet. What we have now is quite powerful but far messier—and that gap between expectation and reality matters.

    Looking back, this arc probably started earlier than I realized. What felt like casual tinkering at the time—experimenting with tools, workflows, and ways of interacting with information—was really the beginning of a longer loop of building, reflecting, and writing.

    The first half of the year was deliberately focused inward. The arrival of our newborn changed the rhythm of everyday life in fairly fundamental ways. Time became scarcer, but priorities became clearer. Decisions that once felt nuanced or debatable started resolving themselves quickly when viewed through the lens of family well-being and long-term sustainability.

    Around the same time, we moved from Dubai back to Mumbai. On paper, it was a relocation. In practice, it was a broader reset—of cost structures, support systems, and optionality. Some things became simpler, others more complex, but overall it created a sense of grounding that had been missing.

    In hindsight, the first half wasn’t a slowdown so much as an incubation period. That stability mattered more than I realized at the time, because once the personal base felt settled, professional decisions became easier to make—and easier to commit to. The questions that kept surfacing during this phase were telling. Education, work, and what we’re really preparing the next generation for stopped feeling abstract and started feeling personal. Agency matters more than intelligence—the capacity to take initiative, make things happen, shape your path rather than wait for it. Are we educating for that? It’s a question that feels more urgent when you’re thinking about your own child’s future.

    The second half of the year marked a clear shift from exploration to ownership. I chose to go down the solo path, not because it’s easier, but because at this stage it offers speed and coherence. Fewer dependencies, tighter feedback loops, clearer accountability.

    AI changed the feasibility equation in a very real way. What once required teams and capital can now be prototyped solo—not perfectly, but fast enough to learn. Over time, this also changed how I approached building itself, gravitating toward a more fluid, iterative style where intent and execution sit much closer together.

    That conviction led to formalizing OrchestratorAI. Registering the company and filing the trademark weren’t about signaling externally as much as they were about drawing a line for myself. This wasn’t just advisory work or experimentation anymore; it was something I wanted to build patiently and seriously.

    A lot of the focus naturally gravitated toward the long tail—especially MSMEs. Large enterprises will adopt AI, but slowly and expensively. Smaller businesses can leapfrog. The marginal cost of intelligence has dropped enough that problems once considered too small or not worth solving suddenly are. That idea kept resurfacing as I looked at broader patterns in work, strategy, and go-to-market, often in ways that felt far messier in practice than in slides.

    Completing a year self-employed felt like its own milestone—not because of what I’d built yet, but because I’d committed to the path.

    Three things that have crystallized

    This is a great time for builders—not for shortcut-seekers.

    There’s a popular narrative that AI is about doing less work—the Star Trek computer fantasy where you state your intent and complex systems just work. My experience has been the opposite. We don’t have the Star Trek computer. AI rewards those willing to go deeper, not those trying to bypass fundamentals.

    Tools amplify intent and effort; they don’t replace them. The gap between “prompting” and actually building systems—workflows, artifacts, and feedback loops—is widening.

    Jevons’ Paradox is no longer theoretical in knowledge work.

    Making intelligence cheaper doesn’t reduce the amount of work; it expands it. Lower costs unlock suppressed demand—more ideas get tested, more workflows get built, more edge cases start to matter.

    Entire categories of previously unsolvable problems suddenly become economically viable. We’re even seeing fundamental business model shifts—from selling seats to selling outcomes, from “buy software” to “hire agents.”

    This is the foundation of what I’m building: serving markets that were previously uneconomical to serve.

    A lot of old ideas are finally working the way they were meant to.

    State machines, artifact-centric design, structured workflows, even the promise of auto-coding—none of these are new concepts. What’s new is that the economics finally make sense.

    But there’s also a new layer to master. Programmers now need mental models for agents, subagents, prompts, contexts, tools, workflows—a fundamentally new abstraction layer intermingled with traditional engineering.

    Abstractions still leak, and much of the year’s noise around agentic coding oscillated between hype and reality before settling. What’s emerging: structure matters, and there’s a real shift as agents become central to how work gets done.

    One curious footnote

    Starting in September, I noticed an unusual spike in traffic to my blog—specifically to posts from 10-15 years ago. The pattern was unmistakable: China. Most likely LLM training runs scraping old content at scale.

    There’s something quietly amusing about that timing. While my decade-old posts were feeding tomorrow’s AI models, I was using today’s AI to finally act on ideas I’d shelved post-IITB. Full circle, in an unexpected way.

    2026 feels different. Not because the work gets easier, but because the constraints are clearer. Family grounded, venture formalized, year one complete.

  • 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

  • From Data to Decision: AI Assistance in the Agile Workplace

    From Data to Decision: AI Assistance in the Agile Workplace

    I recently had the privilege of presenting online at the Business Analytics and Decision Sciences Conclave to a group of enthusiastic MBA students. The session, titled “From Data to Decision: AI Assistance in the Agile Workplace,” focused on how AI and analytics are revolutionizing the workplace and how students can prepare for these changes.

    Key Takeaways from the Session

    Data Literacy

    One of the core ideas we discussed was the importance of data literacy. In today’s data-rich world, it’s not enough to simply collect data; we must understand and interpret it effectively. I used the analogy of looking for lost keys under a streetlight to illustrate how we often focus on easily accessible data, even though the true insights might lie in harder-to-reach places. This highlights the need to measure what truly matters, rather than what is easy to quantify.

    Deep Analytics

    We also explored the concept of deep analytics. It’s crucial to go beyond surface-level data and understand the context and intricacies behind the numbers. For example, understanding the difference between correlation and causation can prevent misleading conclusions. I emphasized the importance of domain expertise in providing context to data and avoiding biases in AI-based decision making.

    Practical Examples

    To make these ideas more tangible, I shared practical examples from the pharmaceutical industry:

    • Follow-up Email Campaigns: We discussed why data literacy is important for new channel activations and how AI can help launch and optimize follow-up email campaigns by incentivizing the right behavior, monitoring customer satisfaction, and adjusting campaign content based on performance. The Rule of 80 – 80 – 40 was highlighted as a guideline to ensure campaign effectiveness.
    • Next Best Action (NBA) Solutions: I showcased how AI can determine the next best actions for the field force by analyzing customer preferences, transaction history, and available content. This approach helps in personalizing interactions and driving better outcomes.

    Agility

    The session also covered the importance of agility in today’s fast-paced business environment. AI plays a crucial role in speeding up decision-making processes by providing actionable insights, enabling rapid hypothesis testing, and offering predictive analytics. Embracing agility allows businesses to adapt quickly to market changes and stay competitive.

    Preparing for the Future To conclude the session, I offered practical tips for students on how to prepare for the future workplace. I also recommended three impactful books for those interested in diving deeper into these topics:

    • “How to Lie with Statistics” by Darrell Huff
    • “Weapons of Math Destruction” by Cathy O’Neil
    • “Data Science for Business” by Foster Provost and Tom Fawcett

    The session was an enriching experience, and I’m excited to continue the conversation on how we can better leverage AI and analytics to drive operational resilience and innovation.

    Feel free to check out the attached presentation slides for a more detailed look at the session.

  • Interning on FOSS 1: Open Source Development

    I’ve been interning at Sun Microsystems in Delhi from May 1st and during this period, I’ve had the opportunity to research a variety of open source applications. My initial project was to explore and research various open source applications suitable for use by students and compare them against each other and with the proprietary alternatives. There are indeed a bunch of alternatives available for the software we use during the course of our day to day work.

    I managed to submit a paper on “Components of an Open Source Operating System for Sustainable ICT Education in Schools in Developing Countries” to the HICSS conference, and I’m starting off a multi part post with my learnings on open source software and development.


    One of the interesting works that I read on open source development was Eric Raymond’s “The Cathedral and The Bazaar”. This is probably one of the definitive works on open source development, and a number of theories stem from it. In fact, quite a few papers that I referred to during the course of my research cited this work. He has postulated the following principles in the essay:

    1. Every good work of software starts by scratching a developer’s personal itch.
    2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
    3. Plan to throw one away; you will, anyhow.
    4. If you have the right attitude, interesting problems will find you.
    5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
    6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
    7. Release early. Release often. And listen to your customers.
    8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. (The full version of Linus’s law – Given enough eyeballs, all bugs are shallow)
    9. Smart data structures and dumb code works a lot better than the other way around.
    10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
    11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
    12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
    13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
    14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
    15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
    16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
    17. A security system is only as secure as its secret. Beware of pseudo-secrets.
    18. To solve an interesting problem, start by finding a problem that is interesting to you.
    19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

    Most of his principles are for software development in general, and so also apply to open source development. The key learnings form his essay are two-fold. First is that it is important to have a working prototype of the project before making it open source, or at least trying to find other developers who’d be interested in it. Second is that open source attracts a wide variety of talent that can be put to various uses, ranging from bug finding, to improvement suggestions to actual coding. Thus, it is essential to treat the participants in the right manner as everyone could make an important contribution.

    One of the other observations to be made about open source development is the vital role that the internet has played in creating the synergy that exists between the developers, users and other contributors of any open source project. In fact, Eric Raymond has said as much in his essay:

    … Another (in hindsight) was that the Internet wasn’t yet good enough.

    Before cheap Internet, there were some geographically compact communities where the culture encouraged Weinberg’s “egoless” programming, and a developer could easily attract a lot of skilled kibitzers and co-developers. Bell Labs, the MIT AI and LCS labs, UC Berkeley—these became the home of innovations that are legendary and still potent.

    Linux was the first project for which a conscious and successful effort to use the entire world as its talent pool was made. I don’t think it’s a coincidence that the gestation period of Linux coincided with the birth of the World Wide Web, and that Linux left its infancy during the same period in 1993–1994 that saw the takeoff of the ISP industry and the explosion of mainstream interest in the Internet. Linus was the first person who learned how to play by the new rules that pervasive Internet access made possible.

    In essence, open source development has a lot of potential when used in the right manner. In fact, many companies use it quite strategically and couple them with interesting licenses (I’ll cover licenses in another part). There are also quite a few organizations championing free (as in freedom) software with the FSF (Free Software Foundation), headed by Richard Stallman being one of the pioneers. There is also a bit of controversy in the Free/Open Source world with some preferring the term free to open source. This has however not deterred organizations from leveraging open source development strategically. Open source development may not be practicable in every situation, particularly for routine software development in enterprises, but it definitely has its merits and I’ll be looking at other aspects of open source software in subsequent parts.