Connecting The Dots May Be Dangerous

If I'm a vendor, and you are my customer, will you give me permission to connect the dots?

Will you view me and my company as a provider of separate, standalone niche products, or are you willing to consider the synergies my company can create if you allow us?

Before you answer, you might want to read the rest of this post ...

So, What's This All About?

As you might know, I do a fair amount of customer interaction.  I love it -- most of the time ...

My preferred venue is when we've got a fair cross-sampling of the IT leaders in a room, and they want to know what EMC can do for them.

What I've found is that they prefer -- and expect -- products that map well to their specific domains, or specific named and identified projects. 

As long as I stay within their mental map, all is well.

But if I start connecting ideas, themes and investments across multiple domains and projects, it's almost as if I've crossed some invisible barrier of political correctness.

By the way, I've stopped using the term "stovepipes". 

I now refer to them as "Cylinders Of Excellence".

The Scoping Paradox

If I work for a large IT group, and I'm in charge of a specific domain, naturally I expect a vendor to bring me solutions that solve my domain-specific problems. 

Storage people expect storage solutions.  Network people expect network solutions.  Security people expect security solutions.  Database people expect database solutions.

And so on.

That's fine.  EMC and just about everyone else knows this, and does this.

But if I'm IT executive management (or want to think that way), I'm probably looking for approaches that span multiple domains and problems -- things that tie things together, create common capabilities and so on.

You know, that whole "leverage" thing ...

But, I've got to say -- if that's the sort of thing you want to hear from EMC, you're going to have to speak up  -- and loudly. 

Why?  Simply because I've found that the "domain-owners" in IT usually give us the stink eye when we start talking in that big-picture way.  We're strongly encouraged to respect political boundaries in an organization.

And I'm finding it's getting in the way of discussing the real issues as time goes on.

Recent Example 1

I was speaking to a fairly senior group at a financial services firm, and someone said -- in a moment of precious honesty -- that they had no idea what was in their file systems, and it was causing all sorts of problems.

The legal guys were getting more into eDiscovery, and the current approach was painful.  Since they were a financial services firm, there was a certain paranoia as to what was in unsecured files -- they didn't know what they didn't know.

They hadn't deleted anything in a very long while, and things were starting to pile up.  What to save, what to toss -- a hard problem to solve.  Not to mention an interest in finding useful stuff like customer information, intellectual property, and so on.

So I naively said that there are two ways to look at this problem. 

First, you could take it piece by piece, and put in one solution for eDiscovery, another for information compliance, another for knowledge management, yet another for ILM, and so on.

But look, I said.  Each one of these has common elements: a discovery capability, a classification capability, a workflow capability, some sort of repository with metadata.

Might it be more interesting to think in terms of common capabilities that could be used in a variety of ways (including all those that you described, and more)? 

And wouldn't it make sense to start with the front-end discovery and classification tasks, just to see what the situation looks like on all fronts?

Turns out that different people in the room had different flavors of what was essentially the same project that needed the exact same set of core capabilities.  And, not surprisingly, they weren't exactly in the sharing, collaborative mindset.

And by naively proposing a common platform (rather than tailored yet largely redundant approaches), I could feel my Vendor Rating Factor drop by  a few points.

Ooops, sorry.

Recent Example 2

Yep, another VMware example -- hard to avoid them, isn't it?  This was a large manufacturing firm who was hell-bent on server consolidation.

Of course, the initiative was being led by the server guys -- naturally. 

And I, once again, made the fatal mistake of connecting the dots. 

I happened to offer up that a converged management model -- one where a single dashboard is used to provision and manage servers, storage, backups,  replication -- would probably be the way to go, simply for speed and efficiency.

All of the sudden, the storage guy in the room straightened his back, and glared at me.  As did the backup guy.  As did the DR guy.

No matter how much I argued the logic, I had Crossed The Line, so to speak.

Once again, I had offered a viewpoint that crossed traditional fiefdoms, and didn't earn any brownie points in the process.

Recent Example 3

If you're familiar with Smarts, you know that its power is spanning multiple domains (network, applications, servers, storage, et. al.) to provide a logically correlated view of complex environments.

As such, it's turned out to be perhaps the most politically incorrect product to talk about in mixed company.

Sure, I can paint a picture of how great it would be if you could discover all the different domains, model their interactions, and use that capability to deliver all sorts of wonderful things for the enterprise.

But when someone pulls me aside afterwards, and explains that -- from their point of view -- a shared management model across multiple IT disciplines really wouldn't be in their best interests -- well, I have to scratch my head a bit.

These Are Not Isolated Cases

I won't bore you with dozens of other examples -- there's no shortage of these types of stories that I've experienced.

IT appears to be a relatively political profession in larger organizations, as far as I can surmise. 

And that leaves us vendors in the unfortunate position of having to decide what's right, and what's expedient. 

So, Where Does That Leave Us?

First, there's a clear choice for domain-spanning vendors like EMC.  Do we play to the enterprise, or the fiefdoms within it? 

Sure, we can do a bit of both, but the real question is -- as a vendor -- do you create a strategy where you gingerly step around traditional fiefdoms?  Or do you do the brave thing, and point to the elephant sitting in the room? 

Tough choice -- especially when competitors are involved.

Second, there's an implicit ask here of senior IT management -- please tell us what you really want.  And be prepared to back it up.

If you really want domain-spanning approaches that reduce costs, manage risks and create new value -- can you please make sure your people are on board?  Otherwise, we're in the uncomfortable position of trying to serve two competing agendas: yours -- and those of your people.

The Bottom Line

What's the motivation here? 

Simple: we want our customers to win at this IT stuff.  It's that simple.

And sometimes, our role of "trusted advisor" means we need to have a bit of open and honest dialogue about how the organization functions, or doesn't, as the case may be.

You may have your views on the topic, but from my perspective, I'd rather work with a vendor that could have that honest (and potentially revenue-damaging) conversation, rather than one that just pandered to internal politics.

So, What Do You Think?

Do you invite vendors to propose solutions that cross political boundaries?  If so, do you give them a 'get out of jail free' card if they end up ruffling a few feathers?

Or, are you more comfortable with vendors that market directly to individual domains (fiefdoms?) within IT, and stay within defined boundaries?

I'd be interested in hearing your views -- thanks!

Comments

[Conray]

Chuck,

Social engineering is much harder then product engineering.

I have learned to position this as a social organization issue caused by the relentless advance of technology.

Question is when will organizations do the social engineering necessary to get the lower costs associated with these newer products?

Answer is when the benefits get large enough to not ignore or not be noticed by someone above the cylinders, or someone in one cylinder proposes the new way to do things because of the major impact it will make on the organization.

I tend to talk about divide by 10 economics as not optional; the threshold may be a lot lower, divided by 10 get lots of attention.

[Andy Leonard]

Chuck,

You seem to primarily view the response you've gotten from clients as a selfish, short-sighted defensive reaction from each domain owner - and that may often be a large part of it, depending on the organization.

But, coming from the other side of the table, I think you also have to recognize that the M.O. of IT vendors - and particularly their sales forces - is to over-promise patchy and under-implemented but far-reaching products that will "solve all your problems" - and which all-too-often wind up being duct tape jobs months late and way over budget. Even if EMC isn't a major offender in this area - and I haven't had the experience with EMC to say one way or the other - you unfortunately have to overcome the reputation of your peers and competitors.

So if you're sitting across the table from me, a domain owner, and you see me giving you the stink eye about something you propose, don't take it personally, and don't assume that I'm being unprofessional and working against the best interests of my organization. Take it as a reminder that if you want to set yourself and your company apart from your peers, this moment would be a good time to do so.

[Chuck Hollis]

Good perspective, Andy ... thanks!

[Juan Jose Palacios]

Hi again, Chuck.

Yes, you've hit "the key".

IT Departments, at least where I move around, are crowded groups. Almost as crowded as the existing IT disciplines, suggest they should be. That makes up for a human problem, who's the boss in each territory. Jumping those boundaries is a risky maneouver, as you say, you're "invading" someone's lair.

As IT climbs steps in the corporate strategy decision process, you're not facing just team coordinators, you're facing departamental Managers. Yeah, with "all" that.

Don't missundertand me, I'm just trying to make up a different point of view from the problem you described, as I also agree to the point made by Andy. He's explained one face of the prism, I add another.

Technology has allways coped with one of the most complex problems to solve; people and their relationships. Furthermore, nowadays is the most complex problem to solve in a project.

There's another one. First thing I observe, (and I see it everyday) in the less specialized (midsized companies) groups, is a lack of market positioning of EMC solutions. When your customers tell you they don't see EMC as an option to solve some of the problems you know you could solve, your marketing is not doing very well and [we] your partners are not doing very well. Maybe it's a matter of time, maybe is that campaigns must be more focused. Maybe they should be different.

But, make a small execise. I see you are keen on talking to customers and see what they say. A healthy and uncommon approach I must say (my congratulations on that). But ask partners how they see EMC and what do they expect EMC to be able to solve for their customers.

I you go into a channel approach, partners are your primary customers. And, if they're not able to make a clear statement on what is their strategy with EMC, you have a first picture of part of the problem.

If neither EMC, nor its partners, can clearly explain customers how they can bring value to their companies, you'll get the stink eye everytime you speak about eDiscovery (for example), for obvious reasons.

It could well mean you're misspositioned. And believe me, it's a pity.

Cheers.
Juan

[C. Hansen]

Having been a part of EMC's Consulting Services Group, as well as a part of enterprise corporate IT, I have seen this from both sides of the equation. Andy Leonard summed it up brilliantly.

We have a current large-scale engagement with EMC across multiple disciplines and product lines.

What is persistnetly missing from EMC is an EMC-provided Enterprise Architect who maps Engagement to products to client's strategic needs.

what we get is Channel Sales "Advisors" - aligned on Product - certainly all qualified in their own right, but limited by the scope of their exposure and their role. They are trained to prescriptively Sell, not specifically to Advise at an EA and strategic planning level.

As a result, we can (and do) speak frequently about product and features, because that's what we're being presented with, informationally. Unfortunately, that's not valuable to IT Leadership.

As an example, help me design and position a strategic intitiative around ECM using Documentum, EMC STorage AND SharePoint.

The unfortunate reality is that EMC only wants to "Advise" against its own product catalog, and that's not beneficial. For their advice to be truly hollistic and trusted, it needs to incorporate the tolls in their client's toolbox, which include EMc products, not just EMC products exclusively. That's reality, but EMC seems to be unable to consume or act upon that scenario.

As a result, we have yet to get credible Advisory services along this paradigm; this is supposed to be EMC's sweet spot.

So it's no wonder that when we get into a room with EMC engagement managers and sales people that we are somewhat skeptical as to the benefit they're providing.

Tactically - absolutely no question at the value-prop, up to and including enterprise platform implementations; and that's also the difficulty.

Whenever IT deals with enterprise platform implementations or strategic delivery projects (+5mm) - those are "landscape changing" programs that require strategic alignment.

Leaving that strategic positioning up to the customer does not provide the customer with a credible Advisor - and that's where the stink-eye comes into the equation.

Resepctfully, CH