jump to navigation

Method CIO December 16, 2009

Posted by Chuck Musciano in Technology.
Tags: ,

It is said that during the filming of Marathon Man, Dustin Hoffman stayed up for several days to appear appropriately disheveled for a particular scene in the film.  When his costar, Lawrence Olivier, asked why, Hoffman explained that method actors were trained to actually experience the role they were playing.  Olivier replied, “Why don’t you try acting?”

While actors may choose to act or to use Stanislavski’s classic Method, I don’t think that CIOs have that luxury.  To be effective, a CIO needs to be a Method CIO: directly experiencing the systems, technologies, and platforms that they will subsequently select, acquire, deploy, and manage.  It is not enough to consider technology at arm’s length.  Technology must be experienced first-hand to be fully understood.

I have always embraced technology, long before I moved into a management role.  Even when I held technical positions, it became clear that reading about new things was not the same as using and exploring them.  The technology we use is too unpredictable, with side effects and unintended consequences that can only be discovered through first-hand use.

I can remember the first time I tinkered with a PC, or used email, or set up a network, or created a web page, or configured a RAID array, or used any of a hundred tools that have since become part of the technical fabric of our lives. My expectations of the technology were dramatically different from my actual experience.  The longer I used the tool, the more I discovered about it.  The lessons learned and the overall experience made it much easier for me to understand the system and be able to decide how and when to use it.

Even as I’ve shifted away from a direct technical role, I’ve stuck with my decision to directly experience as much technology as I can.  That’s why I blog, and use social media tools, and experiment with mobile devices.  It’s not that these tools hold a sudden fascination for me.  Instead, they are simply the next generation of potentially useful technologies that may or may not matter to me and my company.  I’m expected to be able to evaluate these tools for their personal, professional, and corporate potential.  I can’t do that effectively without directly using them until my curiosity is satisfied.

Obviously, no one has the time (or the wherewithal) to try everything that crosses their path.  We have to use some discretion to sort out the potentially valuable tools from those that may not be worth a look right now.  Even the list of potential tools can be long and unmanageable; that’s when we need to engage other like-minded folks to experience those tools and share their impressions.  Others who share the enthusiasm for the “Technical Method” can be a tremendous help in sorting through the ever-increasing amount of stuff that comes our way.

With all due respect for Sir Olivier, I think that Method CIOs develop a deeper understanding of the technology they manage.  Were Dustin Hoffman ever to turn his attention to IT management, I suspect he would agree.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio144″ only_single=false]

Way Too Much Information December 2, 2009

Posted by Chuck Musciano in Technology.
Tags: , ,
1 comment so far

I received an invitation to Google Wave a few weeks ago.  I was anxious to try it, but got little traction.  Since then, a few more friends have joined, and I’ve been able to experiment a little bit.  The jury is still out on the ultimate usefulness of the tool, but there is one “feature” that gives me pause.

If several people are actively participating in a conversation, the Wave interface actually shows their typing, in real time.  This is the next logical extension of existing instant messaging platforms, which note when another party is actually typing.  This was a handy feature, since it let you know if the person at the other end was actively participating.  Wave’s extension, on the other hand, is unnerving.

Very few people, myself included, write complete, rational thoughts on the first try.  Instead, we type, think, delete, edit, retype, and iterate until we have composed a complete message.  We often start out with something that we later contradict, or use a word or tone that we might regret and subsequently remove.  The end product represents a finished thought.

Google Wave exposes that entire process.  It is weird, and a bit voyeuristic, to watch someone in the act of composition.  In one conversation, I actually began responding to a person’s message, only to have them edit and change it before after I had posted my now-inappropriate response.  My response made no sense, and they knew I had been privy to a thought they later chose to retract.

It should be obvious by now that I am a big fan of all these new-fangled communications tools.  I like the idea of being instantly connected, and I enjoy the immediacy of keeping up with other people.  Twitter, Facebook, LinkedIn: I get it, and I use it.

But this crosses a line.  I am happy to share what I am doing, but I am not willing to expose my actual thought processes before they are fully formed.  Rapid communication is fine, but at some point there are aspects of what I am doing that I absolutely do not want to share.

I suspect that the folks at Wave did not set out to design a “thought exposure” feature.  Instead, I suspect they think that this is just a cooler way of showing that the other parties are typing and interacting.  I’m hoping that they’ll see the error of their ways and at least let me turn this feature off.

The whole experience reminded me of a scene from the show Married… With Children. Peg Bundy and her long-suffering husband Al are sitting silently on the couch.  Peg finally tries to break the ice by asking, “Al, what are you thinking?”  Al, speaking on behalf of every man on earth, replies, “If I wanted you to know, I’d be talking.”

Google, if I want people to know what I’m thinking, I’ll click “Done.” Until then, I’ll keep my keystrokes to myself.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio138″ only_single=false]

There’s Not An App For That November 30, 2009

Posted by Chuck Musciano in Leadership, Technology.
Tags: , , ,

I’ve been in a few CIO briefings of late that have revolved around the topic of business process management.  There is little doubt that much value can be found in formally capturing, defining, and managing the hundreds of processes that keep our companies running.  Even the simplest processes can have costly inefficiencies that can make a big difference in delivering good service and maintaining efficient operations.  A good BPM exercise can find and eliminate those issues and yield a good return on the effort.

For many of these initiatives, much time is spent selecting and implementing the right tool.  Certainly, having a sound workflow system to drive your processes helps.  The right system can automate mundane tasks, track all sorts of things, and make sure people know who needs to do what when.

As with most tools, however, it is easy to get so wrapped up in the tool that you lose sight of the real goal: creating a better process.  While it may be fun to connect lots of boxes with lots of lines, you’re creating a monster, not a better way.

I was once a party to just such a monster, several years ago.  As part of a workflow design team, we were tasked to formalize and automate a process within  our company.  This process had several gates, at which point someone could reject the item and stop the process.  This had been a bit of a sore point in the past, so we were careful to design in ways for rejected applicants to appeal their rejection.

This quickly escalated into a multi-level appeal process, with committees and advisors and automatic hearings.  It looked great on paper and took seven pages to draw out all the various options and choices that could occur.  We were pretty proud of this “better” way of doing things.

Finally, we all came to the same conclusion: this was a disaster in the making.  First, it would be extremely difficult to implement.  Second, it attempted to automate tasks that really needed to be handled by people.  And third, it would cause confusion and chaos among the users.

The real answer to the problem was far simpler: when an item was rejected, the rejecting party was expected to call and explain the circumstances to the rejected party.  The whole group realized that actual communication had an important place in the automated workflow.

That lesson hasn’t changed.  Tools are useful, but they can only go so far.  We cannot automate the most important part of any business: the interaction between team members as they get work done.  We need to use tools to remove the drudgery so that people have more time for the high-value interaction that really counts.  Freed from mindlessly shuffling paper (or email), people can actually discuss issues and work things out.  Communication is the most important thing we do; unfortunately, there isn’t an app for that.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio137″ only_single=false]

The Happy Path November 2, 2009

Posted by Chuck Musciano in Random Musings.
Tags: , , ,

In our last episode, I argued for a more consistent application of the 80/20 rule as we design and deploy software.  I made an exception for testing, however, which prompted a comment asking why testing gets exempted from this rule.

As the saying goes, testing only proves the presence of bugs, not their absence. The goal of testing is to find as many of these bugs as possible before moving code into production, in the hope that we will avoid inflicting them on our poor unsuspecting users.  Unlike a system in which we intentionally design and deploy the first eighty percent so as to get some value to the customers more quickly, we cannot test just eighty percent using a similar rationale. We need to test everything we build as best we can.

There is a limit, of course.  You can’t test forever.  The trick is to know what to test, and to test those parts thoroughly.

A co-worker of mine often talks about the “happy path.”  The happy path is the path through a system where everything works, the data is correct, the system stays up, and the users are well-behaved.  We tend to test the happy path first because we understand how the system should function and want to ensure that the basic features should work.

This results in testing scenarios like this

  • User selects an item and adds it to their cart
  • User enters billing data
  • User enters shipping data
  • User clicks “Check Out”
  • Transaction is processed

If this works, has the system been tested?  Yes.  Would you move it into production? The right answer is “no,” but I’ve used a lot of systems where the apparent answer was “you bet!”

We need to move off the happy path and wander in the weeds.  What if the quantity exceeds stock on hand? What if the user enters too few digits from their credit card? Or too many? Or adds a space, or a dash? What if the zip code doesn’t match the state? What if? What if? What if?

It doesn’t take long to test the happy path.  It takes forever to test everything off the happy path. You need to spend a lot of time wandering away from the happy path, and maybe there is a reverse rule for testing: 20% of your time on the happy path; 80% of your time off of it.

For some reason, I was born off the happy path.  Even at a young age, I was doing things like sticking Christmas lights directly into outlets (they explode and leave a mark on the wall) and riding my bike with my eyes shut (you hit parked trucks and knock yourself unconscious).

I have developed a reputation as the guy who can break things, much to the chagrin of every development team I have ever worked with. I wish I had a nickel for every time I’ve been told “no one ever tried that before.”  As much as it annoys developers, people who can break things are crucial to building solid products.  Better that we break them instead of a user.

We need to find and engage the non-happy-path people in our teams, and make sure that they spend a lot of time testing everything we build.  Admittedly, you cannot test forever, but having the right people test for as long as possible can make a world of difference.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio125″ only_single=false]

Being Bartholomew Cubbins September 16, 2009

Posted by Chuck Musciano in Leadership.
Tags: , ,

Consider an ice cream company.  They make great ice cream and have enjoyed much success over the years.  But lately, their market share is slipping, and they are feeling heat of the competition.  They decide they need a new product line, a complete new set of frozen treats that will reshape the ice cream market.  To whom do they turn for product design and development?

Their CIO, of course!  Who better to know the vagaries of ice cream eaters?

Wrong. We all know this is wrong.  They would no more ask the CIO to design ice cream than they would the CFO or their general counsel.

Why, then, do companies that develop more technical products turn to the CIO to develop and market those products?  Why would anyone think that  a CIO, with their deep knowledge of systems, infrastructure, and service delivery, is able to build and sell a product at a profit?

Many CIOs these days are suddenly wearing several hats: CIO, Product Development, Web Marketing, and the like.  Some CIOs even have a P&L and are expected to make money for the company!  Who ever got it into their head that CIOs are also savvy marketers and salesmen?

As technology pervades every aspect of our lives, computing is becoming intertwined with almost every product bought and sold.  Desperate for help with all this technology, companies are turning to the only people they have on hand that seem to understand how to make all this stuff work: the CIO.  If a widget suddenly has a computer in it, the CIO is called in to help design, build, market, and sell the widget.  In some cases, they put the CIO completely in charge of the entire widget division!

This is a big mistake.  I take great pride in being a CIO, and I work hard to be a good one.  I have lots of experiences with computers and building software systems. I have no experience with developing and marketing products, whether they have computers in them or not.  I should not wear that hat.

I can provide lots of advice to a product developer who has little computing experience.  A person who understands the market space and has a brilliant idea, but has little understanding how computers might be used in that product, would do well to consult with a good CIO to understand the benefits and risks of the technology aspects of the product. Together, we could do great things.  Separately, we’re on the verge of disaster.

When you talk about very non-technical products, like ice cream or lawn fertilizer, this seems like an easy argument to make.  When the products involve lots of technology, like online banking or web-based shopping, people have a harder time seeing the distinction.  I think the problem is compounded by the fact that lots of CIOs are itching to do other things and gladly accept these other hats, all with the best of intentions.

I think a CIO can get in a lot of trouble by wearing too many hats.  If you want to be a CIO, wear that hat.  If you want to be a product designer or marketer, wear that hat.  But, like Bartholomew Cubbins, CIOs with too many hats are going to find themselves, sooner or later, all sorts of difficulties.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio105″ only_single=false]