I'm starting to really like visiting the outlying IT geographies. Places like Milwaukee, Wisconsin to name one. If you haven't been, it's an excellent example of an industrious and progressive midwestern US city.
Compared to the grind of larger cities, travel was almost a pleasure. And I could see a real sense of community -- it seems there are no strangers in Milwaukee, just really nice people you haven't met yet.
I also like the broad mix of industry sectors, and IT shops of wildly varying sizes -- from quite large to, well, "very leveraged". I found the IT leadership style here very progressive, collaborative yet ultimately self-sufficient.
EMC recently hosted a wonderful intimate dinner here for about 8 of our customers and partners. Great food, great wine -- and an insightful range of topics worth sharing.
The Topic: IT Transformation!
It was easy enough to establish wide agreement that (a) things in IT were changing fast, and (b) everyone ought to be getting on with it if they haven't already. As I went through my standard conversation-starter material, I could see heads nod up and down vigorously.
As always, I use the EMC IT experience as a baseline. So far, so good.
The Leveraged Perspective
We had a number of what you might tempted to call "small IT shops", but I can't really use that term here.
They had big responsibilities and big challenges just like the ginormous shops; they just had to get everything done with maybe 40-60 people all-in-all.
What results is a laser-like focus on where -- exactly -- does the IT team create value, and how. Using a wide range of external IT services was almost a given; the discussion was around how best to do that.
Answer: get closer to the business. But how?
The New BA -- Business Analyst+
If you're familiar with my talk track, you'll know that one of the key points I make is that every IT organization should have a go-to-market function: one that engages key IT stakeholders, positions IT services, and -- ideally -- adds value to a business discussion.
Wide agreement in the room that -- yes -- that was turning out to be a very key role indeed. Unless someone from IT could form a trusted and value-added relationship with business leaders, the model wouldn't work. More agreement that this wasn't the requirements-gathering, ROI-justifying, project-managing profile of the past.
The ideal profile emerged: strong business and problem-solving background, broad understanding of IT and how IT worked, great communication and engagement skills, and a natural ambition to excel.
But where do you find these people? How do you make them want to work in your IT group? And when they start to be successful at what they do, how do you keep them around?
No easy answers to that one. We all could describe the person we were looking for, but it didn't exactly fit into familiar IT worker profile. Nor was a role that could be easily outsourced or contracted for.
Would it be a bad thing if these individuals worked for the business instead of IT itself? A 50/50 split resulted on that one.
I Need More From My Service Provider Than Great Service
We invited one of our customer-partners (TDS) to the event -- they've just started offering enterprise-class IaaS branded as Reliacloud. Personally, I think it's great when our IT service provider partners can hear directly from IT leaders on what their needs might be.
One of the more interesting dialogues was the need for go-to-market services -- from the service provider to the IT buyer -- to help the IT organization position the externally sourced services and offerings to prospective internal business consumers.
In essence, this IT leader was a broker of services, and really wanted some help in driving demand for external services with his internal business users.
Now that's really leveraging your external partners!
IT Services -- As A Service?
That same individual put an interesting proposition on the table. He had been approached by Cap Gemini with a unique offer, something I'd dub "IT service provider management as a service".
Imagine an IT organization consuming 20, 30 or maybe several hundreds of IT services externally. The proposed CG service was simple: we'll manage all those relationships for you: we'll help you pick the best, negotiate a good contract, watch them closely, and replace them if they're not doing the job.
We'll then integrate those external services into easy-to-consume user-facing services and market them directly to your IT consumers. We'll do the internal invoicing and customer support aspects. We'll do all the monitoring, reporting, auditing and event management. And we'll charge you for this service.
That sort of proposition was very new to many people in the room.
Now, there might be all sorts of reasons why that wouldn't sound attractive, but this person was coming from a perspective where he had 40 people to do the work of maybe 400. His business wasn't especially security-sensitive, or had particularly demanding application workloads. His business wanted to use IT, and not necessarily own a bunch of it.
He was going to be externalizing as many IT services as humanly possible -- that much was clear. But how best to manage a broad portfolio of external service providers?
I thought it a clever idea.
The Mobility Challenge
When it was time for a new topic, I threw out the mobility challenge -- how were you all getting along with mobilizing your apps and user experiences?
Eye rolls all around -- big headache, much work to do.
Absolutely no one had their head in the sand: their world was going mobile, and IT had better learn to get good at delivering mobile experiences, and pronto.
One gentleman from a very large financial services company stated the obvious: almost every big app they were working on these days had an integral mobile experience at the front of it.
Another gentleman shared that their business had made an eyes-open decision to expose themselves to well-understood security risks simply because the benefits of mobile devices so greatly outweighed the downsides. Tough choice. But they were definitely looking to close those gaps as soon as possible.
Most everyone had figured out had to accommodate BYOD at some level, a few were offering VDI experiences; almost none had figured out custom apps, enterprise app stores, and all of that. But they all sort of new it was coming very fast indeed.
Finding Talent
Well into the discussion, I threw out one of my favorite conversation starters -- how's the local IT talent market? Answer: not good. Plenty of the old skills available; very few of the new ones.
The discussion shifted around to whether it was better a hire outside vs. grow your existing team discussion. One very progressive gentleman took us through how he re-skilled his modest team during a two-year period, and was very happy with the results. Some couldn't see how that would work in their situations, though.
And then came a question for which I had no good answer: what would you recommend to a young person who wanted to get into enterprise IT?
Jeez, I was stumped. As I thought about it, I realized that most of the really great IT people I meet started out somewhere else and had done a bunch of different things during their career. No linear sequence that I could easily detect.
One gentleman opined that a mechanical engineering background -- combined with a smattering of communication and business skills -- was an excellent starting point for an IT professional.
Why? Mechanical engineers are born problem-solvers. Someone else said that a background in manufacturing was a great starting point as well.
I'll need to come back to this one when I have my thoughts in order.
Do You Report To The CFO?
There are two reasons why IT groups historically report to CFOs. One is that IT is seen as a shared service and shared expense. That's where that sort of stuff goes in most organizations. The second reason is more historical: the first critical apps were the ones that finance used.
About half of the participants in the room reported to the finance function; half reported somewhere else in the organization. Generally speaking, their perspectives were different.
From what I've seen, those that reported to finance tend to bias towards a cost discussion; those that didn't were generally more interested in value-creation.
If this is true, I'd like to understand more around cause-and-effect.
As an interesting recent example, the EMC IT team now has a new reporting line. Previously, they used to report to David Goulden, who was our CFO at the time, now EMC's President and COO.
The new reporting line? Directly to Howard Elias' team, which is *clearly* a strategic, revenue-generating function. I think this is very indicative about how we are now collectively looking at the IT function here -- value generation vs. cost containment.
I Think Everyone Got Something From This
As with every gathering of this type , you'll have a few people who are vocal, and a few that aren't. But even the ones who weren't directly participating were following the discussion closely, taking a few notes -- and came up and thanked us for the session afterwards.
Me? I learned a few things, and now have a few interesting and non-obvious questions to go ponder over the next few months.
Thanks to all who joined us -- I hope our paths cross again at some point!
Comments