jump to navigation

Getting Away February 6, 2008

Posted by Chuck Musciano in Leadership.
Tags:
add a comment

As much as I love my job (and I really do love my job), it is good to get away from the day-to-day activity of the office and think big thoughts. I’m writing this in Reagan National Airport, waiting to fly home after just such a get-away.

In this case, I was attending a one-day seminar sponsored by the CIO Executive Board. They provide CIO-focused research and strategic advice, as well as opportunities to meet with other CIOs facing similar issues. Today, 15 of us met to talk about business engagement and fostering innovation. I know: pretty compelling stuff!

Subject matter aside, it is good to engage in these kinds of meetings. As one of the attendees put it, the sessions are part inspiration, part therapy. Executives at any level are often isolated from their peers; CIOs are no exception. Sometimes it is good to get together, share ideas, and commiserate. Isolated from the office and the constant pull of dozens of urgent issues, you get a chance to think at length about things and really put your thoughts in perspective.

While the topics at hand were interesting, my naturally short attention span allowed me to consider other topics throughout the day. Organizational issues, strategic planning, and technology challenges all seem clearer and easier to tackle after a day of reflection.

This kind of break is not uniquely suited to CIOs, of course, or even just C-level people. Everyone needs to get away every so often to consider the state of their world and how they plan to deal with their challenges. To do so in an environment with your peers, where you can bounce ideas around and see how others are doing things, makes it that much better. You come away feeling good about the things you are doing right, and with potential solutions to the things that you need to improve.

Unfortunately, we rarely schedule time for this kind of micro-sabbatical. Once I found myself working from home for a day while waiting for some repairman to show up. What a productive day! With laptop and cell phone at my side, I cleaned up all sorts of nagging issues, got ahead of a bunch of others, and came away feeling great. It made me wonder if we all should intentionally work in isolation once or twice a month just to boost our productivity.

All things considered, we should, and we should plan it well in advance to ensure that it will happen. There have been times in my career when I’ve had to block out time on my calendar just to work, ensuring that there would be no meetings to interrupt my time. Even now, I block out 8-9 AM every day just to start the day with time to get my world in order. I also set aside two hours every Thursday when I promise my team that I will be in my office, available for whatever they may need to discuss. These little oases of time make a big difference in maintaining my sanity and focus.

Time is precious, and focused time is invaluable. Intentionally setting aside time to focus and reflect is an important way to ensure that we stay effective and happy, no matter what we do for a living.

Trust But Verify January 29, 2008

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

I once worked in a company where the President had, in a former life, been a nuclear submarine commander. Needless to say, he had many fascinating stories. He also had an uncanny knack for uncovering the one thing that you had missed, or forgotten, or simply done wrong. When there was some sort of operational failure, he would methodically dig and dig until he uncovered the root cause. He then expected you to fix it, and then to implement some plan that would prevent the problem from ever happening again. Invariably, as he went about one of these rock-turning expeditions, he would repeat that fundamental rule: “You get what you inspect, not what you expect.”

A simple rule. Don’t assume that things are done correctly. Confirm, with your own eyes, that they really are right. Ask pointed questions. Look at logs. Pull on wires. Click things that aren’t supposed to be clicked. Make sure it really works, the way you understand it to work.

This makes a lot of sense when you are living in a submarine. One mistake in that environment, and hundreds of men die. Make a big mistake in a nuclear submarine and millions of people could die.

Working for someone with this philosophy can be frustrating. When my boss would come digging into my world, I would cringe and wait for the inevitable “aha!” moment. Over time I realized that the best way to avoid such moments was to adopt a similar attitude and find the problems before he did. I started doing my own inspecting, finding and fixing things before they became visible problems. Our operational metrics really improved. And the lesson had been passed on to another generation.

Obviously, you cannot inspect everything, all the time. But everything can be inspected, at some point, by someone. As a leader, you need to engage in enough inspection to ensure that your people, and their people, will be inspecting everything else. As they inspect more, and you come to trust their inspection, you’ll find yourself inspecting less. Much to their relief, I might add. But don’t ever stop inspecting entirely. The possibility of inspection is often enough to ensure appropriate attention to detail.

Unlike a nuclear submarine commander, most of us do not operate in a world where lives hang in the balance based on our operational decisions. But businesses do, and with them come customers, and employees, and shareholders, all relying on a small group of operations people to get it right, every time. Are you willing to bet your job on what you expect, or are you going to take the time to inspect your world?

I expect you will.

Perfect? Or Good Enough? January 26, 2008

Posted by Chuck Musciano in Leadership.
Tags: , ,
add a comment

I am, I fear, driving my team crazy.  One moment, I am demanding perfection, unwilling to accept even the slightest error.  The next moment, I’m encouraging them to experiment, to make mistakes, to get results rapidly to our customers.  It all makes sense to me, but I don’t know that they see the method to my (apparent) madness.

In reality, IS organizations suffer from a split personality.  Half of our job is to deliver any and all computing services, 24 by 7, without fail, no matter what.  The other half is to innovate, find clever new solutions to problems, and get those soutions out to people as quickly as possible.  The former role demands unrelenting perfection; the latter will tolerate (and even requires) failure and iteration.

Operations: All Or Nothing

Running computer operations is easy.  Make it work, never let it fail, handle every contingency, and keep all the users happy.  Like electricity and phone service, users view computer services like a utility and have every expectation that they will just be there, all the time.

Users have every right to this level of service.  There is nothing magic about computer operations.  The discipline of reliable computing is a well-understood field.  The processes and best practices that support reliable computer service delivery are not difficult to master.  If you elect to be in that business, you do so knowing what is expected and what it will take.  If you are not up to the task, don’t accept the challenge.

For those who make operations their life, there is great satisfaction in achieving near-perfection on a regular basis.  A well-run data center is a thing of beauty, and the practices and procedures provide a comfortable, controlled world in which to operate.  Don’t misunderstand: it is hard, thankless work, and the only time you get any attention is when things go wrong.  People standing on the bow of the boat, wind in their hair, rarely appreciate the efforts of those shoveling coal down below.  Satisfaction in operations almost always comes from within.

I find it frustrating when we have an operational failure.  Almost every single operational breakdown can be traced to failure to adhere to best practices, be they in communicating, alerting, responding, preparing, or reacting.  Even when things just explode, there is no excuse for not having a plan that will handle such a rare event.

Like the end users, I expect perfection on the operations side of this business.  But I also deeply appreciate the effort that it takes to achieve such perfection, and will do everything I can to ensure that my operations staff has the tools needed to achieve perfection.

Innovation: Good Enough

The other half of IS is about building new things and getting them in front of people.  In this world, creativity, innovation, and experimentation carry the day. Perfection is often the enemy.

An IS staff drilled in operational perfection will struggle when they try to switch gears and innovate.  Schedules slip and projects collapse as teams work to make every new tool perfect.  Users get frustrated as they wait for solutions.  Instead of delivering something that is good enough, we waste too much time trying to achieve perfection.

In fact, many users are happy to get something that is good enough.  Usually, a “good enough” new tool is such a big improvement over the old process or tool that users are glad to get it.  If you build good relationships with users, they will come to trust that you will stick with them to constantly improve that “good enough” solution over time, delivering continuous improvements over the long term.

The other benefit to “good enough” is that it lets you see where you fell short and how you can improve things with good user input.  It is not possible to build a perfect tool on the first try.  You need to iterate, to fail, to rebuild things to make them better and closer to perfect.  You cannot design perfection right from the start.

I strongly encourage my development teams to try new things, make mistakes, and learn from them.  The only bad mistake is one that you repeat.  If you learn from a mistake and move forward from it, everyone benefits in the long run.  The best systems evolve over time, incorporate all those lessons learned, and leverage those mistakes to improve in unforeseen ways.

What Now?

As IS Leaders, we need to enforce both of these disciplines in our teams.  We must deliver operational perfection and innovative solutions.  We have to help our teams see the difference, give them the tools to achieve perfection where it is needed, and the latitude to fail and recover where that make sense.  Achieve both sides of this balance, and your users will truly be well-served.

Who Is Being Served? January 23, 2008

Posted by Chuck Musciano in Leadership.
Tags:
add a comment

A recent issue of CIO magazine included a piece by Kumud Kalia that encourages CIOs to redefine the meaning of “customer” to be their company’s actual external customers. I couldn’t disagree more.

Your customer is the individual or entity to whom you are providing service. Nothing more, nothing less. For years, we’ve been working hard to get (traditionally insular) IT organizations to recognize their customers, build those relationships, and provide good service. In this model, the customers are those employees that use IT services to design things, build things, sell things, and service things, meeting the needs of external customers.

Kalia contends that this is wrong, and that IT should instead focus directly on those external customers. By skipping past all those other employees that really do focus on the external customers, IT is somehow supposed to be a direct contributor the the company’s success. I’d argue that if you could really succeed with this model, you don’t need all those other people in the middle, and that IT should run the whole show.

(I notice that Kalia wears two hats: he is both CIO and EVP of Operations for Direct Energy. With all due respect, I believe he may be blurring the line between two very different jobs.)

In reality, “those other people in the middle” bring huge value to the company. They spend their time really focusing on and understanding the external customer needs. The figure out what the external customer wants, and they translate that into internal business requirements to meet those needs. IT, in turn, provides tools, processes, and systems that meet those internal business requirements as cheaply and effectively as possible.

I’m not saying that IT should never interact with real external customers. In some cases, that can be truly enlightening in our quest to provide the very best tools and systems to our real internal customers. But I would never have IT participate in an external customer relationship without appropriate oversight from the real owner of the relationship, such as sales, marketing, or support.

In short, IT builds tools. Other use those tools to get their jobs done. The better we build and support our tools, the better those other people perform. We make the hammers; others drive the nails. Together we make houses.

More, Better, Faster January 19, 2008

Posted by Chuck Musciano in Leadership.
Tags:
add a comment

Perception is everything.  My mentor on the operations side of this business, Bill Rauscher, long ago drilled into me that the customer’s perception is my reality.  It doesn’t matter what I know to be true; what the customer thinks is true will rule the day.  My job, in delivering good customer service, is to get the customer’s perception to more closely align with my understanding of the truth.

This was driven home to me, once again, as I considered ways to decrease the time it takes to complete projects and deliver new tools and capabilities to my customers at work.  These are internal customers; we provide tools and systems that let them do their jobs and serve our external customers better.

From the project team perspective, we make constant progress on our projects.  Concepts evolve into requirements, which drive design, which fuels development, which enables testing, which leads to deployment, which lets us declare victory and move on to the next project.

Our customer’s perspective is very different.  As we work our way through the phases of a project, their perceived value is nothing, nothing, nothing, nothing, and nothing, followed by everything when we finally deploy.  They get frustrated as time goes by with nothing delivered.  If you graph the two perception curves, it looks like this:

How do we fix this?  Traditionally, we try to accelerate the project schedule, driving the time to complete the project down and pulling in the magical deployment date.  Getting things done sooner is good, but all you’ve done is shorten the “got nothing” time that is frustrating the customer.  Moreover, there is a limit to tightening the project schedule.  At some point, you’ll be making the traditional choice between time, money, quality, or your job.

I think a better approach is to find ways to release incremental value to some customers earlier in the development cycle.  You can’t everything to everyone, but you can give some things to some people.  For that subset of customers, they are getting value earlier, and their perception of your ability to deliver goes up.  The curve becomes this:

Some would argue that the small increase in early value (the area under the curve before the final deployment) is not large enough to make a difference.  I contend that any additional value is better than none, and for the users who get that early value, their perception is that they are receiving close to 100% value that much earlier.

There are a few ways you can accomplish this.  You might develop in phases and release partial functionality as it becomes available (some value goes to everyone).  You could engage a willing pilot group to use early versions of the product, giving them value and getting great feedback in the process (all the value goes to some people).  You will most likely find some variation of these extremes, opening up some value to some people as it becomes available and they are capable of accepting it.

As always, this must be done prudently.  You can’t release poor quality stuff early, and some projects do not naturally lend themselves to an incremental release. Still, if you evaluate this approach for each of your projects, you’ll find ways to get some value out there earlier, which is more than you are delivering now.