What the CIO Wants You to Know (Part I)

I'm reminded of the old commercial from American television where an actor gazes sincerely into a camera and says, "I'm not a doctor, but I play one on TV." Well, I'm not a CIO, but I report to one and therefore make it my business to listen carefully to what he says. Before I became a direct report I used to vaguely wonder what the CIO really thought...whether he cared about the particular project I was working on or even consciously realized that I, as a developer among many, existed. Now that I have a front-row seat I welcome you to listen in. In 2001 Ram Charan wrote What the CEO Wants You to Know—a book described as "taking the mystery out of business, [showing] the secrets of success used by business legends." In this mini-series of articles, I hope to vicariously offer some similar secrets relevant to technology workers. What you read here might surprise you...and how well you apply what you read could make the difference in your career... First let me add a quick disclaimer: I realize there are those among us who aren’t the least bit interested in what the CIO wants them to know. They regard the CIO alternately as hatchet-man, village idiot, sell-out and corporate puppet. In my career I have known or have worked for just about all of these...CIOs who were hired from the outside expressly to make impassionate decisions concerning mergers, relocations, and layoffs without regard to the families it would devastate. Then there were CIOs who seemed more interested in social climbing than software. While I'm not saying my current CIO never exasperates me, I can say that he holds the enviable reputation for being thought capable enough to fill the shoes of any of those reporting up to him, from the network administrator to the programmer. While our IT organization may or may not be globally representative, I will make an effort to select excerpts most widely applicable. Still, readers should consider the culture of their own organizations when judging the relevance of this commentary. "Face facts with dignity." If memory serves correctly, this blurb was on a slip of paper in a fortune cookie, but our CIO read it and practically cackled with delight at the chord it struck with him. He mentioned it even recently when his direct reports were discussing a book that we're reading as a group: Execution: The Discipline of Getting Things Done by Larry Bossidy and Ram Charan. "It frustrates me," he said (and I paraphrase), "when individuals fail to take responsibility for their projects and fail to live up to their potential, and yet seem bewildered when they are passed up for a promotion." [Disclaimer: This is not meant to imply that all failed projects are the fault of the employee assigned to them.] "Perhaps," I said, "we as employees are like anorexic girls looking in mirrors and seeing distorted reflections. Maybe we are incapable or unwilling to confront the reality of our own incompetencies. If all you know how to do is program, maybe it's just too painful to recognize that you might not be a very good programmer." The group acknowledged this may be so as we fell momentarily into a brown study of human psychology. "That's why it's so important to be 'ethically honest' with staff in performance reviews," the CIO reminded us (as managers), "so that they're aware of where they stand and they don't go ten years thinking they're doing just fine." We talked more about the difficulty of communicating relatively poor performance with staff because of individuality...one employee may read between the lines of everything you say, interpreting the slightest voice inflection as significant, while another may remain oblivious. But facing facts with dignity is not just about recognizing poor performance or weaknesses. The CIO reminded us that it's also about making a mistake and learning so significantly from it that you not only don't repeat it, you are better because of it. It's about not making excuses or blaming others or circumstances. It's about not throwing up your hands in frustration when given too many simultaneous assignments...and then missing the deadlines on all of them...it's about having the courage to say to your manager, "I can't do them all in this timeframe...which one is my priority?" It's about making conscious choices and managing expectations with clients, coworkers, and management proactively. Sometimes, as Mr. Nilges has reminded developer dot stars, "facing facts with dignity" may dictate finding another place of employment more suited to your style, ethics, or constitution, or as Mr. Read has suggested, recognizing that a certain programming language is not for you. "Facing facts with dignity" may mean confronting your demons, but it also involves recognizing your strengths and leveraging them to your advantage. There's hope in those words. While you may not be a hot-shot coder, you may be a great communicator, and there's room for both in IT.

What the CIO Wants You to Know (Part II)

Do you feel like you're two phone calls and service request away from dropping all the balls you've been juggling...and then tripping over them as you try to raise a white flag of surrender? In this installment, the CIO responds to one of the most common and troubling aspects of our jobs in the IT business... A coworker described the feeling of being overwhelmed by work with what we've come to refer to as The Frosty Analogy. [The "frosty" in question is a frozen, chocolate concoction sold by the fast food restaurant, Wendy’s. It's thicker than a milkshake and simply cannot be consumed with a straw unless you have powerful sucking-action and let it melt some first.] The analogy goes something like this: "You think you’re drinking tea from a cup with a straw…until you realize it's getting thicker, like a frosty, and no matter how hard you suck, you can't get any through the straw." Translation: The substance in the cup is work. When it comes in at a reasonable pace, it's manageable enough and can be processed with a straw. When there is too much of it, it's overwhelming and your efforts seem in vain. What did the CIO have to say? "When a straw won't work anymore, maybe it's time to look in the cup to see what's making it so thick, or to put a lid on the cup for a while. We shouldn't stew in our frustrations, but should ask "Why, why, why," and talk about it, seeking help and guidance." "Don't you think some people in the IT business are just too proud to say, 'I can't do it all'?" I asked. "Maybe they think they *should* be able to do it all, or it's expected, or they wouldn't have been asked to do it if had been impossible. They may even think that their next promotion is dependent on being able to handle everything thrown their way." "Could be," he said, "but I don't have that expectation. What I do expect is for the staff to ask for help...not wait so long that the problem exacerbates and we've frustrated our clients as well as our staff. Some of us have worked in environments where the expectation in IT was to work 50-80 hour weeks to get the job done, no matter what. You can sprint like that to get through a short crisis but you can't run long distance at that pace." Still, we often believe if we just work harder, focus more, organize, and prioritize, we can some how 'catch up'. But the CIO said this: "There will always be more work than you can do. Pace yourself." He also reminded us that there is a positive spin on having more work than you can do: (1) It means our services are in demand and that may translate into job security. (2) If we track the quantity of work we're being asked to do, we may be able to use the extra volume as justification for additional head counts. If we find ourselves working for a CIO who doesn't listen and demands sustained overtime to meet the high workload, we may discover he's sending us a valuable message after all: look for another job. But first we should make sure that we've communicated with management and aren't nurturing an imagined, self-imposed standard.

What the CIO Wants You to Know (Part III)

"It's not my job to make you happy..." The CIO's words reverberated off the back wall, bouncing back onto stunned employees assembled for an MIS departmental meeting. I waited, thinking he might be using the statement as some sort of rhetorical device to get our attention. I pondered, "What about a happy employee is a productive employee?" While staff were still reeling from that unexpected blow, he followed it up with another: "It's not my fault if you always wanted to be a poet but needed to make a living and settled for working in an MIS department." Wow, I thought, he sees into my soul. No, I didn't exactly want to be a poet. (I did go through a period in high school when I wrote some very bad, dark poetry, conjuring the spirit of Edgar Allen Poe reincarnated as a southern, teenage girl. Even I could recognize I shouldn't pin all my life's aspirations on that.) Yet, I suppose I'd somehow imagined a Technicolor career and saw it unfolding in the various shades of safe, nondescript gray forms that a Microsoft shop is proud to propagate. Just the other day I heard one developer pine for a career as a nurse and another say she'd considered being a dental hygenist. But now that I was a manager, I had some notion of what he meant. It's bad enough to wrestle with your own doubts and discouragement. It's quite another matter when someone else plops theirs like a pile of steaming doo on your lap and expects you to do something about it. What do you do when an employee tells you he doesn't enjoy project management or interacting with coworkers...that he really likes solitary coding...but he'd been promoted several years back out of a straight coding position (and didn't want to accept the pay-cut that would be inevitable if you shuffled him back into his old position)? What do you do when an employee says, "I thought we could choose our own projects"? (Um, yes, we do encourage you to express your interests and we make an effort to accommodate, but sometimes certain (unpopular) work has to be done.) What do you do when someone says their passion is X [insert any sort of specialized work here] but even after being sent to multiple training classes, they exhibit no ability in that area? Some days, even as a manager over technology staff, you get an ear-full of complaints and requests: "Why can't we all have 21-inch, flat-screen, dual monitors? Why can't we get an automatic pay increase if we earn a certification? Can't you do anything about climate control? Can't you do anything about that annoying background hum? Why can't I have an office with a window? I have an office with a window and there is too much glare on my monitor." I can only imagine how many the CIO must hear, considering the multiplicative factor. The complaints are often legitimate. Should someone have to work while wearing an overcoat because they have the misfortune of working in an old building and no one seems capable of correcting the heating and air problem? Maybe some staff really do need dual monitors due to the nature of the work they’re doing. But by the end of that staff meeting, the CIO elaborated on his initial shock-statement further, and this is what he wanted us to know: "Don't bring me your problem: bring me your solution." "Don't expect your job to meet all your personal needs. You might be happier if you pursued some of your outside interests as hobbies." "Realize that outside factors (such as family problems) can sometimes affect how you feel in general, and you may be blaming it all on your job." "Don't act as if you have no choice—that you're being forced to do a job you hate. If you are truly unhappy with your job, realize you have the option to leave." The words might seem harsh. It should be noted that the CIO in question does take great pains to provide a climate where staff can enjoy their work by offering training opportunities, staying current with development tools and hardware, sending staff to professional conferences, offering flex schedules, hosting team events, etc. Yet, the fact remains that a job may not be what an employee expected, or perhaps the employee has aspirations in an area where no opportunity is immediately available. The CIO's words were a reminder that ultimately we need to take ownership of our own fulfillment.

What the CIO Wants You to Know (Part IV)

"Why? Why? Why?" The CIO gestured expressively like a conductor urging his orchestra to step up the tempo. Accelerando! Allegro! "You should always ask 'Why'!" "But," he added (descrescendo), "learn when to stop asking."

Nothing drives me crazier than to ask a developer a simple question about why the client does this or that function in the system he is developing and have him give me a vacuous look and mutter, "I don't know." That pierces the heart of software development's essence: seeking first to understand. How can you write a program for a process you can't express in words or scrawl in pictures on a napkin, for that matter?

While the industry has warmly embraced agile methodologies as a welcome alternative to exhaustive, inflexible, up-front requirements processes, we have to be careful not to use Agile as an excuse for…dare I say…ignorance. Blissful ignorance. Or laziness. Oh...I'll find out about that later...when I get further into it.

At the heart of the needs assessment is the question: Why?

Why do you need this system? Why do you do things the way that you do? We all know the story about the lady who cut off both ends of a ham before she cooked it because her mother and grandmother had always done it that way…only to learn that the practice had begun due to the limiting size of the ancestor's roasting pan. Yet, in IT, where we are supposed to know better, we often find ourselves blindly following practices and doing what we're told (following orders to build System X) without asking the three letter question that would reveal so much.

In our own MIS department we had a notorious track record for fulfilling the letter of a service request (we gave the client exactly what he asked for) instead of the spirit of the request. The assignee might have suspected there was more to the request and it didn't exactly make sense, but the prevailing sentiment was: the requestor should know what he's doing and I'm too busy or don't care enough to delve deeper.

Why not ask Why?

Edward Nilges has touched on one reason numerous times here at d.*: the perception (or sometimes the reality) that the working drones are not expected (or even empowered) to use the word. But sometimes it's a self-imposed limitation. Perhaps therein lies the rub. As young children we're considered precocious when we ask why stars twinkle or why the sky is blue. But when logical answers aren't forthcoming from less scientifically inclined parents, perhaps the sense of wonder is dulled. Or perhaps we get a little older (morphing into obnoxious teenagers) and are reprimanded for questioning our elders and lectured on the merits of respecting authority. Before you know it, you're swinging on the bottom rung of an org chart robotically chanting, "Would you like fries with that?" Not, "why would you consider shortening your lifespan with artery-clogging dead flesh?" Okay...the example leaves something to be desired (such as sustained employment). But perhaps it would be acceptable for a nutrition-conscious employee in that situation to ask his supervisor why he might not offer a plug for the side-salad instead.

How do you ask Why?

The innocent-looking, one-word question can be interpreted as:

(1) "You're an idiot, I'm your intellectual superior, and I could tell you ten reasons why your way of doing things stinks and we both know I will eventually have your job if I don't quit this lousy organization first."

(2) "I can better provide a hassle-free, turn-key solution for you if I more fully understand your goal."

How the question is received of course is influenced by the tone of voice and even the choice of words. "Why?" isn't really a great way to ask "Why?" because it can come across as curt and demanding.

The CIO 'Why?'

CIOs do not appreciate being placed in the position of explaining or justifying their decisions. If you ask a question with judgmental implications, such as "Why did you buy into the Microsoft monopoly for this organization?" you may not receive the positive results you hoped for. Instead, if you ask, "Would you be interested in me doing some research and providing a brief benefit assessment of Open Source tools contrasted with the Microsoft development platform?" your CIO or manager might actually consider your proposal. You are still more-or-less asking the burning question, but in a more productive way.

Everyone you interact with wants you to answer the same question: Why?

Why should I marry you?

Why should I buy your house?

Why should I hire you as a contractor to develop this application for me?

Why will this development tool be useful for our team?

To give an IT-related example, in a recent document management/imaging project, the internal client was drowning in paper and clearly needed the technology more than any other department. It was blooming obvious...but we quickly learned it was only obvious to IT. The client kept hedging, expressing such doubts as, "I can't see how we could use this." Theoretically, the client admitted, it made sense, but she just couldn't grasp how they could adapt their processes.

The perceptive project manager stepped back and scheduled time to shadow the workers, observing the interaction between staff and their external clients, carefully watching the flow of paper. She documented the existing workflow with simple pictures and connecting lines. Then she made a second version of the same diagram with proposed changes, substituting scanning for copying and sometimes rerouting processes that had nothing to do with systems, just because it made sense and would improve efficiency. Of course the workflow required some revisions, but the client response was astonishingly different. Even though the client never quite articulated the question, "Why?" –seemingly more focused on "how"—it was at the heart of her resistance. She was likely thinking, "We've done it this way for the 25 years I've been here, why change now?" She probably thought dismissively, "IT doesn't really understand what we do." By investing the time to fully understand the process and answer the unarticulated question, IT earned respect and credibility, selling the solution.

When to Stop Asking 'Why?'

The CIO cautioned, "Learn when to stop asking." Case in point: You're in a meeting with your manager and several peers. An issue is raised and an active debate ensues. You make your excellent points. You're right and you know it (or at least feel strongly about it). The manager makes a decision and it didn't go your way. My CIO likes to add the important qualification that "if it's not immoral or unethical" then the time has come to stop asking 'Why'. You did the right thing to ask 'Why' to begin with, but you have to recognize you won't always get your way. Some might consider that settling or even selling out, but another word for it is maturity. However, if you find yourself in a position where you're constantly having to choke back the "Why's," it's probably a sign that your employment is not aligned with your value system and the question then becomes, "Why don't I look for another job?"

Editors note: this article was originally published on May 3, but I missed it in the queue and failed to promote it to the front page. Hence, to ensure everone sees it, I updated the publication date to May 23. --DR

What the CIO Wants You to Know (Part V): Reporting from the del Coronado

What do Marilyn Monroe, eleven U.S presidents, Charles Lindbergh, the Prince of Wales, and a humble DeveloperDotStar blogger have in common? They were all guests at the famous Hotel Del Coronado, built in 1888, located near San Diego. However, only the latter can claim to have visited during a CIO 100 Symposium. Shoulder-to-shoulder with the tasseled loafer set, how could I not be inspired to post another installment in this series? I might add that my attendance at a conference targeted to the technology elite was not happenstance. After sharing CIO perspectives here for almost a year, based primarily on daily interaction with one CIO in particular, I was pleased to be attending the conference to witness his acceptance of a CIO 100 award on behalf of our organization. Our organization was a speck among giants and it was all I could do not to be intimidated, especially since everything about the venue contributed to the aura of grandeur. L. Frank Baum (Wizard of Oz author) penned some of his books at The Del (as those-in-the-know fondly refer to the hotel) and designed the chandeliers in the Crown Room. The room is aptly named, as each chandelier is an illumination fit for a king (or CIO). The edifice itself conjured thoughts of a murder mystery, with an endless maze of hallways, massive staircase, proliferation of gleaming wood, and quaint elevators that enclose guests in a cage and justify numerous headcount to sustain operation. The CIO 100 awards night was a black-tie event that felt like Technology Oscars. Fortunately since there were 100 awards to be presented, recipients weren’t allowed to give a monologue of thanks. The company name was announced, followed by polite clapping. Occasionally rowdy clapping, if the organization brought along a table-full of employees. Heralding from the south and meeting most of the criteria for being called educated red necks, we made as much noise as three people can in polite company, with a little help from stranger-CIOs at our table who were rendered somewhat more enthusiastic by the free-flowing beverages. Speaking of stranger-CIOs, I went expecting a stiffer and less friendly set. Yes, occasionally I encountered the CIO, who upon learning you were an award recipient would ask rather bluntly, "What did you do to deserve the award?" followed by "What's special about that?" after hearing your elevator pitch. That was generally the exception. More often the CIOs were eager to share their own stories – like the fellow who was the top-tech for an au pair company, and another for a health supplement outfit that bore the name of NSA – a sure conversation starter. I couldn't help wondering why conferences are held at such beautiful resort locations. I suppose to get you there. So they get you there, and then you have no time to take a dip in the Olympic-sized pool or dredge your toes in the cool waters of the Pacific or gold-specked sand…unless you blow off some of the sessions. I missed precious few sessions, feeling it my moral obligation to attend and absorb. I will draw the substance of this post from the first morning's keynote, as I considered it the highlight of the first day. Bill Walsh, Professional Football Hall of Fame Coach, walked onto the stage while speakers blasted strains of Queen’s We are the Champions. His topic was "Embracing Innovation to Sustain Success." Skill Matters One might wonder to what degree professional football relates to the job of a CIO, but software developers might assume the link to be even more tenuous. I was astonished by the relevance of the speaker's advice. For example, the man responsible for leading the San Francisco Forty-Niners from Sport's Illustrated's list of worst to best sports franchises in a span of 5 years said this: "If you have skill, people can use you. If you don't and you fake it, you will be found out." "At one time if you knew the right buzz words, had an attractive spouse and attended the right dinner parties, you would get promotions. We've matured as a society and now people like this hit a brick wall by age 40." "If an employee is motivated to improve their own skill and expertise, they’re a good employee." Walsh described an elaborate effort to boost ticket sales shortly after he was hired for the Forty-Niners. A public fun-day was planned, including every kind of free food imaginable, donkey rides, games – every conceivable attraction to lure families to the site. Red bows were attached to the seats already sold and staff were on hand to help customers hand-pick their own seats. At the end of an exhausting day, Walsh looked for his marketing guy to get the final tally, only to learn that they sold a whopping 5 seats. Walsh bought 5 more himself just so he could report that they sold "in the double-digits." The moral of that story? It doesn't matter how you package it (or yourself): if you don't have a good product, people won't buy. Improve While You're Losing Walsh, who led his team to win five Super Bowls in 11 years, described a pivotal moment in his career when he broke down and cried quietly on the bus after a game. He felt he was instructing the team wisely and they were doing all the right things, but they continued to lose. He decided to finish out the year before resigning. Shortly after the lowest moment of his career, the wins started coming in, one after another. He explained simply: "We were improving while we lost." That's a hard one to process. In a society that expects instant gratification, sometimes it's hard to tell that you're on the upswing of the curve; that you're getting better, even when improvement feels like failure. Suppress the Ego Walsh's proudest achievement is that his leadership ultimately produced 14 men who later became head coaches in the NFL. He said, "If you're a CIO, you have to suppress your own ego to listen to the people who work for you or with you..." But this series is What the CIO Wants You to Know. Walsh's next statement was for us, the working stiffs who report to the CIO: "...And they have to suppress their ego when we don’t implement every idea they have." It Takes all Kinds Relating to the theme of innovation, Walsh admitted, "Whatever innovative ideas I had, I was probably over the edge most of the time and had to be reigned back in. I was thought of as the crazy professor a lot of the time. And likewise sometimes I had to respond to people on my staff with, 'That's a good idea, but there's a federal law against that.' If you have 10 employees, one or two will be creative but one or two might be institutional." It's good to have both employees who can envision the bright, crazy ideas, but also those who can provide a dose of reality when it's needed." Have a Contingency Plan, or Two, or Three "Pre-plan with contingencies for every situation you can think of…and openly discuss the plans. It's critical." The temperature was well below freezing and the opposing team’s fans were screaming expletives through megaphones pointed in the general direction of Walsh’s face. His mind was a blur with the cacophony. He couldn't think of any plays…all he could think about getting out of the cold. What saved him (and helped the team win the game) was having a contingency plan that he’d carefully developed before the game. This vivid image of work stress was not unlike the feeling in the pit of a technology worker’s stomach when facing a hard system failure: bad memory, suspect database, fried motherboard. Whether contingency planning involves football strategy or how to sustain business continuity during a disaster or what to do if a critical system isn't delivered on schedule, the formula is the same: preparation. Beware of Success Is failure your biggest fear? Consider the alternative. "We lost nine players out of 45 because they couldn’t handle euphoric success," Walsh said. "People can self-destruct when they’re ultimately successful." So what is the remedy? To fail? "The more success we had, the firmer a leader I was and the more I expected from them," said Walsh. Focus is critical, and never more so than following success. Lead Authentically "The players followed me because I knew what the h&*% I was doing. Leadership comes from being an expert in your field." Independently develop every employee so they feel like they can be the best there is, at what they're assigned. And change their assignments eventually. "You cannot influence people's minds – develop an attitude/atmosphere by giving one talk, or sending one memo. Today's leader must continually influence." Play Intensely "Don't be awed by the competition – by the stadium you're playing in or the team's reputation. Worse than that is having contempt for the competition. Play with the same intensity regardless of the score." These are Bill Walsh's words (more or less, considering the error-factor of a note-scribbler). Personally I am a huge admirer of software developers, CIOs, or housekeeping staff who "play intensely," at whatever task is at hand – not adjusting the effort expended to the importance of the client or how they're feeling that day. It's a tall order when you have more work than you can ever do. But if you're going to accept the responsibility of going out on the field, then play (code, manage, clean, work) intensely. Next Up I would love to report next on other highlights from the CIO 100, including a presentation from the CIO of Circuit City who encouraged the audience to "celebrate failures," and a rocket scientist (chief engineer, planetary flight systems for the Jet Propulsion Laboratory) who made the audience feel collectively dim-witted by contrast.