Monthly Archives: September 2008

Reflections on 1 Year of Blogging: 10 Lessons Learned


Quite amazing, but this blog enjoys its 1st anniversary today!  I’d like to use this minor milestone to draw a few lessons learned, and perhaps some insight about blogging, Web 2.0, and management of change.

My entry to the blogosphere arose from 3 primary drivers:

1.  The first was the acquisition of The Concours Group – my corporate home for about 10 years.  Our new CEO, Steve Papermaster, said at our first meeting (and repeated many times since then), “If we are going to be successful helping companies become ‘next generation enterprises,’ we have to become one!”  This seemed reasonable, logical, even inspirational, but, to be frank, also somewhat mystifying.  What exactly did that mean?  How would we know we’d arrived?  What would look and feel different?

Fairly soon after that, the company implemented our own collaboration hub, were urged to avoid email except where it made sense (with some guidelines on how to decide), added personal tagging to declare, validate and track things such as competencies and interests, and were generally encouraged to learn and discover for ourselves how this might all play out.  Daily postings on the collaboration hub quickly exposed me to readings I would not otherwise have seen and soon began to expand my knowledge base, especially about the Web 2.0 world.  Recommendations and ‘early adopter’ colleagues soon turned me on the the magic of RSS and readers such as Google Reader.  Note, all this in a mostly “virtual” environment – my office is in my home, and many of us in nGenera rarely go into an nGenera office (though many of us do spend time in our customers offices.)

2.  The second driver was more direct – I got a call from blogger extraordinaire Susan Scrupski who had joined nGenera (as we became known sometime following the acquisition) telling me, “I’ve been appointed your blog coach – you need to start a blog, and I’m here to help you!”  I cannot overstate how important this little intervention was.  The coaching probably ended up being about 3 hours on the phone over a few weeks, plus some encouraging messages and advice between calls.  I now pass that advice on to my clients who are trying to become more “socially networked” in their own companies – find someone who’s already an active and successful blogger, and enlist them in helping others learn the trade, as it were.

3. The third driver is more subtle, but important.  I’m inquisitive at heart.  Over the years, my family has laughed at my occasional tendency to take up a hobby with great enthusiasm, and then drop it a couple of years later.  What they don’t appreciate is that when, for example, I took flying lessons when I first came to the USA, it was less about wanting to be a pilot, and more about curiosity about flying – I wanted to know about planes, controls, navigation, and so on.  (By the way, I did the same thing with remote controlled model planes I built, flew and crashed repeatedly for a couple of years way back when!)  When, some years ago, I bought a Sitar (an Indian stringed instrument) and took lessons from a local teacher, again it was curiosity, rather than any ambition to become the next Ravi Shankar.  (The joke there was my teacher would book my 1 hour lessons for 90 minutes to allow time for me to stand up straight after sitting for an hour in the proper, but very uncomfortable cross-legged position with the bowl of the giant instrument resting awkwardly on the inside of my bare left foot!)

So, I had a curiosity about blogging and about how it would work out for me.  On the other side of the ledger were a zillion reasons to resist becoming a blogger.  For example, I already had way more to do than there was time for – I feared the amount of time blogging would require.  I always fear learning a new technology, particularly if it’s not super-user-friendly.  As I looked at some of the basic blogging platforms, I had grave concerns about how much HTML and CSS I would need to learn.  Also, I have to admit that at the time, it was not clear what the benefits would be.  If I wrote it, would they come?  Even more important, would they come back?

So, what have I learned from a year of blogging?

  1. It actually takes me even more time than I imagined it would.  The surprise here was the need to read more, especially blogs, than I had ever previously done.  I reckon there’s probably one hour or more of reading time needed to support one hour of writing time.  The good news is that both the reading and the writing became such a pleasure, that it never felt onerous.  To the contrary, sometimes it is actually cathartic to sit and the computer and write (or read) late in the evening or very early in the morning.  For example, I’m writing this section at 6pm after a very long day in my home office, mostly on phone calls, web conferences, dealing with emails (yes – I still have those to deal with, though much less than used to be the case!)  I find this is a good time to unwind from the day and ease into the evening dinner and perhaps a Netflix video.
  2. I was initially disappointed at the low number of comments I received.  I’ve learned since that this is par for the course, and the level of commentary has picked up over time.  More important, some of the comments have been really insightful and have led me in unexpected and sometimes valuable directions.
  3. I have found that the process of mentally rehearsing things I will post about, and the posts themselves, often helps me process some of the day’s issues that surface though my research, client activities, or from the reading.  i.e., I feel better prepared to deal with these issues thanks to my digesting them through the act of blogging.
  4. Not surprising, but the patterns of readership are very cyclic – often highest on a Thursday, dropping over the weekend, picking up again on a Monday and building from there.
  5. Most satisfying has been the steady growth in readership.  I’m very pleased with the statistics and information WordPress (which I’ve been absolutely delighted with as a blog platform) provides, and am fascinated to learn what search terms bring people to the blog, my referrers, incoming links, top posts, and so on.
  6. More surprising to me is that the readership seems to have relatively little to do with how frequently I post.  I dare not experiment to find out at which point my posting frequency leads to an erosion of readership!
  7. I was very excited when I added the ‘Visitors to this site’ Clustrmaps widget.  I was initially excited as this was my first widget, and it worked!  (Trivial, of course, but as a novice I was not expecting that!)  But the real excitement came with actually seeing that blogging is truly is a global experience.
  8. After a year, I’m still a relative novice.  I’ve experimented with embedded videos and slideshows, but only occasionally.  I need to do more to bring the ideas and issues I write about to life.
  9. Good and unexpected things have surfaced out of my blog, including guest spots on other’s blogs, invitations to write and podcast, and I’ve made some new friends and important contacts.
  10. Finally, the lessons in change management.  I saw the firm’s leadership modeling the behaviors they expected from me.  They set a clear expectation for me, but not in a threatening or dictatorial way, but in a helpful and constructive way – the call I got from Susan.  Having a blogging coach to get me started was absolutely key.  At the time, Susan was working with 3 of us, so we were also able to form a micro ‘community of practice’ and learn from each other.

So, as I enter year 2, I’m relatively satisfied with the first year, determined to make the blog more interesting and valuable in the second year, and am extremely grateful to those who encouraged me to start a blog, and especially to Susan Scrupski for really being the catalyst that got me over the initimidation factor and learning curve.  Of course, my hightest gratitude goes to you the readers – I’m not sure this would be so enjoyable an activity if I was the only reader!

About these ads

Speed vs. Momentum in Organizational Change


Last week I was teaching an IT Leadership Development program with a team of senior IT executives – virtually all of them engineers by training and by inclination.  It was a very energizing and productive session, loaded with thoughtful dialog and rich, provocative discussion.

At one point, one of my colleagues on the faculty, while talking about lessons learned in organizational change stated, “Speed matters – if you don’t move fast, the change you are trying to achieve will likely dissipate.”  The group’s CIO said politely, “No, I think you are confusing speed with momentum.  And it is momentum that matters most in organizational change!”  This led to an interesting discussion where we rapidly concluded that the CIO was correct.  But in the process of that discussion, I think we all got a little more clear on the nature of transformational change, and some of the critical success factors.

I want to drill into the distinction in this post, and see if we can shed light on the murky topic of transformational change – I believe there can be some important insights from this discussion.   First, a caveat.  I was trained as an engineer, but my degree was in Electrical Engineering (my first excuse!) and to be honest, other than the instinctive application of engineering principles I apply daily, I have not given much thought to classical mechanics and the formal definition of terms, so please forgive any engineering goofs – unless they significantly impact my key points, in which case, bring it on!  I’m also going to stay away from quantum mechanics, and the particular spin (if you’ll excuse the pun) that the quantum world adds to classical mechanics.

In dealing with the concepts of speed and momentum, we have to sort out some distinctions with the lazy ways we use these terms in everyday speech, and their mechanical differences.  We tend to use speed and velocity interchangeably.  In fact, velocity is a vector, so it has direction.  Speed is the magnitude of velocity – it doesn’t have direction.  So, strictly speaking, we should be talking about the velocity of change, given that direction is important.  You can imagine a situation where I say, “Fred and Anne are both changing their facilitation behaviors very quickly.”  We might think that’s a good thing, but if Fred is becoming a more effective facilitator, while Anne is becoming less effective, that’s not a good thing.

The speed/velocity distinction is important to understanding momentum, which is the product of the mass and velocity of an object.  Velocity is defined as the rate of change of position of an object.   In everyday speech, mass is often synonymous with weight, but strictly speaking, weight means the strength of the gravitational pull on the object – how heavy it is, measured in units of force.

So, we often talk about speed, when we really mean velocity, and where we should be referring to momentum, which takes into account the mass we are trying to move.  So, the sum of small movements every day across a large organization will have far greater impact than if a few people make great leaps of change.  I came across this great quote (and a nice little audio post) on Odeo.com:

Most business owners make a horrible mistake.  They confuse the words ‘momentum’ and ‘speed.’  The people who really succeed do little things every single day.  The little things start to add up.  The speedsters want to go from start to finish in 55 seconds.  They want to reach the top of the Google ranking in next to no time.  They want to learn a skill like copy-writing or article writing in three weeks.  They want speed. And as you already know: Speed kills.”

This speed/momentum distinction also reminds me of the superb work of Jim Collins and the flywheel analogy he introduced in his classic book, Good to Great: Why Some Companies Make the Leap… and Others Don’t.   In his research for that book, Collins learned that companies who make the transition don’t do so overnight.   He analogizes their success to that of a flywheel, where it is sustained momentum that accelerates the energy output and ultimately drives transformation.

This also reminds me of the wisdom of the great sage of total quality Edwards Deming, and the first of his 14 points: Constancy of purpose.

Create constancy of purpose for continual improvement of products and service to society, allocating resources to provide for long range needs rather than only short term profitability, with a plan to become competitive, to stay in business, and to provide jobs.

As I look at some clients I’ve worked with over the years with their “flavor of the month” change programs, it is no wonder why they move backwards rather than forwards, and why their employees adopt the “this too shall pass” attitude over time, ignoring strategic change initiatives.

Lack of Accountability: Who’s Dirty Little Secret?


Susan Cramm’s interesting post for Harvard Business Publishing, “IT’s Dirty Little Secret: No Accountability” contains some worthwhile observations and valid recommendations, but her post’s title is misleading.  I believe it is not “IT’s dirty little secret” but the “Business’s dirty little secret.”

As has been observed before, businesses get the IT they deserve, and it is primarily a lack of business accountability for the business value of IT investments that places IT in the somewhat sorry state it finds itself with regard to value realization and the measurement thereof.  Now one can argue that IT is accountable for colluding with dysfunctional behavior – i.e., spending money on IT investments on behalf of the business without insisting on business accountability for the results.  This is not only sloppy management practice, it is also a source of “value leakage” (failure to figure out how realized value will be tracked often leads to poorly planned or designed systems due to lack of real understanding and agreement on how the business outcomes will be achieved or enabled by technology and/or process change).

One leading practice we’ve seen that can help address this accountability gap is a partnership between the CIO and CFO focused on driving business value realization from IT investments.  For all the grumbling that it is hard to achieve, there is lots known about how to achieve and some great success stories for those that try.  If you are interested in this topic, please check out my recent posts: Financial Forensics as a Clue to Dysfunctional IT,  and Measuring the Business Value of IT – Where You Can Win By Simply Trying!

Web-Oriented Architecture: From Push to Pull – So Very 2.0!


Dion Hinchcliffe’s excellent recent post on Web-Oriented Architecture (actually, this is his latest in a series of posts on this topic) reflects an important shift in thinking around technology architecture and componentization.  This is the shift from push to pull approaches to change – a shift I’ve covered from from time to time in this blog.  It is, I believe, inherent in the evolution from “1.0″ to “2.0″ (as in Web 2.0, Enterprise 2.0, and so on.)

I’ve posted previously on the shift from IT Architecture to Enterprise Architecture and how this takes you from an IT-out to a business-in approach to design.  I’ve since expanded on this idea in my post about moving from Enterprise Architecture to Ecosystem Architecture).   Our research last year into SOA showed that most companies try to go about SOA the wrong way - IT-out rather than business-in, and as a technical standards rather than a business capabilities issue .  Our research report identified  hope then was that IT professionals would get it, and leverage SOA appropriately.  In retrospect, that was probably an unreasonable hope.  Instead, WOA is evolving naturally from the mélange of emerging standards and architectures.

One of the most powerful attributes of the 2.0 world is its outside-in, bottom-up “pull” nature (as opposed to the 1.0 inside-out, top-down “push.”)  I think that WOA (as a manifestation of SOA) is working because it is emergent, and is inherently “pull” oriented.  Dion captures this beautifully in this graphic.

Note:  Thanks to Brian for his photo from the 2005 Burning Man extravaganza.

IT Organization Design: Part 2


Picking up on my previous post on Organization Design and the Value Disciplines, my colleague Roy Youngman reminded me of the theoretical work by Henry Mintzberg that we drew from many years back.  At that time, Roy was helping me to write a book, Development Effectiveness: Strategies for IS Organizational Transition.  (Note:  I’m not plugging the book – it was written in 1994, and while I think much of it is still relevant, there are more current and relevant books on the topic today.  I include the link here in the interests of completeness.  Of course, if you want to buy a copy, that’s OK too!)

Anyway, Roy has been using the Mintzberg insights with a current client to great effect, and as I was on the subject of organization design, I thought it was worth revisiting these ideas.  Mintzberg’s Theory on Organizational Forms discusses four “standardization” strategies that can be applied in organizational design:

  • Standardization of work processes, which achieves coordination by specifying the work processes of people carrying out interrelated tasks.  This is the common model for things that are routine and sequential (e.g., IT operations, data center, telecommunications, IT infrastructure, etc.)
  • Standardization of outputs, which achieves coordination by specifying the results of different work.  This is the best model for things that are collaborative and perhaps visual.  This is perhaps the dominant model for systems development and programming.
  • Standardization of skills (as well as knowledge), in which different work is coordinated by virtue of the related training the workers have received.  This is the model for things that are complex and exploratory.  There is an element of this in all IT roles, but tends to apply mostly in the more technical and operational roles (think Microsoft Certification programs, Project Management Institute, etc.)
  • Standardization of norms, in which it is the norms infusing the work that are controlled, usually for the entire organization, so that everyone functions according to the same set of beliefs.  I’ve found over the years that IT groups with the most cohesive culture (i.e., they have a shared sense of their destiny, and a passion for fulfilling it) are the most effective in driving performance and leading transformations.  For example, at their best, movements such as Total Quality Management and 6 Sigma instill norms of quality management.  I’ve also found (though this is unfortunately not the norm) values initiatives such as Johnson & Johnson’s Credo Values, and Google’s Mission to be effective ways to motivate and focus people around important values and norms.

Like most models, Mintzberg’s theory is valuable because it simplifies reality.  While the reality of IT organizations can be quite complex (e.g., Mintzberg’s standardization strategies all apply to IT roles to various degrees) it can help to think about the dominant strategy for a given IT capability.

We often find the standardization strategies and the interventions to achieve them get confused.  For example:

  • We see people trying to standardize work processes for things that are not routine and sequential – think of waterfall life cycle methodologies applied to rapid, iterative development!
  • I once worked with a health sciences company who was trying to standardize software development processes in order to comply with Federal regulations, when what was really called for (and far more easily implemented across about 10 business divisions with their own IT shops at very different levels of maturity) was standardization of deliverables (outputs.)
  • We see simple training programs as futile attempts to induce norms such as self-accountability.  Or, as an industry, we have suffered for years without standardization of many crucial IT skills.  Even today, PMI Certification (and legitimate and worthy credentials) are not taken seriously by a majority of IT leaders.
  • I believe that most IT shops pay too little attention to standardization of norms.  For example, many lower maturity groups believe their mission is to do what their business partners ask for, as opposed to do what they actually need.  This reflects norms such as, ‘the customer is always right’ and ‘to be successful I must behave as an order-taker’ rather than ‘my role is to help create business value from IT investments’ and ‘the customer is not always right – they expect us to push back and guide them.’

So, think about standardization in your organization – have you applied the appropriate standardization strategies to your important IT capabilities?  To drive business-IT maturity, what would you like to change with regard to these standardization strategies?

The Economy, Information Technology and Opportunity Creation


I realize it might be somewhat outré (and very circular!) to reference a post that is referencing one of my own posts, but I’m going to do that.  Espen Andersen picked up my post The New IT Role: From Problem Solving to Opportunity Creation and made some important expansions on the inherent ideas, in his post The Opportunity-creating IT Department.

I really believe that with the confluence of a weakening global economy, widespread social and political upheaval, and the emergence of a whole slew of “2.0″ information technologies, it is now more important than ever to find creative and constructive ways to drive growth and innovation by whatever means.  I made a personal vow when I started blogging almost a year ago to stay out of certain topics – politics being one such taboo.  I am prepared, however, to state my position that I believe a major driver of an economy is psychology and mindset.  With FDR’s words ringing in my head, “The only thing we have to fear Is fear itself” I do believe we can depress ourselves into (or further into) a recession, or just as easily inspire ourselves into an expansion.

I talk to too many CIO’s who have gone into hunker-down mode.  These are the problem-solvers.  They see the problem as IT costing too much, so they try to help solve that problem by doing less.  Of course, the real result is fueling the vicious cycle and creating a self-fulfilling prophecy about the role and cost of IT.  Thank heaven for the visionary CIO’s who are the opportunity-creators.  They see the opportunities in the emerging technologies and capabilities.  They don’t know exactly what that all means to them and their companies, but they are actively involved in finding that out through action and experiments – through bringing leadership and inspiration to their organizations and their companies.

What kind of CIO are you, or do you aspire to be – problem-solver, or opportunity-creator?  What do your actions tell about you?  What can you do to become more of an opportunity-creator?

The New IT Role: From Problem Solving to Opportunity Creation


I was talking with a colleague yesterday about the ways IT management consulting has changed over the last couple of years.  On reflection, the changes for IT management consulting mirror in many ways the changes in the role of IT – at least as far as the more mature business-IT environments are concerned.

For many years, IT specialists inside large businesses and agencies (i.e, I’m not talking about companies who’s business is IT) have pursued a role of problem solver.  “Too much slack in the supply chain?  We can help you re-engineer the business process, enable it with slick supply chain software, and problem solved!”  “Too hard to make meaning of all the transaction data that gets generated every day?  We can build at data warehouse and provide sophisticated data analysis tools to help you make better, more informed decisions.”  “Losing track of inventory?  We can put bar codes or RFID tags on goods, and use a tracking system to keep an accurate record of where stuff is.”  You have a problem – the IT organization will help you analyze it, determine root causes, then design and implement a solution.  It’s been a worthy role for years, and the results, more often than not, are successful.

Note how similar this is to the role of the IT management consultant – for years, we’ve been brought in when there’s a problem the CIO needs help solving.  But over the last few years, that has been changing.  My hypothesis is this:  Most of the traditional IT management problems have been solved, or, at least, the CIO and her team have solved similar problems before, and feel qualified to solve them for themselves. Let’s translate than from IT management consultant and the CIO team, to the CIO team and their business partners.  I think similar forces prevail.  The big problems have either been solved, or at least the tools and disciplines of 6 Sigma, business process re-engineering, and other problem solving methods are now reasonably well known, and have become relatively routine.

So, what’s a poor IT management consultant to do?  More to the point (for readers of this blog) what’s an IT professional to do?  I believe the cutting edge of information technology today, with Web 2.0, Cloud Computing, and the evolving convergence between the consumer space and enterprise computing has shifted the paradigm for the IT professional from problem solving to opportunity identification and exploitation.  This may seem like a subtle, semantic shift, but I think it is more profound and impacts the competencies IT pros need to be successful, and the way they see and operationalize their role and relationships with their business partners.  Let’s consider some of the differences between problem solving and opportunity finding:

  • Problems tend to be brought to you (to map back to the IT management consulting analogy, the problems often come to you via a Request for Proposal), whereas you have to go find opportunities.
  • When people bring you problems to solve, they are hoping for a solution (even though sometimes the ‘be careful what you wish for’ adage applies!)  When you find an opportunity, you might have a very hard time selling your business partner on something they weren’t looking for in the first place and that does not solve a recognized problem.
  • The tools used for problem solving are quite different from those used for opportunity identification.  You might be a master black belt in quality improvement, but not know how to be an effective innovator.
  • The solutions available for problem solving are often ‘off the shelf’ while those required to exploit new opportunities may need to be either invented or at least ‘mashed up’ from component pieces.
  • The skills needed for problem solving (e.g., analysis, design) are different from those required for opportunity creation (e.g., synthesis, innovation, persuasion).
  • The relationships involved in problem solving are quite different from those involved in opportunity identification.  Think about your own relationships with the plumber or car repair shop compared to those with a personal training coach or travel adviser.  I don’t care how little the plumber knows about me as a person – I just want the leak fixed quickly, efficiently, and without getting ripped off.  But I do want my travel adviser to know enough about me to point me to the kind of vacation I’m going to really love and benefit from.

I think this type of role shift for the IT professional relates back to several earlier posts. (Forgive me for referring back to my own posts, but I believe that looking for patterns and connections is important to understanding the changes in the world around us and to opportunity identification.)  For example, in IT Pros – What Will Become of Them I talked about the risk of the old-style ‘business analyst’ becoming a dinosaur.  In Financial Forensics as a Clue to Dysfunctional IT I referenced IT funding as often driving dysfunctional behavior.  In fact, IT funding is often set up for the problem solving paradigm – i.e., funds are made available once a problem has been identified.  As you shift to opportunity identification, it becomes hard, if not impossible, to get the funding needed to pursue opportunities.  In my post Some Suggestions for a CIO 2.0 I talked about the shift in a Web 2.0 world from “the business problem to be solved” to the “potential opportunities to surface”; from “projects to be framed out” to “experiments to find and stimulate, communities to seed”; and from “deliverables to be created” to “behaviors to be fostered.”

So, are you operating primarily as a problem solver or an opportunity creator?  Are you helping innovate products, processes and services, or simply helping take the kinks out of them?  Are you helping grow the business top line, and perhaps creating new revenue streams, or helping improve the bottom line by taking out costs?

IT Pros – What Will Become of Them?


Ben Worthen had a great post last week in the WSJ Business Technology blog entitled “Tech Pros: The Next Dinosaurs?”  Ben cites Nucleus Research’s Rebecca Wettemann:

It’s the logical consequence of two interrelated trends: the average worker becoming more tech savvy, and tech companies realizing that appealing directly to workers is as – if not more – important than appealing to IT management… There was a time when IT departments could get away with forcing employees to use complicated and hard-to-use software. The average worker didn’t know that better alternatives were out there. But as workers gain experience with consumer-focused software – either in their personal lives or at the office – they’re starting to realize that software can be easy to use and quick to get started on. It started with productivity boosters like instant messaging and collaboration software, but it’s crept into the realm of software that’s traditionally the realm of IT departments, such as sales automation.

In the language of Business-IT maturity often cited on this blog, I find that business demand in general is maturing quickly, and IT supply, as defined in terms of the collective supply (hardware, software, services) is maturing alongside demand (perhaps just slightly ahead of demand).  However, if we consider IT supply through the lens of any particular IT organization as opposed to collectively, then to Ben Worthen’s and Rebecca Wettermann’s point, progress is not so rapid or so obvious at many IT organizations.  I’ve referenced before that some IT shops seem to be stuck in time warp – in an age of mainframe programming and big ERP application packages, of taking orders from business partners and delivering against those orders, no matter what the potential business value.  Innovation and collaboration are not seriously visible on their agendas, and notions of measuring business value of IT investments are as foreign as notions of flying saucers and apparitions.

It is the IT pros in these low maturity shops – especially those without a real ambition to drive up both business demand and IT supply maturity that I fear for.  They are becoming the dinosaurs.  They evolved in a time when you could get by with a fairly weak set of IT capabilities, and lay the blame on the business for “not getting it!”  I come across many such IT pros who are cruising along with an ‘entitlement’ mentality.  I have never been more convinced that their time is limited.  They will be the ones that will be outsourced, off-shored and ultimately, will have a hard time staying actively employed.