There are three levels of success, in action: doing it right, doing the right thing and redefining right.
At best, the simple joy of performing an IT function is difficult and automated. Technology changes faster than IT architects can find time to keep up with. As a result, if you are not putting out IT fires or lavishing effort on the next killer technology, you are trying to master better ways of doing things. You know, "smarter" not "harder"... "faster" .. "more with less"... "support that non linearly scales with headcount".
Once you cross this step, there are decisions to be taken about the right thing to do. Armed with technical expertise, mastery of IT business, and of the role of IT in business, one can craft a trajectory for IT. Portfolio management, project management, business knowledge, soft skills and execution efficiency are all subservient, in this phase, to what can be termed "far sight": what are the right mix of technologies and technology changes that one would have to focus on. This is difficult passage, melding the skills of IT function, business form, and an experience rooted in the art of change.
The final frontier is a different level. This is the domain of the unknown - like taking on a business function and running with it, or creating a product out of IT organization's efforts. Here, you ask questions that no one in IT has asked the business without an immediate "no" for an answer: can you develop a product that can be used by R&D within an engineering firm; can you create a new financial model for your bank, from within IT?
Now, why would anyone hand over their core competency to IT, you may ask. The answer is that most times core is a synonym for a tangled mass of competencies ossified over time which no one dares to unlock or pry apart. And sitting right in the middle, as the lowest common denominator, is systems magic or fundamental infrastructure that was baked in because it was a "good enough" implementation for the job on hand. This has served the organization for a long time, and is completely "implicit". Everyone uses it, or everyone has their own version of it.
How cool would it be to invent a new way of doing core business? How better would it be to make an IT solution as a core business in it's own right? How difficult would it be to evangelize this view to insiders and make them converts, one by one, to the realities of a changing world. How do you craft a solution that serves a disruptive market, yet does not threaten the core areas of business, with an IT innovation serving as the platform.
Welcome to redefining right! Very few organizations think about this, and fewer have performed this transformation. Most times, it is not deliberate. In the best, the CEO realizes a winner, and quickly moves to position it as a core competency (Amazon's EC2 is the best known example I can think of).
When this is done well, you can see the change. Not by what happens, but by how everyone views IT's role. Everyone now wants to know how IT works, and learn how to fit into the IT framework. Or even better, compete with you on building a better platform than you did. That's when you know you've won - you create a reference implementation.
The transformation is completed when you are not merely "serving (internal) customers", but "selling to (external) customers", hand-in-hand with business. When you're not the lowest common denominator, but the greatest common unifier (of organizational boundaries). When you (IT) are the uncommon denominator of success.
At best, the simple joy of performing an IT function is difficult and automated. Technology changes faster than IT architects can find time to keep up with. As a result, if you are not putting out IT fires or lavishing effort on the next killer technology, you are trying to master better ways of doing things. You know, "smarter" not "harder"... "faster" .. "more with less"... "support that non linearly scales with headcount".
Once you cross this step, there are decisions to be taken about the right thing to do. Armed with technical expertise, mastery of IT business, and of the role of IT in business, one can craft a trajectory for IT. Portfolio management, project management, business knowledge, soft skills and execution efficiency are all subservient, in this phase, to what can be termed "far sight": what are the right mix of technologies and technology changes that one would have to focus on. This is difficult passage, melding the skills of IT function, business form, and an experience rooted in the art of change.
The final frontier is a different level. This is the domain of the unknown - like taking on a business function and running with it, or creating a product out of IT organization's efforts. Here, you ask questions that no one in IT has asked the business without an immediate "no" for an answer: can you develop a product that can be used by R&D within an engineering firm; can you create a new financial model for your bank, from within IT?
Now, why would anyone hand over their core competency to IT, you may ask. The answer is that most times core is a synonym for a tangled mass of competencies ossified over time which no one dares to unlock or pry apart. And sitting right in the middle, as the lowest common denominator, is systems magic or fundamental infrastructure that was baked in because it was a "good enough" implementation for the job on hand. This has served the organization for a long time, and is completely "implicit". Everyone uses it, or everyone has their own version of it.
How cool would it be to invent a new way of doing core business? How better would it be to make an IT solution as a core business in it's own right? How difficult would it be to evangelize this view to insiders and make them converts, one by one, to the realities of a changing world. How do you craft a solution that serves a disruptive market, yet does not threaten the core areas of business, with an IT innovation serving as the platform.
Welcome to redefining right! Very few organizations think about this, and fewer have performed this transformation. Most times, it is not deliberate. In the best, the CEO realizes a winner, and quickly moves to position it as a core competency (Amazon's EC2 is the best known example I can think of).
When this is done well, you can see the change. Not by what happens, but by how everyone views IT's role. Everyone now wants to know how IT works, and learn how to fit into the IT framework. Or even better, compete with you on building a better platform than you did. That's when you know you've won - you create a reference implementation.
The transformation is completed when you are not merely "serving (internal) customers", but "selling to (external) customers", hand-in-hand with business. When you're not the lowest common denominator, but the greatest common unifier (of organizational boundaries). When you (IT) are the uncommon denominator of success.
i feel that the following should be cyclic and not one time effort
ReplyDeleteredefining right -> doing the right thing -> doing it right -> goto redefining
Can't agree enough on your following statement..
"The answer is that most times core is a synonym for a tangled mass of competencies ossified over time which no one dares to unlock or pry apart."
i would like to extend and say that lack of courage in questioning the status quo leads to further mass accumulation and blurs the core competency. Core competency is not constant and got to change periodically ..atleast once in 18 month review (refining or redefining right).
:-)