Nuts And Chocolate October 23, 2009
Posted by Chuck Musciano in Leadership.Tags: Best Of 2009, Chocolate, Nuts, Patience
1 comment so far
I really like chocolate. I also really like nuts. It is not surprising that I like nuts and chocolate together, at least in the form of a Mr. Goodbar, which blends the perfect combination of milk chocolate and peanuts into a single treat. I recently discovered, however, that I do not like dark chocolate and nuts together. In fact, they are in such conflict that taken together, they actually ruin each other.
As all aficionados know, dark chocolate is best when savored slowly, melting on your tongue. You do not chew dark chocolate; you let it dissolve in your mouth and release all its flavors over time. Nuts are a different story. They don’t melt; you have to crunch them up to release their flavor.
Mixing these two in one mouthful is a disaster. If you chew, you enjoy the nuts and turn the dark chocolate into tasteless, crumbly wax. If you let the chocolate melt, you are left with a mouthful of soggy wooden nut bits, which is no fun.
Every day, our leadership roles present us with nuts and chocolate in the form of various challenges. Some require fast, decisive action: we must chew them up and move on. Others require a more methodical approach, taking time to melt before they can be fully understood and solved.
Unfortunately, we tend to confront more nuts than chocolate in our day-to-day jobs. This conditions us to want to handle things quickly, to react and decide, to figure it out and move on. Every problem seems urgent, every concern is pressing. As we chew up the nuts, we inadvertently chew up some chocolate, creating bigger problems.
Some problems require time. In some cases, you can use that time to reflect and consider alternatives, to really seek the right response to an important issue. In other cases, some problems solve themselves if you just let them. This is especially true of interpersonal squabbles; letting people figure things out on their own is preferable to injecting yourself and trying to referee a no-win situation.
The trick, of course, is to separate the nuts from the chocolate. Waiting for nuts to melt isn’t helping anyone; you need to dive in and chew them up quickly. I’m afraid there is no simple answer to this problem. Experience is the best teacher, and comes with the requisite scars and lessons learned.
In the meantime, as you build that experience, take a moment to think about the issues that present themselves. Think through the implications of waiting versus diving in. You may find that some issues are better solved later, freeing you up to deal with the urgent ones more effectively. And while you are deciding, have a piece of chocolate. Or some nuts. But not both at the same time.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio121″ only_single=false]
Field Of Rakes October 9, 2009
Posted by Chuck Musciano in Leadership.Tags: Best Of 2009, Management Skills, Mistakes, Users
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]
What Can You Capture? September 25, 2009
Posted by Chuck Musciano in Random Musings.Tags: Best Of 2009, Information, Knowledge
17 comments
There is a lot of discussion these days on the topic of “knowledge capture.” Recognizing that there is a lot of intellectual capital locked in the heads of employees, companies seek tools that will make it easier to find, categorize, and ultimately share this information. This is particularly important in industries where an aging workforce is retiring and taking a lifetime of knowledge with them.
As wonderful as it sounds, I don’t think knowledge capture is possible. Certainly not in the sense that it can be published and managed like a vast database, to be perused by those not yet enlightened. We are trying to treat knowledge like data, and that’s just not possible.
We have no problem capturing data. Data is nothing more than facts, collected and indexed. We have data streaming at us all the time, and computers are great at grabbing and storing all that data. We also have great tools for searching all this data. Google is the pre-eminent example; given a vast database of facts regarding which web page contains certain terms, Google will quickly tell you which pages match your query.
Stepping up from data, we have information. Information is data, correlated. Thus, a collection of temperature readings across the country is simply data. Those readings, correlated to produce areas of equal temperature, become information that will expose patterns that the individual data elements cannot disclose.
We have many tools to turn data into information, loosely grouped into that class of applications known as “business intelligence.” Depending on the usefulness of the tools, the correlated information may prove valuable or useless. Google is notoriously hit-or-miss on this; searches for certain phrases can yield bizarre search results, because Google cannot extend a clean semantic model onto the queries it services. For example, this blog gets hit on a daily basis by searches on “Scarlett O’Hara” because I once wrote one post about her. I am pretty sure that those seeking Scarlett are not looking for IT management advice, yet Google keeps delivering that result.
Google keeps making that error because it lacks knowledge. Knowledge is the result of placing information into the hands of someone with relevant skills and experience. With knowledge, information becomes useful. In our temperature example, the information represented by the temperature gradients allows a trained meteorologist to figure out when it might rain. In the hands of a lay person, it is just an interesting picture.
You can argue that some knowledge can be captured; that’s why we have books. I’d agree, but define what was captured as “shallow knowledge:” the part of knowledge that is close to the information, that involves repeatable activities, easily described. I can read a book and learn calculus, but knowing how to apply the calculus to a problem is far deeper and more intuitive. That’s “deep knowledge:” the complex ideas that knowledge capture seeks to document and categorize.
Regrettably, deep knowledge is almost impossible to capture. Consider the knowledge required to drive a car. Could you write down everything you know about driving? Could you even say it all? Absolutely not. The core of driving, what makes you good at it, was learned by practice and observation, absorbing lessons that are unspoken.
So it is with all deep knowledge. Imagine trying to write down how to negotiate with a vendor: reading body language, verbal cues, etc. You can’t; you learn it by watching a skilled negotiator. Even the skilled negotiator may not be able to express what they do; they just “know.”
The ease of data capture and the improvements in deriving information imply that the next level, knowledge capture, is possible and even easy. I contend it is not; while some rote knowledge may be captured, really important knowledge is only learned over time through continuous exposure to a master, much like a traditional apprenticeship. Our fascination with tools misleads us into thinking that there is a tool for everything; I don’t know that there is a tool for true, deep knowledge capture. I think that the real answer is one I’ve promoted before: know who knows, and learn from them before they are gone.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio109″ only_single=false]
Simply Amazing September 11, 2009
Posted by Chuck Musciano in Technology.Tags: Best Of 2009, Corn Maze, Simplicity, Technology
2 comments
It is the time of year that corn mazes become popular. People will pay to wander through a maze cut into a corn field, enjoying the fall weather while they try to find their way in and out. I always naively assumed that corn mazes occurred almost as an afterthought to the process of raising corn. At some point, I supposed, a farmer rode through his fields with some sort of mower, carving out a maze. I was markedly incorrect.
Corn mazes, it turns out, are a big business. Mazes are laid out before planting begins, and the actual cutting is often controlled by GPS-directed tractors. Maze designs are marketed by various companies and can cost many thousands of dollars. In my area, farmers join maze co-ops that control where mazes are created, ensuring that each maze has a strong local market to drive revenue. Within the co-op, mazes are not located closer than 30 miles from each other to reduce competition. Non-co-op mazes pop up, of course, but they do not get the other benefits of belonging to the co-op.
Who knew? How could such a simple, all-American thing like a corn maze actually require so much complicated planning and forethought?
It turns out that almost every “simple” thing is actually quite complicated, behind the scenes. In fact, the best simple things are just a front for very complicated systems and processes. From clean running water and electricity to your iPod Touch, there are many layers of detail that you just don’t have to worry about. Thankfully, I might add.
IT is no different. There are many complicated layers to even the simplest of IT tools and systems. Ideally, those of us in IT should be masking all that from the end users, providing a simple tool that does something well. Unfortunately, we generally do a terrible job of hiding complexity from our end users. Sometimes, we think we are doing them a favor when we expose complexity in the form of “features” intended to help them. Instead, we generate more confusion and annoyance.
It is unfortunate that people know what a “404” error is or that disks must be defragmented. My mom should not have to know that software is updating itself or that the printer heads need to be aligned. People want to use computers to get something done, not to become more proficient with computers.
I have no idea, honestly, how to do anything with my car except to start and drive it. I like looking under the hood to admire the engineering therein, but heaven forbid that I would do anything under there. I am not an automotive engineer, and I don’t want to be one. I just want to drive a reliable car.
I think those of us in IT lose sight of what users really want. We forget what it is like to really be an end user. Even as we build wonderful new systems, we need to keep our users’ real goals in mind. They just want to enjoy the maze. They don’t want to know how to grow corn.
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio103″ only_single=false]
The Effective CIO 