Maybe I'm getting more cynical as my career progresses. I've found I can take a quick look at just about any org chart, and quickly figure out how well the team is doing -- or not -- as the case might be.
Most of the time, I'm pretty accurate.
The corollary is also true: if you want to deliver different results than you have in the past, you're going to have to take a hard look at your organization: their mission, their structure, their skills -- their very DNA.
That's what good leaders have to do to achieve results, I've found.
When it comes to IT transformation, the same is inevitably true -- an organization produces what it's organized to do.
Organize around technology silos, and that's what you'll deliver. Organize around large and complex projects, the same is true. Ultimately, if you organize around delivering attractive and competitive IT services that your internal customers want to consume, and that's what you'll eventually deliver.
And that's exactly the mission that so many IT leaders are facing.
As part of our recent EMC IT Leadership Council, Jon Peirce delivered his experiences in leading just such an IT transformation. Jon, as you might remember, is the key actor in many previous popular posts, such as "From Silos To Services". During this presentation, Jon laid out the key concepts and insights better than I've ever seen him do.
If you're an IT leader, or aspire to be one, you'll likely want to invest the time in reading this very lengthy and detailed post.
Some Context
This post is actually part of a series. Rather than repeat myself incessantly (these posts are long enough already), I'd encourage you to read the background on EMC's IT Leadership Council, and Sanjay Mirchandani's excellent presentation on "Leading An IT Transformation".
Before we get started, I have to say that I really enjoy working with Jon. He's one of those quiet and humble but incredibly effective and insightful leaders you'll find throughout EMC's broader management teams.
I hadn't really realized what made Jon so effective at leading an IT transformation until he mentioned that his previous career was doing something similar in the manufacturing industry when it underwent the exact same sort of transformation over a decade ago.
History repeats itself, just with different actors?
Jon set out to cover a substantial amount of material in his session, which he did. As you can see, he has a structured approach to the topic at hand. He also ran a wonderful Q&A session that could have gone on for quite some time.
Unfortunately, his material has resulted in a super, extra-long post from me. Apologies in advance.
Aren't We Done Yet?
Jon started with some baseline material to set some context.
He started with EMC IT's "cloud vision", which -- not surprisingly -- is the exact same view that EMC is promoting to its customers and partners.
If you're the cynical type, you'd say "well, of course". Jon has a different perspective: because the company he works for already had a well-thought-out vision of what cloud would look like, he could focus on his efforts on making the vision real vs. arguing about the details.
The corollary for anyone wrapped up in a similar philisophical debate is clear: pick a vision you like, preferrably from a vendor set you like, and get on with it.
Jon then put up Sanjay's slide that showed the results after the first two phases of EMC IT's journey. The cost savings had been delivered. IT production had been largely optimized.
Why invest in making the painful and disruptive effort to move to phase three -- IT as a service?
I thought it an excellent (though rhetorical) question.
If you look at IT's traditional role as to be cheap/good -- you'd be done. All the big costs were wrung out. IT service delivery was humming along at exceptional operational efficiency.
Aren't you done? Can't you collect your reward and move on?
In a word: no.
Jon then proceeded to lay out one of the most honest self-assessments I've ever seen from an IT leader -- anywhere.
A Brutally Honest Look in The Mirror
His first slide is clear: "Users Have A Choice", followed by a litany as to why business users will continue to source around internal IT. In EMC's case, it was a familiar refrain.
IT remained hard to do business with -- especially as compared to a flexible and willing external IT service provider.
The funding model -- project-based, fully-allocated, etc. -- got in the way at a deep and fundamental level.
The IT organization appeared from the outside to be a group of technology or process specialists of one flavor or another -- there was no friendly and engaging "face" for working with the internal IT group. Where was my sales rep / consultant / presales person?
The IT function was genuinely afraid of promoting their capabilities and skills -- because they could easily create demand that they could not fulfill.
And, of course, a natural bias towards lengthy and extended "custom" engagements vs. standing up repeatable enterprise IT services that everyone could consume in one fashion
or another.
As Jon was going through this, the silence in the room was profound. It got better.
He then positioned the case for IT transformation as IT overcoming its historical legacy. The past wasn't up for debate; it was the future that was in question. Could IT learn to compete for the business the way external service providers do so naturally?
He then coldly ticked off specifically which aspects of legacy IT were holding IT organizations back.
Things like fixed budget and fixed supply of services: here's your 2012 budget allocation, go make it happen.
Or the primary role of IT governance being around how to limit IT consumption vs. increase its effectiveness.
Or the observation that the majority of IT organizations were structured around the technology piece parts vs. the services people wanted to consume.
And, ultimately, the general nature of IT professionals to react and respond when the phone rings vs. investing in repeatable and measurable processes.
The silence in the room continued to be profound. Here was one of their own offering up a relatively thorough indictment on how IT was mostly done today -- and that it had to change.
Jon then framed the opportunity as "winning the business" with ITaaS. His premise was simple: unless IT was constructed and motivated to compete for the business, IT workloads would eventually go to external IT providers who better understood that mindset.
For external IT service providers, it's all about service consumption -- how many, how much.
It affects the way they package their services, the way they're delivered, the way they are priced, supported, managed, marketed, etc.
And the better ones do it off a single platform -- one where management, security and GRC is built in vs. bolted on.
IT Transformation Concepts
Jon then shared what he believed were the foundational elements around organizing for success.
One bucket was what he called the "new IT business model". Sanjay discussed most of the elements in his presentation, so I don't want to cover it here again.
One bucket was "enabling technology".
Despite my natural inclination to wax poetic on the subject, we'll leave that for another time as well.
And the third bucket was people: their DNA, skills, roles and organizational alignment.
After the event, it became blindingly clear to me that this third bucket -- people -- is where the discussion has to start for the majority of IT leaders. If they can't see a celar way to get the people skilled and aligned to support the new model, there won't be ITaaS anytime soon.
Conversely, if you see your way clear to building the right team over time, you can have increased confidence around making the case, investing in the new capabilities, etc.
As any experienced leader or manager knows, it all boils down to your team :)
The New Roles/Skills Model
Jon then presented an amazingly detailed model for how to think about the problem -- definitely worth understanding.
As he went through the components of the model, it was clear there were a few parts that he hadn't arrived at definitive answer -- but the question was framed beautifully.
Jon's matrix model speaks to five logical groupings of skills: client-facing IT, IT development, IT engineering, IT operations and IT business ops. Just to be clear, this isn't presented as an organizational structure per se -- just a way to frame the discussion.
Across those skill groupings, he looked at five aspects: roles, skills, organizational alignment, automation, governance and process, and -- ultimately -- measurements.
Understandably, you'll appreciate that I thus have 30 (5x6) logical buckets cover here in this next section. Please bear with me as I go through this material in some detail -- it was very enlightening.
If nothing else, the logical structure is very useful -- even if you come up with better answers on your own.
Client-Facing IT
One very important skill grouping is around the folks who face off against the business consumers of IT. As I've mentioned previously, this is an area where you're not likely to find a strong proficiency in most enterprise IT functions.
Not surprisingly, this is an area where competitive external service providers tend to invest :)
Under "roles", it's pretty clear -- this is the sales force for internal IT, whether the service is built internally or brokered externally.
They promote the use of standardized enterprise services, and steer people away from customization. Like any good consultative sales rep, they educate their customers on their choices and implications of their choices, and -- over time -- develop expertise on aggregating existing services to meet clients' needs.
Under "skills", there shouldn't be much of a surprise. Think of what you like about the best IT sales reps and presales people you work with -- that's the sort of skill set you're looking for: engagement skills, negotiation skills, influence, solution selling.
Not to be too literal here, we're not talking about a *real* consultative enterprise sales rep (with everything that entails), just something that walks and talks like one.
Organizational alignment? That's a tough one. There's one argument around organizing around business units, and yet another one around service specialties.
Much the same way a technology vendor or service provider has to figure out how to best cover its customers, the answer usually ends up being a little bit of both -- maybe a few dedicated roles for the big consumers, and generic services for everyone else.
Automation for this role is relatively simple. When someone wants a service, the delivery should be quick and automated. Even if there's a human being figuring out how to combine and integrate the underlying services into what's desired, the supporting service creation against the catalog should be as quick as possible.
And, of course, any good sales rep needs to show their client how much of the service they've consumed, and the quality of the service delivered.
Now, here's where expectations get turned upside down. Under "governance and process", Jon put both "demand maangement" and "financial management". Everyone presumably thought that was about limiting demand and controlling spend.
No, precisely the opposite -- if you really think about it.
Any good sales rep should be able to forecast demand for what they've got in the price book. The incentives should align around increasing demand for the services, forecasting the accurately, etc. and not rationing them. And, in this context, "financial management" speaks more to making sure that people can pay for what they're consuming; aggregate financial targets for the service are met, and so on.
The measurements here should look familiar -- if you look outside of IT, that is. Like any good rep, more services consumed is goodness and should be rewarded. Getting people to buy off the standard service catalog vs. insist on extensive customization as well.
And, when a decision is made to use external IT services vs. internal ones, that should be considered a "lost deal" and fully understood as to exactly why a business consumer of IT felt it necessary to go outside the company. That's how you get better.
IT Development
Going through the same sort of model for the important group of people who build applications is also a useful exercise.
When it comes to "roles", I like Jon's two key concepts here. One is "configurability vs. customization" -- I think that important distinction might be lost on many people.
The other is "aggregate vs. create new" underlying services that compose an end-user service or application.
Note: if you'd like to read an excellent rant on the subject of platforms and services, this viral post from a Google engineer is fascinating.
As far as key skills for the IT development role, nothing really out of the ordinary, except one: networking and mobility skills. Jon's perspective is that -- going forward -- it's a safe bet that the user and the information and application will be separated by either meaningful distance or intermittent network connections -- and that perspective has to be integrated into the IT developer's thought process.
It's not for the networking guys to go figure out :)
Alignment -- as before -- is a thorny challenge: do you align around the application, or the technology competence? As before, the answer will likely be a bit of both.
No clear answers here, sorry ...
Automation is important here as well: mostly around testing, performance validation and capacity planning.
Some tools exist, more are needed: especially ones that are cognizant of fully virtualized environments, significant distances, user experiences on mobile devices with poor network coverage, and so on.
Governance areas that Jon highlighted as important was the crucial decision to build vs. buy.
And, if extensive customization of a relatively standard environment is to be undertaken, that should be subject to the utmost of scrutiny.
As far as measurement, Jon mention two things he cared about: one is reuse of standard services and enterprise platforms vs. inventing something new.
IT developers should be highly incentivized to use/improve existing capabilities vs. create new as can so often be in their fundamental nature.
And, of course, he'd like to see end user experience -- especially synthetic transactional performance as experienced by a user on a mobile device in a remote part of the world -- as part of the measurement.
IT Engineering
Continuing our tour of new skills and how we describe them, we come to the IT engineering function -- the folks who build the underlying platforms and systems that support the applications and user experiences.
Jon is pretty clear on how he sees the role: basically, they're responsible for designing, building and keeping an eye on the "factory" that delivers the shared services.
It doesn't show up here, but the incentives should be strongly biased towards standard, simple, extensible, etc. vs. the more common practice of building a customized stack for every application that shows up.
When it comes to skills, Jon is adamant that -- yes -- you do still need deep skills in the traditional disciplines (server, storage, etc.) but a also a big investment in the new layer of "platform" skills that hybridize the underlying disciplines into shared and integrated platforms.
It's these new "cloud" skills he finds both so important and so hard to find.
Indeed, Jon has worked with EMC Education to develop and deliver an increasing set of new certifications for these roles. As an example, EMC's Cloud Architect and Data Center Architect certifications have been extremely popular -- even if you're not an EMC customer!
Note: I'll be announcing some new offerings along those lines in a near-term post.
From personal experience, when we get deep with a customer who's adamant in IT transformation, one of the first things they do is make sure they've got this essential core of
architects to get the party started.
In regards to organizational alignment, Jon sees four key disciplines within this function: services, automation, platform and foundational technologies.
He is quite vocal that these four disciplines need to live together to achieve ITaaS at the infrastructure level. He can't see it working well at all if the disciplines are scattered elsewhere in the organization.
In addition to all the usual automation tools that IT engineering thinks about, Jon called out two new ones that had become very important: configuration management and capacity planning. In this model, most aspects of configuration management not only become centralized, but the foundation for higher-level automation process.
Put differently, you end up being very reliant on your CMBD in this world. And, of course, in this model capacity management really becomes "aggregate capacity forecasting".
Regarding governance and process, Jon called out a few new things that took on increased importance in this model.
One clear example is "virtual first". Lenghty and complex justification cases need to be made around physical non-compliant infrastructure, rather than the other way around. Extending the thought, "standards first" makes sense.
Indeed, the governance discussion should be "is this noncompliant requirement important enough that we should invest in making it part of our standard capability" vs. immediately going to a one-off.
Metrics? All around the platform and the services it supports.
Availability (of course), scalability (in the sense that scale can be achieved as needed without significant reengineering of platform or process), unit cost TCO (all in!), and speed of provisioning.
IT Operations
Architecture and engineering are important disciplines, but at some point the services have to be operationally delivered, and that's what happens here.
Jon describes the role as "manufacturing and customer services", if we were using an analogy. Jon characterizes the new skill set here as breadth, breadth and more breadth.
Indeed, the task of creating incentives for people in this discipline to be on a continual jounrey of cross-skilling (vs. increasing technical depth within a discipline) is one of the more important challenges here.
When it comes to alignment, Jon thinks the recipe is simple: one team, one location -- to the greatest extent possible.
"Follow-the-sun" basically means replicating the entire model in a new geography vs. smearing out the required skills across multiple time zones.
Jon boils down the key automation aspects to three: working towards the proverbial "single pane of glass" so one person can get the big picture of what's going on, investments in predictive alerting (react before there's a phone call), and as much higher-level service-delivery orchestration as you can stomach.
Considering governance for a moment, Jon things the key areas ot focus are in facilitated communications: escalations, reporting, alerting, etc.
If you think about it, in this model, this group is responsible for the shared "power plant" that drives the majority of IT service delivery.
They should over-communicate -- and be listened to seriously when they think there's a problem at hand.
The metrics Jon suggests for this function aren't all that unusual: service availability, time to resolve, and -- to keep costs in line -- service delivery unit cost TCOs, ostensibly shared with other groups.
It's not surprising that -- in Jon's model -- key measurements (and thus ostensibly compensation, rewards, etc) tend to be shared between aligned groups.
It is rarely the case that a single function "owns" a single measurement in this model.
IT Business Operations
Before diving into this, Jon believes (and I do as well) that this function ends up being perhaps the most important in an ITaaS model, and the one you're least likely to find well-developed in the vast majority of enterprise IT organizations.
However, look inside a successful service provider, and it will be very well developed indeed :)
Jon describes the key role here as the "marketing, product management and finance arm of IT". Marketing in IT? Product management in IT? A progressive finance function in IT?
Yes, yes and yes.
If you aspire to "run IT like a business" (even if you never get to real chargeback!) you will need some flavor of these functions. Most businesses (and business units) invest in these functions. You should too.
The key skills behind these roles are not unusual -- outside of traditional IT, that is. For example, the ability to communicate effectively with your internal customers through a variety of mechanisms (e.g. marketing).
Or the ability to conceive, justify, introduce, manage and sunset a portfolio "products" (e.g. services) just like any other product or service manager would.
Once again, desired alignment doesn't present an obvious answer.
One can make a strong case for IT Business Ops to be independent and report directly to the CIO, the "business" side of IT far removed from the fray.
Another case can be made to bundle it tightly into the group chartered with creating and delivering the services.
For me, I think the first order of business is building the capability, and *then* figure out where it might ideally align to :)
As we look for opportunities to automate, no surprises here: service catalog creation and consumption, service consumption metering (predicted vs. actual), financial transparency and chargeback, and service level reporting -- e.g. most of the stuff that the client-facing group will need to do their jobs :)
The governance aspects closely mirror what's done in the product and service world: governance around the entire service lifecycle process, the all-important concept-to-approval cycle, and -- of course -- service pricing to drive the desired behaviors and outcomes.
Measurement?
Like any product management business team, they'll be looking at the numbers: who's buying, how much, what did it cost, etc.
So frequently, I hear IT operations people say "it's so hard getting to the numbers". I think getting to the numbers is relatively easy; it's making sense of them to make good decisions that's the hard part :)
And, if they want to continually improve, they'll join the client team in closely scrutinzing any "lost deals" for key insights.
A Few Higher Level Views
If you've made it this far into the post, you're probably very interested in this subject. That's good.
We've got a bit farther to go on Jon's material, so hang in there please ...
Jon then stepped back from this ground-level view, and showed a few higher-level conceptual views on how all the parts could (and should) work together.
One view was sort of a higher-level "organizational stack" (not an org chart!), that showed IT service management functions at the proverbial top (and the disciplines that support them), logical groupings of services beneath that, the notion of an architected and shared platform (engineered and operated), and -- beneath that -- the traditional technology disciplines.
I've found that this layering view helps people think about what's more important going forward -- and, of course -- what's less important going forward. Also, it's pretty clear to articulate the handoffs and the interfaces between the various functions.
An equally useful view results when you draw the picture in terms of "what people see from the outside".
They see (1) strong operational and governance processes, (2) end user services that they can directly consume, (3) applications accessed through the end user experiences, (4) a shared software platform supporting the needs of applications, and (5) infrastructure underneath that all.
My belief is that there will never be One Diagram To Rule Them All when discussing an IT transformation to an ITaaS model.
You've got different stakeholders, they're going to want to see different views that are relevant to them, and not you.
So, better start constructing your library of "alternative conceptual views" sooner than later :)
Polling Time!
We asked the attendees a few simple questions to see where people were at.
Please do not interpret this as the definitve survey :)
The first question was simple: where are you spending most of your time building ITaaS capabilities today?
Over half the audience indicated it was infrastructure.
Maybe that was sampling bias (after all, this was an EMC event), or maybe more people realize that -- once you get infrastructure right, the rest becomes just that much easier.
To validate that second perspective, we asked a second question: where do you think ITaaS will make the greatest impact in your business?
The number of respondents who indicated IaaS dropped to 13%.
I think this is because most people have the broader view -- it's a journey, and IaaS is a logical starting place for many.
Back To EMC IT's ITaaS Strategy
Sanjay took the audience through this "big picture" view on how we were approaching the daunting challenge of morphing EMC IT into a competitive internal service provider.
I dont' want to repeat all the elements here; you'll find it in this post.
Jon, however, wanted to drill down on element #6 -- skills, roles and competencies -- a bit further.
In addition to the model he presented earlier, he wanted to talk about some broad-based ideas that had worked for him.
He put up a nice overview of these thoughts on a slide "Preparing Our People".
Early on, he realized that the shift to an ITaaS model would be rather wrenching and signficant to the vast majority of people who had made a career working for EMC IT.
And, like any other daunting challenge, he believed the best approach was to acknolwedge the problem and to take it head on.
The big three elements for him were:
(1) talking openly about cloud and what it meant to the organization and to each individual,
(2) fostering new forms of collaboration and co-location around emergent skill clusters vs. traditional ones, and
(3) creating a broad range of incentives for people to learn new skills.
Each is worth some brief discussion here.
Jon jokes that he finds he spends a large amount of his time basically saying the same thing over and over again. The world is changing, IT is changing, EMC IT is changing -- and there are great opportunities ahead for you if you're willing to change.
He says it feels like he's been doing this for years. I think he probably will be doing it for some time to come. No big revelation here, if you think about it.
I found the co-location discussion useful. Jon and his management team gives great thought around "who sits next to who" in an effort to foster "opportunistic collaboration". Example: if you do any form of architecture, you sit with other architects -- regardless of discipline. If you're working on some sort of operational process, you co-locate with other people who are working on similar operational processes. And so on.
I would express the thought as "co-locate around emergent behaviors, and not legacy ones".
Finally, perhaps the greatest amount of work went into re-engineer job descriptions, compensation and implied career tracks for the IT organization.
Although Jon relied heavily on his HR team in this regard, he did offer a word of caution. The natural instinct of HR professionals is to immediately conduct a survey of industry peers to establish a baseline. Jon believed (and I agree) that's a good look at the rearview mirror, and not down the road where you want to go.
He'll freely admit -- they ended up making up a bunch of stuff at the outset, and refining as they went along. Fortunately, there are a few more examples to draw from these days :)
The more difficult part was creating a comprehensive rollout across the rank-and-file of IT, saying "here are the new career tracks, here are the opportunities to train yourself, and here are the rewards if you do". Not a quick project, if you think about it.
One interesting data point is the year-old EMC Cloud Architect certification. Within EMC IT, it has quickly become The Cool Credential to have in your portfolio :)
The Organizational Evolutionary Sequence
One of the more interesting discussions our customers like to see is the step-by-step sequence of the IT organization morphed as these processes were underway.
A couple of caveats. First, we've elected just to show the infrastructure-related aspects here, and not the entire IT function. Second, Jon states that the org chart tended to lag organizational reality -- especially later in the sequence: people had already started to work together in new ways, and the org change was simply an acknowledgement of that new reality. Third, had we known what we know now ... we probably could have gotten there much sooner.
Which is one of the reasons we're investing in sharing this story with you :)
The first chart in the sequence shows the IT infrastructure organization circa 2008. Every time I put this chart up, most of our customers say "yep, that's us".
The first thing you'll notice is the silos around technology.
There's a "systems" silo, with their respective sub-silos of UNIX/Linux, Windows, virtualization, etc. Move over a bit, and you'll encounter the "storage" silo, with their respective block-heads, file-heads, backup people, etc. Network, security, datacenter, etc. and the picture is largely complete.
Siloed architects at the top, a service function (actually, a trouble-ticket passing function) at the bottom.
As a user of EMC IT at this time, I think it's fair to say I wasn't a big fan. Looking at the organizational structure, it's clear to see why. Who do I talk to? How do I get things done? Why is this taking so darn long? And so on.
Not entirely unlike many IT organizations I meet every day.
The first major structural move Jon made (2009) was to pull all the "support functions" away from the silos, and put them in a single, unified and mostly co-located team.
People in this group were now responsible for solving problems, and not necessarily just routing workflows.
Within a few weeks, it was obvious to all in this new group that -- yes -- things weren't really organized and built for success. (I'm being polite here).
It's also interesting to note that -- at this time -- virtualization was called out as its own specialty and given equal weighting with UNIX and Windows.
In 2010, Jon took the next logical steps.
He brought together the systems team and the storage team under a single lead (without fully integrated the functions at this time), and created an entirely new function: IT Service Management.
He said he believed that -- while the skills themselves aren't all that unique -- he did have to go outside the IT organization (and enterprise IT hiring sources) to find the right candidates.
The mission here was simple: start thinking about what it would take to create and deliver standardized enterprise IT services.
The next big move was at the beginning of 2011.
A formal "private cloud infrastructure group" was formed (the shared platform and associated operations), and IT service management (with a greatly expanded set of roles and resources) was put at the proverbial top of the org chart.
Look closely, and you'll see the same three-part organizational model you'll also find in most IT service providers: service management, shared platform, supporting technologies.
When the mission is the same, the org structure ends up looking the same as well.
A Different View?
Jon then presented a different view of how he was starting to look at his organization -- around job titles and -- more importantly -- career tracks.
The logical groupings make sense -- client engagements, services, applications, platforms, technologies and support. Add in some finance and governance, and you've got you're fundamental recipe.
Look down at the bottom of the slide, and you'll see a new acronym trying to get out: SOOA, or services-oriented organizational architecture. Clever.
Polling Time Again!
We wanted to ask the audience where they might be in their organizational journey.
We put up some logical choices, and let them vote.
You can see the results -- the two leaders being essentially two sides of the same coin: implementing service management and consolidating tools and automation. Your mileage may vary.
I think the point here that Jon wanted to make is that he saw it very important to pull out all the various tool and automation groups into a single, consistent whole -- otherwise, you end up automating the wrong things :)
Measurement of ITaaS As A Whole?
I think there's general agreement that, yes, measurement is important.
Measure the right things, you'll get the right outcome. Conversely, measure the wrong things, and you'll likely get the wrong outcomes.
Jon led the discussion here with his notions of "value" -- the best way to measure value is when willing customers give you more of their spend.
That's how it works outside the enterprise IT world, that's how it should work inside the enterprise IT world as well.
The fact that business leaders see more value from spending their money with the enterprise IT group than other alternatives (IT or otherwise!) is the ultimate indicator.
Yes, I realize just how controversial this is to many -- after all, hasn't it always been true that the prime mission of IT is to reduce costs and limit consumption? ;)
Jon is also very clear that managing aggregate IT consumption is not the role of IT. To make IT in in charge of rationing IT is to set IT up for organizational failure.
Enterprise IT's real job is to create attractive and competitive services that internal customers want to consume -- the more, the better. Overall IT expense control -- well, that goes to our friends in corporate finance, who also keep a watchful eye on other variable costs like headcount, travel, facilities, etc.
IT expense should be no different in our view.
How will EMC IT know when it's succeeding?
When it's winning business from internal customers -- they consume more, they go outside less often. Even if it's IT brokering an external service.
Just like any other customer-centric business on the face of the planet.
The Biggest Challenges -- In Jon's View
One thing that I love about Jon is his complete transparency, and this slide is no exception -- it details the fundamental struggles EMC IT is facing in transforming itself to a competitive internal IT service provider.
First and foremost -- company culture.
Face it, EMC has been doing internal IT for a very long time. Changing IT consumption habits won't be done overnight.
That being said, there's been spectacular progress in business behaviors and attitudes in the last two years.
Sometimes we forget just how far we've come.
Second, EMC IT is now well-engaged with EMC corporate finance around having to fundamentally change our long-held views as to how IT is forecast, paid for, and charged for. The interesting part is that -- at a macro level -- the required financial models and skills are being used elsewhere in our business -- but, as before, change is hard.
Big progress along these fronts in the last year, more to do.
And, finally, the big challenge associated with changing the DNA of EMC IT itself -- thinking in terms of customers and having to compete for the business.
If we're all being honest, that's not what we've trained and encouraged enterprise IT professionals to do. But it's clearly the new world, and it's here today.
The Most Sobering Poll Question
So, we decided to wrap up by asking the audience where they saw the biggest challenges around IT transformation in their own organizations.
I'd like to draw your attention to the number of responses associated with "technology".
Zero, zip, nada, nothing.
Dear technologists everywhere -- whether you work for a vendor or an enterprise IT organization: this next phase of IT evolution has very little to do with your favorite subjects around deep tech.
In fact, the more you make it about your favorite subjects, the slower progress will be.
I'd invite all of you deep tech people out there to apply those massive intellects, years of practical experiences and creative problem-solving skills and aim it all squarely where the real opportunity lies ... fundamentally reenginering the way enterprise IT does its job.
You can be part of the problem, or part of the solution.
Because -- with every passing day -- its more and more clear that technology alone isn't the answer.
Comments