Slashdot Mirror
Fire Your IT Boss
theodp writes "Instead of laying off techies who directly help users, Robert X. Cringely argues that the best place to cut IT organizations is at the top. One of the great problems in IT management, Cringely says, is that the big bosses typically haven't a clue what is happening, what needs to happen, and what it all should cost. He issues the following challenge: 'If you are managing an IT shop and can't write the code to render "hello world" in C, HTML, PHP, and pull "hello world" from a MySQL database using a perl script, then you are in the wrong job.' Even with help from Google, Cringely believes many technical managers would fail this test and should get the boot as a result — you can't manage what you don't understand."
Sorry Slashbots but people skills are more important than tech skills and always will be.
I would like to see you back up your implication that those two skill sets are mutually exclusive.
I know we're all colored by our personal experiences - but, based on my own, I think the problem is exactly the opposite. A lot of IT managers think they are technically savvy, because they've managed to get some sort of certification at one point or another in their lives (or maybe they were rather knowledgeable at one point, years ago, but have not kept up simply because of the other demands that come with management). These types of people are the epitome of "know just enough to be dangerous". It then gets exacerbated because they often sell themselves to the rest of the organization as "IT savvy", and feel free to make technical decisions regarding project details when they really have no business doing so.
I think we need IT managers that are MANAGERS, not IT people. Those managers should then trust us to know how to do the detail work required for our jobs.
My own manager has been learning this lesson over the last several years, and as such my work situation has steadily improved. He is still the liason with the rest of the organization, but he usually sticks to the broad strokes and lets us underlings sweat the details.
#DeleteChrome
It's true. They pretty much all fail.
I had a job where my boss told me to go redo the website using whatever technology and features I thought I needed to make it excellent. He gave me two weeks time to do the first phase of moving the old content over to the new framework and coming up with some cool new ideas.
It was fun. About six days into the project, a manager came down from another branch had an interview with my boss, sat next to me while I explained the site.
The two of them had a little meeting and called me in. "We're pulling the plug."
"What? Why?"
"You're doing it wrong."
"What are you saying?"
"You should be using Dreamweaver. Everyone uses dreamweaver and you're doing hand-coding. What language was that again? PHP or ASP?"
"PHP and MySQL."
"Dreamweaver does that automatically."
Anyway the whole conversation went like that. I was told that I had to change into their idea of what a programmer was -- and that's the big problem. Managers have no idea what a web developer or programmer should be because their idea of the job typically is distorted. They rule based on FUD.
I left the company, obviously. If you can't manage your people, you won't have any.
The dangers of knowledge trigger emotional distress in human beings.
Unfortunately, this is frequently bad as well. Being a good programmer does not make you a good manager. As much as I hate to admit it, management is a valuable skill. A good manager will base decisions on the information supplied by the the tech that report to him (or her).
Of course, many of us have ended up working for those who are neither good programmers or good managers.
Here's a different technical case: I know someone (let's call her Betty) who is an HR director. She's standing in for someone on maternity leave. The person she's standing in for (let's call her Helen) is "technically" superb, knows the nitty-gritty of HR really well. Helen is fully up to speed with every current aspect of HR. She could not only replace every member of her team, she's probably technically better than every individual member of her team.
But she's a crap manager. She micromanages everything, everything HR has been tasked with gets delivered late and in too much detail. Why? Because at director level, you don't need the micro-detail and you don't need the HR director's involvement in getting every step of every task done.
Betty hasn't done the job of HR for a decade, but she knows how to run a tight ship. After six months of having Helen out of the way, the HR staff are happier and more productive, the board is delighted with the stuff that HR is producing and Betty is doing very little indeed.
You don't get a dog and do the barking yourself, Mr Cringely.
Ciao, Obnoxio
If you can't do at least a LITTLE of the technical stuff then you better be willing and able to listen to your technical people! I'm lucky enough to have a director who spent 20+ years in the trenches, but our VP is not at all a technical person. When she asks us to do something that would be extremely difficult or impossible to implement we let her know and she listens. Her strengths are in managing people and contract negotiations, she got us Oracle Enterprise at a cost that Microsoft corporate refused to match (for SQL Server Enterprise) and her modification to contracts has saved our bacon several times.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
I prefer a non-technical manager.
A technical manager often inserts himself as a buffer between me and the users. This makes it harder for me to determine what the users really want.
He also typically starts to solve the problem before I can, while solving it using his own ideas, which are typically not the ones I am used to. (Everybody seems to write programs their own way.)
The result is that by the time an assignment comes to me, it has already been "partially digested." It is not so clear what my program is supposed to do, but I am given rigid requirements about how it is supposed to do it. In the worst cases I am simply given a big pile of code and the instruction, "Finish this."
I much prefer to work for non-technical people. I can work with them to hammer out what the program is supposed to do, and then I am free to use the ideas I know best in order to do it. This allows me to work faster and more accurately.
While it's certainly helpful to have the management know how things down below work, as the organization or project grows larger this becomes less and less practical, down to downright impossible. The CEO of Ford knows what a carburetor is, but certainly can't identify the parts of one taken apart in front of him. That doesn't make him a bad CEO.
Each step you take up the management ladder, you lose skills and you gain skills. Every very rare now and then you will run across someone that started at the bottom and is now VP or something, and has a very detailed knowledge of how things worked way down at the bottom, ten years ago. Only does him a marginal bit of good now. More often the knowledge they value is of how the people interact and who is responsible for what. This is what makes a good manager - not knowing how you do your job, but knowing how you are important to the company, where you fit in, etc.
I repair computers. My manager tries to repair computers, but isn't very good at it, and I don't expect him to be. That's not his job, and I can't do his job any better than he can do mine. HIS manager knows how to USE a computer, but certainly not how to work on one. This is how it works.
I work for the Department of Redundancy Department.
I once had a similar gig for a major newspaper. They had contracted the usual clueless newb to engineer their online presence. The app had a memory fault that crashed the server. They hired me to fix it so that it worked, and incidentally deny the original guy the pay for the contract. I found that a different method of memory allocation would eliminate the issues. Rather than telling my bosses about it, I called the original programmer and told him how to fix all three lines of code that were at fault. He revised it and it worked.
I lost my gig but I still feel good about it. Doing the right thing is not always in your immediate best interest. I'd feel bad about stealing the benefits from his work for three lousy lines of code.
The retarded newspaper editors - not so much. They haven't given up their horse-and-buggy-whip model of business. If they had kept me we would have fixed this issue by now. It's not too late to fix this but I no longer care about their welfare and they neither think I have the answer nor remember where to look for me to find their salvation. Such is the ebb and flow of business.
Help stamp out iliturcy.
The car companies certainly support your point. For quite a long time now, the CEOs of American auto makers have typically come from the sales or finance organizations. I'd like to see them go back to being run by a "car guy."
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I'd like to see them go back to being run by a "car guy."
A 'car guy' is not necessarily good at running a business.
they need to have an understanding external to us.
... or experts they can trust. Some of the most pleasant managers I've had, didn't have a clue about the technical aspects of what I do, but they did trust me when I gave them a time/cost/resources estimate. Then they either gave me what i asked for in that estimate or asked what could be accomplished within more limited parameters. My co-workers and I would do everything we could to make good on that estimate, and the manager would do everything they could to keep non-task distractions (like upper management) out of our way. Those were wonderfully enjoyable jobs because i could just go and work, with a minimuim of haggling, looking over my shoulder, or politics.
We are all just people.
This simply doesn't work with programmers.
Take a team with a couple of average programmers, one really excellent programmer, and an incompetent programmer who tries really hard all the time.
What does the manager see? He sees two average employees doing overage things. He sees the excellent programmer "goofing off" half the time, because he spends more time thinking than coding. And he sees the incompetent programmer putting in long hours and always working furiously.
What does the manager hear? He hears nothing from the excellent programmer. He hears a lot of moaning about long hours from the incompetent programmer. And he hears a lot of complaining from the average guys about how incompetent the incompetent guy is and a lot of praise for the excellent guy.
What does the manager think? Well, that depends on what he knows. If he knows programmers, then he'll recognize that the excellent guy's output is fantastic, that the incompetent guy's output per hour is extremely low and is causing havoc, and that the average guys are right to complain.
If he doesn't know programmers, he sees some guy who spends all his time goofing off, another guy who works really hard, and two average guys. The average guys complain about the hard worker and praise the lazy guy, thus showing that they are not to be trusted. Apparently they are jealous of the hard worker's success, and are trying to convince the management that they should be allowed to spend all of their time goofing off too. After enough time passes, the heaviest bonuses are awarded to the incompetent guy, and the excellent guy gets fired for goofing off.
It probably doesn't work with a lot of other jobs too, but programming is what I know and it's what we're talking about.
If you mod me Overrated, you are admitting that you have no penis.
From my personal experience, bosses with limited to advanced "tech experience" tend to stick to "the old ways" and old tools.
The problem is/was that when first released, these tools come pre-compiled with obscure bugs that are only found when users start building heavy applications. Such obscure bugs can include: memory leaks that gradually suck up all available system memory over a number of days, obscure device driver/hardware glitches, compiler misinterpretations.
As far as the manager is concerned, he won't lose his jobs for approving a project with a combination of solidly reliable OS, compiler, programming language and window GUI's.
Of course, it is absolutely brain-f**king for the programmers (especially entry-level graduates) working for such a person, because they see the rest of the industry rapidly moving forward with the skills they have just learnt while at college, while they are stuck with yesterday's technology trying to gain enough experience to move onto the next gig.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
No No NO you've got the outcome of the joke wrong.
Those Uphill dispatched a Committee tasked to discover the problem with the American crew. The Committee researched the issue and reported Uphill that the trouble was that while one guy was rowing, 7 were managing.
Uphill requested the Committee's recommendation for improving the situation.
The Committee replied that they had been tasked only to discover the problem, that designing solutions was outside the scope of that mandate, and that, as a consequence, they had not designed one.
Dispatched again by Uphill, and with a new mandate, the committee reviewed the situation and returned to report.
Asked by Uphill for the solution, the Committee replied, "that guy has to row harder".
Being someone who 2 years ago left big corporate life.... that "joke" is 100% accurate description of how american fortune 100 companies work.
and from the stories I hear from friends still there it's worse. they are adding useless managers while cutting the workforce.. This economic slump is not even starting... we will be having major corporate collapses in the next 5 years that will make the economic downturn right now seem like a camping trip!
Do not look at laser with remaining good eye.
That is the dumbest thing I have ever heard. So, Jack Welch needed to know the basics of the tens of thousands of products that GE sold to be a good manager?...Apparently not.
It would be an incredible person indeed that knew the basic operation and could identify the major components of electronic, computer, petro-chemical, gas turbine, locomotive, electric motor, generator, lighting, appliance, and finance products (to name a few GE products).
This absolutely accurate in a general sense. My field is Electrical Engineering and I have seen managers of the latter type, where "programmer" can be replaced with "engineer". An ignorant manager is an irresponsible and shortsighted way to do the job.
I can't agree more.
I'm a bottom-level IT manager. They call me a "team lead," which is code for "you're a manager but we're not giving you any more money."
I was on vacation for 12 days at the end of August. When I got back, I got two reactions:
1. From my boss - "I'm so glad you're back, I tried to get the guys to do a build and apparently just managed to confuse them."
2. From the most senior developer - "I'm so glad you're back, I didn't realize how much you filter out. It was one of the worst weeks I've had in a long time."
My job is to run interference between my boss and my team, and to translate between boss-speak and developer-speak. Occasionally I get to write some code, too. If there's something that looks fun and is small I selfishly grab it for myself. God knows I don't have time to do anything big.
The preferred solution is to not have a problem.
Except the CEO of Ford sure as hell knows what a carburetor is, how it works, and how to take it apart and put it back together. He's an aerospace engineer. We both had the same professor for Senior Aircraft Design in school (years apart, of course). I know he knows his engines. :)
I would have throught the best way to measure performance is in functionality/bug fixing, combined with some sort of rough syntax analsys so you can see how many bugs a person is introducing, how many non best practices their introducing and how many their fixing.
Last week I spent all week re-writing and heavily expanding an interface and it allowed me to remove something like 5000 lines of code from the software. Measuring LOC would have had me seriously in the negitive.
Amen!
I have seen more than one company that was effectively dysfunct in the way you describe.
In one particularly disturbing example the CTO is a former taxi-driver(!), I kid you not. He apparently participated in some tech gigs before joining the company but nothing that would turn him into a competent manager by any metric. The boss praises him for his "communication skills" which pretty much translates to the constant ass-blowing (CTO towards CEO) that you mentioned. Other than that everybody knows that he's clueless, it's even obvious when you only look at the figures since he never meets a deadline (well, maybe once a year) and budgets frequently expand like supernovas. Needless to say the company has completely lost all its momentum because this guy accumulated a team of ass-blowers around him that, just like him, can't get shit done but knows how to disguise it in creamy communications...
The scary part is that in our economy this setup *can* work, depending on your business-model. The aforementioned company is making millions in revenue with a ridiculously crappy product, simply because the competition is equally bad or worse.