Fire Your IT Boss 509
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 don't know if I fully agree with that (Score:5, Insightful)
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..)
Common Sense? (Score:2, Insightful)
How it is (Score:5, Insightful)
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.
Writing hello world is not a manager job (Score:5, Insightful)
Re:I don't know if I fully agree with that (Score:5, Insightful)
Except, I'm not there to provide them with that info. Not really. I'm there to provide them with "this is how long it will take me" or "this is how long I think it should take". That's not necessarily the same thing as how long it should take, what it should cost, etc.
In order to manage me and my fellow employees, as well as the time and money we are spending, they need to have an understanding external to us.
Re:I don't know if I fully agree with that (Score:5, Insightful)
(timing, resource allocation, cost, etc..)
Yes, but the people who actually see those resources and money at work have a *much* better better idea where they actually go. A manager who has a history lower down will make better choices, instead of just throwing money at something, they might throw it at the project, but aim it a bit better.
Re:I don't know if I fully agree with that (Score:5, Insightful)
A manager who does not grasp at least the fundamentals of the job(s) that the people under him/her do may not believe or understand subordinates when they give estimates of time/manpower/risks/benefits/etc.
Someone who doesn't have a bit of knowledge of coding is more likely to say "yeah yeah, you can do that in half the time or I can hire this guy in India who says he can".
Re:Yes you can (Score:3, Insightful)
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?!
Re:Writing hello world is not a manager job (Score:4, Insightful)
As long as the communication's right, a manager doen't need the technical skills.
I don't agree with this assessment. (Score:5, Insightful)
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?
IT boss=human filter for stupidity @ higher levels (Score:5, Insightful)
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.
Re:I don't agree with this assessment. (Score:3, Insightful)
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.
While I agree, the ability of a manager to understand what is going on at some level is in fact important, depending on what you are developing. The key skill of a manager is knowing how to assess people, their skills, their talents, their personalities, who meshes with whom, who is incompetent, who is not, who works with whom... the ability to separate truth from illusions of truth
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.
While I agree with you on the micro-management thing, the whole point is to keep the team on track and not give into feature creep or pet projects, or "this code should be done like that because it's more beautiful, efficient, etc but it will require a reworking of x/y/z" beauty and function sometimes have something in common, but often times it's irrelevant to the task at hand.
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.
IT managers ideally need enough understanding of what they are dealing with to make effective decisions, the fact is that things change too quickly too often and the manager doesn't have enough time. Hence managers SHOULD be former (reformed) coders or from professions who's skills cross pollinate, who have "let go" of their past profession, i.e. are laid back, no longer longer concerned about micromanaging others work, code, etc. But who is able to separate truth from illusions of truth, that is, know what the hell is going on in the overview.
Re:I don't know if I fully agree with that (Score:5, Insightful)
I haven't RTFA (natch), but from the summary I would agree with you that this argument is wrong. The manager of some programmers does not need to be able to write "Hello World." I've had a very good manager that couldn't do that, but she was very good at keeping track of what impacted on what and keeping an eye on our progress. I do agree that the valuation of managers vs. those that actually do the work is often the wrong way round and cuts should follow accordingly. I often think the better way to consider a manager is as an assistant to those who do the actual work, taking care of the peripheral details of a project allowing the important people to do the actual work. But the reasoning in this article, along the lines of whether the manager can do the programmers job, is *not* the place to start.
Re:Writing hello world is not a manager job (Score:5, Insightful)
No, often a manager also manages resources, makes decisions as to future projects and product directions, etc.
A certain amount of technical knowledge is required. Either that, or the manager has to be willing to listen to and trust those who are knowledgeable below them.
I've seen good managers who were technical and listened, good managers who were technical and didn't listen as often, and good managers who were nontechnical but knew who to get reliable information from. However, I've never seen a good technical manager who lacked the technical background *AND* didn't listen to underlings.
What does it mean to "manage people"? (Score:2, Insightful)
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.
As an IT manager... (Score:5, Insightful)
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
Re:I totally disagree (Score:2, Insightful)
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).
THANK YOU.
My current boss fits that most exactly. To judge from his behavior, he used to be a hotshot coder at some point, but to further that judgement from his actual knowledge of coding, that era is long past.
When he gets news from us that he doesn't like, he insists on debugging the issue with us. I don't mind extra eyes on a problem... I frequently bounce problems off my teammates to see what other angles they might come up with... but in my boss' case, it's worse than useless. It's rehashing of ideas we've already long since canned. The guy's just not a coder any more, and fueling his ego as a still-savvy techie just slows us all down.
They pay us to be experts at what we do. I wish to hell he'd trust us to be what he pays us for and stick to what they pay him for. We've delivered time and again. The results would be better if we didn't have to babysit him, and morale would be far better.
Re:How it is (Score:5, Insightful)
I do like the Starship Troopers attitude though.
Re:How it is (Score:5, Insightful)
Re:I don't know if I fully agree with that (Score:4, Insightful)
Re:Fat chance of that happening... (Score:2, Insightful)
Most developers, myself included, don't have the skills to run their own company. We're as out of place in the business world as Donald Trump would be with a C++ compiler.
Worse, those developers who do have the skills to run their own company, if they do so, will eventually be viewed by those working for them just as they used to view their bosses. Or they'll just go bankrupt. There's a reason it's the same thing everywhere you go, and that's because that's what works in the business world.
Re:IT boss=human filter for stupidity @ higher lev (Score:2, Insightful)
Wish I had mod points. Instead, I'll use my low-low ID to say that you're absolutely correct.
Generic problem (Score:2, Insightful)
[...] 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.
Re:How it is (Score:1, Insightful)
You make some good points, but ultimately I disagree.
I have several customers that need everything from C to HTML to Windows support to graphic design. I can configure the servers, network storage, perl to query Oracle, PHP to print reports from MySQL... But when there's something I don't know how to do, I hire someone. Though I'm a reasonably intelligent person (or so I think), there's no way that I can be good at everything.
Plus, I couldn't stand working for someone who thinks he/she can do my job as well as I can. This is insulting on many levels.
I'm not saying that they should not have a clue about what I do, but I was hired for my expertise. The moment my manager has as much competence in what I do then I should get another job.
Re:Common Sense? (Score:1, Insightful)
I think they key is in an understanding of what is involved, not necessarily the ability to accomplish it. Being a good manager requires good management skills and an understanding of all the pieces involved in the process. This includes understanding time constraints, cost/resource/benefit ratios and how to balance these effectively.
It doesn't require a degree in coding but decent programmers understand these ratios. Mixing good management and a fundamental understanding of the process leads ANY manager to success. Most middle managers I have met are elevated due to charisma and not management prowess. A truly good manager can really learn the core fundamentals of ANY discipline.
Re:I don't know if I fully agree with that (Score:5, Insightful)
You are exactly right. I have worked with numerous execs who weren't very technical, but if they are doing their jobs well and respect my opinions then they are perfectly fine in their roles.
Years ago, at one particular job, I was the corporate network admin. My job was to maintain the network and to a lesser extent, help employees with computer problems. Anyhow, there was a time when the head of our marketing department had an issue that, by my rough estimation, I would be unable to resolve without an hours worth of work. When I told her this, she starting yelling and screaming at me, to which I basically told her to fuck off. She threatened to issue a complaint to the CIO since she had no authority over me. All I had to do was tell the CIO what had happened and he went over and chewed her out. It was a perfect example of two management types who both lacked the technical knowledge to assess the problem, yet one chose to berate me while the other chose to trust me.
Re:I don't know if I fully agree with that (Score:4, Insightful)
Point is, managers manage people.
No, managers administer a business function.
Some managers called 'supervisors' or HR Directors do perform primarily functions in the management of some people. Most manager posts perform much broader functions, and dealing with the people hired to assist in performing a function of the business within their 'jurisdiction' is only part of the job.
For example, the manager of finance is responsible for manging the business finances. They had better know about financial concepts like what balance sheets are, how income statements are made, taxes, credit cards, etc, in high detail. Even if they have subordinates responsible for dealing with the direct work in dealing with these things. This is just the same as an IT manager knowing what programming languages are like and being able to understand high-level design documents, program flow chart, etc.
A facility manager would be responsible for everything that goes into maintaining a certain facility.
In a large enough business, even an IT-related business, there are managers who don't need to know about technology or details of coding.
But for a manager to be effective they must have appropriate knowledge of the domain they are managing.
An IT manager that manages coders directly needs to have knowledge of coding. Individual coders are not likely to be able to give good timelines for a project that needs timelines. Unless they are managers of their project, it's not their job or their ability to provide such estimate.
Adding up the times individual coders think is no good. The IT manager needs to have the knowledge, or needs to hire or delegate to someone to manage the coders and take all responsibilities who does have that knowledge and ability to work on getting a rough estimate.
IT managers will often be responsible for making purchase decisions; approving requests from departments for computers, or for software. An IT manager cannot make good decisions about what computer equipment to allow to be purchased on their IT budget without clear understanding of the equipment and what the usage will be.
It will be difficult for IT managers to allocate resources in a manner that will allow completion of projects if they lack sufficient understanding to know when a request is reasonable, when a request is already stripped down, or when a request is exhorbitant, and it's better to authorize only a cheaper alternative.
Also, IT managers will often be involved in setting policy for the use of technology business-wide. It will be difficult for them to set or approve reasonable usage and internal IT support policy if they do not understand the technology.
Moreover, it will be difficult for an IT manager to hire competent subordinates, rather than candidates who are good at bluffing their way through an interview.
A good IT manager should know enough to be able to quiz candidates and discuss technical issues with clear understanding.
Re:I don't know if I fully agree with that (Score:5, Insightful)
It's not so much about slacking as it is about incompetence. Someone might work really hard but produce far worse results than someone who works half as hard, but has talent and pride.
A manager without the skills is likely to keep the former and lay off the latter.
And what does it help if your project completes on time, if it's seriously b0rken? Then there will be months of band-aiding, followed by a declaration that it was a success, no matter how horrible it was. And you end up with five times as many people in the support organization (and managers to oversee them) because you didn't understand enough of the gritty details to ensure that the project got done right. And as a CTO, you'll get a bonus, while the lower level people who have to support the steaming pile of technology get the shaft. Repeatedly, to Ravel's Bolero.
Re:How it is (Score:3, Insightful)
To run it all? It's not feasible. But to step in for a few days and take the help requests, or help the company limp along when a critical employee steps in front of a bus? That is a good manager's job. The idea that a manager is a purely 'people person' and that this makes them somehow better able to manage if they do _not_ have the technical skills is a fallacy of a lot of empire-building little bureaucrats.
I don't expect a hospital supervisor to do heart surgery, but I do expect them to be able to do CPR and apply pressure to a bleeding wound. And I expect my supervisor to be able to actually _read_ my reports, and understand why we're using a central source control system rather than a lot of source tarballs.
Re:I don't know if I fully agree with that (Score:4, Insightful)
Someone who deals with time and money being spent sounds more like a secretary than a manager.
A manager is someone who is experienced, has detailed understanding + knowledge, and is able to make good decisions.
It's this communicating and making effective decisions that are so key.
Such that the responsibility of a manager is to make good decisions in the areas they are familiar with, and to have enough knowledge to know when they need help make a decision or fulfill a function, and in that case, to find someone who will make a sound decision or fulfill a function.
The creation of subordinate positions is just an iterative step of an endless loop of MakeGoodDecision([situation]) functions.
At some point, the CEO's MakeGoodDecision([...]) function return was MakeGoodDecision(["Need help with IT"]) => Hire an IT manager & MakeGoodDecision([...]) ...
Re:I don't know if I fully agree with that (Score:5, Insightful)
Management is a similar situation. The manager is there to make sure that if he wants to outsource part to India, that the product has clear delineations and interfaces so the work can be split up. A manager who learned these lessons in 1980 doing RPG is the same as a manager who learned these lessons from his old boss at IBM who learned them writing COBOL in 1971, who is the same as a manager who just helped Google launch a new BETA product. His architect will tell him how to split it up, but the manager will be the one deciding what the important choices are, getting the right questions in front of the right people, and helping those who know work towards the right solution.
Re:I don't know if I fully agree with that (Score:5, Insightful)
The very best manager you could ever have manages the people above him, not the people below him.
Re:I don't know if I fully agree with that (Score:5, Insightful)
Just my opinion, but you are dead wrong. The CEO of a large company must know the basics about that company's main products. I would not expect the CEO of Ford to be able to understand all the finicky details about Ford cars. However I would expect him to be able to open up the hood of any Ford car coming off the assembly line and point out all the relevant parts and roughly what they're responsible for.
A CEO must rely on subordinates to handle details, but the CEO himself must know enough about his products to be able to make some independent checks and decisions.
Take this back into the computer world. Apple and Microsoft are great examples of successful computer companies led by people who, while not experts, know computing pretty well. Gates may not be the best programmer in the world but he certainly knows his stuff. Jobs may not be out there writing code but he understands the technologies to a much higher degree than the hypothetical scenario you describe with Ford. Now take a contrary example, say, Hewlett Packard. HP went way downhill under the management of Carly Fiorina, someone with a great deal of "management" experience but who, as far as I know, is not technically knowledgeable.
Re:I don't know if I fully agree with that (Score:1, Insightful)
I've been around software companies big and small for over 20 years. Most managers I've seen have been mediocre, but some have been very good, even outstanding. But there is no single mold that defines a successful technology executive or manager. Ideally, they would have excellent people skills, excellent business skills, have a deep grasp of the underlying technology, and keep current with the latest technical trends. And they should be a self-starter and willing to work hard, not slack off when their boss was out of the office. Generally it is hard to find someone with all of these attributes.
But even if you found somebody who had all that, that person might be a failure as an executive or manager. A successful executive is focused on results. What they personally lack can be compensated for in whom they hire. But if they don't care enough about results, then their whole organization goes downhill. As for what "results" mean, Jack Welch had it right: anybody can manage short-term, and anybody can manage long-term. The trick is for a manager to focus on delivering the short-term milestones over the next year AND be building the organization and brand for the long term. And that's hard to do, even for someone who has a resume that will brings approving nods all around when their hire is announced to the troops. From my experience, most executives and managers are concerned almost exclusively with what happens over the next 12 months or less. And that's wrong.
Re:I don't know if I fully agree with that (Score:3, Insightful)
I actually do.
An IT manager doesn't need to be able to program but he does need to understand proper coding practices.
If not he cant see whats behind programming and the nature behind maintaining a strong and well groomed source base then he truly doesn't understand what he's managing.
How can an IT manager determine if the new person they are hiring can actually program up to the particular standard the company needs?
The manager could of just fired the best programmer and kept all the spaghettio's simply because the spegettio programmers get the job done quicker. (I see this happen more then i'd like to admit)
You don't need to know the language, and "hello world" isn't going to help them, but if an IT manager who cant fathom the "processes" i.e the application design and whats involved then he shouldn't be there.
I agree with the "vibe" of the article but i don't agree with the explanation. There are far too many IT managers out there with no idea, plenty of them will go and hire a bunch of indans to replace a dev team, and literally destroy the companies well kept code base simply to make him look good at the end of the day in the eyes of his directors, in the short term he fixes problem and moves on but the trail of destruction he leaves behind him is someone else's program.
Re:I don't know if I fully agree with that (Score:5, Insightful)
I'd like to see them go back to being run by a "car guy."
A 'car guy' is not necessarily good at running a business.
I guess it depends on what you mean by a "car guy". Running Ford is a very complex job - you have to make huge macro decisions years in advance of the end effect. For example, you have to decide all the details of all the cars you are producing today probably eighteen months or two years in advance. How many of each model to produce, design decisions for each car, etc. A "car guy" has a marginally better chance of creating an organization that will design a car that will be a "good car". The problem is that the CEO really has to delegate almost all of those decisions to the mid-level executives in the design and production groups. The CEO can work with other senior execs and the board of directors to say "next year, we will make a good profit if we produce X of model A, Y of model B and Z of model C and sell them at appropriate profit levels." Its up to others in the company to make sure that the cars are produced, that the dessigns are appealing and so on. For what Cringley is talking about the auto industry is really a terrible example. The macro factors are so huge compared to most smaller tech companies. Care are a better comparison for either large tech companies like IBM or for tech work in "non-tech" industries.
Re:I don't know if I fully agree with that (Score:3, Insightful)
I think people from a engineering background like this guy [wikipedia.org] are the very best at running any business, especially high-tech businesses like Automobiles. Just for some reason, people from a sales/finance background are the best at getting on top of an established organization. This is because the sales guys learn politics from an early age and the finance guys hold the purse strings.
Re:I don't know if I fully agree with that (Score:4, Insightful)
You are not describing a technical manager, you are describing a *bad* manager.
Good managers will not get in your way, bad ones will. The only difference between technical and non-technical is the tools they use.
I think that that is the problem we had. (Score:5, Insightful)
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.
Re:I don't know if I fully agree with that (Score:5, Insightful)
Agree agree agree. I've had a good time working at utterly incompetent workplaces because the bosses 2-3 levels up from me shielded me from the idiocy above me. They deserved their perks, believe me.
Re:I don't know if I fully agree with that (Score:5, Insightful)
Exactly. As someone who has moved up through the IT organization and manages a large group, I spend FAR more time managing my boss and his boss than my staff. They get their assignments, with enough authority to get them done and responsibility to get them done. My job is to secure the necessary resources, provide a sounding-board, review technical decisions they make and run LOTS of interference to keep my boss out of their hair so they can actually get the work done.
I've had very little turnover in my years of managing, and have had people who seek jobs for companies I go to work for to work for me again. Guess I'm doing something right. :-)
Re:I don't know if I fully agree with that (Score:4, Insightful)
I have no clue what a carburetor is. I don't care. Don't use cars much.
You shouldn't assume much at all is general knowledge; I know far too many linux fanbois at my school who think everyone somehow is born knowing how things like netboot, dhcp, and computer internals work. We tend to see the things we know as elementary and hte things others know as more difficult, or so it seems to me.
Re:I don't know if I fully agree with that (Score:3, Insightful)
So Ford doing so abysmal as a company should be blamed at the workers lower down the chain who can identify a carburetor? Not the CEO who can't, or can't hire the right people, or can't make get the right contracts, or can't sway the public to buy more Ford products?
I'm sorry, but with ultimate power there should be ultimate responsibility. You don't need a business degree to run a company to the ground, but it seems to ensure that you get big fat bonuses and golden parachutes when you do.
Re:I don't know if I fully agree with that (Score:1, Insightful)
If the manager were competent, he would be looking at their output, rather than whether they seemed to be working hard or not. By looking at output, he would see one of his employees has higher quality output than the others, and one has lower quality output than the others. Then he would try to find out the reasons for the disparity, and take action to ensure the programmer with the lowest quality was improving or being replaced.
Re:I don't know if I fully agree with that (Score:5, Insightful)
The managers decide whether it's complete or not. Systems work by fiat -- they're declared working, and thus they work on paper, no matter how b0rken they may be.
Remember, support comes out of a different manager's budget.
Re:I don't know if I fully agree with that (Score:3, Insightful)
Unfortunately, I do agree, in principal, IT Managers that don't have the know-how to do it themselves, should not manage IT based projects..
The big issue with managing IT based projects is that, if the manager doesn't know enough of the technologies behind a project he/she is managing, then this manager has no real control over timelines, efforts and cost, because in order to know if the estimates are correct, he's got to rely on what he's being told, not what he understands.
That's why I don't undertake contracts to subcontract to others, unless, if something happens, I'm not able to step in and do it myself.
Now, the reality is, managers who know what they are managing at the IT level, are a rare breed.
And while it's true that managers are there to manage people, well they are also there to manage the project and an IT project is more than likely based on one or several frameworks and, hate to say it, one or several types of technologies, from scripting/coding platform to databases, etc.. If the manager isn't proficient in these disciplines and technologies, how can he accurately manage the project to success and/or within budget in the first place? The only way that's happening, is if he's lucky and got a great and "honest" team to work with. But then, what if "stuff" happens? How can this manager truly know what's the deal from the fake? That puts a project in jeopardy. Now, maybe, for these "non-IT" managers, they have a special tool to help them, did I hear that there are Ouija Boards out there that can help with that? Is that the secret for these managers?
:)
Financial literacy among engineers (Score:3, Insightful)
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.
Re:I don't know if I fully agree with that (Score:2, Insightful)
The CEO SHOULD know enough to do the jobs that his subordonates do though, and to a lesser extent know enough to do the jobs of his subordonates subordonates. The CEO should be know how to be a director, directors should know how to be project managers, and project managers should know the basics of their projects.
Yes, technical knowledge in a CEO or VP is probably not very important; but an understanding of management is and part of knowing how to manage is understanding what your employees are doing. Heck, if you didn't know what your employees did and the basics of how to go about doing it then it would be rather hard to rate their performance or reward them for an exceptional job.
Re:I don't know if I fully agree with that (Score:3, Insightful)
Re:I don't know if I fully agree with that (Score:3, Insightful)
Re:I don't know if I fully agree with that (Score:5, Insightful)
This is so true and common!
But i tell you as soon as the smart programmer is fired. The average programmers who received all the insight and help from the smart programmer disappears as well (usually hence why there is all this praise).
As for the incompetent programmer he totally loses access to his "sugar daddy" and "yoda master" work colleague and in a manner of months if they cant find another good programmer to fill his shoes then the whole ship starts to sink :)
Re:I don't know if I fully agree with that (Score:5, Insightful)
By output do you mean lines of code? For many non-technical IT managers, that's how you measure output. Incompetent programmers can often put out ten lines of code that should require one.
I am sorry, but I got to disagree (Score:3, Insightful)
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.
Re:I don't know if I fully agree with that (Score:5, Insightful)
Some of the most pleasant managers I've had, didn't have a clue about the technical aspects of what I do, but they did trust me when I gave them a time/cost/resources estimate.
Sure, that can be nice when it is you, but what about the less-than-competent/ethical cow-orker who can endlessly blow smoke up the technically clueless manager's ass?
A good manager has a good bullshit detector, which means technical competence is necessary.
Re:I don't know if I fully agree with that (Score:3, Insightful)
Alas, I cannot properly respond to you as I have no idea what an SME is. When you use an acronym like that, please spell out the long form the first time you use it.
The fact that you use words like "leverage" and "resourcing" as well as some weird three-letter management acronym that you apparently expect everyone to know already make me suspect that you are the clueless, incompetent manager I was discussing.
Re:I don't know if I fully agree with that (Score:3, Insightful)
I would have throught the best way to measure performance is in functionality/bug fixing, combined with some sort of rough syntax analsys so you can see how many bugs a person is introducing.
Probably. Thing is, to do that sort of analysis, you'd need at least some technical knowledge. Which is what this whole argument is about.
Re:I don't know if I fully agree with that (Score:3, Insightful)
Re:I don't know if I fully agree with that (Score:3, Insightful)
/Never/ measure simple bug fixing rates. People get assigned to fix bugs in the code they wrote. Some competent programmers fix their bugs before the people who document present bugs get to look.
Also you can't use bug reporting rates because some competent programmers will allow others to see a work in progress (since, technically, /everything/ is a work in progress and never perfect) and bugs can then be reported weeks after they're fixed. A competent programmer often checks in buggy work and reports all the bugs having discovered them since it is better to share the state of your work than to leave the product missing a required feature.
The only thing you can do is ask for appraisals, and that requires trusting your people.
So two rules for softeng managers:
1) trust your people
2) listen to your people when they say something is wrong and listen to them when they say something is right
3) fight beancounters tooth and nail - they will turn your team into an abject failure
Re:I don't know if I fully agree with that (Score:3, Insightful)
A manager is someone who is experienced, has detailed understanding + knowledge, and is able to make good decisions.
I agree. but key to management, especially of a department in which creativity is part of the job, as IT, is that he/she must be able to gain the respect of the people he/she is managing.
I've worked in fund management for all my life, and the difficulties are broadly similar. good managers fall broadly in two categories:
1. "good secretaries": they basically cohordinate the people involved, act as a go-between in funding/resources allocation within the company, but they have no pretense of technical knowledge; they actually do MORE than that,some people are so good that you do not feel they exist even when they are very effective;
2."Peter's disciples"; they've risen through the rank and file on merit, and while they may not be current anymore on the leading edge, they know the challenges involved, and they know how to play on the respect they deserve; they're less unobstrusive than type 1, but in the end they're on a par, because they usually are not at the same level of political ability.
both these types gain a measure of respect out of their rank and file, the first in their sheer usefulness, and the second because they've been there and done that.
In my experience, all people are usually open minded when a new boss comes along, unless they're saddled with someone who has a "reputation", either as an inconsistent meddler of just a dumb fool. in too many cases, managers think of themselves as the "higher up"'s secretaries, which is the worst situation of all: there's no line of responsibility and passing the buck becomes a national sport. So what little clout the company has in regards of Creative thinkers goes down the drain for good, because in the end trust in the higher levels is challenged as well.
Re:I don't know if I fully agree with that (Score:3, Insightful)
Incompetent programmers can often put out ten lines of code that should require one.
Now, now. Just because they don't know the glories of Perl, doesn't mean they're incompetent programmers.
Re:I don't know if I fully agree with that (Score:4, Insightful)
I repair computers. My manager tries to repair computers, but isn't very good at it, and I don't expect him to be.
But your manager DOES understand the process of repairing computers even if he's not all that good at it. Cringely wasn't saying that the manager should be able to competently do the job of everyone under him. He was talking basic knowledge. Just having some idea what is involved. The test is to write "hello world", not the next version of the company's product.
From a human psychology standpoint a manager who can't find the power button will quickly convince a technical department under him that his decisions are based in ignorance and so, are bad. True or not, that will have a negative effect on morale and, in turn, productivity and employee loyalty.
Beyond that, managers who don't understand even the basic nature of the jobs the people under him do WILL make serious mistakes. Witness the many many flavors of cool-aid drunk by managements everywhere when it comes to flavor of the day "programming paradigms", application frameworks, buzzword compliant languages, etc. If managers had even an inkling of what developers do, they'd realize that many of the "wonderful" tools they seem to buy into hook, line, and sinker actually only address the last 10% of the work (code generation) while making the other 90% clunkier.
Development isn't an assembly line process producing widgets (programs), it is the design of the assembly line. The program is the assembly line that produces the widgets(output). The coding is the process of building the assembly line once it is designed down to the last millimeter.
Some managers are just discovering the same thing with outsourcing. They expected to hand over the same vague notions of what they wanted to a team half way around the world that doesn't speak much English, and somehow, magically, they'd do just as good a job as their on-shore team who have worked in the industry for years (and so, know the implicit assumptions).
In other cases, they figured they'd have the project lead precisely describe the problem to the offshore team. They don't get that once you have precisely described the problem in detail, the actual coding is just the denouement. Before that, the coding is just a way of thinking out loud about the problem. They actually took away a great tool for thinking about the problem (90% of the job) in order to get half price on the last 10% of the job. If they had any idea what it is that their people actually do, they'd have never made that mistake. That doesn't mean the off-shore team is incompetent. Things might work much better if the MANAGEMENT is off-shored and then the project comes back home for finishing touches and implementation, but no manager will ever outsource his own job and fire himself.
Digging deeper in to things, why is it that such a large percentage of software projects fail miserably? I suspect that the problem is (in part) that management believes that definition and design is the first 10% of the work (after which accurate timelines can be projected) and that the code grinding is 90%. The truth, of course, is that the design is 90% of the work and happens out-loud with code after the first 10% or so. This is somewhat like assembly line designers laying out machines or mock-ups out on the floor. It is a mistake to believe that they are building the assembly line at that point (and so, the project is nearly done). Estimates that happen before the job is 90% complete are educated guesses at best. The many *Programming paradigms accommodate that reality to some degree or another but lose the fundamental truth in slavish adherence to methodologies and process.
Examined with that in mind, the *Programming and friends all look like the many Dilbert like cases of developers tricking their bosses into making the right decisions for the wrong reasons. Fundamentally, they just try to reframe a lack of proceduralism as a procedure for managers who can't understand that some th
Re:I don't know if I fully agree with that (Score:2, Insightful)
And yet if he could work without a manager - why have the manager there in the first place?
The whole point of a manager is as an organiser and as a single point of communication into and out of the group he manages. All the GP was asking for from a manager was that role to be fulfilled.
Re:Company development standards are... (Score:3, Insightful)
"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".