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.
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
Sorry Slashbots but people skills are more important than tech skills and always will be.
I would like to see you back up your implication that those two skill sets are mutually exclusive.
But without Pure managers in IT, who would make facial expressions during Scrums? Where would we get our positive social affirmation from?
BBH
I would like to see you back up your implication that those two skill sets are mutually exclusive.
you're reading slashdot and expect to see a better example of the exclusivity of those 2 skill sets?!
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
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?
You could argue that people who read slashdot are more inclined to only have technical skills without people skills, but that still doesn't prove that the two don't exist in individuals elsewhere. It's true that the two set's CAN be exclusive, but that doesn't mean they HAVE to be, and (inserting useless anecdotal evidence here) I have know a good many people (bosses, mentors) who prove that those two can coexist within one mind. If you haven't encountered this, then you need to leave your computer for a while. Meet people, not usernames.
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.
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!
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.
...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.
...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
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 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.
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.
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?
Wanna trade? :-D
I don't believe in time. It's a grand conspiracy designed to sell watches.
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.
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
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
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 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.
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.
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.
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.
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!!!"
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"
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 :)
There are implications to the manager who only knows management. For one, management requires no greater education, intelligence, or skill than any other professional field. The entire justification for paying managers more is based on having to know management and have a good understanding of the work they manage. If that's no longer true, adjust the management payscale to cut costs.
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
....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.
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.
"If the rest of the company is using PHP and you're using Java, that's a problem for management to solve."
Look at the parent poster again. He was told "to go redo the website using whatever technology and features I thought I needed to make it excellent". Then about 50% of the time spent, he was told otherwise.
Certainly a company using PHP and one project using Java could be a "management problem". When management is not able to properly define the problem's realm and its constraints and properly communicate them to their "doers", then it's not a "management problem" but "management is the problem".
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.
They're not managing CODE, they're managing PEOPLE and PROJECTS.
Any sufficiently simple magic can be passed off as mere advanced technology.
In others, it's seen as a good thing - face time as a measure of productivity and devotion to the company. People ... not -forced- exactly, but certainly pressured and co-erced into putting in hours above and beyond their contract.
Thing is, Henry T. Ford found out ... some years ago ... that moving employees from 6x12 hour day working week, to 5x8hour day working week, had no difference on productivity, and huge benefits for morale and motiviation.
The key problem is this (as the whole discussion). In the absence of a better understanding of what someone is doing, it's often easier to fall into the trap of assuming more hours = more work. Particularly in 'white collar' jobs, that's just not the case.
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).
Your explanation is something I hear far more often than the idea that long hours are good.
It's ok if you do want you want and I do what I want and we get what we are looking for - you some free time and me some advancement.
This is all just my personal opinion.
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.