My view of the role of management especially in IT is an oversimplified cliché:
Lead, follow, or get out of the way. Thomas Paine
That makes 3 possible categories to delve into, but really I only want to discuss two distinct middle-management types. While in a morning enrichment session this morning with some of my closest colleagues I made a allusion to two particular management style from the abyss that is my imagination. There are givers and there are takers (leeches).
Givers
Few people in IT get to work for givers. The giver is a contributor. Maybe they don't write code, some do and hopefully they're good at it. Givers are ready for change at any moment in the project life cycle and make sure that their influence on the project does everything it can to move the project toward progress. The giver only asks questions when absolutely necessary. The giver will lead when required, but knows when to get out of the way of the people actually doing the work. True givers may only exist in a vacuum of the IT space.
Leeches
Most IT workers have come into contact with some sort of middle-management leech. They do what a leach does best: take. It's usually hard to spot a leech when you start somewhere. At first they seem very helpful and very productive. They spend their time being in the act of being busy. Soon though it's easy to notice that they're helpfulness is a little too helpful. Helpful to the point of no helping. Leeches use classic phrases like:
Givers
Few people in IT get to work for givers. The giver is a contributor. Maybe they don't write code, some do and hopefully they're good at it. Givers are ready for change at any moment in the project life cycle and make sure that their influence on the project does everything it can to move the project toward progress. The giver only asks questions when absolutely necessary. The giver will lead when required, but knows when to get out of the way of the people actually doing the work. True givers may only exist in a vacuum of the IT space.
Leeches
Most IT workers have come into contact with some sort of middle-management leech. They do what a leach does best: take. It's usually hard to spot a leech when you start somewhere. At first they seem very helpful and very productive. They spend their time being in the act of being busy. Soon though it's easy to notice that they're helpfulness is a little too helpful. Helpful to the point of no helping. Leeches use classic phrases like:
Far be it from me to get in the way of progress, BUT.
or:
You guys know what you're doing, BUT.or:
I'm just like you guys, BUT.Are you seeing a pattern? Leeches come in with the appearance of wanting to contribute. Wanting to help. BUT they always have some aside that they have to share because the powers that be (someone that we never get to meet) has decreed that there will be beatings if you cross this imaginary line. The leech will not get out of the way on any issue. They want to be right in the middle of it so they can either take credit for a job well done or hand out the "I-told-you-so"s once something goes wrong. And it's the possibility of failure that drives the leech to constantly add friction to progress.
At one interview I had I was given a few minutes for a pseudo-interview with lower-mid-managers (basically they were designated the same as Project Leaders). It was less of an interview than than it was a get to know me session. I did most of the talking. One thing that I was asked was:
I took the question at face value and answered it with elegant clichés and tried to show how much of a people-person and team player I am. After working there for a while I realized the importance of that question. It was a proof of what I experienced at this job. They wanted to know what my view was because their view was that they weren't going to do anything about those people. They expected no improvement from those employees. They were afraid they would rock the boat and their happy little family of developers would turn on them. They managed with tied hands whether self-imposed or not.
To me this is classic leech management. When it comes to managing people they're impotent, but if something comes up dealing with a change of tool or a new implementation or process where they can enter their contributions/ideas/endless list of questions, they will. And somehow their contributions seem to suck the motivation right out of the group. Most of a leeches contributions will actually improve the quality of work-life for people who don't help the project progress. That's been my experience anyway.
What's the best way to deal with leech management? It should be as simple as dealing with real life leeches. Just pull them off and discard them. But I can't say that I have a solution that is viable. I guess that will be for another post probably years from now when I've had enough experience to make suggestions on that sort of thing.
Until next time
Les
At one interview I had I was given a few minutes for a pseudo-interview with lower-mid-managers (basically they were designated the same as Project Leaders). It was less of an interview than than it was a get to know me session. I did most of the talking. One thing that I was asked was:
"How do you handle being on a team with members whose skills aren't as advanced and who aren't as up to speed on the platform/language/project as the rest of the team?"
I took the question at face value and answered it with elegant clichés and tried to show how much of a people-person and team player I am. After working there for a while I realized the importance of that question. It was a proof of what I experienced at this job. They wanted to know what my view was because their view was that they weren't going to do anything about those people. They expected no improvement from those employees. They were afraid they would rock the boat and their happy little family of developers would turn on them. They managed with tied hands whether self-imposed or not.
To me this is classic leech management. When it comes to managing people they're impotent, but if something comes up dealing with a change of tool or a new implementation or process where they can enter their contributions/ideas/endless list of questions, they will. And somehow their contributions seem to suck the motivation right out of the group. Most of a leeches contributions will actually improve the quality of work-life for people who don't help the project progress. That's been my experience anyway.
What's the best way to deal with leech management? It should be as simple as dealing with real life leeches. Just pull them off and discard them. But I can't say that I have a solution that is viable. I guess that will be for another post probably years from now when I've had enough experience to make suggestions on that sort of thing.
Until next time
Les
3 comments:
Good followup about "Yes, but" and "Yes, and" as ways of communicating :
http://ezinearticles.com/?The-Powerful-Difference-Between-Saying-Yes-And-and-Yes-But&id=432322
Yeah! Morning Enrichment! Whoo!
{ sorry...kinda like the guy that cheers every time the professor says 'beer', huh? }
In other news...
I wonder what the ratio of givers/takers is in our profession.
From my experience the lower management were at one point programmers themselves, so I would think they would have more of an eye toward progress. That doesn't necessarily seem to be the case, though.
Post a Comment