The Myth of the Mighty Team: Why 10 Developers Are 9 Too Many

Nadella predicts AI agents will disrupt SaaS, Benioff champions AI on his platform. But here’s the kicker: AI might just replace half your dev team. Welcome to the era of efficiency, where team size isn’t a guarantee of success. We’ve all seen the ‘super team’ myth—more bodies don’t magically solve problems. In software development, bigger often means chaos.

I remember vividly one of my first managers took me out to lunch on my first week at work in Cupertino, “Do you want to eat good, or eat at a good place?” It’s a question about priorities, about focusing on the outcome rather than the spectacle. In software development, that translates to focusing on delivering quality code, not just filling seats.

Think of baking a cake. You could try to bake a cake the size of a swimming pool, throwing every ingredient in the pantry at it. But what happens? You end up with a massive, uneven mess, half-baked and half-burned. It’s impossible to manage, and certainly not enjoyable. Now, imagine baking several smaller, perfectly formed cakes, each with a specific recipe and purpose. You can then assemble them into a stunning, multi-tiered masterpiece.

Or let’s consider a bicycle. You could weld everything together, creating one monolithic piece. Sure, it might look impressive, but what happens when you need to adjust the handlebars or the seat for a rider’s height? Or when rust sets in, or you want to upgrade to a shiny new model? Suddenly, you’re looking at a major overhaul, a costly and time-consuming endeavor. Now, imagine you used fasteners and distinct parts. Customizing the height becomes a breeze, and replacing a rusty handlebar is a simple, cost-effective swap. That’s the difference between a bloated, monolithic system and a modular one.

In software development, this translates to breaking down large projects into smaller, manageable subsystems, each handled by a focused team. These teams have clear “contracts” or interfaces, defining how their subsystems will integrate with the whole. Just as distinct bicycle parts come together to form a functioning machine, these smaller teams collaborate to build a cohesive, high-quality product. And if the problem is truly large, this is a great way to manage complexity.

The Productivity Paradox: More People, Less Done?

Research, like those dry studies from the ISBSG and Boehm et al., tells us what we already suspect: bigger teams often mean slower progress. It’s like trying to herd cats—except the cats are carrying laptops and arguing about semicolons.

• Imagine a team of nine. By the time they’ve finished their daily stand-up, it’s time for lunch.
• Various studies claim that smaller teams (just two people!) were significantly more productive. That’s right, two people accomplished nearly 40% more than 3. That third person must be really good at coffee runs.

Quality Quagmire: When More Cooks Spoil the Code

And it’s not just about speed. Quality takes a hit too. More people means more communication channels, which means more opportunities for ‘lost in translation’ moments.

• Ever played telephone? Now imagine playing it with code. ‘Wait, you said change the variable to ‘banana’? I thought you said ‘bandana’!’
• Larger teams tend to come up with more complex solutions to prove how smart they are. The problem is that complex solutions take even more time and effort to maintain. This leads to a vicious cycle of bloated systems that take even more time and effort and money to maintain/enhance. And let’s be honest, sometimes these complex solutions are just… well, they’re like excessive syntactic sugar. Sure, they might look pretty on the surface, but as any seasoned developer knows, “syntactic sugar causes cancer of the colon.” We prefer solutions that are clean, maintainable, and transparent—no hidden complexities lurking beneath the surface.

The Culprits: Why Bigger Teams Stumble

1. Coordination Overkill: Not just every sprint, but every meeting becomes a marathon. Project management turns into a full-time circus.
2. Context Switching Chaos: It takes 25 minutes to refocus after a distraction. That’s like losing a quarter of your workday every time someone asks, ‘Quick question…’ Developers switch between tasks, and the bugs multiply. Like a bad game of wack a mole.
3. Focus Follies: Interruptions become the norm. ‘Attention residue’ sounds like a sci-fi villain, but it’s just your brain getting stuck on the last thing it was doing.
4. Communication Catastrophes: Miscommunication is the new black. Documentation becomes a novel.

The Sweet Spot: Finding the Right Size (and the Right Skills)

So, what’s the magic number? Research, bless their statistical little hearts, points to teams of 3-7, with 3-5 being the sweet spot. It’s about finding that balance between collaboration and chaos. But let’s be honest, those researchers probably haven’t met the rise of AI and intelligent agents. I’m betting that in the not-too-distant future, with the right AI copilots, we’ll see the optimal team size shrink to a team or two—maybe even just a lone developer, a digital virtuoso, orchestrating code like a symphony.

More than just team size, it’s about the qualitative aspects. The future of the “full stack” developer is the human as a Swiss Army knife. We’ve all abused that metaphor, but with the rise of AI Agents and LLMs, it’s truer than ever. When we need a specialized tool—a knife, scissors, corkscrew—we find the precision LLMs that do it. But for high-level tuning, for the nuanced understanding of the whole system, we become that Swiss Army knife.

Yuga Shift: Your Agile Ally

At Yuga Shift, we get it. We’re a boutique firm, like a specialized motorcycle shop or a team of master bakers. We understand that speed to value is crucial. That’s why we embrace lean methods, delivering results in weeks/months, not years. We prioritize quality, ensuring lower defect rates and reliable solutions. And we believe in outcome-oriented engagements, sharing the risks and rewards with our clients. Plus, we offer competitive pricing, because great service shouldn’t break the bank. We focus on getting stuff done, not just looking busy.

The Takeaway

Don’t fall into the trap of thinking bigger is better. Build smaller, more focused teams. And remember, sometimes, less is truly more—especially when it comes to code. And who knows, maybe soon, it’ll be just you and your AI sidekick, conquering the coding world, while we all watch the CRM/Clippy smackdown unfold!

AI and the Authenticity Paradox: Can We Write Honestly with Machines?

Have you noticed a shift in the tone and style of posts from people you know online? I have. For example, I notice a more formal style in posts from colleagues who typically adopt a more casual tone. There’s also a certain “sameness” creeping in, and it’s making me wonder if AI writing tools are blurring the lines between human and machine-generated content. This raises a crucial question: in an age where anyone can use AI to polish their prose or even generate entire articles, how do we maintain authenticity in our writing? I’ve always enjoyed writing and sharing my thoughts with others.

Recently, I too have started using tools like ChatGPT and Gemini to help me craft emails and articles. In fact, I even used AI to help write this article about my experiences with AI code generation. Here’s how I used AI in that process:

• I started with a rough draft outlining my motivations and objectives.
• I provided detailed descriptions of my experiments.
• I shared my observations on the LLM’s strengths and weaknesses, and where I had to intervene.
• I concluded with thoughts on the technology’s potential.

To make the article concise, I pasted it into an LLM and asked it to shorten it to a 5-minute read. The LLM produced a more focused version, correcting my rambling and repetition. This experience made me wonder: Did I sacrifice authenticity in the process? Did I write that article, or did AI?

Benefits of GenAI:

• LLMs can be incredibly helpful for writers. They can:
• Help overcome writer’s block. If the block is caused by anxiety about the choice of words, LLM provides a safe space to get feedback in a non-judgmental way.
• Improve clarity and conciseness by identifying repetition and refining ideas.
• Help experiment with different writing styles to make content more engaging, professional, or humorous.
• “Level the playing field” by assisting those who struggle with articulation. Some people may have powerful ideas or want to express a point of view but may lack the necessary vocabulary to get the idea across.

Ethical Concerns:

However, there are also ethical concerns to consider:

• Misrepresentation: LLMs can be used to create content that doesn’t reflect the writer’s true beliefs or experiences. For example, an author could instruct an LLM to cherry-pick data to support a viewpoint, even if the majority of evidence suggests otherwise.
• Deception: Readers may believe they are interacting with a human writer when the content is heavily influenced by AI.
• Potential for Manipulation: LLMs can be used to craft emotionally manipulative content.
• Erosion of Trust: Widespread use of LLMs could lead to a general decline in trust in written content.

Finding a Balance:

Some thoughts on how to use of GenAI ethically:

• Be transparent: Disclose when and how we’re using LLMs in our writing.
• Maintain human oversight: Use LLMs as tools to enhance our writing, not replace our own thinking and voice.
• Focus on genuine expression: Don’t let LLMs dictate our ideas or emotions.

Conclusion:

Authenticity is crucial in writing. While LLMs offer many benefits, we must use them responsibly and thoughtfully. By emphasizing critical thinking and media literacy, we can navigate this new era of AI-assisted writing while preserving genuine human expression.

The Road to Digital

All enterprises continuously strive to trim their bottom line through operational efficiencies and grow their top line by enhancing customer experiences and discovering new revenue streams. An appreciation for how the Digital Economy functions is key in accomplishing this for the new age enterprise. In doing so, many challenges and opportunities present themselves. As always, decision-makers look for clarity in terms of what potential benefits can be realized and when. There is also a need to understand (and plan for) impacts to various stakeholders including employees, customers, vendors/other business partners. This article explores these aspects and some thoughts on what elements that could be part of an organization’s Digital Strategy and a roadmap to executing on the strategy.

Digitization & Digitalization

A key aspect of this is the difference between digitization and digitalization. Others have written about this and there are many definitions that have been proposed in the recent past. Hopefully, some examples from our daily routines can help clarify this distinction.

Until recently, most professionals had a habit of keeping a record of meetings and events in a physical(paper) calendar/diary. Sometimes, maintaining separate diaries for personal life, social commitments, and official meetings. When software tools like Outlook/Google calendars became more ubiquitous, the calendars were digitized. Once the data is available in digital format, some of the advantages become apparent – for example, having a better understanding of one’s availability as schedules from multiple digitized calendars are digitally superimposed. We can also create more digital experiences like finding the earliest time when multiple parties can meet based on availability as published in their digital calendars.

This simple example hopefully illustrates the difference between digitizing and being digital. Digitization is the process of converting data that exists in a physical form into a stream of bytes. Being digital is the ability to use that digitized data to gather information that is useful in performing higher order activities and redefine processes to make things better. This data is typically consumed in tools from analytics, artificial intelligence, process modeling and the like.

Let’s look at a specific illustration from the restaurant industry where these concepts apply. The typical workflow when we visit an establishment. This thread on yahoo answers details the workflow behind the order/ticket system for a typical customer. An abridged version: a) Someone jots down food orders. b) Order queued up for preparation by the kitchen staff C) Food order prepared by kitchen staff. d) Food is served to the customer. e) Customer pays the bill. There could be variations, for example, in a fast food establishment, we pay at the time of ordering.

Now, this system can be digitized by recording orders using a software system. Digitizing the order allows us to be more efficient at some things. If the goal is to provide faster service to our customers, it may be possible to tweak the systems/workflows to achieve this. However, we should know what to tweak. Are customers waiting a long time to place their orders or are they waiting longer to get their food once their order is placed? Does the answer change by time of day? Once we know the answers to these questions, the solutions may be more apparent. If customers are having to wait to place the order or if food is taking longer to reach their tables after it is prepared, then we can look at a different set of solutions. Options may include increasing the front office staff or taking the digitization closer to the edge. Like we see in many eateries at airports, customers seat themselves and order food from a device on their table or from their phones. On the other hand, if the bottleneck is in the kitchen, we need more staff/automation in the backend. Some establishments allow customers to self service themselves partially as they serve their own soda from a dispenser. We can analyze data from the first wave of digitization to understand the problem better before rushing into a solution. This process of using analytics to understand the bottlenecks, what to optimize and tweaking workflows is being digital.

From the above scenario, one can perceive how digitization is a prerequisite for digitalization. Digitization becomes an operational necessity. Typically, this step involves higher investment and requires the blessing of executive management. Once an enterprise is digitized, folks on the ground would feel empowered to create efficiencies. Analytics will help them move forward with solutions to optimize based on evidence as opposed to just intuition. Solutions are implemented with greater confidence thereby reducing risk.

Summary

Digitization is the process of creating a digital representation in bits and bytes of data that is present in a physical form such as on paper, documents and pictures. Digitalization is the logical next step; using the transformed data to create efficiencies through alternate operating models. This will increase customer delight and perhaps even create new business models.

In subsequent posts, I will share some thoughts on how technology enables organizations to be more digital; changes in the operating model will help accelerate this process; ways in which we can use technology to reimagine how work gets done; how this impacts the people in the ecosystem; how the nature of their work itself may change and changes in attitude that will help employees be successful in this new environment. I’ll try to illustrate some ideas drawing from different industry segments.

My Code, My Motorcycle, and the AI That Said “No.”

I Challenged AI to a Code-Off! Here’s Who Won.

Everyone’s talking about AI writing code these days. But can it really handle anything beyond “Hello, world?” I wanted to see for myself, so I set out to build something more complex – not a full-fledged enterprise app, but something that went beyond the basics and even incorporated security features. That’s how I landed on creating a Rahukalam calculator.

For those unfamiliar, Rahukalam is an astrological concept that involves calculating inauspicious periods of the day based on location and sunrise/sunset times. It requires some intricate date and time manipulation, making it a good test case for AI’s coding abilities.

I challenged both Gemini and ChatGPT with a simple prompt: “Create code that I can execute from my browser alone to compute Rahukalam once I enter the date and city.” And guess what? They actually delivered… mostly.

Here’s the play-by-play of my AI-assisted coding adventure:

• APIs? No problem! Both AI models effortlessly found free APIs for getting latitude/longitude and calculating sunrise/sunset times. Talk about saving hours of research!
• Logic (almost) nailed it: They even generated the core Rahukalam calculation logic, though it wasn’t bug-free (more on that later!).
• Where humans still reign: I still needed to do some manual work, including: Setting up accounts with API providers and obtaining those all-important API keys. Integrating those keys into the code. Debugging a fair amount of JavaScript (timezones and date arithmetic, oh my!). Implementing a typeahead feature for city names using a public dataset, which involved some back-and-forth with the AI for optimization.

LLM’s role:

Despite the manual effort, I’d say the AI tools handled about 70% of the work. This was particularly impressive considering my “intermediate” JavaScript skills (I’m a decent programmer overall, but JavaScript isn’t my forte).

What could be improved:

• AI Agents to the rescue: Imagine if an AI agent could automatically create accounts with API providers, obtain keys, and plug them into the code. This would be cool! Some providers might offer management APIs for this, but I didn’t see any readily available.

• Testing, testing, 1, 2, 3: I tried to get the AI to write automated tests based on a CSV file of inputs and expected outputs. It suggested using Playwright, but I haven’t gone down that rabbit hole yet.

The Verdict:

Despite the hiccups, I was impressed by how much the AI assisted in building this Rahukalam calculator. You can even try it out yourself at https://banurama.github.io/calculate_rahukalam/.

This experiment reinforced my belief that generative AI has the potential to revolutionize coding. While it’s not a magic bullet (yet!), it can significantly accelerate development, even for those of us who aren’t JavaScript wizards. I’m excited to see how these tools evolve and what new possibilities they unlock in the future!

The Road to Digital – Part II

In my earlier article, we discussed how investments in digitization set up an organization to reap the benefits of being in a digital world. In this article, we will explore some of the technology trends and tools that make such digital journeys possible using an illustration from financial services. We will use a scenario of opening an account at a typical bank to trace their digital journey.

Context

The figure below shows a typical sequence of events that banks use as part of the Know Your Customer (KYC) to onboard a customer. Let us trace the digital journey of this fictitious bank in realizing this use case.

These were the sequence of steps that the bank will follow to open an account.

Initiation

• Potential customers used to fill a multiple page application form on paper and hand it over along with copies of documents like a passport/Driver’s license/incorporation documents to a front office person.
• The bank employee would then enter the same information on an internal system.
• There could be some further communication with the customer when this information is verified. For example, if the address on the application does not match the address on the driver’s license, additional documents like a utility bill may be requested

Customer Due Diligence

• These details are then reviewed by employees from the compliance department as part of their due diligence. This is to ensure that the account complies with Anti Money Laundering (AML) laws and will not be used for other illegitimate purposes. They would scan the customer information across multiple databases to see if the individual is a Politically Exposed Person (PEP) or if the name exists in one of many sanctions lists maintained by OFAC (Office of Foreign Assets Control).
• During this process, the bank may seek additional documents from the customer depending on the individual circumstances – for example, if they discover that s/he has ties to a nation that is classified as high risk.
• Another bank employee then computes a risk rating for the customer using a spreadsheet. The spreadsheet contains information from the result of the scans, nature of client’s business, where s/he lives, what is their nationality, which countries are they likely to operate and other data they deem relevant.

Disposition

• For customers that are deemed to be low risk, the application is approved and sent to another department to open the account. For high-risk customers, a committee of senior officers will review the application to determine if they will approve the application or decline.
• The documents and details of the disposition are recorded and filed for safekeeping in case of an audit or further reviews.

This entire process needs to be repeated periodically in the event that circumstances that impact customer risk changes. The frequency of reviews varies depending on the risk rating the customer received. Also, this process could be more involved in case the client is a corporation as opposed to an individual. The due diligence phase will include steps to identify who trace the ownership and identify the ultimate beneficiaries. The bank will need to gather the information from each beneficiary and conduct individual risk assessments.

Challenge

Over time, the bank found that they were losing ground to the competition and initiated a study. They identified several key opportunities for improvement.

Poor customer experience

• Customers found the forms were not easy to fill. The same information was requested in multiple forms. They were not sure if some sections were applicable to their situation and if they need to fill it.
• There was some frustration when additional documents were sought after a few days. Customers wondered why the bank did not ask for it earlier.
• Customers were not sure how long the process will take and would have liked to track the progress of their application.
• This frustration was worse for some existing customers who wanted to open additional accounts when they realized that the bank is asking for information that it already has since it was provided to them earlier when opening the previous account.

Inefficiencies within the bank

• The bank was losing money as delays in account opening translated to delays in realizing revenue.
• An audit discovered that many of the reviews that needed to done were missed. This generated a huge backlog. It was difficult to predict when they will catch up with the renewals and what resources were required to do so.

Solution

Management decided to invest in a digital program that improves the client onboarding process. A small cross-functional team comprising of 4 developers and a representative from the client onboarding team was formed. They were asked to develop a Minimum Viable Product with the following features.

• Create a better user experience for the customer. Start with a simple online application that the customer can use to open an account. The forms were designed to be interactive so that responses to the initial set of questions would drive what further questions were asked.
• Most of the customers were spared the trouble of responding to questions that were deemed more intrusive unless it was absolutely necessary. For example, an entire section was required to be completed only for individuals from nations classified as high risk.
• The Client Onboarding team from operations worked with the technology team to model the entire workflow using a process modeling tool.
• The process model was developed using an intuitive visual interface that looked like a flowchart detailing the individual steps and decision points. From the model, many aspects of the workflow application were generated automatically. This meant that corrections could be made quickly and a simple portal was developed in weeks.

Initial Results

The first version was quickly tested in the cloud environment and piloted in a test region. The feedback was very positive. Customers were happy as they were able to apply and track the status of their application from the comfort of their homes. The self-service capabilities freed up the bank employees to catch up on the large backlog of renewals. Executives at the bank were also able to see on a real-time dashboard the status of applications in flight and how many applications were in which state in the workflow. Knowing the choke points allowed them to redeploy staff to areas where they can make the maximum impact.

Next Steps

While the initial pilot was successful, there was obviously a lot of scope for improvement. A backlog of additional work was created. Below is a sample of some of these features.

• Expand the pilot to other regions the bank operates in.
• Use a Document Management System to store customer documents and tag them. When an existing customer wants to open a new account, we can use the same set of documents without troubling the customer. The KYC steps have to be repeated as the new account could be requested with a different set of attributes that may change the risk rating.
• Use an OCR on the documents to prepopulate some of the data the customer or operations staff enters. This saves time and eases the burden on verification as the data is taken directly from the document.
• When documents like passport/license expire, automatically trigger notifications to the customer to provide current documentation.
• Explore opportunities to eliminate manual entry. For example, if there is a question regarding a customer’s employer or are of business, can we pull this information from social media sites using a RESTful interface? Customer can still edit the information if it is not accurate. Similarly, can we use APIs from third-party data providers to pull data that is useful for the risk assessment?
• Codify the rules for computing the risk rating and automate this process. This may not be possible in all scenarios. Special rules for arriving at the score may be applicable for specific regions. So we need the ability to automate some steps alone on a per-region basis while keeping other steps common across regions.
• Many other areas where region-specific customization may be required were identified. For example, In one country, an employee would perform all the risk assessment activities for a customer. In another region, people specialized and were organized by groups depending on the type of screening that was being done. Also, all the employees in this country would be co-located while in the other country, many employees operated from virtual offices in their homes.
• Integrate the workflow with staff calendars and skills database so that if someone is on leave, their work can be reassigned automatically to someone else with similar skills.
• Use presence/availability information from mobile devices or chat status to distribute the workload.
• Incorporate electronic signatures in the workflow where legally feasible
• Expand the online form to other channels like mobile devices and chatbot.

As we see, there are many opportunities where digital technologies can make an impact. The product owner on the team that represents the client onboarding team is working with the various stakeholders to understand which items in the backlog can create maximum impact; analytics can also help her identify bottlenecks in the process and volumes involved. She uses this information along with data from developers on the effort involved to prioritize which capabilities will be developed when.

Most of the technologies we discussed are quite mature and can be leveraged in organizations to make incremental improvements gradually. As organizations reach a point where they are continuously making small improvements, they can look consider introducing relatively more recent technologies, like AI and blockchain. AI initiatives are more successful when one starts with a significant amount of data collected over time. For example, during the Enhanced Due Diligence phase, AI may be able to make some of the decisions being made by the committee of senior officers. While the platform pushes work to employees based on attributes like skill, access, geography, and presence, AI can be used to spread the knowledge by pushing work to employees with the goal of spreading the expertise across a wider section of the staff. A junior employee may be assigned advanced tasks if the system determines that the junior employee can take help from experts in the same location and make use of available slack without impacting the end to end cycle time. In other use cases, smart contracts can be used to initiate additional workflows if certain conditions are met. One can imagine scenarios where an account is frozen or funds are automatically moved when triggered by an external event, say when the system detects a change in ultimate beneficial owners for an account.

Catalysts and Inhibitors

Many advances in technology make this story plausible. These include Cloud Computing to provision/release computing and storage resources at will; Mobile Computing and Unified communications for multi-channel access and to capture presence information; Analytics; Process Modeling tools; Document Management etc. More than any single technology, a successful digital journey exploits the combinations of these. It is the convergence of these technologies that make it impactful.

Having said that, capability in technology needs to be supplemented with the appropriate processes and people with the right mindset to achieve success. A key success factor is the ability to experiment and incorporate feedback loops in this journey. Start with an aspect to improve; implement a solution; check if it gave the desired results; then expand on the original idea/pivot.

Until recently, IT organizations were not equipped to support their businesses in this agile manner. It was too expensive and time-consuming. As these technologies evolved and tooling became more mature, the nature of development itself was changing. We will see how with more automation many tasks performed by IT personnel became redundant and most activities morphed into some form of development work. As a result, those who embraced this change benefitted more. Over time, there were fundamental changes to how work got done, statuses were published and results measured. The model-driven capabilities in software development are not restricted to just process orchestration and workflow, platforms like JHipster automatically generate database and code to store/manipulate data and deploy them as microservices into the cloud-based on a description of the domain elements. Other low code environments bring software development capabilities closer to the end-user.

The ability to make a large number of small releases at frequent intervals is key. Keeping a release very small to just one or two features allow us to make realize the value from that quickly. It also translates to reduced risk. Less feature means that it is less like for something to go wrong. Even if something does go wrong, since the magnitude of change is small, rollbacks will be easier. The use of technology has to be in lockstep with the appropriate development processes to make an impact. Developers can no longer rely on an army of manual testers if one needs to deliver at the cadence that is required. Instead, the tests themselves need to be automated. This is the only way in which one can confidently assert that we have not regressed after making a new release, (i.e) the features that were working in an earlier release continue to work. This approach to software engineering in which software functionalities are delivered frequently through automated deployments is called Continuous Deployment.

I recently came across this article by Gary Maier, where he highlights several anti-patterns we may unconsciously follow in our rush to embrace the latest technology trend. For example, just deploying an existing monolithic software on the cloud may not always yield the benefit we desire. It does lower the entry barrier; however for us to truly reap the benefits of the cloud, developers need to look at entire environments as a consumable as opposed to a durable commodity. Just like infrastructure can be provisioned/release at will; we should have the ability to stand up and tear down entire software environments whether it is for development, testing or production at a moments notice. This includes servers, code artifacts, configuration information, storage, databases, and static data.

Conclusion

We reviewed some of the catalysts for digital transformation against the backdrop of a typical fintech use case. We also saw how an agile approach to digital transformation has a better chance of being successful.

In the next post, we will further explore the cultural aspects of a digital transformation, some thoughts on organization structure and how various stakeholders may need to adapt for the digital age.

Revolutionizing Spam Management in Salesforce Email-to-Case with Agentforce AI

The Challenge

For organizations utilizing Salesforce’s Email-to-Case feature, an often overlooked issue is the influx of spam emails generating fictitious cases, disrupting support workflows. One of our clients, a provider of industry-specific software solutions to small and medium-sized businesses (SMB) and mid-market organizations, faced this challenge head-on. Despite relying on an advanced AI spam filter within their Microsoft 365 email system—effective for general inboxes—the filter produced daily false positives. These misclassifications were untenable for their support team, who lacked visibility into IT systems to clear quarantined emails. Initially, the client opted to bypass Microsoft 365’s filtering due to these false positives, shifting the burden to manual review, which led to increased effort, potential missed customer inquiries, and a strained case management process.

What We Did

To solve this singular yet pervasive problem, we implemented a tailored solution using Salesforce’s Agentforce, leveraging its AI capabilities to enhance spam management within the client’s ecosystem. Here’s our approach: 

• AI-Powered Spam Detection: We configured Agentforce to analyze incoming emails’ subject lines, bodies, and header information. Using large language models (LLMs), the system assigned a spam score with transparent reasoning, offering contextual spam identification beyond traditional filters. 
• Prompt Optimization with Feedback: To minimize false positives—critical for the support team—we used Salesforce’s Prompt Builder to iteratively tweak LLM prompts based on agent feedback from the quarantine queue. This ensured the AI adapted to the client’s email patterns, prioritizing accuracy for legitimate support requests. 
• Quarantine Queue Workflow: Suspected spam emails were routed to a dedicated quarantine queue in Salesforce, enabling the support team to review and classify them without IT dependency, keeping the process seamless within their workflow. 
• Feedback-Driven Refinement: Agents could mark emails as “not spam” in the quarantine queue, providing reasons for their decision. This feedback guided prompt adjustments via Prompt Builder, creating a self-improving system tailored to the client’s needs. This solution integrated with the client’s existing setup, addressing their constraint of limited IT visibility while bypassing the email provider’s initial filtering challenges.

Outcomes

The results demonstrate the profound impact of this solution, with data tracked from the go-live date of March 21, 2025: 

• Dramatic Reduction in Manual Effort: Manual spam case handling dropped from an average of 3,850 cases per month pre-implementation to just 853 cases in the first full week post-go-live (week of March 24, 2025), and further stabilized with automation resolving 85% of spam over the next two months. This freed service agents to focus on their “real” work of supporting customers, saving an estimated 5.7 Full-Time Equivalent (FTE) hours. 
• Robust AI Detection: Agentforce identified and quarantined 2,800 spam cases in April 2025 and 2900 in May 2025, showcasing its ability to handle the bulk of spam traffic effectively after the initial 853 cases in late March. 
• Managed False Positives: With a deliberate 6.5% false positive rate (adjusted from <1% at a 65 spam score threshold to 6.5% at a 60 threshold to capture more spam), false positives were controlled at 197 in May 2025 and 83 in June 2025. The trained team reviewed these in the quarantine queue, averaging ~1 spam case per user monthly, a significant improvement from pre-implementation levels. 
• Team Transformation: Of the original team of six, four agents were reassigned to solve legitimate cases, while the remaining two spend approximately 15% of their day (down from a significant portion) reviewing spam, dedicating the rest to case resolution. 
• Client and Agent Feedback: 
  • “Yuga Shift helped us solve a frustrating problem quickly and effectively. What stood out was their ability to align the solution to our business goals and deliver outcomes our execs noticed.” – Director of Internal Systems.
  • “This has been a huge morale boost. Our agents are engaged again because they’re solving meaningful problems, not just filtering noise.” – CX Ops teams leader.
  • The client described the Case AI project as “a great success,” reflecting enhanced efficiency, reduced workload, and improved customer service quality. This progress, as shown in the monthly trend chart, illustrates a clear shift from manual to AI-driven spam management, stabilizing by June 2025.

The Way Forward

This case study addresses a singular yet pervasive challenge many organizations may not initially recognize: managing spam in Salesforce Email-to-Case without disrupting support operations. Moving forward, we recommend: 

• Ongoing Monitoring: Maintain a Salesforce dashboard to track manual spam, AI-detected spam, and false positive rates, ensuring the solution adapts to evolving spam patterns. 
• Enhanced Feedback Process: Refine the feedback loop with standardized reasons (e.g., “Known Customer,” “Technical Content”) via a custom field, potentially automating logging with Salesforce Flow to further optimize prompts. 
• Future Microsoft 365 Integration: As a possible enhancement, re-evaluate integrating with Microsoft 365 email spam filtering to leverage headers or bypass rules, addressing initial false positive issues once data supports a layered defense approach. 
• Broad Industry Impact: Share this success to inspire other SMB and mid-market software solution providers facing similar issues, positioning Agentforce as a versatile tool for spam management in customer support. 
• Consult with Your CRM Team: Assess spam impact and pilot this solution to drive efficiency.

Why This Matters

Spam in Email-to-Case is a stealthy obstacle for many organizations, particularly those relying on generic email spam filtering. Our innovative use of Agentforce resolved this client’s issue, offering a replicable framework to save an estimated 5.7 FTE hours—translating to significant cost savings and improved team efficiency—and elevate customer support.

Salesforce Flows in the Era of Generative AI: Are They Still Relevant?

Salesforce has long championed its no-code/low-code platform, promising a streamlined way to build business applications. Through configuration tools, admins could create data models, processes, and user experiences without extensive coding. However, limitations remained, particularly for modern UI design and complex workflows. Traditionally, overcoming these hurdles required Apex coding and custom Lightning Web Components (LWCs), skills often beyond the average Salesforce admin.

With the recent surge in AI, particularly in areas like LLMs (Large Language Models), generative AI, and AI agents, we must reconsider the value proposition of Salesforce Flows. Are they still as innovative and essential as initially intended?

Illustration using Income Tax Calculation

Let’s examine a practical example: calculating income tax based on taxable income.

Apex Code:

public class TaxCalculator {

    // Tax brackets and rates for single filers (2023)
    private static List<Decimal> BRACKETS = new List<Decimal>{0, 11000, 44725, 95375, 182100, 231250, 578125};
    private static List<Decimal> RATES = new List<Decimal>{0.10, 0.12, 0.22, 0.24, 0.32, 0.35, 0.37};

    public static Decimal calculateIncomeTax(Decimal taxableIncome) {
        Decimal tax = 0;
        Integer bracketIndex = 0;

        // Iterate through brackets, calculating tax for each portion
        while (taxableIncome > 0 && bracketIndex < BRACKETS.size()) {
            Decimal bracketTop = BRACKETS[bracketIndex + 1]; 
            Decimal bracketBottom = BRACKETS[bracketIndex];
            Decimal rate = RATES[bracketIndex];

            if (taxableIncome >= bracketTop) {
                tax += (bracketTop - bracketBottom) * rate;
                taxableIncome -= (bracketTop - bracketBottom);
            } else {
                tax += taxableIncome * rate;
                taxableIncome = 0;
            }

            bracketIndex++;
        }

        return tax.setScale(2); // Round to 2 decimal places for currency
    }
} 

Salesforce Flow:

While the Apex code may initially appear complex, even non-programmers can gain understanding by leveraging tools like ChatGPT or Gemini. By simply pasting the code into these AI-powered tools, users can receive plain-English explanations, such as:

“The primary goal of this Apex class (TaxCalculator) is to calculate the income tax owed by a single filer in the United States based on their taxable income. It uses the tax brackets and rates defined for the year 2023.”

This demonstrates how AI can bridge the gap between technical code and everyday understanding, potentially leveling the playing field for those without programming expertise. Experienced developers might also raise concerns about the time and complexity of building Flows compared to writing code. Additionally, traditional software development lifecycle (SDLC) practices like unit testing, debugging, and version control are not always as seamless in Flows. Salesforce has made strides in addressing these concerns, but gaps remain.

Generative AI: A Disruptive Force

The incremental improvements offered by Flows feel less impactful compared to the disruptive potential of generative AI. Consider how an AI tool like BPMN-GPT can auto-generate complex business process models, minimizing the need for manual Flow orchestration. Similarly, AI-powered UI builders can create responsive interfaces across devices, potentially outshining the capabilities of Screen Flows.

Beyond Processes and UI: A Broader Perspective

While my examples focus on logic and UI, Flows also play a role in other areas. However, we’re seeing AI encroach here as well. For instance, AI-driven chatbots can handle customer interactions that previously required intricate Flow logic.

The Challenge for Salesforce

It is possible for Salesforce to invest in:

• Deeper AI Integration: Infuse Flows with AI capabilities, perhaps by allowing users to leverage LLMs or other AI tools directly within Flows.
• Enhanced Developer Experience: Address pain points related to testing, debugging, and version control to streamline Flow development.

The question is: Are investments in “Deeper AI integration” and “Enhanced Developer Experience,” as outlined above, sufficient for Salesforce to maintain the relevance and value proposition of Flows in the face of rapid AI advancements? While these improvements are undoubtedly crucial, Salesforce needs to consider if they are enough to differentiate Flows from increasingly powerful AI tools that can automate processes, design UIs, and even handle complex logic.

To truly stay competitive, Salesforce might need to think more broadly:

• Redefining the Role of Flows: How can Flows evolve to complement AI tools, rather than compete with them? Perhaps Flows can become a user-friendly interface for interacting with AI-powered features.
• Leveraging Unique Salesforce Strengths: How can Flows leverage Salesforce’s vast ecosystem of data and integrations to deliver functionality that generic AI tools can’t easily replicate?
• Prioritizing User Experience: Even with AI assistance, how can the Flow building experience be made more intuitive and accessible to a broader range of users?

What are your thoughts? Is Salesforce rising to the challenge, or is it falling behind in the face of rapid AI advancements?

The Road to Digital – Part III (Execution)

Background

In earlier articles in this series, we explored these aspects from Digital Transformation

• Digitalization and the beneficial outcomes that one can expect by undertaking a journey in digital transformation.
• The catalysts in terms of advances in technology that enable digital transformation and a more concrete example of how such a journey would look in a typical enterprise.

In this final article in the series, we will explore how this impacts the people who participate in the journey; how employees need to reinvent themselves so that they continue to be valued; and how enterprises adjust their operating models to take advantage of these trends.

The KYC example in the previous post illustrates how agile methods are used in the software development process. However, agile is not just a software development methodology but applies as much or more to other aspects of the business. Let us stay with the KYC example in the previous to explore this further. The Product Owner for the program was not from the IT department, rather she was selected from the operations group responsible for performing KYC. She had a vision for the end product informed by an understanding of the goals of the program. She directs the communication efforts, alerting the team to significant events that impact the program such as a new regulation that requires capturing added information. She is also responsible for any course-correction that is inevitable in large engagements as we learn to use the feedback from earlier iterations. She does this by managing the backlog and prioritizing features as necessary. The prioritizing activity is a judgment made by her based on the following estimates.

• Value: Which feature when implemented has the greatest impact on the program. Being part of the business/operations group, she is better equipped to make these decisions rather than someone internal to IT.
• Development effort: The dev team provides her with an estimate of how easy/difficult it is to develop the capability for a feature.
• Other operational factors: These could include the effort to train staff if it entails a significant change from current procedures and communications that need to be sent out.

This shift in focus to a value-based operating model has implications for financial models for budgeting and accounting, organization culture, and talent management.

Organizational impacts

Financial Models: Budgeting vs Funding

Most enterprises have an annual budget cycle that looks something like this

• Somewhere around August, this exercise is kicked off. As the owner of your “cost center”, the manager is required to provide his “ask” in terms of the budget for the next year
• If lucky, he is notified in November/December, that the ask was granted with an x% reduction. The not so lucky ones get notified in January.
• In February, he finds out that he is “over budget”. The expenses from December were not properly accrued and the “Carry Over” projects have to be closed.
• In October, he is informed that he “under budget” and will scramble to use it lest he loses it

The manager’s performance is rated against his ability to stay within budget instead of the value delivered. This inhibits his ability to respond to changes in the operating environment. This misalignment has at least one of two consequences. Technology initiatives tend to deliver lower value or there is opaqueness around work performed.

Here is an alternative approach leveraging agile practices to make a distinction between granting money, viz., budgeting and managing money, viz., funding. Some elements of how such a mechanism might work.

• Budgets are allocated for specific themes in the annual budget under a broader, (say) three-year program.
• Product Owners map their themes or epics under the broad budget items.
• As the user stories within the product backlog are elaborated, the various components of cost are estimated by development and operational teams.
• Similarly, the expected value of implementing the story will be provided by the product owner. To do this, the product owner works with the user community for a feature enhancement/new capability. If it is to pay off technical debt, the decision will be made based on input from the technical team.
• As described before, the grooming and prioritization of the product backlog are informed by an assessment of both the cost and associated value.
• Post-deployment, the value redeemed within the budget cycle is captured.
• Additional funding is granted based on the value redeemed.
• Tools used to manage the product backlog are integrated with the financial tools and processes so that the requisite monitoring and alerting happens.
• Tool integrations also promote transparency in reporting as the underlying data from financial tools and product backlog are synchronized
• Quarterly/bi-annual reviews could be more productive. Decisions on whether to provide/deny additional funding are informed based on accurate information from the reporting tools.

Cultural

It is well understood that there is a strong correlation between the success of transformation initiatives, organizational culture, and ease of acquiring mindshare with the stakeholders. Let’s explore some strategies to overcome resistance and promoting the status quo. Many of us have encountered/experienced sentiments like this is the way things have always been done or why fix what’s not broke. Here’s a great experiment that illustrates this point. Let us take the same KYC example from the previous article. It is quite possible that employees in different geographies have allegiance to a process followed locally and so resist changes to standardize. Many of these employees may be “traveling in time” on a daily basis. At home, they and their family members frequently interact in social media; they use the latest smartphone; use apps for checklists, calendar, monitoring investments and interacting with various service providers. The same employees when they show up at work may get transported backward in time. They open 15 windows for emails, its attachments, multiple spreadsheets, and proprietary applications often copying data from one window to another. Influencing the employees who do not find this time travel all that appealing by showcasing how the same workflow can be reimagined using a prototype may be helpful.

A consequence of changes in how work gets done is refactoring of the workforce. Many of the advancements in technology also enable operations and other non-IT personnel to self-service themselves instead of relying on IT. With some training on tools like rules engine and tools to author process models, many of the SMEs can work on product/platform teams that manage the workflows. Conway’s law is a significant impediment. Here is one article that discusses strategies to overcome this.

Another consequence of the financial model suggested earlier is that there is more process, but less bureaucracy. Teams that focus on due diligence, governance, and administrative matters can be leaner, but also more effective.

In his book, Dealing with Darwin, Geoffrey Moore describes the idea of core vs context to describe how organizations evolve. A company’s core is what differentiates it from its competition. It is something that gives the company a unique advantage because of an IP or a secret sauce it holds and through which it generates higher revenue or can operate with a higher margin. Context is what the company does that is necessary for it to function, but not a differentiator in the marketplace. In this interview, Moore offers some suggestions for companies to discover their core. Data Science can also help. This is important for digital transformation initiatives when it comes to setting the agenda and prioritization. While determining ROI and where investments need to be made, organizations would prefer to invest in its core.

For example, in financial services, company A may have an established presence and a very high market share but be constrained in its ability to innovate quickly. Company B, a new fintech, on the other hand, could be very agile, quick to market new capabilities. They would likely have greater success in attracting new customers by highlighting a great user experience and less friction during the onboarding process. Company A, on the other hand, may choose to focus on customer retention strategies while it figures out how to disrupt from within in the background – like in the KYC example earlier. As an example, because company A has been around for longer and since it enjoys, greater market share, its ROI when it comes to investing in technologies like AI that leverage data science. As time progresses, company B may be acquired by company A – or company B may choose to reinvent itself. It may be able to offer the algorithms it developed using the large amount of data as a service to other FinTechs.

Another example would be a company that is expanding through mergers and acquisitions. An important goal might be to integrate the various systems in order to provide a unified experience to all parties. Such companies may choose to adopt an API first strategy to further these goals.

Impacts on people and their roles

The KYC illustration in the previous article highlighted the changes in how services are developed, delivered and consumed. For this to be successful, the individuals who develop and deliver these services need to not only develop different/additional skills but also undergo a change in mindset. Let us explore some these in this section.

Developer: In a traditional setting, there were distinct roles associated with requirements gathering, design, coding, testing, deployment, and support. Each of the roles became more important in the corresponding phase of the project. In a typical agile sprint, all these activities are performed within the sprint cycle. The shift toward making more frequent, but smaller releases means there is less opportunity for handoffs across teams. The same team code, test and deploy the software. In addition, they participate in backlog grooming sessions in lieu of traditional activities like requirements gathering, design, and estimation. With the advent of frameworks to support automated testing, the act of testing also involves coding and so the a full stack developer is expected to perform all these activities.

In terms of skill, this means s/he should know her way not just around the traditional development tools like an IDE, but also work with the product backlog and tools used in continuous integration and continuous delivery. Examples of these are Jira, Rally, Confluence, Jenkins, TeamCity, Upsource, git.

Further, it is not just knowledge of these tools, but also the mindset of not being more accountable for what you produce as opposed to throwing stuff “over the wall” to the testing team/documentation team. Working with an agile team can also be different. The team is the unit for which many of the performance metrics around productivity and quality are captured. So the dynamics within the team are different. There is an expectation to share all artifacts/work products even while they are still work in progress.

Project Managers: A project manager typically morphs into a scrum master role. Instead of managing, this person becomes more of a facilitator ensuring that the team follows a routine within each sprint and that removes any impediments that the team may face.

In a traditional project, a major activity for a PM would maintain checklists, add entries as new tasks are discovered and check them off when done by following up with the individuals. In an agile team, there is greater accountability with each developer and s/he is expected to update status directly in the backlog. The scrum master’s role is now elevated to that a process QA – Ensuring that team members feel empowered to perform their activities and removing any friction in the process.

A project manager who understands the business processes; amassed significant subject matter expertise and has nurtured relationships within a user community may also be effective as a product owner in that domain.

Product Owners: We have discussed this role at length. Someone who has the vision and maintains a roadmap for the product; understands the value proposition and makes informed choices on prioritization by weighing expected value against cost estimates. The typical roles and responsibilities of a product owner are well documented. Instead, we focus here on the aspects of this role that are critical from a digital transformation perspective.

The PO is responsible for marketing the product within its user community and other stakeholders and secures funding as necessary. They are in many ways change agents. Creating value also means driving value and promoting adoption. The PO has a good understanding of the organizational dynamics and navigates her way to driving value.

Similar changes should be expected within the support functions that are contextual to the enterprise.

Summary

We saw how organization can use digital trends to transform to reach their growth target and be more efficient. We reviewed some of the catalysts and inhibitors for enterprises starting on this journey. Finally, we also reviewed execution strategies that organizations may consider to implement such a program along the dimensions of people, process and technology.

From ‘What’ to ‘Why’: Unlocking Better Outcomes Through Consulting

A young boy is sitting under a tree, seemingly doing nothing. A passerby scolds him for being lazy and wasting his time. The boy, with a curious and innocent tone, responds with “Why?”

The adult, taken aback, explains that he should be working hard, studying, and getting good grades so he can get a good job, earn money, and eventually retire comfortably.

The boy continues to ask “Why?” after each explanation.

“Why get a good job?” “To earn money.” “Why earn money?” “To buy a house, a car, and nice things.” “Why buy those things?” “So you can enjoy life and be happy.” “Why wait until then to enjoy life? I’m happy now.”

The adult is left speechless, realizing the boy has a point. The boy’s simple contentment challenges the conventional idea that happiness is only achievable after years of hard work and striving. This humorous tale reflects an essential truth: sometimes, the simplest approach is the best way to achieve a goal. Of course, the boy’s method isn’t exactly sustainable—or socially responsible—but his questions remind us of the importance of challenging assumptions and rethinking conventional wisdom. It also underscores a key mindset for effective consulting: asking “why” to uncover the real need, challenging assumptions, and finding simpler, better solutions.

At Yuga Shift, this story resonates deeply with our approach to consulting. In the crowded marketplace of technology consulting, many firms claim to prioritize customer success, but few truly deliver on this promise. We believe there is a world of difference between simply taking orders and being a true consultant. Our approach is centered on two core principles: Time to Value and Outcome Focus. While these might sound like corporate buzzwords, we live by them, ensuring they permeate every project we undertake.

Time to Value: Delivering Solutions, Not Delays

“Time to Value” means delivering tangible results quickly and efficiently. It’s about recognizing that our customers’ time is valuable and that the sooner they start seeing benefits from a solution, the better. However, this doesn’t mean rushing to implement the first idea that comes to mind. Instead, it requires a deep understanding of the problem at hand, ensuring that the solution is not only fast but also fit for purpose.

Outcome Focus: Solving Problems, Not Checking Boxes

Too often, consultants focus on delivering what’s asked for without questioning whether it solves the right problem. At Yuga Shift, we prioritize outcomes over outputs. This requires digging deep to uncover the true business needs behind a request.

We use techniques like the Five Whys method to get to the root of the problem. For example, a customer once insisted on automating email notifications for every support ticket created. On the surface, this seemed straightforward, but by asking “why” repeatedly, we discovered their real goal: ensuring customers felt informed about their ticket’s progress. The final solution was a mix of milestone-based updates and a customer portal—a more comprehensive and customer-friendly approach.

The Power of “What For” in Problem Reframing

A critical part of our process is reframing requests to focus on outcomes. We use a widely used format for writing effective user stories in Agile development:

· As a [persona], I want [feature], so that [motive/desired outcome].

This approach shifts the conversation from “What do you want?” to “What are you trying to achieve?” It ensures alignment between technology and business goals, avoiding missteps like over-engineering or overlooking simpler, equally effective solutions.

For instance, a client asked us to pull information like Annual Contract Value (ACV) and payment dues from their external systems into their CRM so their sales team could have better context during client interactions. Their initial requirement was phrased as “real-time” integration with a point-to-point setup. By reframing the requirement using this structure and asking “why,” we discovered that the real need was to provide updated information before customer calls—not real-time updates. We proposed using lightweight middleware they already owned and implemented batch updates instead of real-time integration. This solution was simpler, less expensive, and fully met their business goals.

Empowering Customers to Make Informed Decisions

We understand that every customer faces unique constraints—budget, timeline, resources, and priorities. That’s why we always present multiple solution options, complete with estimates and potential trade-offs. This transparency empowers our customers to weigh costs against benefits and choose the path that best fits their needs.

For example, a manufacturing client wanted to enhance their sales team’s ability to create accurate and compelling quotes quickly. They requested an advanced quoting tool integrated into Salesforce to include complex pricing calculations, discounts, and dynamic visualizations. Upon closer examination, we realized that their top priority was to reduce the time sales reps spent creating quotes and to improve quote accuracy.

We presented three options:

1.     A lightweight enhancement to their existing quoting process, which met 80% of their needs and could be implemented within weeks.

2.     A Salesforce-native CPQ (Configure, Price, Quote) tool setup that covered 95% of their requirements but required a moderate budget and timeline.

3.     A custom-built solution with every feature they requested, requiring a significantly larger investment of time and resources.

Through discussions, the client recognized that the additional 20% of functionality from the custom solution would rarely be used and that their goals could be met with a simpler approach. They opted for the first option, complemented by some additional training, which allowed them to achieve their desired outcomes with minimal disruption and at a fraction of the cost.

The Yuga Shift Difference

At Yuga Shift, we see ourselves as partners in our customers’ success. We don’t just deliver projects; we solve problems. Our obsession with Time to Value and Outcome Focus ensures that every solution we implement drives meaningful impact—whether it’s a quick fix that avoids unnecessary complexity or a strategic investment in a transformative solution.

By asking the right questions, reframing problems, and empowering customers to make informed choices, we bridge the gap between technology and business outcomes. These are strategies for being an effective consultant at the micro level. For a broader perspective on aligning technology and business, you can explore my article on digital transformation: The Road to Digital, Part II. This is what it means to be a true consultant, and it’s why our customers trust us to guide them toward success.