Internal Evolution, Adaptation and Change….

Warning - this blog post is about some internal EMC organizational topics, and may have less broad interest to my more technically inclined readers.  That said, I think there are some interesting things in this for people that follow the industry, and also for people who think about leadership and organizational topics in large high-tech organizations.

I write about it for three reasons: 1) being part of it is part of my ongoing/lifelong personal learning - in this case, leadership and organization at large scale; 2) many EMCers, EMC partners, and EMC customers read my blog, along with many others - and it's a good way to have a dialog on an important topic; 3) my personal philosophy is one centered on openness, transparency and sharing - always.

If it's of no interest to you - you're always welcome to NOT follow after the break :-)

Yesterday, internally we brought together the people that develop VMAX (internally this was formerly called EMC's Enterprise Storage Division or "ESD") and VNX (internally this was called the Unified Storage Division or USD).    The new team is the "Enterprise and Midrange Systems Division" (EMSD).   The organizational change and name change reflects both the broad market, the fact and that both systems are are have integrated NAS/SAN with common management now - so both are unified - not just in the organizational sense.   The use of the word "system"  vs "storage" reflects the fact that "primary storage" is starting to morph and over time, its more and more likely that primary storage subsystems will be also able to run other workloads beyond pure primary storage IP stacks.

We also aligned the teams that make VPLEX and Recoverpoint with the people that develop Avamar, Networker, Data Domain (internally this was formerly called the "Backup and Recovery Systems" or "BRS" team).   The new team is the "Data Protection and Availability Division" (DPAD).   The organizational change and name change reflects the fact that backup, recovery, continuous availability, snaps, replicas - and their application integration - are all reflective of a common continuum of copy management of the things stored on primary storage.

While a relatively small thing on the global stage (heck, there are "smaller things" that are "bigger" on the global stage - Toronto Mayor Ford is on SNL!) within EMC and for our customers - it's a material change, one that touches thousands of people, and I think will help our customers (and continue to accelerate our growth - those two things are intrinsically linked).

It's been interesting to be part of this planning and the dialog - and I wanted to share my personal perspective.

If you think about the VMAX and VNX businesses - they represent the lion's share of the storage market today (by customer count, revenue, marketshare, capacity - pretty well any metric you want to choose).   They both are best-of-breed in their own right.   They do cover very different market segments and workload use cases - but also with a fair amount of healthy overlap. 

In EMC's portfolio - they represent the "mission critical, transactional primary storage platforms".   "Primary Storage" has as it's purpose in life to store data, and then deliver it back in production use cases.   Now, when people need "super fast" primary storage, but are OK with less mature storage stacks and less of the traditional "enterprise" data services, we have other tools in our toolbox, like XtremIO.   When people need massive scale NAS that isn't transactional in nature, we have other tools in our toolbox like Isilon.  When they want to deploy on commodity hardware - ScaleIO is a great choice.

But - VNX and VMAX are the workhorses for EMC and for hundreds of thousands of EMC customers.

Separately the technologies, patent portfolio and most importantly - the teams that VMAX and VNX tick are impressive.  

Something to understand the "internal culture" of EMC has an ideal rooted in trust in individuals rather than centralized bureaucracy.  This is coupled with a belief in healthy internal competition and collaboration.  

If you think about this - to a certain point, it's not bad to have teams competing to have the best technology and solutions in the marketplace.    BTW - this is one of the core philosophies that powers the idea of the independent federation of EMC, VMware, Pivotal. 

Those that know me know a "Chadism" is "your greatest strength is always simultaneously your greatest weakness".   This belief in autonomy is one of the secrets to our acquisition and merger success - because people are given a wide latitude to execute and do the right thing when you're part of a mature business unit - or a newly acquired company.   But - taken to extremes - it creates unnecessary complexity and missed 1+1=3 opportunities.

So - if it's all great, why change and bring together the VMAX and VNX teams?  

1. If they are impressive separately, together - they are an industry force to be reckoned with.   Separately, the engineering and product teams have a scale that is really impressive - not only billions in revenues, but thousands of brilliant people.
2. Collaboration/acceleration on existing work.   Increasingly, there is a lot of shared IP across the two teams: a) they use the same hardware; b) they share a UI (Unisphere) and increasingly API framework (as we move away from legacy SymmCLI/NaviCLI towards ViPR controller restful APIs); c) they share a transactional NAS stack (UxFS), and as it gets updated, it gets updated on both.   What often happens in organizations is that when you are part of a common org, there's a tendency to reinforce these "use common IP where it makes sense"
3. Collaboration/acceleration on net new work - while always recognizing and respecting fundamental differences in market requirements.   There is a fundamental design center difference between the "Reliability, Availability, Serviceability" center that defines the thinking of the VMAX team from the "Be the best multipurpose, scale up/down hybrid on the market" that defines the thinking of the VNX team.    
   1. If you look at point #2, there are things the former VMAX team could learn/leverage from VNX team (simplification, the Unisphere core work, the unification work around NAS and block stacks) and vice versa (the hyper-robust QnA, support, and product planning that goes into the VMAX cycle).
   2. … But further than that - there is work that has been pursued separately that could be accelerated/amplified by making it a "cross platform" thing - one huge example is the work around Federated Live Migration on block and Virtual Datamovers on NAS.   If we can make universal "non-disruptive movement" (without putting a data plane in front of the data plane) - a universal thing wow, that would help a lot of customers.  Likewise, acceleration of work to leverage TLC and cMLC for certain use cases apply across both VNX and VMAX.  

Think of this "best-of-breed" but distinct segmentation/brand model has some clear external analogies.   A great example is Volkswagen (who happens to be a great customer too).

Look at these three pictures:

  

What do you see?   Three clearly distinct brands.   Yes, they are all "cars" in the sense they have engines, four wheels, etc.   Just as clearly they have different market segments they target (clearly with different requirements).   They are all part of the Volkswagen group.   The analogy here is VNX and VMAX within EMSD.

The way Volkswagen seems to do this so effectively is operating these brands as distinct, but wherever they can - leveraging common platforms and IP to accelerate innovation, to accelerate their ability to delight their customers and gain market share.   But - they also are very wise about making each of their brands fit their target - not simply mash everything together. 

It's not a coincidence that as of right now, Volkswagen are the revenue leader in the automotive market.   Imagine what we as EMC could do if we bring together the massive investments we make - just like Volkswagen does with "cross platform" things.

What about the other change (VPLEX and RP product teams aligning with the backup and recovery team)?  

This one was even more obvious - the fundamental driver behind backup, recovery, availability, snapshots, protection (all wrapped up into the applications themselves) - these are all fundamentally about "copy management" - managing point in time copies and representations of information that primary systems are serving up in a transactional way. 

You gain a lot when people have "common mission", and are at common lifecycle stage, and common scale.   If we can accelerate use of the intellectual property (both code, and the knowledge and innovation potential in those human brains) inside these teams:  as standalone appliances; as pure software; as features in the primary storage - that would be great for customers, and great for EMC.    That's what this part of the change is all about.

We've got our Emerging Technologies (XtremIO, ScaleIO, and some others) and our Advanced Software (ViPR, Storage Resource Management Suite, Service Assurance Suite) grouped organizationally for that same "common mission"/"common lifecycle stage"/"common scale" reason.

For what it's worth - I'm very excited about the changes.   I think it creates focus, leverage - and the platform for these teams to deliver the things we have not only on our committed roadmaps (critical as when something is committed, we must deliver), but also innovations to come that are twinkles in people's eyes :-)    Best of breed - to be sure… But also better together!

There's one last thing that is a takeaway for me personally (and as leader as a large scale organization myself) - while it's hard (because of inertia and the human instinct to fight change), but change is fundamentally good.

It's not always good, to be sure (!) but we live in an industry, and in a world - where often the riskiest "move" in the long term is "just keep doing what you're doing".   It's hard to drive that change when you're doing well, and people ask "why change now?".     It's even harder when you're a giant (and inertia is enormous) but that's when the risk of staying stagnant is highest (classic "innovators dilemma").   People struggle with change - not matter what the change is.   In the end, so often - a little change is the beginning of something awesome that gives birth to great new things.

Comments - as always, welcome!  It's been a very interesting growth experience for me to experience first hand, and through it I see many of the things that make EMC a great place to work.

Comments

[Scott Belz]

As someone who has installed both VMAX and VNX, you can see that the hardware is so close that it seems the separation is the microcode. It will be fun to see if/when those will be the same too. Change is often scary, but it also wakes up the sleeping parts of the brain that have been on cruise control.

Thanks for the post. Good to hear about the internal workings of the mission going forward.

[Endre Peterfi]

At EMC we are constantly changing - and change is good, I agree with that! The bigger we get, the harder it will be for us to make changes quickly (see, HP, IBM) but because of the way we acquire and enable companies (RSA, VMware and now Pivotal) we can argue that we can keep it up. I must say every year-end at EMC is exciting: bring more change with the re-shuffling of the accounts, SE's, promotions, new initiatives from corporate for next year with maybe a new theme, something new to focus on. It never gets boring, that is one thing I can say for sure. The more you do - the more you learn, and the more you know the more credibility you have in front of your customer. Just please,please whatever you do marketing teams, don't rename some products with the pace you did with some in the past - we will confuse our customers more than they already are with our portfolio :-). This newes move however will help with a better positioning and here I must say your VW/Audi/Porsche analogy is great.

[Alan Warwick]

Chad, you say "It's hard to drive that change when you're doing well". It's even harder when you're not doing well. Do it while you're on a roll :)