Slashdot Mirror
How to Stop the Dilbertization of IT?
Alien54 writes "In the simplest terms: too many IT workplaces have become Dilbertized -- micromanaged, bureaucratic and stifled creatively. It's become an environment where busy work is praised and morale is low. How is it possible to bring IT's appeal back? 'IT professionals that have worked in the field for a long time often speak about a shift in their work where they have gone from tossing ideas back and forth to make for better technology solutions to fighting fires all day. "There's less emphasis on creativity, and more on maintenance. Tweak this, work on this ... In being reactive not proactive, everything is a crisis. Something has to be done right now, putting out fire after fire, going a long way to making IT a less pleasant environment," said Skaistis. Beyond making for a unpleasant work environment for the techies already in-house, this firefighting serves as a warning to potential recruits: you will not like this job.'"
Ten years ago the internet was just coming into the public awareness, there was tons of infrastructure growth, and lots of issues that didn't have very clear cut solutions.
These days most of the growth has slowed, things have been tried and proven or cast aside, and we're transitioning to more of a steady state environment. Even where there is lots of growth we know how to handle it and growth has become routine too.
"Prefiero morir de pie que vivir siempre arrodillado!"
Welcome to the world profiled, catalogued, and databased such that every person is pigeonholed into their own individual spreadsheet cell--and heaven help them if they should try to take up more space than the metaphorical spreadsheet maintainers (the stock brokers, analysts, and accountants) have allotted.
the NPG electrode was replaced with carbon blac
1. Many IT shops are in financial institutions or other businesses where systems are handling millions or billions of dollars. In that situation you don't want a whole lot of creativity. Every time you change code you introduce risk, and the more money at stake, the more risk-averse you are.
2. I'm not sure creative new techologies are needed right now. A lot of creative new technology emerged during the dot-com boom, and the tools and talent were subsequently bought up cheap by corporate IT shops. The IT industry still has not digested the technology it already has.
3. If you want creativity, shun the larger shops and go work for a startup, or start one up yourself.
1) IT folk need to understand that they are there to solve business problems, not IT problems, and need to leave a little more about business, instead of making business people learn the IT language.
2) Currently, if you're good at your job, you will be promoted to management in IT, which means you will no longer code, and have to learn to manage people. What would be better is to create a senior position that has the money of management, but allows a great coder to remain a great coder.
3) People in the organization have to be punished for causing problems that they look to IT to fix. Due to others lack of planning, we're constantly having to pull micicles out of our asses. But while we take the risk, others get the reward. This has got to change.
Just my opinions...
This is a predictable result of managing tons of users who all want to treat a complex machine that can perform millions of functions as though it were an appliance like a toaster or a microwave. The "I just want it to work but not if that means I have to learn anything" crowd are high-maintainence users when compared to someone who knows the utility of understanding the use of the tools you need to do your job.
Think about it this way. A car does only one thing, and yet you are required to obtain training and a license before you are allowed to use one. The idea that you can use a general-purpose device and not have to learn anything about how it works is an absurd pipe dream that has generated a lot of profit for the likes of Microsoft, but there is an expense to that idea and the expense is shouldered by support staff who act as a surrogate for the knowledge that the users did not want to learn. Much of IT really has changed from finding creative technical solutions to babysitting "permanent n00bs", you know the ones who can use a machine for five years straight and somehow manage to never learn anything new about it. Not everyone wants to be a tech? I'll buy that, but not knowing much about the tools you need to do your job and depending on someone else to pick up the slack doesn't sound very responsible, and never picking up more skill over the years, well, that takes work.
I used to be in the IT industry, and it is precisely this situation that made me decide to get into another line of work. As a hobby, I can really enjoy computing. As a profession, I became so sick of the willful helplessness (when all the tools and information are available and people don't learn anything simply because they don't care, but when there's a problem they sure do care then) and pure laziness I kept encountering that I ended up deciding that it wasn't for me, that there are less stressful ways to earn a living.
It is a miracle that curiosity survives formal education. - Einstein
While this seems like a very limited solution, I would agree. I worked for a Big-5 and noticed month after month that propz went to people who could RESOLVE issues (usually issues created by their own bad coding.) Little propz went to people who simply didnt create issues (by designing properly, testing well, etc.) I reduced my testing one quarter and spend less overtime at work. Naturally bugs resulted. I was promoted for resolving these issues. I quit tech work and became a business analyst. I couldnt work in a position where people were rewarded for being idiots. Though i'm sure this was very particular for this group in a particular Big5, just some food for thought. Basically, what are management's expectations?
The answer to your question is that for in-house projects, IT needs to be separated into distinct engineering and operations groups.
.war or .ear file just like you would for any other customer. As a developer, operations should be your only customer, and your relationship with them should be the same as the relationship you would maintain with your most valuable and critical customer.
IT Engineering is what the OP obviously favors. Designing new technologies, building better solutions to existing problems, and increasing productivity through these incredible meta-tools we call computers. IT Operations is about taking these technologies, cataloging their shortcomings, and doing what is necessary to implement them and keep them implemented. Engineering is about the introduction of new ideas; Operations is about the constant war to keep those ideas safe from entropy.
Often, these goals are in direct conflict. It is only natural for a solution developer to recognize the shortcomings in their product and want to fix it. It is in the best interests of operations that a stable server not be changed unless absolutely necessary, and then only when the changes have been thoroughly tested, put through miles of red tape and human business process, and signed off on by people whose jobs are on the line if the application goes down. The idea that you can write a program and be the person who runs it most effectively is a false one in any mission critical application. When there's money on the line, red tape and paperwork is the only way to make sure that it keeps flowing.
So to be successful in IT, we on the one hand need developers who are free to try radical new ideas in an environment that rewards creative solutions to entrenched problems, and on the other hand we need a static environment ruled by business process and red tape, which stifles unproven concepts and chokes creativity. The only solution to this is to separate these groups completely, and have development treat operations as a very stodgy customer. Too many companies don't realize that this split is necessary to maintain their financial longevity, and have the same people who develop their applications responsible for their day-to-day operations. This situation not only leads to frustrated development staff who feel creatively stifled, it is also in the long term project suicide. In-house developers should not only be relieved of the responsibility for running their code, they should in fact not even have logins to the servers on which their code is running.
Professional standards of code release need apply, too. It's not enough to release code to production via CVS checkout, you need to write an installer with an uninstaller and an upgrade path, just like you would for commercial software. It's not enough to run an ant build on your server via an NFS mount back to the depository, you need to compile a
But one person wearing the development and operations hat? That leads to nothing but frustration, burnout, entropy, and failure.
Even Jesus hates listening to Creed.
That's what the
"Debt" is a ten thousand year old playground game.
the NPG electrode was replaced with carbon blac
and focusing on root cause, not the current fire. Get things working again and then take the time to find out why things went wrong. 85% of service interruption is caused by human error. Companies and techies spend money and time constantly fixing the same things over and over again. If you take time to find the root cause, using ishikawa and other techniques you can actually stop running from fire to fire. One huge thing though is that a LOT of IT people like being the firefighters because they get more glory, and unfortunately a LOT of managers don't reward employees who aren't firefighters, and fix problems before they impact production. When things are quiet, that means that someone did their job right. Proper problem management will decrease calls to the service desk (helpdesk) and decrease first level resolution rates- you're not solving the same problem over and over again. A knowledgemangement system helps with this.
d ent_Managementl em_Management
d =19
Check out the ITIL definitions of problem and incident management:
Problem Management-http://en.wikipedia.org/wiki/ITIL#Inci
Incident Management-http://en.wikipedia.org/wiki/ITIL#Prob
Another good one- http://serviceinnovation.org/
I've seen Greg Oxton from serviceinnovation speak and here's a link to where he describes the true impact of errors on the user community. (starts really getting into impact on slide 11)
http://itsmf-tampabay.org/WordPress/?attachment_i
My 2 cents
The problem is that many (most?) companies nowadays see programmers as commodities, creativity as risk, planning and careful deployment of systems as expenses. They have managers that don't know anything about technology, deadlines impossible to meet, no recognition for merit and talent. The consequence is that systems crash all the time, "workarounds" are the rule and the good professionals are overloaded with work to make up for all that people that work with them that don't have a clue.
With such perspective ahead, it will be no wonder if in a near future the best brains will go to finance, law or any other profession that may offer what IT used to do.
The problem is that IT has been taken over by Business School Product. They have no grasp of science, no feel for aesthetics, they only have feel for next quarters numbers and covering their ass. This is what Business School teaches. One needn't know anything about an industry in order to manage it, Business Schools build this into their Product. They will never, ever learn a new skill unless it is something useful for climbing the corporate ladder. The best thing IT can learn is to weed Business School Product out. Dilbert's boss is hiding in every last one of them.
This is silly. "Creativity" does not mean "being a cowboy." A creative solution can be implemented carefully, after thorough testing and validation. On the other hand, a non-creative solution can be implemented in a sloppy and haphazard manner. Handling large amounts of money means you need to be careful and disciplined when you design, test and implement a solution. It doesn't matter if the solution is creative or not.
I disagree with your second point, too. Even if I grant that "the IT industry still has not digested the technology it already has," that doesn't mean that existing technologies solve the problems that people and companies have. It would be nice if they did, but it's just not realistic to think so.
Your third point, though, is right on the money.
Of course, if the "uncreative" 1000 line version is 7-times bigger for the right reason, it is avoiding clever-clever tricks so it is easy to determine that it does what it's supposed to and it's easy to maintain.
The most bloated, boring and uncreative code I have ever seen in my life was a safety critical system that had the potential to kill hundreds of people if it went wrong. It might have been bloated, boring and uncreative but it was also blindingly obvious what it did, how it did it and that it did it right. There is a place for creativity in software, but there are also some places in which creativity can be a bad thing -- and as well as the safety critical domain, the financial sector is probably one. Sorry folks, but I think the place for creativity is likely to be in novel applications, not the mainstream, and as somebody else has pointed out that means that the interesting stuff is in the small software houses.
Quidnam Latine loqui modo coepi?
Dilbertization is INEVITABLE in any hierarchial organization. There's nothing whatsoever you can do about it.
It's causes are ultimately all within human nature. Starting with the technologists themselves, they're all in competition with one another. Each wants to be recognized as the alpha geek. Furthermore, some are lazy and some are energetic. the lazy ones hate the energetic ones because they make them look bad. The energetic ones hate the lazy ones because they're not carrying their weight. Finally, the TALENTED technologists are repulsed by the thought of being promoted into management, but the inept ones love the idea, as do the closet fascists.
The professional managers, middle-managers, "project managers" (ha!) and other undead minions of all standard IT organizations are just as dysfunctional. Secretaries are sullen, convinced that everyone thinks they're stupid (in some cases, this is astute on their part). Project managers, like the fawning little lap-dogs they are, tell management whatever they want to hear, often totally fucking over their staff by agreeing to ridiculous deadlines that cannot be met. Middle managers often know nothing whatsoever about technology and run their areas according to whatever management theory is currently in vogue. Worse, they often rate employees by how well they schmooze, not how well they code. Nepotism is rampant. Other minions, like managers selected to represent users in design meetings, often are in way over their heads and only want to cover their asses and contribute enough to meetings to LOOK as though they've got things under control.
If you work in a private company, you can be fired at any time for any reason, and often your fate is totally arbitrary. Knowing this, you MUST always keep your eyes open for new jobs; companies are like women, they never want available developers, because they think there must be something wrong with them (so they stick to poaching from other companies). If you think you're going to be fired, you have to start interviewing right away before you lose that "I'm still employed" cachet. And you have to know who is a "special friend" of which bigshot so you don't accidentally step on the toes of so-and-so's asshole cousin and prematurely end your career.
If you work in civil service, you can't be fired easily but this means that you always end up with at least a few totally useless idiots in your department. They KNOW they can't be fired, so they just sit around like barnacles, slowing the whole boat down. At most, the part of the staff that'll actually be able to DO anything will be 25-50% (and they'll be bitter and snarky about it -- can you blame them?). The rest are all deadwood. The same is true for management! You see these ridiculous men in their fifties, already mentally a senior citizen, just waiting to retire at 55. They DREAM of a "25/55" deal and talk about it with anyone they can pidgeonhole. Finally, because the deadwood just wants to be left alone to play some stupid downloaded Windows game (which probably was a trojan) they'll pretend they're really busy to the boss and you won't be able to get ANYONE to agree to let you build anything, even if it would make the whole department more efficient.
The whole system is completely, hopelessly, irrepairably FUBAR. It's a clusterfuck of legendary proportions. The only way to survive within it is to make yourself invisible and get your work done as efficiently as you can, while not getting drawn into any politics, never suggesting anything, and never volunteering for anything.
NO CARRIER
Sounds like your friends either suck at their jobs, and thus don't expect to ever be able to get another one, or they are gluttons for punishment. If your bos expects you to work 70 hr weeks without compensation, or be on call 24/7, or do impossible projects without any money, you should just quit. There are always other jobs out there if you are good at what you do. It sounds to me like your friends will let people walk all over them and their managers know it. Why hire an extra employee when you can get the ones you have to work for free? I don't care if you make $10/hr or $1000/hr, if your boss treats you like shit, and has no respect for you, quit and find a job somewhere else. The only people who can't do that are the ones who managed to sneak their way into a job they weren't capable of doing in the first place, and they will do anything to keep it because they know ir probably won't happen again.
Some people get disproportionate amounts of credits for stuff, and those tend to in two categories, people close to executives and people who get approached by customer executives first.
Too many times I've seen a technical person get shipped off for *months* to work on the technical details of achieving an unreasonable schedule. They'll work long stretches of 7 day work weeks at 10-12 hor days to make up for overly-optimistic schedules hundreds of miles from home and family. They come back to a pat on the back and maybe a 50 dollar gift card to a restaurant (though admittedly, their room/board/travel for the months away were covered..).
Meanwhile, the project manager who set the insane schedule, kept their ass comfortably in their desk chair for 9-5, M-F days, for the most part just asking the technical guy 'how close to done are you', and repeating that data to customer executives and their own management chain. This project manager gets promoted in recognition for their 'stellar work to make it happen'.
Same with sales to a degree. Some sales situations, particularly in technical sales, requires a fair amount of work. Other times, I've seen cases where a customer without provocation approaches sales and says "Here is a very large, specific set of stuff and I am buying from YOU, place the order". In making it happen, sometimes its a tall order and technical people are called in, working long weeks of long days far from home. At the end, a note comes out congratulating 'all who made it happen', and then lists everyone, the list more often than not includes some executive who barely has a vague notion about it happening at all and the salespeople who in some cases just did the equivalent of forwarding a customer note verbatim to a sales system. Technical people are just interchangeable cogs that were simply there regardless of the miracles they pull off.
People removed from the direct customer pay-out and from higher-level managers just frequently get overlooked. I've seen this in several companies and I learned a long time ago volunteering to overextend yourself just ends up screwing me and making some undeserving person look good, so I refrain from things that I know will end in travel and long hours. What little credit there is to be had for going 'above and beyond' for many doesn't scale up at all beyond putting in just a little extra effort.
XML is like violence. If it doesn't solve the problem, use more.
Dude, if you or anyone you know works in such situations... get the HELL out of there. If you have any of those skills, you can start anywhere but there. I currently make around 70k and I work from 8-5 and I take 1 hour lunch break and scatter 'plumbing' breaks throughout the day. They know that if they lose me, they lose a lot of money because of all the custom work I am doing. They can't outsource me, because I'm the guy they outsourced to.
If they really know all those protocols, let the company outsource (or threaten to), they will probably end up being the contractor on site doing the job, but then outsourced. I worked direct for a company, got fired because I didn't want to bend to the advertising manager's every whim (very archaic and bureaucratic company, and he was good friends with the CIO), and I got the next week the offer from a company they were forced to outsource to, to go back there and continue the same job, I declined, but you see what happens when managers screw you. Oh yeah, it was a Fortune 500 company and due to this and many other reasons, they are in progress of being taken over by competitors.
Another job I did was sysadmin and I was there 2 years, again the CEO was Dilbert's pointy haired boss and everything had to be done whenever he felt like it. I left as did many others. Their whole helpdesk was replaced within a year after I left (I was the first and showed everyone that you CAN get a job elsewhere these days), their 'custom' programming team (6 persons; programmed a totally custom ERP system tying in to their server park, website and customer database) got together, quit simultaneously and started their own company and now the original company has to source the programming out to them, they do whatever they want on their own pace and get paid big bucks for it.
I constantly get calls and a lot more e-mails with offers because I have the knowledge. Skilled IT workers are in demand, most outsourcing projects failed horribly (what good is an internal IT department that doesn't/barely understand the native language and is located in India) and companies are hiring massively to build up their IT departments again although most of them are on contracts these days. I love being on contract, you get to do a job you like, you do it good and nobody is going to oppose you because you're expensive ($58/hour or more). If you deliver, you can stay longer and you don't have to put up with any of the salaried bullsh*t, because if they call you at night, or ask you to do some extra, you ask, should I put this as overtime (rate x 2.5) or can I come in later tomorrow.
But really, I'm not putting up with the 24/7 crap (unless I get paid big bucks for it and I don't have a partner to live with) or unpaid overtime anymore. They can say you're going to be outsourced, but actually, these days YOU are in demand, those threats are so 2000.
Custom electronics and digital signage for your business: www.evcircuits.com
I agree with this completely. Every IT manager / CIO should have to read Peopleware.
In no other job are you asked to do the equivalent of tracing through 10000 lines of code to track a potential threading problem while working around people answering phones and having loud conversations about TV shows. Meanwhile your manager keeps asking you what a thread is and why it takes so long to find one because he needs to present a 10 word summary of the problem to his manager and hasn't programmed since 1973..
After 4 days when you finally find the problem and explain that it's a three line code fix, you're not given the slightest bit of credit because as we know, IT workers are a commodity and anyone could have solved that problem. Even the guy who created the threading issue by putting a static PreparedStatement in a servlet to make it 'efficient' could have fixed it. It said on his resume that he knew JDBC..
Good IT workers are rare. Our office is filled with people with 10 years of experience in XML who try to emulate transactions by writing delete statements for inserted rows because they haven't heard of distributed transactions. They code everything according to 'design patterns' making it a nightmare to debug. Eventually you're the one who gets stuck with the problem of figuring out why credit card transactions are being credited to the wrong customers. Management doesn't see the difference between you and Mr. Design Patterns, except that he gets all his projects in on time and you're always late. The time you spend cleaning that dung heap of design patterns gets charged to 'General Maintenance' and is invisible...
If IT people built cars, they would randomly start reversing on the highway and about every 10 minutes the steering wheel would get stuck while the car tried to figure out what it should do next. Sometimes it would just explode without any reason. Upper management would send a retail manager to put together a team to fix the problem.
Coding is just as much of a thinking job as research.. sometimes it's easy because the problem is simple and well known (power cable not plugged in). Sometimes it's esoteric, and then you really need good IT people with a breadth of knowledge and excellent problem solving skills - you know, the ones you drove away with idiotic management and commoditisation.