Perfect? Or Good Enough? January 26, 2008
Posted by Chuck Musciano in Leadership.Tags: Best Of 2008, Innovation, Operations
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.
In The Beginning… January 24, 2008
Posted by Chuck Musciano in Random Musings, Technology.Tags: Computing, History
add a comment
For me, my computing career started in the fall of 1975. Up to that point, my natural affinity for math and science seemed to be leading to the glamorous world of nuclear physics. Who wouldn’t want to spend their days building bombs and reactors? It was hard to imagine anything more exotic or enticing.
Then I saw it. Tucked in the corner of my high school’s mezzanine was the coolest device I had ever laid eyes on: an ASR33 teletype. Noisy, oily, built like a tank, it was attached to an acoustical modem that, in turn, dialed out to nearby Princeton University. Our high school had an account on the University system that could be used to run BASIC programs. My math teacher, Mrs. Horvath, taught simple computer programming to some of her higher classes. She invited me to try it, and from the moment my fingers touched the keyboard, my life was changed.
My first program allowed you to type in three numbers, after which it would print out the largest of the three. The whole idea of programming, of figuring out sequences of instructions to accomplish some larger goal, was absolutely fascinating. Although I wasn’t in a class that was actually learning to program, Mrs. Horvath let me use the system after school. I’d spend hours writing programs for everything I could think of.
The ASR33 was wonderful. It printed in uppercase only, on rolls of yellow teletype paper. The print carriage used a cylindrical type head that pounded out the characters, and a piston and cup arrangement caught the printhead as it slammed to left on each carriage return. You could lose a finger if you stuck your hand inside at the wrong moment. When you sat down at that terminal, you knew you were using a computer!
The ASR33 had a paper tape punch/reader, which let you punch your programs to tape without dialing in, saving connect charges. After punching your tape, you’d dial in, feed the tape back in, and quickly enter and save your program. Thus the acronym ASR: the paper tape allowed for Automatic Send Receive. (The lesser model, the KSR, allowed only real-time Keyboard Send Receive).
I can still recall the smell of the ASR33, and the separate, slightly oily smell of the paper tape. The big round keys would travel at least a quarter-inch when you pressed them, and touchtyping was pretty much out of the question. Beyond the chunka-chunka-chunk sound of printing, the only other noise it made was a real bell that would chime. None of this mattered: it was a real computer, and it ran real programs.
I wrote all sorts of programs, from maze generators to a Battleship game to graphing tools and even a program that drew hydrocarbon molecules after you gave it the chemical formula (I’d like to see today’s web hotshots do that on a teletype!). I built a database that tracked our wrestling team’s statistics and another program that generated random music. You couldn’t play the music on the ASR33, of course, but it did print out the complete score so that you could then play it on a piano.
The system also handled FORTRAN and PL/I programs, and I dabbled a bit in those languages as well. Is there anyone left who can still recall typing “PROC OPTIONS(MAIN)” to start out their program?
I have written millions of lines of code since then, for more systems than I can count, but the joy of using that first system still resonates in my soul. I knew then that I’d be playing with computers for the rest of my life. I wonder if those who are just starting in our industry today have similar memories of their first machines. In some ways, the best part of that ASR33 was that it was so primitive; getting it to do anything was a major accomplishment. It’s so easy to do cool things with systems today; is the experience less fun and inspiring as a result?
Who Is Being Served? January 23, 2008
Posted by Chuck Musciano in Leadership.Tags: Customer Service
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: Project Management
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.
BASIC Leadership January 14, 2008
Posted by Chuck Musciano in Leadership.Tags: Best Of 2008, Computing, Leadership
add a comment
One of goals when I started this blog was to capture my thoughts on leadership, motivation, and coaching, which are crucial to my day job. I also wanted to capture my various random thoughts, some of which surround my endless fascination with old computers.
As these themes have been simmering in the back of my mind, I suddenly recalled an event from my high school years that serves both.
I first touched a computer in 1975, when I was a student at West Windsor Plainsboro High School. We punched in BASIC programs and watched the results chunk-chunk-chunk out on rolls of yellow paper. It was the coolest thing I had ever seen, and I was hooked for the rest of my life.
I was so enamored of computer programming that my math teacher, Mrs. Horvath, let me teach BASIC programming to the rest of the class. I took on this task with a vengeance, particularly on the grading of tests and programming assignments, where I ruled with an iron fist. I thought things were going along really well, until two of my “students” (Jeanne Haws and Carol Ryan) shared this sample program with me:
10 READ 20, N$ 20 DATA "CHUCK MUSCIANO" 30 END RUN LINE 20: OUT OF FRIENDS
Ouch! Clearly there was more to this teaching stuff than I had first thought.
I’ve since learned that teaching and coaching is an art. One of the most important aspects of leadership, it also one of the most satisfying. I long ago left the predictable world of programming computers for the unpredictable world of managing and leading people. There are few things more innately satisfying than helping someone learn, seeing them absorb something new, and watching them apply it to their world.
Leaders must have a vision, a plan, a goal in mind. Their ability to explain that vision, convey it to others, and get them to absorb and embrace it is key to their success. Their is a vast difference between those who manage and those who lead. That gap is readily defined by a leader’s vision and his or her ability to communicate that vision.
The Effective CIO 