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."
I think having the manager understand the technical nature of whats going on is certainly an asset.. but ultimately I don't know if it's a necessity.
Point is, managers manage people. You are there to code.. not them. The only technical details they need to do their job is: how long it will take, how many people can work on it efficiantly, what tasks are dependant on it, risks, and benifits.. and you are there to provide them with that info.
Managers are about the big picture, not the fine details. In fact.. a micro-managing manager can be a bad thing.
I think we've all been there... the guy who is directing the circus has no clue about whats involved in it's component parts and you wonder how he ever got the job...
When you really look at what he spends the day doing though.. you realize the majority of his job revolves around the non-technical things that you probably don't want to have anything to do with (timing, resource allocation, cost, etc..)
I don't have a lot of experience in the industry, but the one software company I have worked for (albeit a small one) has a programmer in charge... really, you can't expect to manage an IT staff properly if you don't have a basic knowledge of what's involved in the job.
Management is about resource deployment and allocation, not coding. Good managers need threat models and broken down schedules from their coders; a little knowledge is more dangerous than none.
Sorry Slashbots but people skills are more important than tech skills and always will be.
As usual, Cringely is right. The fat floats to the top.
I'm an IT project manager. If one of my peeps bailed and I couldn't step right in and fill their spot and train their replacement myself I would consider myself a failure. It's all about the customer and if we fail to meet the customer's needs because of this everybody involved has failed.
I had this conversation recently: "Can you replace X?" Answer: "Of course. If I couldn't, we both need replacing."
I've got people both under and over me. I fully expect both the unders and the overs to be able to step in and catch the load if I step in front of a bus. I don't want to catch a bus, and I don't want my unders and overs to do so either. But I'm prepared for either event and you should be too because if you can't you're neither responsible nor capable of advancement and that's a sad place to be.
That said, most days my role is reduced to catering. I let my peeps do their gig and I get stuff out of their way. Only the newbs need direction and they get over it right away.
As soon as they're oriented:
I'm only an IT project manager until my bosses find someone better. My techs only work for me until I find someone better. That's the way it is and that's the way it should be.
Help stamp out iliturcy.
A manager manages PEOPLE and not C/HTML/PHP code.
I love the smell of lithium in the morning
But without Pure managers in IT, who would make facial expressions during Scrums? Where would we get our positive social affirmation from?
BBH
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
How much you wanna bet a bunch of CEOs are going to RTA and fire all the COMPETENT bosses and keep the PHB's?
[End Of Line]
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.
... if developers want to work for sane people they are going to have to get their collective heads out of their asses and come together as a community and fund their own companies. But you'd need people who love risk, are laid back people, who have good values, good work ethic and are committed for the long haul, and will not give up their values and ideas. Persistence is key.
I've been thinking of just such a thing (see link in my sig), wanting developers to come together and discuss ideas and have dev's fund dev's to get away from incompetently run companies.
Good developer? Risk taker? Philosopher? Good values? Try here
"Instead of laying off managers who directly help their department, AC argues that the best place to cut IT organizations is at the bottom. One of the great problems in IT techies, AC says, is that the gound-level troops 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 a techie is an IT shop and can't remember what SWOT means, then you are in the wrong job.' Even with help from Google, AC believes many techies would fail this test and should get the boot as a result â" you can't work if you don't understand management concepts."
Hey - this stuff is valid no matter which way you look at it. PHB/techie stereotypes aside, management is a profession as much as a techie is. The further you go up the chain, the more 'management' and the less'techie' you need. Professional MBAs know nothing except management. Whilst is is nice to have a CEO come up through the ranks, that doesn't happen much anymore. Operational issues never go up to the top. If techies are sick and tired of being shat on my management, perhaps they should also recognise that management is also a required role that many of us can't do as we simply lack the skills, aptitude and (critically) training.
The article seems to more say that the IT manager needs to understand the underlings jobs and be able to describe the job. Not that the manager has to understand everything the underling must do to complete the job. The summary seems a little slanted.
The absolute best IT managers I've had were more than willing to state when they didn't understand the technical details. In the cases where they had to explain something in detail they did what a good manager would do; they'd ask the individual who DOES understand it better than they come and explain when that level of detail is needed. Those same IT managers not only understood enough of my job to outline what they'd like accomplished and stepped back to let me accomplish it in the most technically correct way possible, they shielded me from those above and outside the department so that I could do that job.
The last thing I want is to be managed by someone who thinks they are more an expert on the intricacies of what I'm working on. Either they are going to micromanage the individuals on their team or they aren't ever going to be satisfied with the work that is produced.
Maybe the poster would be happier if they were called IT Personnel Managers?
I'd argue that if you can't differentiate between a markup and a programming language, you probably shouldn't be running the shop... or espousing opinions about who should... either.
Typical low level IT backlash. Management is not all about coding and pulling cable.
Its about being able to do feasibility studies, create budgets, do performance analysis, and generally be the "face" of the IT organization.
Just because the entry level IT clerk does not know how to do these things; or even about them, doesn't mean the boss is useless.
I'm an IT manager and I know how to code. I'm not perfect by any means, but I know what my folks are up to, and more importantly up against.
And without the specialized knowledge of that field yourself, how do you know that they know their job?
See above.
Anyone who believes that technical knowledge is superfluous to a manager is deluding themselves.
Are you kidding me?
As long as my I.T. boss shields me from the dipshits and the politics at levels above themselves, I don't honestly care what they can or can't program.
They're worth more to me as a human filter than a fellow developer. Christ. Let me actually fix things - they can go off and interface.
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
IT managers are supposed to do more than direct management of people and projects. They're supposed to have a grasp of overall organizational goals, and to fairly assess how IT can be used to make the organization more efficient or effective.
Of course, as with so many things in life, people are generally interested in protecting themselves. So it can become a policy to protect ones own budget, and to (artificially?) propose new projects as reason to grow or at to at least maintain a department's size. Diminishing returns, anyone?
Still, managers are supposed to add value by seeing the bigger organizational picture. Ask yourself if the front-line IT workers can handle that themselves.
--
Hey code monkey, learn electronics! Microcontroller kits for the digital generation.
I disagree with the summary to a point.
Yes some managers stink and need to be fired. However, I had a great boss once who didn't know how to code anything new (he used to program embedded C, but had been out of touch for a decade). What made him a good boss was that he listened to his programmers and took their suggestions seriously. He was highly competent in the areas necessary for good management; organized, focused, motivated, and open to good advice.
Don't fire managers just because they can't code. Fire them if they don't listen, think programmers are annoying, and are generally incompetent.
Full disclosure: In fine Slashdot tradition, I did not read the article. I'm busy.
With a division of labor, the idea of the manager is to strictly keep to "managing people", right? What does that actually mean in real practice? If the techies are the ones with all the actual skill to implement technology, what happens when techs have a technological debate? If a team is designing a complex system and there is a difference of opinion between two or more choices with subtle but far-reaching consequences, in the real world, is the manager going to be hands-off and stick with the "people side" only?
I don't know about anyone else, but that's not how I've ever seen it happen. The manager must make a decision about the design of the technology. How is he/she to decide? Based on which developer is a snappier dresser, or which one kisses ass more? :-) The business world needs to get rid of this obsolete idea of a "manager" who mechanistically manages human "resources". We need to be more honest about human interaction. What most businesses need are LEADERS. You can't lead if you're not in front. You want quality code from your employees? Then can YOU recognize the difference between bad and good code? In practice, good managers in IT are technically proficient AND have people skills. It's out of necessity, businesses really don't have a choice unless they want to keep burying their heads in the sand and sticking with merely "managing" their employees who they have no idea what those employees actually do.
While I understand the basic premise of needing to basically understand the technologies you're charged with overseeing, you can understand the capabilities and limitations of those systems without having to know what variable type declarations need to be strict and which don't. WHile well intentioned, the submission misses the forest for the trees. I've got 3 guys that work with me that know how to program in at least 4 languages competently, but they're completely unreliable because they lack the ability to think on their feet when a problem presents itself that isn't covered in the google tutorials. You can buy any number of screwball, underpaid asians/indians/H1-B types that can do the same thing I can as long as they have the interwebz to double-reference any piece of code they cut&paste into a project. You canNOT buy people who can look at a problem and make intelligent decisions as to what the general pseudocode should look like to actually solve the problem(s) within budget and on time.
"If your boss doesn't understand your job enough to describe it in technical detail, that boss is in the wrong job."
This is something that many people I know in the industry, at all levels, feel about those who make the decisions. Given that commonality of thought, does that mean that managers are truly clueless or that IT personnel are simply the type that don't cry out for recognition and simply expect recognition from management for the contributions they make?
Sig this!
As an IT manager who has commit privileges to the core Python repository, and can write hello world in half a dozen languages, I'd like to chime in...
IT management almost certainly isn't about doing the work. That's why it's management and not technical work. Management is about helping other people do things.
For example, technical people are notorious for being not very good with people. Having someone helping them interface with the rest of the company, get funding, run interference for projects and decisions, all of this is very important to getting coding done, and does not require an ability to code or even an understanding of what is going on with the people doing the coding.
Having a die-hard techie in a management position may not be as valuable as having a die-hard manager there. Because if the manager just really wants to be doing the techie work, that's really where his passion is, then he probably is in the wrong job. Just as if the person in the techie job's passion lies elsewhere...
If you have someone in the organization, management or not, that isn't pulling their own weight, then definitely look at what you can do to remedy the situation. But whether a manager can write main() { printf("hello world\n"); } is almost certainly the wrong test to be using.
Would you fire the techie who can't come up with $50,000 in funding for new workstations and servers?
But, I guess the "re-purpose people who aren't pulling their weight" headline isn't as easy to get on slashdot as "fire your IT boss". :-)
Sean
A manager can break a window as easily as something that is thrown, say a chair...
Some smaller companies have technical Directors and CIOs who likely wouldn't be qualified to be a technical team lead or lower-tier manager in a larger established company with a strong technical history. Sometimes that's fine. It depends on the company, on the nature of the people over, above, and around each key person, etc.
"Managers" in some organizations code (and are effectively Technical Team Leads with hire and fire authority), while "Managers" in other organizations simply manage. Some organizations don't have a manager level at all, while others might have three levels between "Directors" and FTEs.
Sometimes a project management layer exists which handles things like large project coordination and the like, and sometimes that fals into the lap of a manager. Or a tech lead.
Some companies allow their managers to make strategic decisions about where their area is going, others don't even give them much input into the process (being driven instead by internal user groups and organization-level processes).
I've worked for a large technology company, a large airline, a small manufacturing company, and a meduim-sized IT company, and all four of them are so different in the organization and general approach to IT that it's very very difficult to compare a position in one to a supposedly similar position in another.
That makes it hard to come up with snap judgements about "who is responsible", since a large and complex organization might even have multiple internal corpirate cultures. Look at IBM for an obvious example, but even a much smaller company like Northwest Airlines had three distinct IT cultures: IBM mainframe, Unisys mainframe, and UNIX. There are very different processes and general mindsets in each group, believe me...
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
nt
You have the kind of manager that you describe.
He is is charge of two people.
Those people are telling him two different things.
How does he choose what to do?
Why?
I have been in that situation many times.
The problem is that the less technical the manager is, the easier he is to be swayed by vague promises and hand-waving.
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.
Which car-buying customers really know how their car works, especially, now that cars include microprocessors in their engine systems?
Do you want the car-makers to decide what each customer should buy?
I don't think so.
Hold on! Maybe you're right: After all look at the monstrosities that General Motors, and other "dinosaur-makers" have put on the market... eg, Hummer, & the like...
I'll buy into your plan for this industry, if not the IT departments within it:
Let's remove the heads of such companies, eg, replacing them with people who understand Global Warming, electric vehicles, the joy of bicycling or motor-scooting through a scenic place on a warm, summer's day and really care about energy independence (as a political goal).
Let's see what the new "people's boards of directors" would direct their companies' engineers to design, and how soon they manage to overcome all the problems that present ones seem unable to solve.
Smaller, lighter, electric "smart, city-commuter cars" would save much & would cost less (when in production), enabling first-car buyers to skip 8-cylinder gas-guzzlers, thereby putting more of their money into supporting the new energy-efficient car-makers, and less into ancient, off-shore oil-producers.
US car companies would begin to lead, again, and jobs would be created instead of going off-shore.
More important, people would feel proud to buy locally designed/made cars, again.
Win, win, win, win, win...
Yes, I think I like your idea after all... in its place!
Does it work the other way around too? Can I become an IT boss if I can do those things, write "hello world" and query a database? No, because seriously I'm getting tired of cleaning toilets for a -- no pun intended -- shit salary and then come read here about incompetent people in the IT industry.
Perhaps it would be best illustrated by this 20 year old joke:
The Americans and the Japanese decided to engage in a competitive boat race.
The Americans and the Japanese decided to engage in a competitive boat race. Both teams practiced hard and long to reach their peak performance. On the big day the Japanese won by a mile.
The American team was discouraged by the loss. Morale sagged. Corporate management decided that the reason for the crushing defeat had to be found, so a consulting firm was hired to investigate the problem and recommend corrective action.
The consultant's finding: The Japanese team had eight people rowing and one person steering; the American team had one person rowing and eight people steering. After a year of study and millions spent analyzing the problem, the American team's management structure was completely reorganized. The new structure: four steering managers, three area steering managers, and a new performance review system for the person rowing the boat to provide work incentive.
The next year, the Japanese won by two miles!
Humiliated, the American corporation laid off the rower for poor performance and gave the managers a bonus for discovering the problem.
Skip ------ See the latest from http://www.anArchyFortWorth.com
Most decent IT pros in production jobs can quickly learn new techniques and systems - that's their main skill. If you've got one of those kinds of teams (and everyone should, or the IT department is really a joke - though perhaps most are), then you probably want to fire its tops managers first, if the department isn't performing. Because those top managers probably got to the top by working some more or less specific way of doing IT, riding some vendor's marketing white papers, having one good idea once that saved the day. And they're usually older, less able for many reasons to change their "wetware". Plus, they make a lot of money after feathering their nest for a while, that gets saved to pay someone else to replace them. And they can take with them a lot of accumulated resentment from the production staff when they go, which might even have been most of what's wrong with the department.
Just make sure that their balance of pros and cons is in favor of benefit when you replace them, and not just with some new idiot. Make sure the new leader is really a leader, and can lead the team in learning the new way - and not just a way that's new, but a better one.
--
make install -not war
Actually, you can manage what you don't understand. I expect first line managers to understand what their people are working on but I only expect second line managers (one layer up from first line managers) to understand how the pieces fit together. From that layer on up to the C-level, people manage budgets and strategies. They rarely have the foggiest idea about how those strategies get implemented and it would be a waste of their time to get lost in the minutiae of the actual implementation.
The whole trick of making this work is for managers to realize what they don't know. Problems come up when people who really don't know squat try to make technical decisions that should be left to the people with the technical knowledge to make the correct decision. The most dangerous beasty in this jungle is the idiot who thinks he knows what he's doing and is unwilling to get the technical inputs he needs because he sees asking for such inputs as diminishing his "power."
I'll take the manager who can't write a line of code and knows it over the bozo who thinks he knows everything just because he can write a "Hello world" program in FORTRAN.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
I fully agree. There is a union type seniority mentality where experience far outweighs talent. I have found that many organizations have IT managers who came on at the same time as the IT department was created. Typically there are two problems with these people. Either they came from another department to manage this new IT thing and thus don't really grasp what they manage; or far worse in most cases they came in long ago with a now dead technology and never kept up. So here we are potentially decades later with IT managers who might not yet be in the 90's techwise let alone up-to-date. I have seen companies where they resist giving even management access to the internet or email. When the reasons are explored it turns out that the network is so old that TCPIP is not really an option. I have seen these people going to heroic levels to persist with the madness of these old dead systems. I was a fly on the wall when the local phone company was first offering DSL in the late 90's. They nearly cut the internet option as they saw the DSL business model as renting applications such as MS word via some complicated Novell system. Let me repeat: they nearly left internet out of their DSL product in the late 90's.
Wish I had mod points. Instead, I'll use my low-low ID to say that you're absolutely correct.
[...] you can't manage what you don't understand.
ITs are suffering from generic problem. (Correction: users are suffering, it is of course not IT's concern.) It's not that they do not understand what they are managing.
The problem goes much deeper: IT never really knows what for and how IT resources are really used by people who actually do work.
IT always concentrates on its end of job.
Results are obvious: horrifying end user stories about lost data, lost hours of work and IT which simply can't give any sensible response in emergencies.
Problem as I see it: whatever company is, IT is always way too far from real work: real work company is doing and earning money with.
My idea was always that IT has to be not department, but people spread all over the company. You need about 1 dedicated guy to be responsible for communication with suppliers (or probably somebody from Purchases can handle it - they handle it (monetarily) anyway). Rest has to be managed by teams themselves. They can have a dedicated guy(s) for the IT needs. Or one/more people on team can handle as part-time job the problems and etc.
As R&D guy, I yet to see a competent IT guy who can competently set up *nix server which after reboot is ready to work. Piles of certificates from lengthy trainings do not help them in real life. Outside of checking cables and phoning suppliers - I've seen no use to IT. And phoning/checking I can do myself. No big deal.
But probably that's only me who is that unlucky.
All hope abandon ye who enter here.
So, I understand that mindset also. And I agree, it helps managers relate to their employees if they have spent time in the same trenches, etc..
However, management in itself is it's own career path and it should be about balancing the business and people aspects in support of their organizations.
One of the largest problems however, particularly in corporate settings is, the development and support, QA, etc teams do not understand the domain/business or operational aspects and therefore, and only code/build/test what they're given.
When you have a management position who understands the business side, it can help ensure success once you put in a new build etc. because the operational aspect can be considered.
While most downlevel individual contributors tend to look up at sr. level managers and think they are lemmings, there's a lot to the business side that goes on the employees don't see. Then it's more about how effect the mgr is at communication at then end of the day.
...that from the "managing" point of view their demand that "You should be using Dreamweaver. Everyone uses dreamweaver..." is the same as demanding the ability to "write the code to render "hello world" in C, html, php, and pull "hello world" from a MySQL database using a perl script"?
In other words: "Do it like we tell you/according to arbitrary standard."
NOT, "Do the job right and in the most productive way".
From my personal experience, bosses with limited to advanced "tech experience" tend to stick to "the old ways" and old tools.
For example, coding in C - never in C++, or using ancient compilers.
Bosses with advanced people skills on the other hand manage people - not the code or product that the said people are working on.
Mediate between people in the team, steer in the right direction, and help in the communication along the company's and project's "chain of command".
Managing code... that is YOUR job.
Mit der Dummheit kämpfen Götter selbst vergebens
Pandering to the Audience (Guilty as charged)
Just closed my Team Fortress 2 game, where I was playing Pyro. Then read "FIRE Your IT Boss" as top story on Slashdot. Sounds like a plan!
"MHenenEHHEHenH!!"
-- Home is where you eat your heart out.
Peter Principle at work here
That's why finding good managers no matter where (IT, HR, etc) is difficult.
IT Managers are not all code monkeys. My job as an IT Services Manager is to keep the break/fix cycle flowing smoothly, guide the company towards ITIL/COBiT frameworks, and to keep the shit that floweth from overhead from hitting my teams. Don't assume IT managers are coding-centric. Hell, try adding in configuring Active Directory objects, getting AD to work smoothly with LDAP for SSO simplicity for the MAC and *nix users, and to set up VLANs in Cisco equipment. A manager that can do the coding and services side is a tough thing to find, especially throwing in soft skills, planning skills, and management of projects and personnel.
I'd fail the first test because I stopped coding C back when Borland 4 was new. I can still whip up a decent bit of COBOL, perhaps that would counter the missing C experience.
"First things first, but not necessarily in that order."
- Doctor Who
I'm sure they mean well, but the CEO of a company should not necessarily know how to perform every task of the organization. It is not their job. The same applies here -- managers manage people. If the people are organized/empowered/self-managed/[buzz word here] in such a way they don't need that management, go ahead and fire the boss.
From my still young experience in a few companies why you need to get at least somehow technical good managers.
1st company: Being tasked to do a tivo like system based on mandrake in 3 months (why a mandrake and not some already lightweight distro, think 3 months for a single person is reasonable?)
2nd company: having to manage customer cases with MS crm, and that was the only purpose of the crm, neither management, nor sales where using it (why not a bugtracker or some case management system)
3rd compagny: on the first day, the servers have an issue, usual admin is sick, manager says "please do whatever you techies usually do to fix the problems, here is the admin login and pass, there must be a program somewhere to do that" the company was serving half a million pages per day.
4th company: a security audit been given 4 weeks to complete it, after 3 weeks i say the timeframe is to short to make a decent report because we tried to make a way too wide audit, they admit they had no idea how much an audit take caus eit was their first one,i get 2 additional weeks, at the 4th week i get a phone call, please send me your report draft now the audit is over, i ask what about the 2 additional weeks, i didn't even had a reasonable answer, yet the gave the audit result like this.
These were just some obvious thing which still stricks me and i had stuff like that to live with on a daily basis in each company, no amount of whining or explanation could get the manager or boss idea to change (didn't even said anything in the 3rd case).
...and I love it. I've been in IT for 12 years and became an official manager for the first time a couple of months ago. I can pass the aforementioned test which definitely makes my life easier. I don't have to micro-manage my team to know if they are doing what they're supposed to be doing and I am in tune enough with the challenges they face to know how to properly manage expectations up the food chain. My knowledge also allows me to take input/requirements from the non technical groups within my company and lead all of the deep-dive planning sessions with my team. I also act as the buffer for my team... it's amazing how many non-techies (i.e. my customers) will not only give you a problem to solve, but include their input on how they think you should solve it. Amazingly they tend to get pissed if you don't listen to their suggestions. I've found that things at work run a lot smoother if I take the brunt of the scope definition with our customers work and just allow my team to figure out the best way to accomplish the task. In the end my job is two-fold. 1) Keep peripheral noise out of my teams' hair so they can do their work and 2) Be the keeper/driver of the larger vision and let my team shine by allowing them to be their own people by catering to their individual strenghts by respecting what each of them brings to the table.
If I didn't have a heavy background in IT I don't think doing those things would be so easy for me.
So your situation is more like 2 technically knowledgeable managers (one Windows and one Unix) and a rubber stamp from the guy who is "above" them.
Now, what happens when the rubber stamp guy has a limited budget ... but the Windows manager wants to spend 51% of it on a Windows project ... and the Unix manager wants to spend 51% of it on a Unix project?
Unfortunately, a lot of managers I've worked under are also responsible for project planning, scope and execution. One of my previous managers managed to turn a simple customer address input form into a 15 page, tedious, complex and confusing web fiasco.
This manager put together a big powerpoint presentation for upper management, for which she received applause. As the developer assigned to accomplish this task, I was given the opportunity to voice my opinion and suggestions.
My manager was not happy with my comments pointing out the many shortcomings of her plan and praising upper management for promoting her out of my hair.
"Lame" - Galaxar
If your initial thoughts on this are to the effect of "too right, I have no idea what my manager is actually doing all day, our team seems to work great without his/her input", chances are you are working for a pretty damn good manager. Like a good sys admin, the less input they are obviously making, the better the job they are doing..
I would just add that if you think Active Directory is "pretty darn good" --- you're fired.
Tired of FB/Google censorship? Visit UNCENSORED!
Wow. Someone who actually advocates that non-technical managers look in "published articles" for insight.
My experience has been completely the opposite. I have to continually fight to stop management from wanting whatever magic bullet they just read about in an in-flight magazine.
Your boss, since they have a position of authority, should be a champion of these technical solutions. Since there are good and bad source control systems, good and bad bug trackers, etc., and new developments happen all the time. Understanding the tools available to manage people is just as important as managing them.
I don't think I would fire them, they have their place. A managers job should be to fill out tps reports and
take a bullet from the rest of the org when something goes wrong.
Three simple rules in any org could immediately reduce spending to fight off the slowing economy.
1. Remove purchasing approval from the IT manager.
2. Anyone employee caught taking a perk(lunch,golf, trips etc) is fired immediately.
Purchasing power would be delegated to team leaders, going over budget would lead to immediate firing. Bonus will be paid
in the event the team came under budget.
I cannot tell you the number of times I have seen senior manages go out for a friendly game of golf and the next
day are stroking a check for 10's of 1000's of dollars for something we either don't need or just plain will not work.
Got Code?
I'm an IT project manager. If one of my peeps bailed and I couldn't step right in and fill their spot and train their replacement myself I would consider myself a failure.
If you don't have a single employee who has a skill that you don't, then your real failure is in hiring.
So while I can do all of that in .NET/SQL Server does that mean I get fired? Maybe I can substitute the PHP version in Assembly being that's what we use.
The *last* thing I would want is a manager sitting over my shoulder saying "why didn't you do method a() this way" or "why not write the mysql code a different way".
I would rather the manager, you know...manage. If a manager can't understand a method or get the reasoning behind a programming choice and cannot grasp changes or accept new ideas then get rid of them, not for not knowing code.
Why do overlook and oversee mean opposite things?
Cutting managers is an attractive idea, but there are a few who are both competent and a pleasure to work for. (I can think of at least two.) The good ones should be encouraged, perhaps even to breed. The rest? Sterilize, and banish to the fringes.
There have been a lot of comments about how your manager doesn't need to know the technical aspects of what you do.
Let's just extend that with your Ford analogy.
The CEO doesn't know what a carburetor is. ...
So he hires person A to handle that.
But person A does not know, either.
So person A hires person B to handle that.
But person B does not know, either.
So person B hires person C to handle that.
Eventually you end up with the situation where you have layers and layers of "middle management" that do nothing other than move reports around and attend meetings.
And that's why you're probably driving an import today.
And 100% agreement on HP and Carly. I have no respect for HP now. The person at the top is paid a LOT of money ... supposedly because she has a LOT of knowledge and expertise and skill. Arguing that knowledge is not needed ... well, people always disparage what they do not have.
First, I love Cringley. However the article can be summed up as "Dilbert is true!". News?
Second, I think it's funny how as soon as you talk about IT somehow that means you're talking about programmers.
No offense (really!) but F**K programmers!
I've spent more than 10 years in IT, with hundreds perhaps thousands of coworkers and neither they nor I have ever (professionally) touched a line of code.
Perhaps it could be said that the real problem is too narrow a focus?
-Matt
This may very well be true for the manager of a technical focused team, for example, IT shops consisting of 20 IT workers with less than 2 million dollar budget.
In most large IT shops (500 workers plus), the executives mostly deal with budget and decision making, they generally rely on technical managers to advise them of the technical options.
The term "IT boss" is too loosely defined. For technical managers, I couldn't agree more that they need to have a clue about technical stuff. For executives in large IT shops, they have to manage hundreds of millions of dollars budget, so finance, ability to understand and decision making ability is much more important than actual IT skill.
All managers should read this book or listen to the cd set. Very good morals to manage by. Everyone that I manage know when I need something done and want to help to get there. This being reason that I will help them.
Just look it up and understand
All this tell me is that good IT managers are even harder to find than good IT coders. Managers don't need to know how to code, they just need to know how to manage resources while minding their business ethics courses so they don't tick everybody off.
If they can't code, I don't see that as a big issue. If they can't handle the stuff behind the code, that's a problem.
I'd have to look up the syntax to complete the perl portion from scratch, do I still qualify ?
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
Managers need to know what their underlings are talking about. When I tell my boss that Rails' to_xml method only goes one association level deep the boss needs to know an association is (in rails), what to_xml means, and what impact this limitation has on consumers of the XML resource.
Those that don't know and are unable to learn will be a hinderance to me when they promise someone a feature that will take me hours more to implement to extend the default to_xml method.
The bad ones will insist on XML and avoid JSON, even though JSON is lighter weight and has no association-depth issues.
In my experience the best managers stay out of my way and answer questions promptly and effectively. Technical ones seem to have difficulty keeping themselves from giving me their opinion on how best to code something.
That was not supposed to happen. You made an insightful and interesting response to my post.
Managing people is a craft, and there are educational resources to teach people that craft. When an organization grows beyond a certain size it requires some people who are trained and skilled in this craft. The common practice is to compensate them disproportionately for this skill. Most of these people are quite proud of the fact that they don't know how to do anything other than manage people.
Given a choice I'd line all these sort up against a wall and shoot them. The company would do better, but that's probably insensitive, eh?
Help stamp out iliturcy.
This is what actually happens. When dead weight needs to be cut, it is almost always middle management that gets the axe. Rarely (if ever) will developers be the first out door. You need actual workers to get the code done and senior management knows it.
This whole article strikes me as years late to the realization. The nineties were all about eliminating management positions in all industries (not just IT) as those jobs became obsolete with the technology revolution.
First idea, firing the guys at the top when things don't work correctly, good. The rest, bullcrap, that's an awful way to test for managerial competence. Besides I'm a coder and I couldn't pass that test.
You just got troll'd!
Many companies take people along a development track of
Worker Bee Level 1
Worker Bee Level 2
Worker Bee Technical Lead
Worker Bee Manager
Hive Manager
This is usually wrong. Managers require a different set of experience from workers, and they are skills that are not taught or learned by being a worker. And the jump from Worker Bee Manager to Hive Manager is even worse. Hive Managers need to understand the interactions between workers, drones, queens, etc. And people who start as workers are probably not interested in those other jobs.
A good IT manager is not a manager at all, or a programmer, they are a servant leader. Servant-leadership emphasizes the leader's role as steward of the resources (human, financial and otherwise) http://en.wikipedia.org/wiki/Servant_leadership/ .
The worst IT managers are the ones who try to manage. IT is a function that tends to best be performed by self-managed people. The only things the tech team needs are good requirements and intrinsic motivation. A servant leader gives those things to his team.
Is exactly what this article asks to introduce into IT. A lot of the times, the person managing the budget in schools is a teacher that's been promoted. They do an awful job at managing money, and most schools are extremely wasteful with their budget. The problem is that this person is a teacher.. not an accountant... or a manager, etc. A manager should be a manager, simple as that.
This is the point of a good tiered system. You have the coders, you have the project coordinator who can code and manage the coders, and then you have the manager who could be in a completely different type of company and still work the same way.
"Fire Your IT Boss" is a very poorly thought out argument.
And revoke their credentials too!
If knowing PHP and MySQL are critical skills for your CIO, you have far, far bigger problems.
Follow the debian + LAMP "The Perfect Setup" Then, add modsecurity 2. And then fine tune your shit. Add a firewall, and keep the whole thing behind another hardware firewall. Add Port Knocking. Add banlists. READ LOGS, and REACT QUICKLY...
peace
We don't want managers who know how to manage, we want managers who want to do everything.
We don't want them to create processes so we do less work, and focus on allowing us to work, we want them to do our jobs for us.
End sarcasm.
This is a ridiculous notion. Managers sometimes don't know what's going on beneath them, but usually they have an overall idea of the projects direction, and how that benefits with the rest of the business.
A greater problem with IT is being promoted to fail also known as the Peter Principle.
A lot of people think management is easy, that developing processes which get things done, and making some of the harder decisions is a joke. However, these are usually the people who have had managers who think the same way, and so they think they can do a better job. Or they don't understand why he is doing what he is doing, because he doesn't communicate that to you.
Management is a specialization like all other disciplines. The business of business is business. It is more important to have a good grounding in business.
I shouldn't have to understand the low level of the system, that's your job, at the most I should want to understand how it basically works, and how it can benefit the business.
This has worked the best in organizations where I have worked. When the upper most IT executives think they understand the lowest levels of the system and could write it all, they tend to exert too much control on the system. However, when the upper most IT executives recognize that you specialize in doing this code, and they specialize in management, they leave you more to your devices and focus more on how you are working with others.
This is my footer. There are many like it, but this one is mine.
While I've had my fare share of situations where I wished my boss better understood the stuff I was doing, I believe that the purpose of a manager is two fold:
Would it be nice if a manager understands the core portions of what his/her team does in the technical sense? Sure. But you'll get too many managers who believe they know more than their team because they got Certification X or used to use punch cards. A manager with enough knowledge to be dangerous is far worse than a manager who has no technical knowledge at all.
A manager should be able to trust their team members to do what they're supposed to. Part of this includes evaluating a member on his/her strength, which is where the lack of technical knowledge becomes a problem. But aside from this, they don't need much in the way of technical knowledge. What they should have is the ability to motivate, to act as a barrier if someone else comes raging in about something, to get the team the equipment/money they need to complete their tasks, and to make sure the higher ups know what's going on. They should try to learn technical stuff relating to their team during their career, but it should be only so they can better understand their team instead of making technical decisions for them.
Do you really want your manager looking over your shoulder and asking "Why aren't you using bubble sort?"
Similar tests could be easily applied to any management position. A good manager should be able to do an task they assign, plus the skills to manage multiple workers, as a team.
If they can't do my job, why are they making more than me?
Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand.
That said I prefer a manager who understands enough to distinguish me from the kiss-ass nimrod in the next cube.
Wanna trade? :-D
I don't believe in time. It's a grand conspiracy designed to sell watches.
I'm pretty sure I could pull off a Hello World in all of those situations and I'm a law student. However, I in no way consider myself to be qualified to work in IT in any way.
Top level managers have to be both good at managing people AND have at least a basic understanding of the code (or whatever) that his department is doing. Cringley isn't saying all IT managers should be hardcore programmers, his point is they have to have some cursory knowledge of the work they are making decisions upon.
He's right.
I understand that many today believe that managerial skills are completely transferable to any industry/profession. The idea is false. Yes, all managers need to know how to manage people, but that is not all they need to do their job.
Managers, especially upper level get paid alot of money, the way they earn it is to be good at alot of different things (including people skills).
If you operate under the assumption that the only thing that matters for a manager is their people managing skills, you get incompetent managers who basically have to rely solely on their support staff to tell them what to do.
What you get is the CEO of a horse racing company hired to direct FEMA (see: Katrina)
Thank you Dave Raggett
As a CIO and a technical guy, I can tell you with a high degree of certainty that I don't need most of the skills I used to keep polished (like writing COBOL code) to be able to manage IT people and resources. Budgeting, Organizational Behaviour (go take the course), resource allocation, etc are much more important. You only need enough technical knowledge to keep smart-ass young code monkeys (or infrastructure guys for that matter) from trying to bullshit you about what they are (or ofter aren't) doing. Firing the guy that browses SlashDot articles all day instead of doing his job is more important to the organization's well being than having a manager of IT or a CIO debug proggies or pull the logs from a Cisco switch.
Officially a geek since 1984
While it is important to know what's going on in your company (not only in IT!) and to be able to tell a good (programming) job from a bad one, it's even more important for managers to be able to hire people who can do that just as well or even better. A good manager is like a good system administrator: he does his job best when he is never really needed.
"I love my job, but I hate talking to people like you" (Freddie Mercury)
I'm a self-trained coder, and while I can Hello, World in many languages, I can't do Perl -> SQL. Perl I can do, SQL I can do, but I've never done both together. That's just how things are.
Give me a year to study and I'll be able to pass that test, and more. On the other hand, one of my best friends is an amazing IT guy. I love him like a brother, but I wouldn't trust him to manage a lemonade stand. Nor would 20 years of training make him any better.
I've calculated my velocity with such exquisite precision that I have no idea where I am.
I doubt Steve Jobs could code "Hello World" for an iPod if his life depended on it. That doesn't make him a bad manager. Quite the reverse, in fact. I've known too many senior managers who enjoy rolling their sleeves up and getting their hands dirty on the technological side when they should be managing their team instead. Management requires championing your team and ensuring they have the resources (both people and technology) to do the task at hand. It requires foresight and insight into the bigger picture. A manager functions as a liaison between other business units and the team, and should also be capable of strong leadership when things go wrong.
From a technical perspective, a successful manager needs to know enough to recognize which team members know what the hell they're talking about, and needs to rely on their experience and technical knowledge for guidance.
Carburetors are something that gets taught to a 15 year old student and is as such certainly within the grasp.
Perhaps you attended a high school with an auto shop class. I didn't and neither did any of my close relatives or friends in my generation. The last carburated car in the US was produced in 1991 which coincidentally was the year I graduated from high school. Every car I have ever owned has been fuel injected. Yes you can find carburators even now but mostly on the smallest and cheapest engines and they are slowly going away. Even motorcycles are headed toward fuel injection these days. The only reason I know anything about carburators is because I'm just kind of a curious geek that way and find them interesting.
Point is, knowing how a carburator works has little to do with the skill set of being a decent manager - automotive industry or otherwise. I've worked as an automotive engineer and I know this from first hand experience. ,
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."
I assume by "car guy" you mean someone with an engineering background. There are reasons that relatively few engineers end up in management. Managing a business, particularly a large one, requires a STRONG understanding of accounting and finance. A manager who doesn't understand accounting is like an engineer who doesn't understand math. Additionally managing is about people and, let's be frank, engineers tend to be rather bad with people on the whole. There are notable exceptions but we're not a demographic noted for being overly social - at least not in ways that aid in rising to the top of Fortune 500 companies.
It's NOT that engineers can't handle it (they definitely have the brainpower) but they tend not to seek it out accounting and finance training. One hypothesis is that management requires making decisions under uncertainty which doesn't appeal to the mindset of many engineers. Perhaps some of that is cultural as well. Look at how many snide "MBAs are idiots" comments you see here on slashdot. As someone who is both an engineer and an accountant I tend to laugh at those comments because most of them are absurd rants against The Man.
Just because someone handles the cash, at the level of individual sales, is no reason to think they can keep a company in the black. The two skillsets have almost no overlap.
Absolutely true but a bit of a strawman argument I think. Sales is a people and money oriented job. Being a good salesman can result in becoming a sales manager which involves a tremendous amount of finance, accounting and people management by the numbers. In other words excellent training grounds for higher management. You're right that just making a sale doesn't make one management material but neither does designing a nifty widget.
For companies that make a real product rather than service industries, coming from manufacturing or distribution ought to have just as good a chance of making good management as coming from sales or finance.
They can do make good management with the caveats that A) they have to seek out training in accounting/finance and B) they have to have or develop "people skills" since managing is mostly about people. Engineers and production people who do this rise to the top as easily as anyone else.
Just my opinion as well, but you're just as wrong.
I can just as easily point out people like Jack Welch who multiplied GE's worth by 40.
More to the point, the CEO of Ford doesn't need to know anything about cars. He only needs to know how to most effectively manage Ford. Knowing about what's under the hood has some practical value, but not anymore than him volunteering at a hospital. They're both good PR moves but won't have much influence in the big picture.
Toyota is run by automotive engineers. They do pretty good.
That attitude among our competitors is how my customer service oriented company grew so fast. You keep it up please. I have options yet to vest.
Help stamp out iliturcy.
I think you have a good point, but Perl?! I can hardly blame *anyone* for not knowing Perl! /me sits back and waits...
Many managers in IT shops might not be able to write "hello world" in C or perl, but they can do the equivalent in other languages or use Google to figure it out.
It is only at the very top, people who lead organizations come from backgrounds like Sales, Accounting, etc. These people cannot write code.
But people who write code might not know sales or accounting basics and that also can kill an organization, even a technical organization. People who are praising Bill Gates and Steve Jobs are really admiring their business acumen, which is what is needed for business success. Business basics remain same for IT and non-IT business.
O this learning! What a thing it is - William Shakespeare
A boss inside an IT-department should never, from my point of view, be non-technical. If someone is going to decide how I spend my time, they damn better know something about my work.
I see many argue that they need someone to run interference, take care of various small stuff for me, and so forth. In that case, I would call this person a secretary. Its not someone I report to - its someone that is there to help me out.
If you want to claim authority over what Im working on, you better know what Im working on, understanding it, and being a person I can go to for help / hints / and so forth if I get stuck.
Ive had non-technical managers, and Ive had technical managers. Ive never been able to work well with the non-technical ones, while the technical ones have been wonderfull.
It's been a maximum about as long as I've been alive -- people either understand technology, they don't manage, or they manage technology, they don't understand. By the logic of the moron who started this thread, Jack Welch should have never gotten the job as CEO of General Electric, as he is not an engineer. Thanks for making us look bad in front of the audience, fucko. Not A Jew
There must be a lot of managers posting to keep their jobs.
I keep hearing, the call out save my management job scare tactic of: Politics! Filter! So you can do work.
Ya well you know what? You get that anywhere you go in any job. From a lowly bus boy to a high tech consultant. REAL LIFE ENCOMPASSES EVERYTHING.
Therefore each individual needs to understand how to manage their own job and communicate.
This is not something you leave to 1 person who doesn't know jack crap about what you are doing and let him get paid 2x as much as you and take credit for your successes so he can provide a better life for his wife and kids.
If you give up power to someone, then you are only endangering yourself. Just like when we give up more power to the government, its us that gets screwed.
My advice is grow up, quit whining, get rid of your manager who likes to scream Politics! Filter!
Save that money and give it back to your team.
A group of doctors would never let a bumblefudge nobody with no knowledge of medical school manage them. A team of lawyers would never let a snot nosed wannabe try and manage them. AND WE SHOULD NOT EITHER.
What a luxury! In my past jobs people didn't notice my long hours because they left before me. They also weren't impressed - they just noticed that I was working on a problem and not getting it solved quickly.
I am still employed because this tends to happen with really hard problems that other people have given up on and I am the cavalry as far as my team is concerned.
My experience is that people who work long hours are *not* appreciated but they attract lots of flak from other whiny team members who are worried about being disadvantaged. Perhaps they are right in the long run but they have lives and there's something to be said for that.
Of course it seems to make sense, lead from the front, don't ask others to do what you won't/can't do you yourself.
But it is wrong. A manager has the task of managing, that is hard enough in itself. More importantly, it is a skill in itself. Make a programmer a manager and you most likely find yourself with a programmer who wasn't to good in the first place and a lousy manager partly because that was not what he was trained for but also because he will forever be stuck in the mindset 'in my day we did that...'
I have had plenty of bad managers who once wrote a little DB app or a VB script who somehow thought that made them experts on backoffice systems or server security. ARGH! It is as bad as letting the guy who put Apache on his desktop be in charge of the servers.
The best manager I ever had knew very little about any of the jobs he was managing, it was a web department for a large company but thanks to the company not thinking the web was going to worth anything (yes it was a telecom) the department was entirely seperate. He didn't know art, yet managed the artists, he didn't know servers, yet he managed the server guy, he didn't know coding, yet he managed me, he didn't know support, advertising etc etc. Yet he managed us all AND did a HELL of job. We sold more mobile phones then ALL other outlets combined.
So they ruined it, brought us in and clipped him and it all went to hell.
What the guy did was not so much manage as stand in the middle and direct all the traffic around him, giving each of us the resources we needed and distrubuting us to those who needed it.
If you needed input from someone, you got it. If you needed time, you got it. Because you could count on him, everyone used realistic estimates. No need to pad your estimates, because he already worked them in and if trouble happened, he managed it.
To this day I don't fully understand how he did it and haven't seen anything like him. In web development a lot of stuff is simple, but takes a long time to get everything together, an app might only take a couple of hours of development but a week for it all to happen in. Not with him. Marketing came up with an idea, quick meeting in the morning to check if it was possible, meet over lunch to check progress, end of the day, the page was up and running. Sure, simple things, rotationg banner, poll, lottery draw, product page. Nothing complex, but on the internet speed counts, if you can have that new phone promo ready before anyone else, it is your company that sells the most.
So please, don't give me a manager who ten years ago put together a 'hello world' program and thinks he can do my job. Give me a manager who can manage and then his job will be to trust me to code and my job to code and trust him to manage.
Like a F1 team. Michael Schumacher isn't a techie, he doesn't have to be, he doesn't have to know how to exchange a wheel or put petrol in a car. For that matter a F1 team manager doesn't have to have a driving license. Everyone their job and managing is a job. To bad so many such at it.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I agree that part of what makes a good if not great manager is to protect those below from the day to day, or even better yet quarter to quarter directional crap that comes from a true lack of clear vision at the top.
My firm changes upper management so often, that we have no clear direction, and often do 180 degree turns with each VP, director change.
I am thankful my manager spends his days trying to keep up with this, and allows those he manages to spend 1/2 of their time doing actual work. The other 1/2 is the BS that comes with outsourcing, economies of efficiency, drafting team charters, and attending training to keep the corporate machine protected from from any hint of being held responsible or accountable should somebody screw up.
You forgot one important thing: a major part of a managers work is to SELL and convince top managers in customer organizations to buy the services and products you and your fellow workers design. In my experience, things go wrong when the top managers promise something ha assumes is "no problem" and accepts a fixed fee on it. When the contract is signed you in development say: this is not easy because of zyz. It will take at least 100xxx hours and we need to hire xxx more people to do it. If the manager knew how things work, how complex it is and approx how long to to develop it a lot of problems like that would not occur.
I think that the truly great managers do understand a lot of what goes on and could do some of it - but only as an additional skill to the general management and people skills they have, and they will still know their own limits and have people they trust.
But a good manager doesn't need to be that good - so long as they are reasonably smart, humble and capable they don't need to know how to do all the jobs.
Great managers are very few and far between. Good managers are much easier to find (though still rarer than we'd all like).
For every expert, there is an equal and opposite expert. - Arthur C. Clarke
My best corporate experience with management was when another fellow (slightly junior to me) was hired as we grew our city's office. This was back during the Internet bubble (1999-2002) when our startup was hiring 3 to 8 people per month. Our city's office had the smallest IT team in the organization, yet we were consistently more productive - even bringing up services and solutions for other offices. We just cut through all the BS. I didn't worry about asserting my "power" over him - we just fell into a knack where we would brainstorm together. I was good at technical implementation & problem solving, while he was great at organization. We'd run through a plan, go over the dependencies, get cost justification, sell it to the CTO and then knock it out. We didn't let title or official roles hold us back and we had lots of fun. Our users were happy and management loved us. When the company started to implode (as so many Internet bubble companies did) we were some of the last to get laid off. Incidentally, I was let go before he was. It made sense - I had a much higher salary. He may have been the last one left in our city's office.
There's no place like 127.0.0.1
The best managed place I worked was an engineering company where everybody, including the top people were engineers. Managers got MBAs. Everyone understood the business and work got done.
You got me into this! You were the ideologue! I'm only a poor assassin! - Twenty evocations, Bruce Sterling
The premise may be correct if the IT Manager is only managing the IT people like a manager over the mail room would manage his/her staff.
/. readers would ever try to get a pet project into the house, or come forward with a product recommendation without any legitimate analysis ;).
I've been in the IT field for 15 years, and have only recently moved into management. In addition to my day job, I also teach technology to business students in a hybrid degree program (B.S. in management with a technology emphasis). My students have to put up with me for nine months, and during that time there is one message I try to drill into their skulls time and time again: a successful IT manager will bring to the table skills necessary to bridge that gap that often exists between IT departments/teams/vendors and the business' needs. To me, that's even more important than knowing how to code if managing a group of coders. That said, there's a second goal I have for all my students, especially those who don't have particularly technical backgrounds: you need to know enough so that you don't get completely snowed by your technical staff. While it is helpful to have first-hand knowledge for that reason, among others, it is possible to have a peer network that can help keep you from falling prey to a snow job on the average day (not that any
I use irony whenever I can, but my shirts are still wrinkled...
The first thing people get in management school (especially project management) is an ego boost. "As the manager you are the most important team member and you can manage anything." It can be true, many business people view managers as themselves plus their team so even a feeble manager is worth more than any single sub-manager, and, for known and understood fields a manager should be able to step in with no background. Managing something known, like opening a store, or starting an accounting division, or building a house does not require a manager who knows the field. He can ask a few questions and expect people to know their tasks. Managing IT is quite different. The field is still relatively young and unstructured (though there are lots of good IT management books out there, and being managed by someone who has read one or two can be relaxing, stuff sort of works out), and few HR departments can hire the right techies (HR generally can't distinguish between a guy who knows his stuff and a guy who lies or writes random acronyms; at best they just eliminate the best candidates in screening, at worst they hire clowns). A good IT manager cannot necessarily code, but he needs to know IT management, to be able to figure out who knows his job, and to know what he should not be assuming and/or messing with. Many places have a non-technical manager and a team lead, with the manager way above the team lead. This only works if the team lead has no hesitation about saying "no, we are not going to do it like that" to the manager. If the manager has free rein the project will not work out well. I have seen non-technical managers do very well. They figure out who to listen to, who to push, and who is going to be late, and they make sure everyone knows what they need to know. A good manager says "in two weeks we are going to have an issue because team X has implemented Y wrong, and Team Q will be late with interface R, what can we do to head this off?" A bad manager says something like "I heard the specs changed two weeks ago, and our interfaces with projects J through S will be different, but I only found out today."
You got me into this! You were the ideologue! I'm only a poor assassin! - Twenty evocations, Bruce Sterling
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."
While I agree that you can't manage what you don't understand, I would question whether an IT manager is supposed to be managing technology or managing people. IT staffers might say that they should be helping to manage technology, but the manager (and his upper management, up to the CIO/CTO level) might think that the IT manager is supposed to manage the people that make up the IT team. This is especially more common in larger organizations where there is a lot more established process, procedure, and administrative overhead. It's also pretty common in smaller organizations where one manager covers most or all technology areas. Having a manager with a technical background can be a benefit, but it's silly to expect that they will understand all of the technology that their team manages.
My wife and I used to have this argument all the time. She would often want me to take a day off of work just to hang out with her, or she would want me to not work during a specific weekend. I would sometimes tell her (honestly) that there was x, y, and z that had to be done and I needed to do it because nobody else knew how. She would always get upset and ask why my manager couldn't do it, and would complain that I must have an awful boss because she didn't know how to do the jobs of everyone who reported to her (my wife works in a pharmacy, so she's used to an environment where the boss knows how to do everyone's job). I never could get her to understand that IT doesn't work like that. In our IT team we had one guy who was a straight developer with some DB skills. We had another guy who was a PM with DBA skills. Then there was a Helpdesk/PC tech, a junior admin with PBX management skills, two application specialists (responsible for niche applications in the medical and financial space), and one person who did servers/routing and switching/security (me). As you can see, there's very little overlap. And our manager came out of the DB area, so she knew databases really well but had mostly passing familiarity with everything else we were responsible for. In my opinion she was a good manager, but how can someone honestly expect a manager to understand how to develop software, manage databases and projects, support PC technology, administer a PBX, manage servers, manage routers, manage switches, manage firewalls, implement best practices for security and IDM, as well as support the financial and medical applications? On top of that she would have to do her job too, which is managing people, navigating procedures and policy, and being IT's interface to the rest of the company's management. It's ridiculous to think that anyone would have those skills.
"Oh, and cancel those contracts with Gartner, Forrester, IDC, etc. You'll feel better in the morning"
.. :)
These consultancies are usually good at predicting what happened last year. And don't quote articles from Computer World to your IT staff. It tends to create contempt. Doesn't matter how many thousands of lines there are in Windows, it still sucks. And keeping all your internal documents on PowerPoint doesn't say much for your own particular knowlege of IT, does it and you know just who you are
davecb5620@gmail.com
"if the manager just really wants to be doing the techie work, that's really where his passion is, then he probably is in the wrong job"
.. :)
It would help if the non-techie IT manager didn't insist on sitting behind you and try and micro.manage you to death. Like I already know how to use the mouse, I've been doing it a long time already
davecb5620@gmail.com
The CEO doesn't know what a carburetor is. ...
So he hires person A to handle that.
But person A does not know, either.
So person A hires person B to handle that.
But person B does not know, either.
So person B hires person C to handle that.
And person C hires on a real programmer to impliment the project, then fires him and hires on a consultant for the day to impliment it and then presents the project to senior management as all his own. And the business goes slowly down the toilet.
davecb5620@gmail.com
Ha;
Given the companies that I've worked at in the past(non-enterprise), good luck with that. Those people get those jobs because they know someone high up in the company, or are sleeping with someone high up in the company. More than likely, you'll get the boot for even bringing the subject matter up.
All content in this message is copyright (c) 2008. All rights reserved. RIAA is prohibited here.
While it may help, the fact is you don't need to know how to rebuild an internal combustion engine, in order to be a good driver.
I don't agree with the details expressed in the article, but it inspires the following thoughts. There are companies where managers are not expected to understand the technical aspects of the work done by people who report to them. I have myself seen such and have heard of such managers in the company where I work. This leads to 2 serious problems: they can't tell when something needs to be done (selling your project to upper management), and they can't tell when people are doing a good job (getting you a raise). These managers rely, instead, on what others tell them. When they happen to rely on good technical people, this works out sorta OK (modulo errors in translation). When they rely on incompetent technical people, this works out very badly (either for you, the company, or both). And since they cannot tell good from bad, when it comes to technical work, their criteria for choosing who to rely on are not technically sound. That sorta thing can spiral downward very quickly.
I pass that test. I knew I had the right stuff. Now go get me a cup of coffee.
The author is a troll. A long-winded, network-funded one, true, but his "bold" statements serve only to feed his ego and perpetuate his own reputation.
For instance, if one of your employees says "this code is a horrible mess, we should take the time to refactor it now". But it would mean delaying the project.
Or the developers say "let's introduce a version control system". Sure, SVN is free to download, but it will still cost some work hours to set it up and get people introduced to it.
You, the manager, have the authority to say yes or no. But without an understanding of the subject matter, can you make a good decision? That's why I agree with Cringley that a technical manager should understand technology.
C - the footgun of programming languages
What is it with HR people on leave, anyway? When I joined a small IT firm, the HR person was efficient and personable. She cared about the employees, she protected her employer, she did a terrific job all around. When the person on leave returned, she shifted to protecting the employer exclusively, ticked off virtually everyone including the managers, then left the firm and lied about it. She was actually leaving because the CEO left and she was loyal to him, not the firm. If she had just said that, we all would have understood. But she lied. Which paled into insignificance when the company did not replace her. "We don't need a full-time HR manager." That should have been the cue for a mass exodus, but instead, 85% of us got laid off five months later.
That same 'boss' of yours IS one of the 'dipshits' you speak of... you just don't "GET IT", do you?
I.E.-> That same "valuable mgt. figure" you speak of, you ass-kisser (obviously) will sell you out in 1/2 a second FLAT, to keep his worthless unproductive ass in a job.
You get fired first, YOU, the actually PRODUCTIVE worker who creates and mends things, vs. whereas all their ass does is act as an intermediate flunky interface to the dipshits above them, to keep their job (while yours gets cut, or, outsourced) while they continue to earn 1.5x-2x YOUR PAY, mind you, for doing something a teenager could and can, do/does.
E.G.-> A baby sitter also "manages people", so - Does this justify 6-8 figure salaries, as it does on the part of mgt.?
By NO means!
Out w/ these useless deadweight "PHB's" I say... and, GO AWAY you obvious "mgt. figure" trying to masquerade as a coder/techie here!
(Spelled sideways -> you overpaid useless deadweight scam-artist, who got his job because he is related to a top shareholder or boardmember, or is related to owner(s) &/or was in the same fraternity as they).
A leader should be able to do a job of his subordinates, period, if not do it BETTER than they are - hence the term "superior". If you aren't SUPERIOR to your subordinates @ the tasks they do, what use are mgt. of that 'ilk'?
None.
Hiring someone to oversee 'subordinates/inferiors', especially one that cannot even begin to do the job of said 'subordinate/inferior', is human stupidity in & of itself. After all - they're SUPPOSED to be "superiors", right?
Labor Unions.
None of those guys had to deal with the complexity that modern day car companies face. From safety regulations/testing, to fuel economy, to labor unions, to pensions, etc, etc. The list is endless.
Keep those suddenoutburstofcommonsense going.
Maybe they'll snowball.
Wouldn't that be nice?
The "Civilized World" jumped the shark ca. 1973.
Managerial.
If the rest of the company is using PHP and you're using Java, that's a problem for management to solve. I'm surprised anyone would think that a programmer can just pick whatever tool and start work.
When my organization starts a major project, part of the fundamental planning involves the set of tools the architects will use to create the environment the developers will work in.
In the Java world, this would be selecting the application server (JBoss, WebSphere, etc) and planing how to use those facilities to make the application secure and usable, and deciding which available (in our organization) DB platform would be best, etc. Struts, JBoss, Tomcat and Apache are all tools that architects and managers select, not programmers.
In the ColdFusion world (Dreamweaver is just an editor, like Eclipse or Notepad, you probably could have used Dreamweaver to code PHP against MySQL) security and navigation can be addressed with various frameworks or you can roll you own.
Yahoo uses Javascript a lot, and released a framework for that tool called EXT.
There are a million tools, and management's role is to select a set of tools for the organization. Anyone who doesn't understand that will work alone forever for tiny organizations who won't understand what he's doing. Because he won't be able to explain it to anyone.
Does everyone have to be the super techno geek to get respect? There are all types of people in this world, some can sing, some can dance, some can sing AND dance. Some people can program...
Perhaps the issue is that money is drying up. And we can circle the drain by reducing expenses (read; People), or we can address the bad trade policies that force us to go to the bottom. We aren't going to win that race.
America needs to push to do great things again, and to do that we need to raise all boats -- not just the one yacht.
Not respecting different skills is going to make everyone miserable. Imagine your irascible super geek, calling your customer an idiot because they want an LCD screen that supports JAVA.
>>"ad space available -- low rates!!!"
Because most of them seem to manage their bosses.
The eponymous PHB manages people.
This is not a good thing.
If a manger has no technical ability AND isn't willing to listen to and accede to the wisdom of their employees who DO, then although this may be a "manager of people", they definitely SHOULD be sacked.
And on to the whole "cutting corners" thing, you can last months or years without a C*O. Without workers, you last until inventory is gone.
So who do you get rid of first?
In my history as an IT worker, 10+ years now, I have found that a good manager is just as mentioned before, a filter..... My current situation, is a bad manager....he calls (almost never in the office, btw) at 4:45pm on a Friday and wants us to have a server built and every piece of hardware documented before we leave. My response, f*ck him, we have stuff to get prepped for our ALREADY scheduled engagements Monday morning. I am not going to let our other clients suffer because dickwad wants to step in at random intervals and try and micromanage things..... billing at $105.00/hr, and paying a total of $56,000/yr in salaries, with the techs billing between 70-80/hrs a month each, him coming in and complaining that it was a "tight month" tells me that captain numbnuts has no frikkin' clue how to manage money, let alone employees. This is why even though the clients are supposed to call him when they need us, they never do....He takes an average of 3 days to return their call, or he just calls us and asks us to call them.
Sorry, needed to vent.
You state without reasoning that a CEO MUST know accounting and so forth but not engineering.
Why?
Why does he need to know what the CFO knows but doesn't need to know what the CTO knows?
Because accounting is all you're taught in an MBA?
That is a perfect example. Who uses carburetors anymore? =D
-Z
The reality of the situation is pretty bleak on both fronts. There is all sorts of bad IT management going on, and ignorance of the subject is just one facet. If I were to pick an underqualification, ignorance is probably the least harmful of the many I have endured.
The worst by far is sucking vendor peepee. The 'Managers' and 'Directors' who obtain their direction by meeting with a vendor whenever they have a major project, leading to product focus rather than problem focus on every issue.
That is followed closely by the "Working Manager" who got promoted into a position of management while retaining all of their prior obligations, leaving them neither the experience or the time to properly attend to their job as a manager.
Worse, they then become a technical authority rather than what they should be as a mentor and manager. Staff meetings devolve into decisions being made by them for things that should be outside their focus. It's really the worst of both worlds.
I have had ignorant managers who are completely hands off, and really that was a fairly pleasant operating environment. So long as I had visibility in the Execusphere and could sell my own ideas, it was all good.
Here's the problem though. If we fired all the IT management who are incompetent, we'd have to hire more. Do you want to interview them? Me either. How about we just continue to work around the pointy haired bosses, the way we are doing already.
It's just the way of things, apparently.
"No good deed goes unpunished"
So you think the CTO/CIO of a Fortune 100 company should be able to program in any of the 18+ languages in use at Big Corp, design a chip at the circuit level, reformulate the ink in their new printer line, and design an aesthetically pleasing case to wrap it all together?
I don't think you've ever had a real job, sorry.
But good luck with your theories. I find them fascinating and would like to subscribe to your newsletter!
You state without reasoning that a CEO MUST know accounting and so forth but not engineering. Why?
Because accounting is the language of business in the exact same way math is the language of engineering. Financial statements are what tells managers how a business is performing, where it is strong and where it is weak. If a manager cannot speak the "language" of finance he cannot possibly successfully manage a company. This includes managing the engineers in a company. The skill set of a CEO MUST include finance but only SHOULD include engineering. His job isn't to design the product, his job is to raise capital and to manage the company. Financial statements are the tool that permits this.
Bear in mind I AM an engineer and proudly so. Be learning about accounting was one of the most useful things I ever did. Made it much easier for me to justify what I want to do and get the resources to do it.
Why does he need to know what the CFO knows but doesn't need to know what the CTO knows?
Point out to me where I ever said that. The CEO needs to be able to communicate with and understand all his employees. But that has nothing to do with what I have been saying.
Because accounting is all you're taught in an MBA?
Hardly. Examine the curriculum of an MBA program before saying something so stupid. Operations, marketing, sales, data analytics, strategy, leadership, and of course accounting and finance are all taught. But like I said, accounting is the language of business. If you can't "speak" it you will be an ineffective manager because you won't have a clue as to what is going on. You might as well try to manage General Electric while speaking only Swahili.
a good manager is the one who can hire *and* keep the best team possible for a job. someone who managed me once told me that; he was a pretty cool kid back in his day too; having done a fair bit of coding himself. probably the best guy i ever worked for :)
It managers that lacks any technical skills are easily gullible and easily fall for the latest buzzwords. Those are the ones who run the lemming race instead of sitting back and take it easy while the other ones makes all the mistakes. There are managers that can sniff a scam miles away without any knowledge in the subject but those are very few in IT. Perhaps because its a pretty new field.
Cringely draws it a bit to long to drive the point home, you cant be a succesful manager if you dont have good knowledge in what you manage. Just as you need to know economics to be a manager in the banking sector you do need to know a harddrive from a router to be a good manager in IT.
HTTP/1.1 400
Yeah I agree, a good middle manager deserves their pay. And they don't need to know how to code anymore than a manager in charge of construction needs to know the details on how to make cement. Sure it does help give you some credibility (and cuts down the "learning what your team can do" time), BUT at the end of the day, you're a manager.
:).
I am currently not a manager. When I was a coder I didn't need my managers to know how to code. They just need to know how to manage.
Trouble is there are lots of managers who don't really know how to manage stuff.
For example: if you are a manager and your coders give you estimates for completing their tasks, you do NOT take the estimates and pass them straight to your boss!
Your bosses don't really care about how long it takes. They want to know _when_. Then they can make PR announcements, make promises to customers, creditors etc.
So if you pass your teams estimates straight to your boss you are NOT doing your job. And that is one less reason for your boss to have you around.
You are supposed to figure out which coders tend to overestimate and which underestimate (Oh that'll take 5 minutes... yeah right and 3 weeks of rewriting and debugging before it's finally really stable for production), and which don't have a clue. If you have any brains and people skills, you can figure that out without even knowing how to code a single line.
Then you can figure out how much time it'll actually take them. Then you also try to figure out what OTHER stuff your bosses will want your team to do in the future, and then after factoring all that in with a margin of safety, you tell your bosses _when_.
If you do that well, and your bosses have a clue, they will start trusting you, and not have to make up stuff on their own. And your team will start trusting you as well.
I have seen managers add stuff for their team to be done "Immediately" and then they expect that the "internal" deadlines for the other stuff to not be changed. They have often screwed up and told their bosses it will be done by "internal deadline", so there is no spare capacity.
When you do stuff like that, if your team has a clue, they'll stop telling you the truth and start padding their estimates. This means lower productivity - stuff takes longer to do.
And that is one of the reasons why a team under a good manager can be so much more productive than a "average" one.
A good coder can be magnitudes more productive than a poor one, it is not so different for a team under a good manager.
You as a manager can try to blame your boss for giving you 20% extra work and not being happy that you want to change the deadline. But hey, if it's just 20%, it's YOUR fault. Remember, you're supposed to _manage_ stuff. In contrast if it's > 100% more work, the average CEO isn't that stupid - they know something has got to give, if they still want you to take the fall for it, you don't really want to continue working for them.
Being a middle manager means you have to deal with crap from both top and bottom, and try to not let it cause big problems
For example, my contract just ended with AT&T. When I was brought on as a contractor, the rule was 3 years, and out for a while. After the buyout, er, merger, it became two years. My director had already grandfathered in two people, and told me not to worry.
Meanwhile, HR had changed the rules, so instead of asking for a contract extension 45 days before the end of contract, it became two weeks.
I've heard our VP talking about cost containment. You'd think that they'd hire, rather than contract, since then you don't pay loading. File this under the heading of "bite your nose to spite your face", but the biting isn't noticed till next quarter (the far future).
Then, last Tuesday, HR, in the name of "cost containment", blindsided my director, deciding they knew better than he did what he needed, and told him they would not renew my contract. That was TWO DAYS NOTICE, not even the usual 14 days.
No. Upper management's part of it; HR is the other part.
mark, Unix/Linux sysadmin, software developer (C/C++, perl), web development
The only way your kind understands ANYTHING (buzzwords for industry only @ most/best), is via the words of others such as newsletters - without these to show you some new 'buzzwords'? You're clueless.
Seen a bunch like you, come & go, & that is the reason why - it shows thru pretty quickly you have NO saavy in tech fields & quite often make HUGE costly mistakes due to lack of understanding of tech fields period.
E.G.=> Calculating the par value of a stock doth not a tech mgt. person make, you fool. Especially in tech oriented fields.
Also, since you asked - The CEO of AMD is just the kind of guy you asked about, he's done the job of IC design for 19 yrs. iirc, and can do the job, & is perfect to lead a company that is "tech oriented", & mainly because he has background in it, hands-on.
(Which of course, seems 'impossible' to you, like somekind of superman... mainly, because they do exist, & aren't lazy 'faked it till they make it' mgt. "superiors" like yourself, you fraud mgt. wannabe tech types).
Incidentally?
I have been @ this field in both mgt. & actual hands on work for decades thru the strata of field/bench tech -> network tech -> network administrator -> Programmer -> Programmer/Analyst -> Software Engineer + even a 2++ yr. chain leading (255 units nationwide) manager in loss prevention security also. I've done the job @ those levels & all thru them, inclusive of possessing both an Associates Comp. Sci. degree AND my Bachelors in Business Administration (MIS concentration)... have you? Doubt it!
Yes: Guys like me must seem like "superman" to a lazy fake like yourself though - you know, the "lie/cheat/steal" type like yourself, who have their jobs because "they know the right people" b.s. (but, couldn't do the jobs of their 'subordinates' @ nearly any level).
In tech fields? Technically oriented leadership IS KEY - you can't 'fool' or misinform those who have actually BEEN there doing the job, & the hands-on experienced mgt. person makes solid estimates and is also yet another pair of hands that CAN & HAVE done the job before, especially useful during deadline/cruch time periods looming.
I just got fired a nontechnical manager and a nontechical guy who was put in as Sr Software Manager or some title like that. They were new to the company, while I had a long standing there (not to mention, I was very respected by my colleagues).
This new manager came yelling and screaming at me.
"WHAT IS THIS LINUX THING!" and I calmly and quietly told him that it was the desktop environment that the engineers use -- since we *do embedded Linux development*. He continued yelling at me asking "WHO USES THIS THING?!". I told him "everyone here but you and the new manager". People hear him in the office (since he was yelling) and the word got around that he was incompetent.
A few days later I was fired by the new manager. He said "it just wasn't working out" even though "you are a very smart person and you are very good at what you do". It worked out for me since I got a better job just days later,
but still --
I recommend that you do someone's job before you manage them, or at least know what your company does before you start yelling at people. ;-)
It isn't a surprise that the new hires that they brought in don't know what the company does either, and everyone misses me. :)
....you mean that incompetent?
that was a common practice a few years back. I still remember when I was working for BBN/Planet, e-mail announcement: we just hired a new manager. Her background: something related to musical education based on Carl Orff methods. ditto for project leaders. I remember working on traffic shaping for Frame Relay, I had to report the progress to the project leader. He had no clue about either Frame Relay, nor traffic shaping, nothing in general. In my short stunt at Lotus/IBM, hiring of non-technical manager was pretty much standard. Not understanding anything, their methods of management was screaming and intimidation. Well, I'm no longer involved in IT/Datacom, but my experience is that that field used to attract very strange "we're only here for money" people.
While any one can manage a group that has no problems or issues, it might not be a good idea or true when issues arise or problems occur. What happens when a group of underlings pick on someone that is an asset to the company but people do not like the person personally; they want him/her gone. How would a manage figure this out if they are using technical attacks on this person that the manager can out follow; office politics.
The worst part of this practice is when a none techie has to make tech issues and has several ideas to choose from. If you do not understand the value of the ideas presented then the person will not be able to make the decision based on reason or understand but some under line feeling or other form of decision making. If it is not a good idea then the company as a hole eats the cost of the poor decision making; not just the person that made the decision.
While yes, managers do need to be able to manage people they also need to be able to understand what they are managing or have an understanding of the area that this person is managing in. Finding a persona that can be balanced like this is hard, and finding the balance point on how much knowledge this person should need can be argue over for sometime. I believe that this was why companies use to promote people from inside, working up the leader, in the past. However, for good reason or not the idea of working up the leader is no longer practiced in most US businesses.
I absolutely hate when techies think that management is unimportant. Most techs have NO IDEA how to relate to senior management of a company. And vice versa, senior management have no idea how to relate to techies. Try asking a help desk analyst to defend a $50MM budget to an executive committee and see how that turns out.
The function of an IT manager is not to manage IT, it is to manage the people, projects, resources, and workload. IT managers do not need to be technically compentant, they need to be effictive and insightful leaders, willing to listen to both the IT people and the customers they serve.
An IT Manager can be completely technically incompentent, as long has he can trust his technical people, and as long as the IT customer is honest.
This applies only to the vast majority of business where IT is the process, not the object, of the business model. In those companies that IT is their business, then yes, the IT manager needs to be both technically compentant and IT wise. In other words, the Insurance IT manager doesn't need a great deal of understanding of IT, but the IT manager of a SAN vendor SHOULD be very well versed in tech.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
I guess there is now another level in the old adage - Those who can do. Those who can't teach. Those who can't teach write text books. And now, those that can't write text books, write articles for magazines. I doubt if RXC has ever "managed" a production IT shop. I agree that most IT shops could/should save money at the top. Because they are not good managers, not because they haven't kept up with specific tech skills. All to often a good techy is promoted to a management position, without the skills or training to be a good manager. And that doesn't count those that do not have enough of a grasp on basic business operations to recommend a solution that the organization needs (instead of the hottest skill in demand on Monster.com)
RXC giving advice about management is like a priest giving advice about birth control. He may have studied the subject, but he lacks the credibility that comes from personal experience.
If all other things are equal, wouldn't it be better to have a manager that was also technically competent?
I can't see how in depth knowledge of the problem field could ever be seen as a liability for a manager, assuming they were competent in the other aspects of management.
Cringely is so full of shit it's coming out his ears. I used to think the same way - how can these people manage when they don't understand the details? Then I got involved at a place with too much management and too many who at least think they understand. They micromanage the crap out of everything down to the smallest technical detail. Technical decisions that would have been made amongst developers, engineers, and sysadmins at my old organization are made by management. If I could go back to the old organization where managers weren't so technical, I would. The key for managers who don't understand all the technology is to simply trust their technologists. When they do that, they succeed.
His comment about all those problems an IT boss should be able to solve was followed by this comment:
I have to agree with him. A technical manager who can't figure out something that is trivially found with Google is no better than a mechanic who can only fix cars that are old enough to have a carburetor.
They're not managing CODE, they're managing PEOPLE and PROJECTS.
Any sufficiently simple magic can be passed off as mere advanced technology.
My company just fired my "IT Executive" boss in favor of hiring a developer turned consultant turned IT manager. The new guy started today, and it already feels like we've got a better plan (our previous plan was to not have a plan).
That stated: "Autonomy and decision making are keys to retaining excellent staff. Being micromanaged by ones boss is the surest way to lose talented people
My Xbox Live Gamer Card
Unfortunately the shake and bake management schools of today almost all teach that "A good manager can manage anything". I see how this can hold true in some corporate environments and most of the military. But specialized is specialized and I feel there are many exceptions in the IT/MIS field.