Saturday, 02 August 2008

My title for this post sort of spins the title of the article I want to point you to, aiming for the positive side of the coin. The article, which is entitled "The Top 5 Reasons Tech Execs Fail," provides a set of bullet-pointed thoughts that can be read as a list of what tech execs need to do in order to succeed. I happen to agree with the authors' assessment.

Here's the short version of Marty Abbott and Michael Fisher's five points, slightly altered to read as a list of positive attributes of a successful tech leader:

5. Ability to Build World Class Team
4. Ability to Execute
3. Ability to Lead/Motivate/Inspire
2. Ability to Manage Operationally
1. Displays and Uses Financial Acumen

The authors point out in their article, "... when technology executives fail, it is not because they lack an individual skill. It is because they lack an an adequate balance of the many technical, operational and leadership skills necessary to make them a complete manager."

Add/Read: Comments [0]
Management | Tech
Saturday, 02 August 2008 11:12:23 (Pacific Standard Time, UTC-08:00)
#  Trackback
 Wednesday, 02 July 2008 has posted a great opinion article by Mike Gualtieri offering nine ways to make sure you're not labeled as a "clueless" CIO. I must say, the list is excellent and one that should be taken to heart by executive managers in general, and information/technical execs in particular.

Among his observations of a good CIO: "He gets opinions from his experts but there is never any question about who will make the final decision. And, if you never watched Star Trek then you shouldn't even be a CIO."

But the list contains several important and valuable points, it's not just humor. Do you know what your reports have to say about you? Does your CIO make the grade? This quick article is highly recommended.

I can especially relate to the issues associated with "drinking vendor Kool-Aid" and the need to keep a distance. In fact, my experiences with massive numbers of vendors led me to take drastic action to stop cold calls and other sales tactics, to the point even of angering those vendors. Basically, if I didn't have an established preferred relationship with a vendor, calls were relegated to a special mailbox. It gave me my time back.

Also, it is important to watch the balance between being a good geek leader and being the "uber-geeky" supervisor. If you are a professional manager, you hire the best and the brightest and make sure they can do their jobs well. If you're hiring smart, those people are much better at the tactical aspects of your organizational responsibilities than you are, anyhow.

Add/Read: Comments [0]
Management | Tech
Wednesday, 02 July 2008 09:55:13 (Pacific Standard Time, UTC-08:00)
#  Trackback
 Tuesday, 16 October 2007

Recently I have been working on writing a set of practices for taking the IT Help Desk to the next level. Well, actually it's about fixing what's broken and reworking the people, processes and technology components in order to be a great, service-oriented help desk with happy customers and happy, motivated employees. And yes, it is possible to have it all.

At any rate, I read this blog entry by Tim Heuer recently, and it illustrates well the common problem with IT support processes. Read and weep.

When you read something like that and both laugh and cringe (mostly cringe in my case), it makes you think.

ITIL, COBIT, and everything else standards-based aside, there's a whole slew of internal motivations and behaviors common to IT organizations and customers, yet not really addressed by standards, that can make or break the success of your service desk and organization. Having processes and checklists in place is great, but what makes for a really great IT organization? What makes someone a great help desk customer?

You never get perfect (on either side of the desk). But you can run a practice that is measurably successful and does more than maintain status quo (not always a good thing, by the way) and just get the job done.

What are some of your help desk stories, good or bad? What have you seen that works? For all that is decent and tactful, please don't disclose your employers, any people or specific teams here (or they'll be deleted). But some illustrations would be great. Just be nice. :)

Add/Read: Comments [3]
Management | Tech
Tuesday, 16 October 2007 15:01:07 (Pacific Standard Time, UTC-08:00)
#  Trackback
 Thursday, 26 July 2007

CIO Magazine online has a great new article detailing the top ten thing you should never write in an email, as well as some other communication tips for business-types. It's decent advice and worth a read, for sure.

Here are the top-ten items (be sure to read the original story as well for the full meal deal):

Don’t Do That! 10 E-Mail No-Nos

1. Negative comments regarding your firm's executives. Too easy for someone else to forward accidentally.

2. Performance criticism. Seems more "official" than when spoken, causing people to worry too much.

3. Bonus or salary matters. Company plans may change.

4. Racial or gender slurs. Enough said.

5. Details relating to product liabilities. Court trail, anyone?

6. Lies about your company's rivals. Another ticket to legal trouble.

7. Office dish. If people want to spread their own news, let them.

8. Sloppy writing. Your image is at stake, even if you're hacking away on a BlackBerry.

9. Sarcastic humor. Without inflection or visual cues, it's risky.

10. Private matters. Don't e-mail details on any part of your life that you wouldn’t want to see in the newspaper.

Source: Dianna Booh

Been bit before? What else do you think should you never, ever put into an email?

Add/Read: Comments [0]
Management | Random Stuff | Things that Suck
Thursday, 26 July 2007 12:25:54 (Pacific Standard Time, UTC-08:00)
#  Trackback

Analogies and parables abound on the topics of life and business. One I have told a number of times over the years is the story about the two fire chiefs. Having worked in public safety it's one I can relate to. It's a paraphrase on other tales, and I have no real idea where it came from. Someone probably told it to me at some point long ago, probably to teach me a well-deserved lesson or two.

There are two kinds of fire chiefs.

The first stands on a hill surrounded by his lieutenants, captains, firefighters and others, overlooking the town his department is responsible for. Fires are popping up everywhere, and the chief orchestrates call after call to put out each fire, emphatically choreographing each move and lecturing to everyone about exactly what's going on and why. He is in control. What the townspeople don't notice or see are the captain, lieutenants and in some cases the chief himself running down the back side of the hill and into the town, occasionally tossing their lit cigarette butts into windows of cars and homes.

The second fire chief stands on the hill, watching for fires. They rarely pop up, but when they do his captains, lieutenants and firefighters follow their safe, practiced, professional training. They quickly and efficiently move to the fire scene, take care of business and then get back to the station to continue to stand watch. No one gets hurt, and the people who work at the department are happy in their profession.

Which chief do you think gets the public's attention, the recognition and the accolades? Which one would you trust with your life on the line? Which one would you trust with your job? How do you think each of these people got to be chief?

Talk is cheap, talk can be dangerous, and talk is not always about communicating. Agendas and drama often overshadow the real heroes in our world - those that lead from behind and instill a sense of worth, value and respect in the people they represent.

And therein lies the difference: As a manager, do your workers represent you, or do you represent them? Your answer carries important philosophical meaning, and coming to an honest conclusion might be difficult. Take time for introspection and you'll be a better person for it. But most importantly be honest with yourself, regardless of the answer. Without that, there is no way you can truly be honest with others. And without honesty there is nothing - Just a bunch of burned, smelly, water soaked buildings. But hey, at least the fire's out, right?

Add/Read: Comments [1]
Management | Random Stuff
Thursday, 26 July 2007 12:12:40 (Pacific Standard Time, UTC-08:00)
#  Trackback
 Wednesday, 02 May 2007

RunAs Radio Show Number Four is now online. Richard and I speak with Simon Goldstein, who (it just so happens) works with me and is a good friend. Simon has a depth of knowledge and expertise that sets him apart in the areas of risk management, compliance and a variety of other topics. In this interview we discussed the compliance and security world and how it applies to practical IT. Simon distills a lot of broad topics down into the nuts and bolts, so pretty much anyone can understand how compliance works and why it's important:

RunAs Radio Show #4 | 5/2/2007 (44 minutes)
Simon Goldstein on Compliance

Simon Goldstein talks to Richard and Greg about making sense out of compliance with rules and regulations around Information Technology.

Links: RunAs Radio web site and RSS feed

We welcome your input and ideas - Just email and let us know what's on your mind! We  are always looking to know what you would like to hear about as we book our guests.

Add/Read: Comments [0]
IT Security | Management | RunAs Radio | Tech
Wednesday, 02 May 2007 07:00:27 (Pacific Standard Time, UTC-08:00)
#  Trackback
 Monday, 19 February 2007

My friend and co-worker, Milind Pandit, is a wicked smart guy who can teach anyone a thing or two about lots of different topics. One of his areas of professional interest and knowledge is product management. The other day Milind presented a webinar focused on product management and dealing with risk, return on investment and real-world options. True to form, he eventually breaks it all down into a nice, clean metaphorical world that anyone can understand. Milind has a way of explaining things and keeping them simple (for which I am eternally grateful, heh).

Check out this webinar by clicking here.

We present a methodology for planning and tracking a product development effort. The primary tool for the methodology is a simple, one-page spreadsheet capturing actual and predicted expenses and revenues, from which IRR or NPV can be derived. Furthermore, the spreadsheet models uncertainty of predictions. By constructing the spreadsheet for a product development effort, real options are exposed. By maintaining the spreadsheet on an ongoing basis, the exercise of real options is tracked and the likelihood of product success or failure is clarified.

The simplicity of the methodology ensures that

  • a product manager can independently stay up to date on the progress of a product development effort
  • anyone from line workers to corporate board members can easily understand the state of a product development effort
  • multiple product development efforts in various stages can be compared or aggregated into a portfolio
  • investment and divestment decisions can be made rationally and with complete information

To demonstrate this methodology, we will construct and modify a spreadsheet for a commonly-understood project: the purchase, improvement, and sale of a home.

Add/Read: Comments [0]
Management | Tech
Monday, 19 February 2007 13:14:24 (Pacific Standard Time, UTC-08:00)
#  Trackback
 Sunday, 28 January 2007

One thing I've noticed about all the weblogs out there is a significant lack of content on certain topics. Management and dealing with management issues is one example. There are a few out there that are quite good, but it's not a common topic. Probably because it's not exactly exciting, geeky or all that interesting to the average person. Or maybe because managers are afraid to talk publicly about problems they run up against. Or because not many managers blog. Personally, I run across complex issues all the time, and I enjoy talking about them in an appropriate way. I think it makes me a better manager in the long run to hear what others have to say. Hence this weblog entry.

A while back I was meeting with one of the people I work with and discussing the variety of ways communication problems can drag an organization down. It was one of those typically generalized philosophical conversations, the kind I like to think of as learning moments. Some call them teaching moments, which is also accurate, but I like to remember I can (and better) learn while mentoring, too. It's a given that inefficiencies can make it difficult to get things done in business, and inefficiencies in communication can certainly have a significant impact. As we traded thoughts back and forth on the topic, I realized that my compadre was unawaredly mixing two different problems together, and classifying them as one. We stopped for a moment, and I explained to him what I see as the difference between communication and behavior problems. There is a fundamental and critical difference, I pointed out - one that is often overlooked and misunderstood.

We've all known people who say or do things that don't contribute in a positive way to an effective team or organization. Unfortunately we often describe such people as having "communication problems," when in fact what they exhibit is instead a complex set of behavior problems.

Because the two types of issues are fundamentally different (as are the respective solutions), a well-honed ability to recognize the difference between them is an valuable and important management trait for one who has the desire to make changes in this area.

A communication problem exists when there is a process gap or other barrier that makes it impossible to successfully communicate some critical information. For example, in the IT support world, we often wonder why users don't provide us with the information we need to help them. Instead they tell us a life story and pass on a lot of information that won't help us solve the problem, all while leaving out the critical nuggets of data. Then the IT employee wonders why and spends significant time chasing users down and trying to gather the missing details needed to work the issue.

But the communication problem in this case is not the lack of information provided by the customer. Rather it's the lack of a properly-defined process. I suggested, in our hypothetical conversation, that if an IT help desk employee has to regularly perform the same tasks and if the information necessary for success is challenging to gather from users, then the solution should be in doing something to ensure the proper information is collected and that the users know what's needed and expected. That's a communication process. And a well-defined communication process does a couple things: It sets clear, unambiguous expectations and provides a known mechanism to accomplish the activity it defines. It also needs to be reasonable and usable, to be fully successful. Perhaps the IT help desk would deploy a standard form, for example, which collects all of the information required to resolve a class of issue. At that point, once the user population has been made aware of the form and process, it is reasonable to expect the users to take advantage of the tools and instructions provided.

Now, if our information communication process is in place and communicated effectively and sufficiently, yet the people to whom the process applies neglect to do their part, we no longer have a communication problem. At that point, we have graduated to a more complicated class of issue: The behavior problem.

Behavior problems are individual in nature, and are more closely related to personality and situational issues. They're not typically resolvable with processes. Instead, they require individual guidance and potentially some form of discipline. Now, the term "discipline" here does not have to be a negative word. Rather, I use it in the context of behavior and performance management. And what works for one won't always work for the rest. This is the area where the professional manager earns his or her stripes: Working with people to change default behaviors in situations where the behavior cannot work. It's hard work.

Perhaps the most useful set of terms we can keep in mind when it comes to defining the issue and a solution: Communication Management and Behavior Management. Understanding these and knowing the differences are what we really need to be concerned about. That and the fact that even with a good communication method in place, it still takes the people and personalities that can and will work within any processes established to be successful.

What kinds of behavior problems are often confused with communication issues? Well, there's the "that's not what I want" class of problems. And then there's the "I didn't think of it so I can't get behind it" philosophy. Or the "that doesn't apply to me because I decided I didn't want it to" issue. Often behavior problems involve some form or another of what I refer to as "terminal uniqueness" - People who believe that they are different and their jobs, situations, wants, needs, requirements and desires are completely different than those of anyone else, and  that therefore nobody else can possibly understand or make decisions that might affect whatever they're focused on. And there are, of course, many more.

Anyhow, I have a variety of stories from my own management experience (both as related to me personally and with others) that illustrate this point, but one person's examples only help to define the situation in a self-limiting form. Do you have examples of your own experiences where the cliche "communication problem" term has been applied, but in reality the issue was people not playing nice? How do you deal with those situations and people?

And I should finish up by pointing out that I am far from perfect in this area. None of us are. I've not been the easiest person to manage at times over the years, to be sure. But a good healthy conversation helps us all to be aware of what's happening around us and within us, and allows us to learn and grow. So, let's converse.

What do you think?

Add/Read: Comments [1]
Management | Random Stuff
Sunday, 28 January 2007 13:59:18 (Pacific Standard Time, UTC-08:00)
#  Trackback