Fresh Approaches to IT Leadership Competency Assessment

Virtually all CIO’s recognize they have a talent challenge – the competencies they have in their IT organization are often not the competencies they need today.  This is an issue I’ve wanted to post on for some time, but it’s complex and requires highly specialized expertise – people who both fully understand the Human Resources and Talent Management domains, and who really appreciate and have experience with the special needs of IT leadership.  I’ve therefore reached out to one of my wonderful colleagues, Dr. Margaret Schweer.  Margaret led our multi-company research last year on emerging IT competencies, and has worked with me on several important client engagements.  She and I have collaborated on this topic, and will post it to our respective blogs.

Being talent ready is a continuous journey – there is no steady state for talent.   Responsible IT leaders are always in the hunt for talent with key capabilities in anticipation of the organization or function’s needs.  This requires a robust competency model that describes contemporary IT leadership behaviors in observable ways.  A good IT leadership competency model helps people visualize what is needed from IT leadership in an era when technology is increasingly a strategic enabler, pervasive evolving rapidly. 

Margaret had a recent conversation with a client that wanted to design a technical competency model that would serve to stretch their functional capabilities from a high level 2 to level 3 Business-IT maturity, allowing them to develop talent in anticipation of business demands.  So what are they looking for? 

  • In terms of leadership competencies, they are looking for leaders who are always sensing in anticipation of business needs and are able to identify and clearly articulate opportunities in and out of the function.  They want people who are sensitive to how the organization functions, can position initiatives effectively, and are experienced leading organizational change on a broad basis.  The breakout competencies revolve around demonstrating strategic agility and driving innovation. 
  • In terms of technical competencies, the focus is on taking the business partner relationship to a different level, proactively planning and creating new, innovative, even transformational ways to create business value through technology.  Using their knowledge about the business, these leaders can leverage technology for revenue generation, not just automation and cost reduction.   The breakout competency is clearly relationship management. 
  • In terms of personal competencies, collaboration takes on new meaning – it’s about developing networks and building alliances across boundaries; routinely contributing to and drawing from others to inform, influence, create, and leverage ideas and services.  And traditional ‘management of others’ competencies give way to a competency that enables talent flexibility and engagement.  It’s about creating  a well supported process for assessing and developing talent to fill an ‘on demand’ pipeline; quickly and seamlessly moving talent in a ‘marketplace’ approach; and engaging talent in a way that enables them to deliver a signature customer experience.  And the talent we are speaking about?  Well, they may or may not be employees.

Let us finish the discussion of IT leadership competencies with a comment about the importance of developing a global mindset.  The question here is not whether your business operates internationally, but whether your talent does.  Even in a domestic organization, a global perspective is essential in IT because the global technology talent and services market is global.  What is unique about these competencies is how they are described and applied culturally.  And I think there is real value in calling these out as transitional competencies.

It’s important to anticipate your organization’s competency needs, as many of these require a long lead time to develop.  We believe that development is best accomplished using a variety of methods, including training, feedback and coaching from others, mentoring and job experiences, including developmental assignments.  While experts agree that the most powerful development is done in the context of assignments, don’t underestimate the power of ‘social learning and networking.’  As noted researcher, Rob Cross reminds us, much of what we know or come to know is learned through others, in formal or informal networks.  Unlocking the collaborative power of your organization can be a real source of competitive advantage as you move to develop key organizational capabilities.

Mind Mapping as Collaborative Ideation and Problem Solving

Years ago I was blown away when a facilitator at one of my clients began a very large meeting (dozens of people) to problem solve a very large issue (data management) by laying out an incredibly ambitious agenda for a very short meeting.  I remember feeling, “Oh no – she’s setting herself up to fail!”  I had just started working at the client and felt powerless to intervene and save her from herself.

She then opened a weird looking page projected onto a large screen and invited people to brainstorm on the major data management challenges they faced.  As they did so, she was furiously capturing them on the page, organizing them and reorganizing them as the list of ideas grew, and as one idea sparked others, or was refined by the “wisdom of the crowd”.  As she did so, people became more and more engaged, and after a hectic 15 minutes or so, she had a page full of ideas beautifully organized into 5 major themes.  Just getting them organized like that, in a chaotic, but emergent way was something of a breakthrough for all in the room.  The excitement was palpable!  She took one of the themes and moved into solution brainstorming mode with the group.  At the end of the one hour meeting, there was excitement, engagement and a level of commitment to working on the solution ideas that had been generated.

My fear that she was trying to do to much, with too large a group, in too little time was completely unfounded.  She was a very good facilitator, but the real secret was the tool she was using – MindManager mind mapping tool.  I bought the tool at the very first opportunity, and have used it ever since.  Virtually every colleague I’ve ever worked with who has seen me use the tool has likewise become a user.  And most clients that have seen me use it, quickly become users.  (I wish I’d owned a piece of Mindjet!)

Over the weekend, my colleague Kimberly Hatch pointed me to MindMeister, a web based and collaborative mind mapping tool (although with Google Gears, you can also use it offline).  I’ve been playing with it and am equally blown away.  It is elegent, powerful, and completely intuitive to use – certainly if you’ve used mind mapping before.  Here’s a trivial example of what a simple map looks like:

Over the next couple of weeks, I will try an experiment and set up a Mind Meister mind map and invite visitors to this blog to work with it – adding and revising – and see where the experiment takes us.

IT Organization Design and the Value Disciplines

My recent post on Shadow IT: The Good , The Bad and The Ugly solicited an interesting comment about organization design and the placement of application development versus application support.  This got me thinking back over years (probably 25!) of helping clients with IT organizational design, and the tools, techniques and principles I’ve used over the years.  I thought it might be worth sharing these, and perhaps engaging in some interesting global conversations.

Let me start with a couple of overarching principles I’ve tried to keep in mind when designing IT organizations.

  1. Share (and make common) everything that can be shared.  Implications include: resource pooling is better than permanently attaching individuals to applications, which tends to foster an endless string of low value enhancements, good for job security but not necessarily for business value or innovations!  Enabling capabilities such as Enterprise Architecture, Global Sourcing and Organization management are almost always great candidates for being globally common and shared.
  2. Don’t share things that should not be shared!  I realize this is a weak principle (according to the principles of principles!) and a corollary to principle 1, but I think it’s important to state.  Some things are better not shared – they are unique to a business unit or function, there’s no leverage in sharing them, and sharing them will compromise quality or service (lowest common denominator).

Let me move on to a couple of models or lenses that I work with my clients to look through at IT capabilities.  The first is an oldie but goodie – the Value Disciplines from Tracy and Wiersema’s Discipline of Market Leaders.  The authors describe three distinct value disciplines – Operational Excellence, Customer Intimacy and Product Leadership. They argue that while any company has to be good at all three, operating models tend to optimize for one of the disciplines.  Not everyone buys this argument, and like all generalizations, there are some limitations to the assertion, but by and large, I’ve found the lens to be invaluable over the years.  Let’s look at the disciplines:

  • Operational excellence means providing customers with reliable products or services at competitive prices and delivered with minimal difficulty or inconvenience
  • Customer intimacy means segmenting and targeting markets precisely and then tailoring offerings to match exactly the demands of those niches. Companies that excel in customer intimacy combine detailed customer knowledge with operational flexibility so they can respond quickly to almost any need, from customizing a product to fulfilling special requests
  • Product leadership means a focus on product innovation, offering products that push performance boundaries

Translating this into the world of IT, it is clear that IT organizations have to embody all 3 disciplines.  It is also interesting to note that climbing the business-IT maturity model tends to focus on the Operation Excellence needs first (IT infrastructure), then on the Customer Intimacy pieces (business processes and applications) and finally on Product Leadership (business innovation through IT).

IT operations (data centers, telecommunications, help-desks, etc.) lend themselves to an operational excellence model.  That is why frameworks such as ITIL can be so useful.  Discovery of IT-enabled opportunities is inherently a customer intimacy play – which is why this function is often best embedded in the business – logically and physically.  I believe that Enterprise Architecture and advanced technology research and development are essential a product leadership play, and these work best with a central focus (perhaps a competency center, community of practice or center of expertise – terms that get used in many different ways) coordinating a distributed network.  For example, an Architecture Center of Expertise owns the role of defining standards and enterprise-level models, but works through a network of business and technical architects (roles, not necessarily full time jobs) distributed throughout the enterprise.

This is turning into a longer post than I like, so I will stop there but follow up with a post on another organizational design framework I’ve found very helpful – one that comes from Henry Mintzberg.

Shadow IT: The Good, The Bad, and the Ugly

I’ve posted before about Shadow IT, but I want to revisit the subject – I think it’s a big issue that needs some more air.  I’ve been reminded of this lately as I work with a client with a neglected IT capability.  A new CIO has been brought in (the first sign that a hitherto neglected IT capability is now getting some attention) and he’s asked us to help him review the global IT operating model.

Among the challenges this CIO faces are a number of Shadow IT groups – small groups of people doing IT work around the company, but outside of the IT budget, governance, accountability or responsibilities of the “official, sanctioned” IT organization.  BTW, when I come across Shadow IT groups that are known/recognized, I always wonder about other Shadow IT groups that might be lurking so deep in the shadows that they are all but invisible.

Shadow IT groups are often a symptom of unmet (or poorly met) demand.  As such, they are prevalent in low business-IT maturity environments (i.e., demand appetite exceeds supply capability, so demand creates its own supply).  Paradoxically, they are also prevalent in very high business-IT maturity environments, although we would probably never refer to them as “Shadow IT.”  More likely we’d think of them as “power users,” or “embedded IT capability” and we’d encourage and celebrate such indicators of high maturity.  So, rule 1 – it’s important to know why you have Shadow IT.  If it’s a result of low maturity, I strongly believe Shadow IT needs to be integrated into the formal, sanctioned, budgeted IT operating model.  If, on the other hand, Shadow IT is a result of high maturity, then the right infrastructure for them needs to be provided, and they should be prodded and encouraged.

Why do I think Shadow IT in low maturity environments should be eliminated?  First and foremost, because they are a symptom of low maturity.  If you are going to eliminate them, you have to commit to (and act upon) improving the state of IT capabilities.  This is, of course, a good thing.  Additionally, Shadow IT groups are often unwitting impediments to improving IT capability.  If as CIO I don’t have the entire budget, then IT spend is sub-optimized.  If as CIO I don’t have control of IT standards, processes and practices, then it is that much harder for me to improve IT capability.  It’s not that some IT capability should not be embedded in the business – it absolutely should.  But exactly what to embed, when and how to embed it are important questions that need to be thought through and the IT operating model properly “designed” (at least at lower maturity levels).  Designing an IT operating model to be something akin to Swiss Cheese, where you have to design around the holes is not efficient, and is not a good basis upon which to drive an IT transformation.

Finally, there’s a “tough love” aspect to tackling Shadow IT groups.  When I was a kid growing up in London, UK, I went to a school where uniforms were de rigeur, complete with school caps!  (Long before AC/DC’s Angus Young showed us how cool they can be!)  I was caught once too often without my school cap and was sent to the Vice Headmaster’s office for a dressing down.  Fortunately for me, he was a wonderful man with a sense of humor, a Royal Airforce mustache and manner, and a vintage Rolls-Royce to boot!  He gave me one of life’s great lessons – that it was not about wearing a school cap, per se, it was about setting and living within defined boundaries, so rebellious chaps like me could push against them without doing real harm.  It’s like a parent disciplining their children – if the discipline is absent, the child will feel unloved.  (Of course, too much discipline is even worse!)  Anyway, when the CIO (with appropriate air cover from the CEO and executive team) announces that all IT will be managed under a single IT budget, and all IT-related resources report to the CIO’s organization, this sends a message to the firm – we are raising the bar on IT!  People may not like it, but they will like the fact that someone is getting serious about improving the performance of the IT function.  I’ve often seen situations where the predictions of “Oh, this will create a real stink and lots of resistance!” was far from what actually happened.  Instead, people said, “About time – please take this group back into IT – its where they belong, and where they will have the best growth and career opportunities!”

So, if you have a Shadow IT problem, don’t be a wimp!  Tackle it head on as an integral part of your IT transformation plan.  Be ready for the noise and resistance, but don’t let it derail you!

The Widening Gap In Business-IT Maturity Levels

We have been compiling the results of one facet of our multi-company research into business-IT maturity – the maturity assessment that companies took as part of participation in the research project.

The purpose of the survey was to provide an assessment of business-IT capability in a corporation or business unit. We asked that the survey be completed by an executive familiar with the business strategy for technology use, the roles and work of the IT organization, and the relationship between IT and the rest of the business.  The survey consisted of 50 sets of statements, grouped into 10 categories of 5 sets each. Each set had three statements, and respondents were asked to choose the statement (corresponding to capability level 1, 2 or 3) that most closely matched the current state of capability or focus in the business and its IT organization. If the capability is in transition, or split between two of the choices, the respondent could choose 1.5 or 2.5.

The average of results was interesting, with delivering business solutions and managing enterprise architecture showing as the lowest maturity, and the highest maturity in overall focus and overarching goals (indicated perhaps that the spirit is willing but the body is weak?)  More interesting than the averages, however, are the individual company results.  I know several of the companies that participated in the research quite well, and was pleased at how well the survey instrument results reflected the business-IT maturity realities at those companies.  The really big surprise for me, however, was the fact that the gap between the lower maturity and higher maturity environments is so wide, and my sense (based upon my consulting activities) is that the gap between the high and low maturity organizations is widening quickly.

My hypothesis about this is that once an IT organization embarks on an IT transformation (sometimes they call it that, other times the “t” word is avoided and replaced by some sort of euphemism), they keep transforming, at least to some degree – i.e., they gradually master organization change and continuous improvement, and are able to continue evolving as the business matures and as information technology evolves.  Those organizations that never embark on a transformation program become almost literally frozen in time – a sea of legacy systems, legacy skills, and a hodgepodge of ancient practices – none of them consistently followed.

Of course, in these neolithic organizations it is not just IT that is stuck in the dark ages – it is business leadership who’s mental models about IT are stuck in the same dark place – i.e., low business demand maturity begets low IT supply maturity.  As had been said before, “businesses get the IT they deserve.”  Some companies survive like this for quite a while – there are attributes of their business model that insulate them from the march of technology.  Obscene margins and a rarefied competitive environment in businesses that are not information intensive are such attributes.  However, I am convinced that in the current day and age, every business is quickly becoming information intensive, all margins are threatened, and new forms of competition are ready to strike.  The global forces, changing demographics and shifting economic and environmental environment will drive companies out of business if they aren’t able to cost-effectively leverage IT.

The other side of this coin is that low IT supply maturity dampens and constrains business demand maturity.  I firmly believe that IT leadership must have and use the competencies to be “working the crowd” of business leadership, demonstrating improvement in IT supply, and enlightening business leadership to foster higher IT literacy.  They have to take the lead in turning the vicious cycle of low supply capability limiting business demand, and low business demand constraining IT supply into a virtuous cycle where IT supply increases business demand maturity which in turn leads to increasing supply maturity.

From Enterprise Architecture to Ecosystem Architecture

I’ve been thinking about IT architecture – more correctly, Enterprise Architecture, and most recently, something I’m referring to as Ecosystem Architecture.  This thinking was stimulated by some of the results of our recent Reaching Level 3 multi-company research project.  That research showed that one of the most critical gaps in many companies IT capabilities is around Enterprise Architecture (EA). 

I don’t find this deficiency in Enterprise Architecture capabilities particularly surprising – the nature and role of architecture in the IT world has been evolving over the last few years – especially from a relatively limited focus on technology, to a more contemporary and potentially higher value focus on the enterprise.  At its best, this incorporates enterprise information, business processes, and even the business operating model.  I also recognize that architecture is one of those things that is rarely fully understood or appreciated, is often staffed by people who are technically very bright, with great analytical and conceptual skills, but sometimes lack the kinds of business communication skills that enable them to convince their customers and managers of the value of architectures, and of the need to properly position and resource the EA role.

Compounding the problem, many companies have managed to stave off the need for a real architecture capability by implementing vendor application packages such as an ERP.  One of the “great things” about ERP packages (actually, this is a double-edged sword – see my post “Did You Accidentally Outsource Your Enterprise Architecture“) is that they bring with them much of the IT architecture.  It’s like the buyer of a “Home-Theater-in-a-Box” does not need to be concerned with the arcane technical interface details such as whether and where to use Component Video, s-video, DVI, HDMI, etc.  The buyer who wants, on the other hand, future flexibility by buying individual components and upgrading piece-by-piece as the technology evolves (DVD to Blue-ray, for example) does need to be aware of the ins and outs of component interfacing, and needs to select standards and design an architecture for their home theater.  Of course, they can outsource this to an installation company, but then they may be at the mercy of this company (and their high fees) when they want to add or change components.  The Home-Theater-in-a-Box solution finesses the need for architectural discipline until some type of flexibility is needed that was not anticipated by or addressed by the integrated unit.  If I can push the analogy too far, it’s as if your business partner comes home one day and says, “Look, I just got a great deal on this library of Blue-ray disks – let’s watch them!”  And you, the IT manager of your home entertainment system has to tell the excited business partner, “Em, sorry, but we went for the integrated system, and it is not compatible with Blue-ray!”

So, I find most IT organizations are weak in this Enterprise Architecture space, and I believe this is a dangerous deficiency that over time will create a business disadvantage.  This is especially true as companies move towards becoming Next Generation Enterprises (NGE), or Enterprise 2.0.  In the NGE world, the notion of the business ecosystem becomes key, as does shifting the focus of IT architecture – hence, Ecosystem Architecture.

As I was preparing for this post, I googled Ecosystem Architecture and came across some interesting things.  See for example this presentation on a Digital Ecosystem for E-Logistics Enterprises, and this tutorial on Dynamic Self-Organizing Digital Ecosystem Architectures, and this one on Ultra-Large-Scale Systems.  This is clearly a topic with some interesting work being done, at least in the academic domain, and a topic I will explore further in upcoming posts.

“Edginess” and IT Innovation

In preparing for our upcoming Executive Perspective in Chicago on September 18/19, my team has been exploring what is meant by “edginess?”  What does edginess look like in its various forms?  When and how is edginess good, productive, appropriate?  When is it bad, counterproductive, inappropriate?

John Hagel and John Seely Brown in their landmark paper, “From Push to Pull- Emerging Models for Mobilizing Resources” contend “The edge is where the action is – in terms of innovation and value creation. Companies, workgroups and individuals that master the edge will build a more sustainable core.”   This analogy of “core” and “edge” has influenced the recently completed (though still in the final stages of documentation) research on Reaching Level 3 Business-IT Maturity.

Many IT leaders when talking about the “core” are referring to the “legacy” systems and their drag on resources and forward motion.  They are typically referring mostly to the computer systems and infrastructures they have built over the years and have to maintain.  But in reality, the core goes much deeper than the systems and technologies.  Business processes – especially when you include the unautomated practices and workflows that interact with the automated ones, are hard to change.  The mindsets that dominate “core” thinking and “edge” thinking are radically different.  I’ve noted before that quality guru Joseph Juran distinguished between “preventing bad change” (keeping processes under statistical control” and “creating good change” (innovating processes and products, or creating “breakthrough” performance as Juran put it) and the different management approaches and structures each requires.  Most IT leaders have focused for years on management approaches more consistent with preventing bad change than creating good change.  This has created a mindset that abhors risk taking. 

So, back to edginess.  People can be edgy – those with strong opinions that often feel at first like they come out of left field.  I worked for a boss once that included in our evaluation criteria, “uses appropriate edge!”  This led to a great deal of dialog (all enlightening) and sometimes, real-time coaching when a consultant used appropriate versus inappropriate edge.  In that context, edge was taking a strong point of view that we believed in, even if it felt at the time that client did not share that point of view.  This, of course, is fundamental to good consulting.  Clients don’t hire consultants to blindly agree with all their positions and plans!  There is often invaluable information in edgy people – be they employees, consultants, customers or business partners.  Sometimes, of course, they are wrong, or their timing is off – but there’s still useful information in “hearing” them.  I had a CIO client once that had one of these “edgy” people (let’s call him Fred), and he just did not know how best to leverage him.  We were trying to help his organization become more innovative at the time.  Everyone I spoke to suggested we talk to Fred, and bring him into a workshop we were planning.  When I suggested this to the CIO, he said, “No – Fred’s too disruptive!”  The funny thing is, the CIO really wanted to increase the innovativeness of his organization – and yet his own instincts resisted the some of the very same attributes he wanted to see.  He had risen to CIO by being a great manager, running a very disciplined and effective shop.  He had the vision to know he needed to moved the shop beyond that (beyond Level 2 to Level 3, in the nomenclature of our Business-IT Maturity Model) but was inhibited by his own instincts.  It’s a case of, “I’ve found the enemy – and it’s me,” or “Be careful what you wish for!”  I think Fred left the organization soon after that – and I believe it was an unfortunate loss.

Technology can be edgy – by which we mostly mean “on the leading edge.”  Many IT shops have a well-worn principle that states, “We will be a fast follower of emerging technologies, but chose not to be at the cutting edge.”  I won’t comment here on the pros and cons, and even validity of such a principle, but clearly such shops have made an explicit decision (at least, in principle) not to be edgy in terms of technologies.  What will it mean to such an organization when they want to move to Level 3 – to become more innovative?

Humor can be edgy.  The late George Carlin was certainly edgy!  And therein lies the rub.  When are you “at the edge” and when are you “over the edge?”  The answer of course is relative to the observing party, but being edgy, with anything, introduces risk.  Risk that must be balanced against trust, and much has been written about the nature of trust and its role in the move towards Enterprise 2.0. This issue of the edginess of humor and how and where to draw the line came up in our collaboration with Second City (comedy and improv) who are working with us on the Chicago Executive Perspective event in September.  How should we define the boundaries?

I will continue with this “edgy” theme in upcoming posts.

BTW, sometimes I get questions about the photos or illustrations I select for a post.  For those not in the know, the photo here is of the guitarist/backup singer from the successful Irish band U2.  He goes by the name of The Edge.