The People Between Strategy and Reality Run Salesforce

When organisations discuss Salesforce success, the conversation almost always gravitates towards two very visible groups. At one end sit the executives and senior stakeholders who approve budgets, define strategic priorities and establish what success should look like. At the other end sit the users who are expected to adopt new processes, embrace new technology and ultimately deliver the business outcomes that justified the investment in the first place. These two groups dominate most conversations about transformation. We talk extensively about executive sponsorship. We talk endlessly about user adoption. We debate change management, training, governance and return on investment. Yet between these two groups sits a third audience that rarely receives the same level of attention despite carrying one of the most important responsibilities in the entire transformation journey. These are the Product Owners, Business Analysts, Salesforce Managers, Operational Leads and Programme Managers who spend their days translating business ambition into operational reality. They sit in the uncomfortable space between strategy and execution. They are expected to understand what senior leadership wants to achieve while simultaneously understanding the practical realities faced by frontline users. They are responsible for taking high-level business objectives and converting them into requirements, processes, workflows and ultimately user experiences. In many ways, they act as interpreters between two groups that often speak entirely different languages. The executive team speaks in terms of growth, efficiency, customer experience and visibility. End users speak in terms of workload, productivity, practicality and getting through their day. The middle layer must understand both perspectives and somehow bring them together into a solution that works for everyone. Over the years, I have become increasingly convinced that many Salesforce projects succeed or fail long before training begins and long before users log into the system for the first time. The determining factor is often the quality of translation that occurs within this middle layer. When organisations struggle with adoption, poor data quality, inconsistent processes or declining user engagement, the root cause is frequently not technology. Nor is it usually a lack of effort from users. More often, the problem can be traced back to a disconnect between what the business wanted to achieve and what users were ultimately asked to do. Somewhere during the journey from strategic objective to operational reality, meaning was lost. This happens because every Salesforce project begins with a business problem rather than a technology problem. Leadership teams rarely wake up and decide they need a new validation rule or an additional page layout. They identify challenges that are affecting business performance. Perhaps sales forecasts cannot be trusted. Perhaps customer service teams lack visibility into customer interactions. Perhaps operational reporting takes too long to produce. Perhaps different regions are following different processes and creating inconsistency across the organisation. These are genuine business concerns that deserve attention. However, those concerns must travel through multiple layers of interpretation before they eventually become something that a salesperson, service agent or manager interacts with on a daily basis. The challenge is that every stage of this journey introduces opportunities for misunderstanding. A leadership objective becomes a project requirement. The project requirement becomes a user story. The user story becomes a design decision. The design decision becomes a configuration choice. The configuration choice becomes a process. The process becomes a screen that users must navigate every day. Each step appears logical when viewed in isolation. Yet collectively they can create a significant gap between the original business objective and the final user experience. By the time the solution reaches end users, it may bear little resemblance to the problem it was originally intended to solve. One of the most common examples can be found in sales organisations attempting to improve forecasting accuracy. Leadership teams often identify forecasting as a weakness because they lack confidence in the numbers presented during executive reviews. The logical conclusion is that more accurate and complete data is required. Project teams respond by introducing additional mandatory fields, more detailed opportunity stages, stricter validation rules and enhanced approval processes. Each decision appears sensible because it supports the objective of improving data quality. However, the sales representatives responsible for maintaining that information often experience the outcome very differently. What leadership sees as improved governance, users experience as additional administration. What leadership views as greater visibility, users experience as increased complexity. The result is frequently lower adoption, declining data quality and growing frustration across the organisation. What makes these situations particularly interesting is that nobody involved is necessarily wrong. Leadership is justified in wanting better information. Project teams are justified in seeking stronger controls. Users are justified in wanting efficient processes. The problem is not that one group is correct while another is mistaken. The problem is that nobody successfully translated the needs of all three groups into a coherent solution. The focus shifted towards process design and technical implementation while losing sight of the human experience at the centre of the transformation. This distinction between process and behaviour is one that organisations consistently underestimate. Salesforce projects devote significant effort to documenting processes, mapping workflows and capturing requirements. Yet far less time is spent understanding how people actually work. A process map may describe the steps involved in updating an opportunity, but it rarely captures the realities of a salesperson moving between customer meetings, responding to urgent requests and juggling competing priorities throughout the day. A service process may look efficient on paper, yet fail to account for the pressures experienced by agents managing high volumes of customer interactions. The gap between process design and operational reality is often where adoption challenges begin. The strongest Product Owners and Business Analysts understand this instinctively. They recognise that their role extends far beyond gathering requirements and facilitating workshops. Their true responsibility is understanding behaviour. They are naturally curious about how work gets done. They spend time observing users rather than simply interviewing them. They look beyond stated requirements to understand underlying motivations. They challenge assumptions and ask difficult questions. Most importantly, they recognise that users do not experience Salesforce as a collection of requirements. They experience it as part of their working day. Every field, workflow and process either helps them perform their role or creates additional friction. As Salesforce environments become increasingly sophisticated, the importance of this translation function continues to grow. Over the past decade, organisations have gained access to an extraordinary range of capabilities. Automation has become more powerful. Integrations have become more accessible. Reporting and analytics have become more advanced. Artificial intelligence is now being promoted as the next major evolution of enterprise technology. Each of these developments offers genuine opportunities to improve organisational performance. However, each also introduces the potential for additional complexity. Complexity rarely arrives in dramatic ways. It accumulates gradually through hundreds of seemingly reasonable decisions. A new field is added because somebody requests additional reporting. A validation rule is introduced to improve data quality. An approval process is implemented to strengthen governance. A workflow is enhanced to automate communication. Individually, these changes often make sense. The problem emerges when nobody evaluates their collective impact on the user experience. Over time, organisations create systems that are technically impressive but increasingly difficult to navigate. This is where the middle layer performs one of its most valuable functions. It acts as a defence against unnecessary complexity. Somebody must be willing to challenge stakeholder requests when they introduce more burden than value. Somebody must ask whether additional information genuinely improves decision-making. Somebody must advocate for simplicity even when complexity appears attractive. This responsibility often falls to Product Owners and Salesforce leaders who understand that every additional requirement carries a hidden cost. That cost may not appear in project budgets, but it appears every day in the time, effort and attention required from users. I often describe this as cognitive debt. Most organisations understand the concept of technical debt. They recognise that shortcuts taken during development can create future maintenance challenges. However, far fewer organisations consider the accumulation of cognitive debt within their Salesforce environments. Every unnecessary field creates cognitive debt. Every confusing process creates cognitive debt. Every exception, workaround and inconsistency adds to the mental effort required from users. Individually these burdens may appear insignificant. Collectively they can transform a once intuitive system into something that feels overwhelming. The consequences of cognitive debt are often subtle at first. Users take slightly longer to complete tasks. They become more selective about what information they enter. They begin developing personal workarounds. Managers spend more time questioning reports. Confidence in the system gradually declines. Eventually organisations find themselves facing the very problems they were trying to solve. Data quality deteriorates. Adoption weakens. Reporting becomes unreliable. Yet the response is often to add more controls, more processes and more requirements, inadvertently increasing the problem rather than addressing it. Unfortunately, many organisations place individuals into middle-layer roles without adequately preparing them for the complexity of the position. High-performing operational staff are frequently promoted into Product Owner or Salesforce leadership roles because they possess valuable business knowledge. While that knowledge is undoubtedly important, it represents only part of the capability required. The role demands facilitation, stakeholder management, prioritisation, communication, negotiation and behavioural insight. It requires the ability to challenge senior stakeholders diplomatically while maintaining credibility with frontline users. It requires balancing competing priorities while protecting the integrity of the user experience. Yet formal development in these areas remains surprisingly limited. Organisations invest heavily in Salesforce certifications, implementation partners and technical training. They invest in project methodologies and governance frameworks. However, they often overlook the people responsible for connecting strategy with execution. As a result, many Product Owners are expected to operate as miniature consultants, change managers, business analysts and trainers simultaneously without receiving meaningful support in any of those disciplines. They learn through experience, often under significant pressure and with limited guidance. This becomes particularly important when we consider the relationship between translation and adoption. Throughout my career, I have worked with organisations that genuinely care about user adoption. They invest in training programmes. They create communications plans. They organise launch events and provide support materials. Yet despite these efforts, adoption remains inconsistent. The reason is often misunderstood. Training can accelerate adoption, but it cannot compensate for poor translation. If a process is fundamentally disconnected from operational reality, training cannot solve the problem. If a workflow introduces unnecessary complexity, training simply teaches users how to navigate that complexity. If key decisions were made without understanding user behaviour, no amount of communication will fully overcome the resulting frustration. This is why I often argue that adoption begins long before training starts. It begins during analysis. It begins during design. It begins when somebody decides whether a field is necessary, whether a process is practical and whether a requirement genuinely supports business objectives. Every decision made during these early stages either strengthens or weakens the likelihood of successful adoption. By the time users enter a training session, many of the factors that will determine their experience have already been established. Perhaps this explains why some Salesforce environments feel remarkably intuitive while others feel unnecessarily difficult. The difference is rarely technology. More often, it reflects the quality of translation that occurred during the project's development. In successful organisations, the middle layer acts as a bridge between competing perspectives. It ensures that business objectives remain connected to operational realities. It challenges complexity before it reaches users. It protects the integrity of the user experience while still supporting organisational goals. In struggling organisations, this function is either absent or undervalued, allowing complexity and misunderstanding to accumulate unchecked. As organisations continue embracing digital transformation, artificial intelligence and increasingly sophisticated technologies, the importance of the middle layer will only increase. Technology is becoming more powerful, but power alone does not create value. Value emerges when technology aligns with the way people actually work. Achieving that alignment requires individuals capable of understanding both strategic ambition and operational reality. It requires people who can interpret business objectives through the lens of human behaviour. It requires professionals who recognise that successful transformation is ultimately about people rather than systems. Perhaps it is time the Salesforce ecosystem paid greater attention to these individuals. We celebrate technical innovation. We discuss new features and emerging technologies. We debate implementation methodologies and governance models. Yet many of the factors that determine success reside within the people responsible for translation. They are the individuals who ensure that strategy survives contact with reality. They are the people who prevent complexity from overwhelming usability. They are the professionals who transform business ambition into practical execution. The strongest Salesforce environments are not necessarily those with the most advanced technology. They are the environments where somebody consistently asks a simple but powerful question: what will this feel like for the person doing the work? That question sits at the heart of effective translation. It forces organisations to consider not just what they want to achieve, but how those objectives will be experienced by the people expected to deliver them. In many respects, that question may be more important than any technical decision made during the project. The next time an organisation evaluates the success of its Salesforce investment, it may be worth looking beyond executive sponsorship and user adoption. Both remain critically important, but neither exists in isolation. Between those two groups sits a layer of professionals whose influence is often underestimated. They are the translators, interpreters and connectors who bridge the gap between vision and reality. They may not receive the same attention as executives or end users, but their contribution is no less significant. In fact, they may be the single most important factor in determining whether a Salesforce programme becomes a genuine business transformation or simply another technology implementation. The Salesforce middle layer is rarely discussed, rarely celebrated and frequently overlooked. Yet without it, strategy struggles to become execution, technology struggles to become value and ambition struggles to become reality. The organisations that recognise this truth, invest in these individuals and develop their capabilities accordingly will place themselves in a far stronger position to realise the full potential of their Salesforce investment. Those that do not may continue searching for answers in technology when the real solution has been sitting quietly in the middle all along.