jump to navigation

What Are You Measuring? October 21, 2009

Posted by Chuck Musciano in Leadership.
Tags: , ,
4 comments

When you boil it all down, computing is about numbers.  Two of them, actually, 0 and 1.  Over the years, we’ve worked up from that, of course, so that you have to dig to find the 0s and 1s, but our obsession with numbers is deeply ingrained.  This has bad implications for those of who try to lead IT organizations.

Given our predilection for numbers, most people in IT like to collect them.  Storage usage, bandwidth, code size, database tables, and the like are obvious targets for the numerically fascinated.  But we also collect more abstracted numbers, like project success rates, hours spent doing things, call volumes, and satisfaction indices.  Sometimes, we place a lot of importance on these numbers and work hard to optimize them in some fashion.

Some numbers are necessary.  On the operations side of the house, disk utilization and processor loading are important metrics that drive good capacity planning models.  These numbers are easy to collect and understand because they relate back to physical resources that can be measured accurately.

Other numbers are a bit softer.  Many organizations try to quantify qualitative data, like customer satisfaction.  Gauging satisfaction is tough; there is no number that equates to “great” or “awful.”  That doesn’t stop us, however: our inherent love of numbers leads us to assign numbers to feelings and opinions. That’s not inherently bad when we make simple comparisons.  When one customer rates us a 9 and another decides we are a 1, there is a clear difference of opinion.

The problem with numbers is that they are so prone to manipulation.  Once you make the leap from adjective to value, it is way too easy to start doing arithmetic.  Suddenly, we are averaging those ratings, or worse, computing standard deviations and higher order statistical metrics.  These computed values are worthless, no matter how attractive they may seem.

Consider: if you are in a room with two people, one of which says “I love you” and another that says “I hate you,” the average in the room is not “We like you.” Depending on which way you turn, you are going to either get kicked or kissed.  Math and emotion simply do not mix.

In spite of this, many organizations use these numerical metrics to make business decisions and control compensation.  I’ve seen teams rejoice when customer satisfaction climbs from 3.3 to 3.5, as if the 0.2 difference has any significance.  They are beholden to the numbers and have lost track of the feelings and emotion behind them.

Part of being an expert with a tool is knowing when you shouldn’t use it.  We fancy ourselves to be experts with numbers; we should do a better job of applying them appropriately. In many parts of our businesses, we need to stop focusing on numbers and start listening to people. That’s where you’ll find the real answers and understand your real problems.

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

Missing Users October 14, 2009

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

A common conversation among CIOs these days is how they are dealing with the current recession.  We talk of budget issues, staffing concerns, reduced resources, and a general reduction in our ability to execute and expand our services.  Especially at this time of year, the conversation turns toward next year’s budgets and what we might expect to see in the coming year.

One of my big worries for the coming year is a shortage of users. Not in the sense that there won’t be people to use our systems, but in that IT cannot survive without those critical users that help define, build, test, and deploy our systems.  The economy is affecting the supply of users that are able to help us do things.

For many years IT worked in a vacuum, building things as we saw fit.  The prevailing attitude was that users should be happy with whatever they got, and little time was spent engaging users to ensure we were building the right things the right way.

Many of us (or those of us still employed in IT) realized that this methodology was less than effective and changed our approach.  We actively engaged our user community in every aspect of the development process.  From project charter through requirements analysis, testing, training, deployment, and post-production support, users with specific business knowledge are key to the success of our projects.  Without them, we are doomed to fail.

Unfortunately, the economic pressures being exerted on IT are being felt by everyone else.  People are busier than ever before, doing more with less.  As a result, they simply do not have the time to engage with IT to partner for success.

In a sense, finding that time to help is harder for our users than it is for our staff.  The reality is that many IT shops can easily augment staff by backfilling with contract labor.  If you want to focus a few developers on a new project, you can bring in additional contractors to take over the day-to-day stuff while your developers dive into a new project.

This is rarely possible with non-IT staff.  Business people, especially those that assist with IT projects, usually have deep knowledge of your company’s business rules and processes.  If they are added to a project team to contribute that knowledge, you cannot easily hire an outside contractor to backfill that knowledge gap.  For the most part, IT skills are fungible; non-IT skills are not.

This has deep implications for our ability to execute and deliver results to our companies.  As we seek funding to do things, it can be easy to overlook the non-IT assets needed to make those things successful.  Funding can’t expand those resources, yet our success depends on engaging those very important people.

What to do?  There is no easy answer.  First and foremost, coordinate early and often with you business partners to ensure their availability and willingness to help.  Be very respectful of their time and engage them for your most important work first.  And like most things in life, these times will pass, things will improve, and we’ll re-engage with our previous fervor.

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

Chief Guinea Pig October 12, 2009

Posted by Chuck Musciano in Leadership.
Tags: , ,
4 comments

As technology penetrates every aspect of the business world, those of us in IT find ourselves deploying tools more and more frequently.  These tools are more tightly integrated to everything our users do.  In days gone by, we provided green screens for data entry and green bar for rudimentary reporting.  Now we control every aspect of communication, including voice, email, and text messaging, and provide interfaces to every system in the business.

Most shops do a lot of testing before rolling out new stuff.  Typically, testing begins on the IT side of the house and ends up on the user side, with qualified end users signing off before something goes into production.  Is there a place in that process for the CIO?

I think there is.  I think I have a responsibility to know how our systems function and what the overall user experience is going to be. I’m the first to admit that I am not qualified to test the business processes behind these systems, but I do think I have a voice in the general experience.

Generally, I consider myself the primary guinea pig for almost everything we deploy in my company.  I usually try out each new laptop, many new phones, and almost all user interfaces that we develop.  I try to see how these tools would impact a typical end user.  Are they easy to use and understand?  Do they have confusing options or weird configuration choices?  Would users be confronted by tedious, pointless interaction sequences?

In short, if I were an end user, would I be happy with the device or system? I feel strongly that I should never ask a user to use a device or participate in a process that I have not personally experienced.

In conversing with other CIOs, I find that some do not wish to engage at this level.  They don’t have time to go through this process and don’t feel that they are qualified to make a reasonable judgment. However, most of them do have trusted coworkers that fulfill the role of guinea pig for them.  They value the testing experience; they’ve just outsourced the task to someone else.

There have been times I find myself doing the same thing.  Some new phones are only available on other carriers; I’ll find someone I trust to see if the phone is acceptable.  Some business processes are beyond my reach (or security level), but I’ll find someone else to give me the unvarnished truth about a new system.

CIOs should be operating at a strategic level above the details.  That altitude, however, does not absolve of us from having the ultimate responsibility for the quality of everything we deliver to the business. Ironically, our distance from a tool or system gives us a different perspective from the developers who toil so closely with it.  By being closer to the forest than the trees, we can often see problems that are overlooked by the tactical developers and testers.

Although it may drive your developers to distraction, simply asking “why?” as you walk through an interface or use a device may ultimately create a better experience for your end users. And that, regardless of your preferred level of engagement, is what our job is all about.

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

Field Of Rakes October 9, 2009

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

In the surreal sitcom My Name Is Earl, Earl (our hero) is at one point confronted with a series of challenges that he must complete to rescue Catalina, his brother’s true love. One of the more painful trials is that he must run through the Field of Rakes, blindfolded.  The rakes are positioned tines up, so that each mis-step results in Earl getting smacked in the face with a rake.  Earl’s painful sprint will seem eerily familiar to anyone who has spent any time in IT.

It is easy, in IT, to build your own Field of Rakes.  Each time we disappoint a user we add a rake to the field.  Even the simplest of problems can turn into a rake that will pop up to smack us in the face when we least expect it.

We work hard to do the big things right: system upgrades, new technology deployments, and major projects get lots of attention so that they don’t go awry.  That makes sense; big projects involve a lot of rakes, and the last thing you want to do is add several hundred rakes to the field in one fell swoop.

Unfortunately, we often get the big projects right but fail on the little things.  Individually, the little things don’t present much risk. After all, it would be pretty easy to run across a field with a single rake.  But all those little things, taken over time, can fill a field with lots of rakes.

What can add a rake to your field? Anything and everything.  Denying a request for special software.  Failing to follow up on a support call.  Getting stuck between two competing users, so that you’re guaranteed to get a rake from one of them.  Missing requirements from a user.  Mismanaged expectations on a contract negotiation.  Ignoring what people really need and acting like you know best. I could go on and on, and every seasoned IT pro could add to this list.

How do you avoid adding rakes?  Easy: listen, care, and communicate.  Continuously. Every rake is the result of our inability to communicate and relate to someone.  As service providers, it is inevitable that we will disappoint people.  How we handle that moment and compensate for the problem determines whether we get a rake.  People know we cannot be perfect, but will only be gracious about it if we sincerely and diligently work to meet their needs.

Even with our best efforts we’ll still get a few rakes, and our run across the field may be a bit painful at times.  But diligent attention to people is the real key to IT success.  My Name Is Earl was a series about karma, good and bad.  All those rakes represent your karma, collected over your career. Focus each day to look for the rakes and remove them from your field.  May we all run through empty fields!

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

In Defense of Apprentices October 5, 2009

Posted by Chuck Musciano in Leadership.
Tags: ,
5 comments

My recent post on knowledge capture generated all sorts of outstanding comments and feedback. Repeatedly, one thing stood out: the idea that apprenticeships, often seen as an “old school” training tool, may be one of the most important ways to transfer real knowledge in an organization.

For hundreds of years, the preferred (even required) way to learn a trade was to become an apprentice to a master.  Over a period of years, the deep knowledge of the master was transferred to the apprentice, until a new master had been created.

We have little patience these days for anything that might take years.  Instead, we seek ways to accelerate the learning process, capture the salient details, and transfer them in days and weeks, if not a few hours.

My original post contended that the knowledge could not be captured in some handy electronic format.  The comments extended this to point out that knowledge, even if captured, could not be quickly transferred.  Instead, it takes time and a deeper relationship to cement the deep concepts in any field.

Apprenticeships were created long ago, when the skills to be transferred were part of a formal, physical trade.  The idea, however, works just as well in the intangible world of management and leadership.  In some ways, we still embrace the idea, although in a reduced fashion over a shorter time frame, with labels like “mentoring” and “coaching.”

Why the name game?  Is there some shame in being an apprentice?  Why not call it what it is?  Perhaps we need more “apprentice CIOs.”

While I have never carried a title that included the word “apprentice,” my deepest learning occurred when I was acting in that role.  I learned the most about operations when I was essentially apprenticed to a great operations director.  My first true CIO role was preceded by a period of apprenticing to a COO who had once been a CIO; he was able to show me the ropes in a most productive fashion.  My current position began with me reporting to the then-current CIO, who took his role as a teacher very seriously.  He helped me understand the culture of our company, so that when he moved on I was positioned to extend his successful track record.

Are you in an apprentice position right now?  Do you need to be?  Perhaps you are and don’t realize it, or think of it that way.  Conversely, is someone apprenticed to you?  Should they be?  Are you even thinking about the relationship that way?

I think we have wrongly relegated the concept of apprenticeship to another era.  Perhaps we need it now, more than ever. Let’s reconsider the need for apprentices in our organizations, and restore the role to the position of honor that it deserves.

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