Slashdot Mirror
9 Reasons Why Developers Think the CIO Is Clueless
Esther Schindler writes "Finally, a Forrester analyst who understands the attitudes of software developers. Mike Gualtieri identifies nine behaviors managers need to steer clear of or risk being labeled 'clueless' — from control freak tendencies to being a vendor puppet. My favorite, however, is point #8: 'the CIO collaborates to death,' in which Gualtieri opines, 'And, if you never watched Star Trek then you shouldn't even be a CIO.'"
What's a CIO? The article doesn't even say.
If you are called a 'CIO' then you are pretty much guaranteed to be an idiot. WTF is an 'Information Officer' anyway, and how can you be the chief one if there are no others? What is wrong with being head of the IT department? It doesn't sound as swanky, which is surely a good thing, reminding you that IT is there to serve the rest of the business.
-- Ed Avis ed@membled.com
Oh yes, because all us engineers are all the same with our funny little ways and you really must get to know us as we all are.
The only thing Gualtieri needs is to never manage software developers, unless he wants a homogenised band of slaves who are easy to tame by sounding "with the gang" but who won't provide an ounce of innovation because they're all already reading from the same hymn sheet.
Also, point 4 in the article is going to be interpreted by any CIOs who do care as "be sure to stay current with all the hot buzzwords". Developers will see through most attempts at this instantly.
The problem is, in many companies, the role of the CIO is pretty nebulous.
It gets further confusing when you have both a CIO and a CTO. When you don't, the CIO has to fill both roles, which are often at odds.
The way I see it...
The CTO is responsible for understanding, predicting, and planning technology.
The CIO is responsible for ensuring that the technology in use by and acquired for the company is in the best interests of the company (and its shareholders, if applicable).
CIOs are typically from a financial background, as at the end of the day their primary responsibility is to the business units that fund the technology. It isn't about the latest, flashiest, or even best gadgets - it's about meeting the needs of the business units while spending the least amount of money to do so. Unfortunately, this often leaves us (the geeks) on the short end of the stick. And perhaps worse, with the financial focus of the average CIO, they often fail to understand where a reasonable investment in technology can save them money over time. Since the typical CIO is only in their position for a few years, they don't have a lot of time for investments to pay off. Cut costs today, and let the next guy fix the mess they've made.
-- "Other than that, how was the play Mrs. Lincoln?"
to visit a webiste like CIO and not realise its just a sophisticated domain squatters site
90% adverts 10% content
Maybe I'm just old hat, but I thought the role of a CTO was to deal with the.. uh.. technology. As in, for companies that actually develop technology. And the CIO does the IT.
As I recall, "CIO" was popularized by the dot-com companies, and immediately thereafter, since they needed as many C**s on staff as possible to get their VC funding, decided that a CTO was needed too, even though their business was selling pimento loaves on the e-web. So then it became just a great big alphabet soup with everyone squabbling over what their all important title should be. (Yes, I have worked in such an environment more than once).
I think the most obvious mark of a doomed startup is when people get completely hung up on establishing the org chart before the company has even made a dime in revenue. I realize it's basic human (/animal) nature to have to get the pecking order establish first and foremost. However when the title itself is the result of such as clueless and counterproductive process - and indeed, a throwback to such a clueless era as the dot com days, it's hard to see how you could expect your underlings could bestow any credibility on it.
I realize I may have offend any CIOs in the audience, but that's not the intent. My point is not personal - what I'm saying is just that if you're good at your job and still getting no respect, perhaps a less "tainted" title is in order.
The only reason there's "a lot of truth" to the article is that it makes points such as "clueless managers will be seen as clueless". A few comments about buzzwords aside, it's such completely generic pablum that anyone with a general prejudice against senior management of any kind, let alone CIOs, can happily confirm their own biases.
The most interesting aspect of the article is the presumption that the CIO must have the technical respect of the application developers. This is in fact not necessary. It does however suggest that the author (and yourself, perhaps) are letting their egos judge these CIOs on criteria that is important to *him*, rather than to *them* or their job role.
And that, for me, sums up the entire discussion.
Slashbots hate the CIO because they all think that they are the greatest 1337est coder to have ever walked the earth. The CIO wouldn't even try to freestyle sed, because they've been around the block a few times and know it's dangerous.
My thought for the day: Your staff is there to educate you. You will be too busy to keep up, and to do all your own filtering and analysis. Make sure they know it is their job to keep you up to date on things that matter.
My favorite meeting moment: Boss steps into my cube for 1-on-1 meeting. I fire up a demo of a new technology I think he should see. Boss: "I just got out of a 1-on-1 with the general manager! He asked me what I knew about this and if I had started a project on it! I had to tell him I had never heard of it. Why didn't you show me sooner?" Me: "You're the one that rescheduled our 1-on-1 3 times this week."
The great thing about having a staff is the astronomical amount of information you can learn from them. Their job is to find and filter it. Your job is to make decisions with it.
Sounds like the CIO wasn't doing his job and implementing documentation policies to make sure there were no esoteric mission-critical functions that could only be handled by one individual on the planet.
Hey dipshit, I guess you're too dense to understand the statement. You must be a CIO.
So, I'll explain it.
1) It's generally believed that most people in the IT profession are fans of Star Trek or some other sort of Science Fiction.
2) If you are in a position of managing IT and the people running your IT systems, you should have a certain level of technical knowledge and background.
3) If you don't, or have never watched Star Trek, you probably aren't into tech
4) If you're not into technology, you shouldn't be a Chief INFORMATION Officer
It has nothing to do with basing decisions on a TV show.
Woah. I underestimated how draining it is to feed trolls like you.
- It's not the Macs I hate. It's Digg users. -
No. Thunderdome is the correct response. Seriously. Wii-boxing. Geek game showdown. No physical contact, and an enjoyable way for everyone else to ease the tension that conflict can bring. Don't tell them about it... just keep a console around and when the opportunity is right, take each of them under an arm and lead them off. If you do it right and pull it off, it's one of those "... hey, did you hear about so and so... he freakin' made them Wii Box!" stories that will precede you where ever you go.
;) If they call your bluff, let the geeks eat 'em alive with technical questions like, "so, is your LDAP backend X500 DIT compliant? We need it to work with our hacked together NIS/perl-fu directory. Here, we can show you the code!"
You won't even have to break the ice the first time you meet a client. It sounds nuts, but sane solutions don't solve problems and get great results. They become political and accounting decisions if left rational for too long. As for the vendors, make them fear you by telling them to have free hardware dropped off to your tech guys to play with before you even consider making a purchasing decision. After all, if this wacky device is nearly as great as they say, the geeks'll love it! Also, Cisco and Sun were kind enough to give you a full rack to play with for a few months.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Actually, no offense, but I found that companion article to be far worse advice. Unless it was meant to be just funny mis-advice, and the joke went right over my head.
E.g., trusting developers and not managing them too much... Well, there's more than one kind of person. In fact, there's a whole continuum of them. At one end, there _are_ indeed people who are perfectly capable of managing themselves and who can be given the big picture and left to their own devices to finish that big chunk. At the other end, there are people who really need to be coaxed to do anything whatsoever.
As an example of the latter extreme, my ex-coleague Wally once asked for some weeks to estimate the effort to fix a trivial bug. You read it right: not time to actually fix it, but that much time to estimate how much time he'd need to fix it. He actually got it, btw. Sometimes just trusting every developer is a bad idea.
Almost all of us think we're at the former end of the spectrum, so, yes, if you ask us, every single one will say he's perfectly capable of managing himself and needs no stinking manager checking on his progress. Reality is often a whole other thing.
The right thing to do, and at that the _hard_ thing, is recognizing the right amount of management each one needs. (And if you're willing to dedicate more effort on your part to coax someone, than it would be to fire him and write the damn module yourself, I guess.) Applying the wrong amount in either direction can get bad results fast.
But at the very least, the best advice I've ever read on the topic, is, "beware the guy in the room." You know, the idea that we have this super-programmer in his own little (metaphorical) room, we're leaving him to his own devices, noone knows what he's doing, but we're confident that at the exact deadline he'll come out screaming "Eureka!" and they all lived happily ever after. Even for the guys who are capable of managing themselves and usually deliver results, do have some indication of progress being made and do track it. That way at least you'll know if he hit some hurdle right before the deadline and is too proud to ask for help.
The thing about needing to be shielded from the rest of the company... well, we would indeed very much like to be left alone with the computer and to ignore the rest of the humanity, not just the rest of the company. Whether that's also good for business, that's a whole other issue. Being isolated in your own ivory tower can lead to some very bad design decisions, based on what you _think_ the outside world needs. Plus, it's good for the morale to know at least that someone else in the company is using our programs, and we're not just moving a pile of sand from here to there, for no other purpose than to stay busy.
So basically do filter out the unneeded crap and politics, but make sure not to filter out stuff that is actually needed for those guys to understand what they're doing and why.
And finally, ok, I know that an analogy isn't supposed to be 100% equivalent to the thing it represents. But the analogy with the cat, much as I do like cats, is IMHO rather mis-leading. You don't expect the cat to do anything whatsoever, except keep you company and not damage your furniture. That's it. You just want it to like you, basically. If you need employees which just like you and don't do outright damage, yeah, take the cat analogy. If you need employees which actually finish a task by a deadline, you might need a bit more effort.
A polar bear is a cartesian bear after a coordinate transform.