Tag Archives: emc

Customer Focus: The EMC Way

Every company has some core founding principles / values – some rather overt, some implicit. These are not principles related to product or technology. Nor are they related to vision. More often than not, these values are not written down. You only learn these through oral traditions of stories / myths at bars through people who have been in the organization long enough. Rarely you get to experience these first hand.

So why bring this up now?

After I shipped myself to the west coast, I am in the odd position of being in a minority (a person who was with EMC but moved to Isilon, from Hopkinton to Seattle). I am a conduit of these very myths – some I have learned (The ‘Yes it does snow in New England’), others I have lived. This is one in the latter category.

This story is from many _many_ years ago. All names (except some key principals who I am sure won’t mind) have been kept confidential for obvious reasons.

I had recently taken on a management role within the engineering organization. I was responsible for SW development and customer escalation management.

As most stories go, this one started with a rather innocuous request from a customer (BTW, they have since become one of my favorite customers – visionary, drive technology, take calculated risks and in every way, partner with us to build better products. It also helps that they are a household name – one of the few ways I can help my non techie family members understand what it is I work on). The request was for them to migrate between data centers with a special request to ensure that engineering was involved.

As it came to us, this seemed like a normal request and we assumed that engineering involvement was needed largely for review. Then the oddness started – the product we had was specifically designed for migrations. But the customer was apparently not using this product for migration.

We dug in, contacted the account team who contacted the customer. Turns out it is a migration, except it isnt a copy of the data but rather a physical move of infrastructure. And the customer wanted to keep their operations online through the physical move and were convinced that they could do this with our product.

I have to share this in all honesty – as the person responsible for carrying the quality banner, I was petrified. While the customer, in theory, was RIGHT (aren’t they always?), we had never quite anticipated a customer contemplating using the product in this manner. Oh yeah, the move was going to happen on Thu and we learned about this on the Monday of that week.

Once you get past the seven stages of coming to terms with reality, we got down to brass tacks (and yes, involvement from engineering was going to be more than just review :-)). One of the engineers from my team was going to head down to the customer site (drivable distance from Hopkinton) to perform this ‘move’. He got testing and practicing the move procedure working out any kinks. So far so good and nothing too far out of the ordinary as far as customer escalations go.

One more thing …

So we have worked through the kinks, the engineer going to the customer site was feeling confident. Thursday morning we run through a last check. Lo and behold, we found out that the long distance SFPs that are needed to enable the migration were misplaced at the customer site. For some reason that I cannot remember, these were not SFPs that were just lying around (I seem to remember that the default was to use short distance SFPs). So, here we are at noon on Thu with everything set except the key ingredient to make the move successful.

I remember going to my manager (@MattWaxman) with a complete dead look that basically said, ‘I am out of options’. In an inspired moment, he suggested something off the wall – since then I have learnt that desperation makes you creative – “Let’s email all the people we know at EMC (our PMTs, BMTs, execs, support) with a system wide SOS that said something to the effect of ‘We need long distance SFPs for a customer in the next three hours – here is the model number. Please contact us if you have any of these lying around. We need 24.’.”

We sent that note – expecting this to be a complete Hail Mary with no chance of success.

Not having much else to do, we ran through one more dry run for the move and let the account team know that we may have to cancel since we didn’t have the SFPs. The final go no go was set at 3:00 PM. The engineer was leaving at 4:00 PM for the drive over.

Here is what happened instead.

I returned to my office post that dry run. And on my desk, I had ten to twenty different packages of SFPs – some from people I knew, most of these from people I didn’t know. I had one guy who drove from our factory in Franklin MA with a box of these SFPs. His exact statement to me was – ‘Someone told me that they had heard about you needing SFPs for a customer. I have tested all of these – they work. Make the customer successful’. I had sticky notes that said the same thing.

Needless to say, the engineer was able to take this on their ride to the customer site with them. The move was executed flawlessly. In fact, the customer’s end customers didn’t see a single app bounce. This customer and that account team became one of our biggest advocates.

What did I learn

Customer focus was something Dick Egan intentionally drove into the EMC culture. Many many years removed from his direct involvement with the company, EMC employee #1 continued to cast a large shadow. It tells you how important founders (and the culture they establish) are.

Customer success is everyone’s responsibility whether you work on a product or not. Customers make the world go round. Over time I have been in many situations where my direct responsibility would have caused me to not act. In all those situations, I try to act in the same proactive ownership culture that I was the beneficiary of.

Always focus on what’s right for the customer. The easy answer above would have been to declare the use case as unsupported. The harder answer was to look past the execution risk and focus on what the customer justifiably needed. Many thanks to the customer for pushing us.

Even as I type this blog many years removed from the actual incident, I continue to be touched by the camaraderie and the sheer stick-to-itiveness of the EMC culture that did not allow us and the customer to fail.

It is one of those rare moments where it feels like the entire company stands behind you as an individual helping you succeed. In my day-to-day interactions within EMC, I continue to use this incident as the yardstick by which I measure myself.


Federation – A new business model for disruptive innovation

[Even if it has been stated elsewhere, for this particular post, it is even more important to state that these are my views. My interest in this topic is to help organize my thoughts on the implications of the Federation structure created at EMC. Equally importantly, I am an EMC employee and an EMC shareholder, so I have my biases. Consider yourself warned!].

What is the Federation?

For the past six months or so, EMC has organized itself as a Federation. For the official announcement and details behind it, please look here. In case you see it on slides, here is the logo that is being used for the federation.

EMC Federation Logo

In a nutshell, the concept of the Federation is the coexistence of independent companies with a shared vision and at the end of the day, to a large extent a common P&L.

Why organize in this way?

Usually, when looking at business organizations, there are two common ways of organizing. Obviously, no one mechanism of organizing is superior to the other. The correct answer for any given organization depends on a bunch of factors – the desired end goal, market dynamics, level of overlap between the businesses and finally, which bets does the organization want to place. In other words, there is no right answer.
The two common ways of organizing are

  1. Monolith
  2. Conglomerate


While the word monolith creates all sorts of mental images, this is by far the most common way of organizing. The organization is built around a singular vision. Different businesses within that organization are organized as business units. Typically, such organizations are able to benefit from shared services – HR, IT, Sales etc. The goal of this mode of organization is clarity of purpose, driving more alignment and efficiency in terms of common capabilities that can be optimized. This doesn’t stop these companies from being diverse – just that the degrees of separation between the individual businesses is relatively small and usually, focused on the same or very adjacent markets. The selling motion is usually similar – the end customer tends to be similar. In other words, the channels are more or less consistent. Naturally, as with most things in life, there are shades of gray – the degree of freedom afforded each business unit is a variable, what shared services operate is a variable etc.
So, whats the downside of such an organization? The greatest strength of such organizations is also their weakness. These organizations tend to be pretty set in terms of their mode of business, what channels and markets they can go after. So, in some ways, for such companies, it is difficult to change their core fabric. Not impossible but definitely herculean. Purely from a business perspective, optimization for a particular market implies that you are completely subject to the vagaries of that market. So, any macro or micro economic trends that impact that particular market leave such a company vulnerable.


To counter some of the issues seen in the monolith, the conglomerate emerged as a way to get diverse selling motions, diverse companies under the same organizational umbrella. The businesses are not required to be related to each other. The conglomerate functions as independent businesses pooling their P&Ls together. Berkshire Hathaway, General Electric and the Tata Group are some of the prominent examples of this structure. This organizational structure gives up on the efficiency of a common set of services in order to be able to diversify what they sell to their customers. Each business may have its own discrete vision, strategy and market. The common binding item across the conglomerate is the set of shared values across the teams. To illustrate this point, transactions across businesses within the conglomerate are identical to transactions with companies that are not within the conglomerate. The businesses are free to optimize to meet their objectives.

Why Federation?

With this perspective, let’s now look at the Federation.

In some ways, EMC has been on this journey since the VMware acquisition in 2003 (yeah – it was that long ago!). Right from the get go, the interactions between EMC and VMware have been independent. I will not say that this was easy at first. My first interaction with VMware was as a developer dealing with a customer escalation where the customer expected that we would behave as one company. There were a few moments of awkward phone silence as we explained to the customer that we were independent entities. As we all grew comfortable operating in this model, folks on both sides understood why this “together but independent” state was important. At EMC, we realized that we had to win VMware’s business on our merits and that VMware had to interface with EMC’s competition in the same way that they interact with EMC. As that message was understood across both companies, EMC mobilized to have the best possible integration with VMware not because of our inherent affinity but because we recognized the business value that VMware brought.

With VMware as a separate entity, this allowed two additional benefits:

  • VMware was able to maintain and develop its go-to-market independent of EMC. This gave it access to different markets and different levers to enable.
  • VMware was free to innovate independent of the impact to EMC. They were not beholden to EMC’s inherent interests and were able to take a different stance than a business internal to EMC might have been able to.

Clayton Christensen has talked about the innovator’s dilemma where disruptive new technology suffers from the hegemony of the current dominant technology. It is far more deeply entrenched than just technology. For a big successful company like EMC, the entire company has been tuned to make the current technology successful. GTMs, incentives, selling motions, profitability structures, purchase cycles, relationships – the list is endless – are all geared to the current technology. Now imagine changing all that after recognizing a market shift while maintaining your current revenues and while people are changing what they do. Despite best intentions, this transformation is a perilous journey that few dare undertake and even fewer complete successfully. To say nothing about going to individuals who care passionately about the products they work on and tell them that the next big thing is going to surpass their pride and joy.

With this backdrop, fast forward to today. The world of IT has been changing dramatically. You can see that there is a shift in how data is generated, how it is consumed and utilized. Data is the new frontier. The implications of this have not been fully realized. However, it is clear that the magnitude of this shift is enormous. So, the same conditions that led to VMware being kept as an independent entity are now in effect for attacking this new market. That independent entity is Pivotal.

So, you have three independent companies (shades of a conglomerate) all working in adjacent markets (shades of a monolith) working with a shared vision (shades of a monolith) with the independence to optimize what they need for their business (shades of a conglomerate). That’s the Federation – not a monolith, not a conglomerate but an amalgamation of both.

It is typical of what I have seen within EMC – we have a big challenge in front of us, we tackle it head on with a very creative solution. I have this mental image of whoever came up with this as waking up one morning with this solution in their heads and feeling like they have solved world hunger – this is brilliant stuff!

Does this mean that everything is perfect? It never is and there are tradeoffs that are needed to make this successful. For one, this strategy does mean that the individual businesses will have to work that much harder to maintain alignment. The businesses have to be judicious about where it is okay to overlap in technology (since they are in adjacent markets) and what to do when that inevitable overlap arises.

If this strategy does work, this may be an interesting way to address the innovator’s dilemma and guide future companies trying to innovate disruptively while continuing to execute on existing businesses. To me, the beauty of this approach is that it takes that challenge out if the realm of organizational discipline (which is frail) and canonizes it within the corporate structure. I, for one, am rooting for its success (and beyond just the ‘I am an EMC employee’ reason). We will see how the story unfolds. As Churchill aptly said, ‘However beautiful the strategy, you should occasionally look at the results.’