I usually read articles about business management the way my dog watches us eat dinner: with hope – never quite crushed, no matter how seldom fulfilled – that some toothsome morsel will come to me. This one was a nice meaty steak, fresh from the grill. If you have anything to do with corporate IT, whether as a member, manager, or customer, read it. The premise is that geeks value competence, logic, and contribution, and reward these attributes with respect. Looking at that statement logically, you can see that the contra-positive must also be true: if you are not getting respect from your IT department, you should look to yourself to see why not. If you ask a good IT person to do something dumb, illogical, or counter-productive, he will object. If you force the issue, you may get compliance but you will certainly forfeit respect. This is where a good IT department will start to rot. IT people tend to view management incompetence as a bug, and if they cannot fix it, they will come up with a work-around. If the bug is in corporate management, the IT department will pursue paths that they believe are better for the company’s interests than what they were told to do. If the bug is in IT management, there will be subversion, factionalism, and low morale, since the IT staff knows that IT management is not effectively representing them to the rest of the company. Either situation causes a split between IT and the rest of the company which may not even be recognized until there is a major failure.
I lived through one of these case studies some years ago. A senior VP with no technology background was given a performance objective for the coming year: put together a web application for the bank’s investment customers. That was about the extent of the mandate. It was the 1990’s, after all, and top management knew the buzzwords but not much more. The team started off with her trusted subordinate who actually had real expertise. Some of the next hires doomed the project. For example, one manager was hired for her generic management skills, but had no idea what her staff was doing. She tried taking a basic HTML/Intro to Web Development course but dropped it before the mid-term. Any request from the business users was treated as a divine law, regardless of what it would take to implement it or what it would do to the rest of the project. You may be familiar with the “big red button that you just have to push it and it does everything.” This beast, like the chupacabra, has never been seen in the wild or captured alive. Despite everything, we wrote the data dictionary, got the data imports right, designed and built the database, made the GUI, tested everything, and got as many things done well as we could during the breaks between screaming sessions. Phase 1 was implemented and the external clients loved it; I had a contract with one of the clients later, and they didn’t know how they would manage if the plug were pulled. When they found out I had worked on it and could show them some tricks and tools, that was as close as I have ever come to being a rock star. When the bank was later acquired by a competitor, this client gave the new owner an earful about shutting it down. Back at the bank, internal customers and other IT groups hated it. It was either too much trouble to learn, too disruptive to the way they were doing things, or represented a turf invasion. For example, we were denied licenses for a software development tool because it was already being used by another IT department which would not let us purchase additional seats. Most of the team, top to bottom, was laid off while phase 2 was being developed, although a few managed to get to other parts of the organization.
Looking back, it’s clear that the job got done despite management, not because of it. It’s not the first or last time that I’ve run into management by self-destruction. Clearly, the team had gone around the bureaucracy to find out what the ultimate client needed, and built that instead of what they were told to do. IT people are naturally self-organizing anarcho-capitalists. Maybe the lesson is that if you find yourself herding cats, you should either get yourself some sheep, or at least ask yourself if the cats might have reasons for going in a different direction.
Speaking as a techie, you also have to watch out for the opposite phenomena in which techs don’t understand business needs and ignore input from those who do. There is an ugly streak of elitism and hubris that runs though geek subculture which confuses highly specialized competence in one field with generic intellectual superiority.
I had to beat that out of lot of people over the years. I had to get techs to take time to listen and to educate their internal and external customers. When I did training for Apple tech support I stomped down hard on people mocking ignorant customers. I pointed out that if everyone knew what we knew, we wouldn’t have jobs. I urged people instead to look at ignorant and frustrating customers as money in the bank. This not only improved service but took a lot stress out of the job.
One of our biggest failings as humans is believing that the things we know are easy and obvious and that people who don’t know them are less intelligent or capable. In reality, we are a civilization of specialist, each of which understands some small corner of reality. We require other people to flesh out the world for us.
There is an ugly streak of elitism and hubris that runs though geek subculture which confuses highly specialized competence in one field with generic intellectual superiority.
Amen.
The best working relationship between management and engineering is achieved when each side focuses on what they know best–business, technology–and trusts the other within its domain. And communication is vital. Management must provide engineering with priorities, with a business assessment of what benefits are worth what costs and risks. Engineering must provide management with an intelligible and honest assessment of what the technical tradeoffs are, what the costs and risks are for different approaches.
Trust is key. When management says, “the quick and dirty solution really is what we want,” the engineers must trust them enough to build it. When engineering says, “this costly problem will be resolved most quickly if you do nothing and leave us alone to solve it,” management must trust them enough to do exactly that.
That last one’s tough. In technical work, there very often are major unexpected storms. And the very best manager I ever had told me that the hardest part of his job was being in the midst of a crisis and doing nothing. I got to see it. A final system integration ran into technical problems, and a one week build stretched into four, and then six. He asked us daily if manpower or machinery would help, and offered to get what we needed. With a few exceptions, we declined. External pressure mounted. Senior management asked him what he was doing to resolve the problem–and he simply said, “letting the engineers solve it.” And it got solved in (relatively) short order for a technical problem of that size, largely because he had the courage to do nothing.
Now that was a manager I respected, and the technical cooperation he got out of his team in return was incredible.
Off topic, it seems to me politicians often find themselves at that same crossroads in a storm, and lack some measure of the wisdom or courage necessary to do nothing.
My perception is very different. I’m sure there are IT organizations that jump through hoops to do whatever the user organizations want, no matter how unreasonable, but far more common are dysfunctional organzations in which too many people are mainly concerned with getting/using the latest software/methodologies/buzzwords for purposes of resume building, and not concerned enough with doing what the business needs. Many end-user organizations wind up doing important applications in Excel or manually because they cannot get timely support from their IT organizations. Far too often, IT acts as a dragging brake on the whole business.
When you say “f you are not getting respect from your IT department, you should look to yourself to see why not”…I’m not sure why it should be assumed that if a person or organization has difficulty getting response out of IT the fault lies with *them*, any more than it would be assumed in the case of someone having trouble getting support from a manufacturing or IT department.
All of that said, I agree with you that it is a disaster to have managers who have “generic management skills” but are incapable of understanding what their staffs are actually doing. This is true in other areas as well–imagine a manager or mechanical engineering who didn’t know anything about the subject, or a finance manager who didn’t understand balance sheets–but for some reason, people of this type seem to be imposed on IT organizations more commonly than on other functions.
death to all users.
jk
I for rue that day, long ago, when my PERSONAL computer stopped being a desktop intellectual tool and became just another NODE on THEIR network.
Are there issues being discussed here that were not covered in the Mythical Man Month?
It’s been a long time since I read “Mythical Man-Month,” but IIRC it was more concerned about the internal management of the development process than about the relationship between the developers and the internal customers. (The experience the author was writing about was mainly the development of the original System/360 operating system.)
For those interested in problems with large software projects, see my post about an FAA/IBM effort to reengineer the air traffic control system: the greatest debacle in the history of organized work?
I have had the full range from officious bureaucrats who needed a form to go pee, to the laissez faire ‘do what you think is best’. The ones most appreciated are those that listen to what you are saying, can grok the content and repeat back the major concept. They are the ones that will stand up for you when the boss wants to cut head count, and when the HR group wants to adjust ‘pay treatment’.
You help them, they help you. You have to learn when to bend and when to stand firm.
My last job was as a contract Y2K person. The boss wanted to change the box, move it, re-address the network, and go to a newer release all in one huge change. I put my foot down and explained that if it broke, we would not know which part caused the failure. If we did the change in steps, we could back out a single step if there were problems. They bought off on my explanation, and deferred to my experience.
tom
The most important tool in any technical manager’s toolbox is the will and ability to say “No.” Without that even successful projects are quickly doomed by “just one more feature..”-ism. That “one more” can come from above or below; from the bossman or the engineers.
Because software is ephemeral if there isn’t one guy with the ability and will to limit scope [and someone to limit the expectations of scope] the whole project is doomed.
/profile link changed to my Python blog temporarily for purposes of street cred.
//more cred? Here is the eye rollingly geeking video of my PyCon 2009 talk.