So, in the expectation that developers know how their managers can motivate them and can manage them most effectively, I asked in several online communities and social networks, "What one thing, one thing, should the CIO understand about managing and motivating developers?"
Although the article is more an invitation to feedback and discussion than a definitive survey, Schindler's informal question did yield a few conclusions. One such conclusion is that managers should trust developers, and that developers want their managers to appreciate their desire to do high-quality work:
The primary wish among developers who responded to my question was that managers recognize their own and their team's abilities, and trust them to get the work done... "Try and challenge me. I'm so much more than what you use me for," wrote one anonymous developer...
"I want my IT manager to understand that I care about the quality of my work," says Bruce Lindman, senior database consultant for Quick Solutions in Columbus, Ohio. "I comment my code with my name, and thus 'sign' every script or procedure I write. Nothing frustrates me more than having to do a shoddy job or compromise quality..."
"Developers, as a general group, are highly competent individuals," wrote Paul Danielson, IT director for a newspaper publishing company. "They need to be given room to develop solutions on their own... without being hand-fed work and methodology by management—especially at the CIO level..."
Nor should managers expect software to be cranked out by factory methods. Software development is not a Six Sigma activity. "You're discovering, not producing widgets," wrote James, a senior developer.
This sort of sentiment seems to go against the belief, held by some managers, and also by some consultants, that software development as another production function, something akin to manufacturing.
The developers Schindler spoke with also prefer that their managers leave them out of non-development issues:
"Developers want and expect their management (including the layers between themselves and the CIO) .... to take care of all the corporate crap, useless meetings, paperwork and other time sinks..."
Leading that list is the marketing department, or whoever decides on arbitrary ship dates. Says Jim Pensyl, a senior performance engineer, "The more you cave to marketing time lines and avoid realistic estimates, the more you set yourself up for a project that will extend beyond marketing's promised date."
Other developers complain about managers who remind them about pending and late deadlines several times a day. They resent managers who tell them to serialize their tasks.
Naturally, developers wish their managers to understand development issues, or at least the work that goes into producing good software:
Communication doesn't mean only the accurate exchange of information. It also means giving feedback and praise to developers—especially if you want to motivate them. "Verbal praise works for me," wrote one anonymous developer via Twitter. "Even if I'm not the best, I still need some positive talk to move me."
And, not surprisingly, developers also wanted their managers to compensate them well:
When I asked developers what motivated them, I expected most of the answers you read above. Most people want to be appreciated for the skills they bring to the table, to be trusted to deliver their best work, and to be given honest and useful feedback. But I didn't expect that several responses would be utterly mercenary...
"As far as motivation goes, if I am not getting paid, I am not getting out of bed," wrote one. "That simply saying I'm the exceptional one who can do this amazing thing doesn't motivate if I'm not being paid exceptionally," said another. "Money is the main motivator for any job; get it right and you will have a happy employee..."
"If you treat them well, offer the occasional special treat, and discipline them fairly, it can be done and done well. If you miss a point or two now and then, they'll adjust," he says. "If you miss any of these points consistently for too long, the really good ones will start to wander off in search of better opportunities."
What's the one thing you would want your manager or CIO to understand about managing and motivating developers?
In general, it is not CIOs' job to manage software development. They just don't get it, and it is not what they are supposed to do, anyway. If a non-software company wants to develop software, they need a CTO, or whatever title they may come up with, who comes from the development background.
So, developers want recognition from their managers for the work that they do. That's good.
On the other hand; developers regard the work that other people do as "corporate crap, useless meetings, paperwork and other time sinks".
Unfortunately, it's a two way street. Those developers who demonstrate no interest (or understanding) in the necessary work that must be done by others to give them their work, are doomed to remain "machine operators" and "code monkeys" and be treated as such.
If you want respect, understanding, co-operation and help from others then you must do the same, and do it first.
> On the other hand; developers regard the work that other > people do as "corporate crap, useless meetings, paperwork > and other time sinks".
The problem is that many developers work for corporations where the internal processes are unnecessarily bureaucratized and sanctimonious.
This is what people see as bullshit. I say people and not just developers, because even managers themselves often complain about this. I've personally heard managers complain that they have to do too much bullshit. So this term -- "bullshit" -- is not necessarily a form of disrespect for company processes, but an honest reflection of the management practices which is often shared by management itself.
This bullshit that developers talk about is often real bullshit and not just some kind of developer arrogance and/or ignorance.
Instead of demanding respect, maybe the right course of action is to look critically at that which has been termed "bullshit" and see if any of it could be improved or eliminated.
And then again, maybe some developers really are just ignorant about the necessities and realities of certain business dynamics. I don't rule that out. I'm just saying that the criticisms developers have of the company processes should not be ignored (like they often are, in my experience).
I manage several development teams and, until recently, was a developer. Our teams seem to work very well because we push accountability to the team as much as we can. That means they figure out how much they can get done and they plan the work. They also are responsible for working with our business to establish the requirements and priorities. When there is a problem, coordination or mentoring is needed, or if additional weight is necessary to move things along, then I get involved.
This seems consistent with the developer comments about trust and challenge. We trust our developers to do the right thing and have processes in place to try to quickly detect when things are going off the rails. If they never go off, then I don't get much involved. The key is having responsibility and authority located in the same and right place to empower the developers to act.
That said, this doesn't work everywhere. My philosophy is that this approach is best but you must have a staff that can handle it. Therefore, ultimate success starts with hiring and staff development. With the wrong people, without the right training and support, this approach would be a disaster.
> > On the other hand; developers regard the work that > other > > people do as "corporate crap, useless meetings, > paperwork > > and other time sinks". > > The problem is that many developers work for corporations > where the internal processes are unnecessarily > bureaucratized and sanctimonious. > > This is what people see as bullshit.
Thank you for recognizing the word that I had to cut because my editor thought it inappropriate for a business site. :-)
And yes -- I do agree with you. For a lot of developers, the boss *is* putting useless stuff in their path.
But I agree with the earlier response, too; some developers disparage what other people do for a living, and don't recognize their contribution as valuable. (Sometimes they're right.)
The problem is that it's not always possible to tell the difference between programmer arrogance and justifiable homicide. Particularly when marketing people are involved.
By the way, I'm open to other topics for " &integer; Things the CIO Should Know..." articles. Designing secure software? web design? software tool selection? more telecommuting or career related...? Tell me on what topics your CIO or Big Cheese is most clueless about; maybe we can't solve YOUR boss' ignorance, but we can save some other poor slob from the pain. I like to think that ignorance is curable; it's just stupidity that's forever. (Private messages welcome if you prefer.)
I appreciate this article and especially because of it's target audience. We programmers bitch to each other about this all the time but that get's us nowhere.
What I'd like IT managers to understand is that the idea that we can split business knowledge from the technical implementation of that knowledge is a fantasy.
No matter how you slice it, no matter what language or tool you use, how many pages of Word documents are written, whether you code with text or pictures and arrows, the skill of programming is teaching the dumbest thing on earth (a machine) to do complex tasks. Teaching an idiot machine something you yourself don't understand is next to impossible. Developing is not data entry or technical typing and it never will be.
> What I'd like IT managers to understand is that the idea > that we can split business knowledge from the technical > implementation of that knowledge is a fantasy.
Kind of funny that you bring this up, because we just yesterday published an article (that I only vaguely knew was coming in -- another editor was dealing with it) which touches on this subject in more depth. (It was also slashdotted.)
9 Reasons Why Application Developers Think Their CIO Is Clueless From being a control freak to being a vendor puppet, here are nine behaviors management needs to steer clear of or risk being labeled "clueless." http://www.cio.com/article/419764
This led to an editorial conversation about the idea of writing a follow-up article: "9 Reasons Why CIOs Think Their Developers Are Clueless About the Business's and IT's Needs" -- and I'm all for it. :-)
> This led to an editorial conversation about the idea of > writing a follow-up article: "9 Reasons Why CIOs Think > Their Developers Are Clueless About the Business's and > IT's Needs" -- and I'm all for it. :-)
I'd love to see this because everywhere I've worked, the developers are far more in tune with needs of the business than the CIO.
An example of this is the 80-20 rule applied as an argument for off-the-shelf solutions. The argument goes, we'll get 80% of what we need off-the-shelf and the users will just get along without the other 20%. You can insert other proportions here, they are always completely made up.
The problem is that the users or the 'business' doesn't want 80% (or whatever) of their problem solved. They want 100% of their problem solved. An often the parts of the solution that are missing are the most important and the cost of not having them far exceeds the cost of implementing them. We should be trying to optimize the 100% solution but we buy the X% solution. We end up implementing the rest of the solution anyway but at much greater cost because we based our choice on a flawed premise.
What really frustrates me is to hear developers complaining about management. It's a victim mentality - like they are 1) smarter, 2) not empowered to do something about it, 3) have to stay.
> What really frustrates me is to hear developers > complaining about management. It's a victim mentality - > like they are
1) smarter - How do you know that are not?
2) not empowered to do something about it - How do you know they are?
3) have to stay - Maybe you are independently wealthy but most people need their jobs. I personally have a family to support. If it's not likely that changing to another job will make things better, then there's no value in switching excluding other reasons.
> My feeling is "Stop bitching and do something!"
Technically, bitching is 'doing something' but I'll agree that it's often non-productive. On the other hand, this is often a bullshit argument that people in positions of power use when they don't want to consider ideas contrary to what they believe.
Communicating dissatisfaction is not 'doing nothing'. I would argue that communication is the first step to problem resolution in a civilized environment.
[punchee] stop hitting me! [puncher] here we go with the victim mentality...
> What I'd like IT managers to understand is that the idea > that we can split business knowledge from the technical > implementation of that knowledge is a fantasy.
I'd like IT developers to understand that, too. :o)
Some do, some don't. The ones that do are valuable, indeed.
> > What I'd like IT managers to understand is that the > idea > > that we can split business knowledge from the technical > > implementation of that knowledge is a fantasy. > > I'd like IT developers to understand that, too. :o) > > Some do, some don't. The ones that do are valuable, indeed.
I think it's fairly easy to to make the case to a developer that if these can be separated, they will soon be without a job.
It's beside the point. The thing that is frustrating is the assumption that management/CIO is clueless.
> 2) not empowered to do something about it - How do you > know they are?
You are always empowered. Ultimately, you can leave. But there are many shades in between. The complainers done even try.
> 3) have to stay - Maybe you are independently wealthy but > most people need their jobs. I personally have a family > to support. If it's not likely that changing to another > job will make things better, then there's no value in > switching excluding other reasons.
That's a cop out. There's always three at least three choices: Help make things better, leave, or shut up and deal with choosing the third option.
I find the complainers are often those who don't have the marketability to leave. There's a correlation with unwillingness to be change agents and a correlation to complain about the pile of shit they're sitting in.
> > My feeling is "Stop bitching and do something!" > > Technically, bitching is 'doing something' but I'll agree > that it's often non-productive. On the other hand, this > is often a bullshit argument that people in positions of > power use when they don't want to consider ideas contrary > to what they believe.
By bitching, I mean complaining. Saying things are bad w/o proposing a solution is more than unproductive, it pollutes the well and it is irresponsible.
> Communicating dissatisfaction is not 'doing nothing'. I > would argue that communication is the first step to > problem resolution in a civilized environment. > > [punchee] stop hitting me! > [puncher] here we go with the victim mentality...
And the tone of this is that it is a foregone conclusion that managers are power hungry, abusive, and unwilling to change. I also get the sense it is getting close to personal - like I am one of those managers.
As I said in my early post, I think it comes back to how and who you hire. I am a strong believer in individual accountability and taking responsibility. I believe every employee is a leader of some sort. Therefore I hire developers who have a tendency to drive positive change and have an aversion to complaining w/o action.
> I was hoping someone would bite. > > > 1) smarter - How do you know that are not? > > It's beside the point. The thing that is frustrating is > the assumption that management/CIO is clueless.
It seems that your assumption is that the CIO is not.
> > 2) not empowered to do something about it - How do you > > know they are? > > You are always empowered. Ultimately, you can leave. But > there are many shades in between. The complainers done > even try.
Wrong. Complaining is a way of gaining consensus. If I complain about something and few of my coworkers agree, I'm less likely to do anything about it. If my complaint is universal, then I might champion the issue.
> > 3) have to stay - Maybe you are independently wealthy > but > > most people need their jobs. I personally have a > family > > to support. If it's not likely that changing to > another > > job will make things better, then there's no value in > > switching excluding other reasons. > > That's a cop out.
I'll just point out here that you are actually complaining about people who complain. Why don't you shut up and do something about it?
> There's always three at least three > choices: Help make things better, leave, or shut up and > deal with choosing the third option.
How does one help make things better if management is unwilling to listen? I'm not posing this as a rhetorical question. Please enlighten me. Are you suggesting that management doesn't have more power than the people being managed?
I personally find no validity in the idea that complaining has no value. Smart people listen to complaints and it they are valid try to address them. If I write some code and someone comes to me to point out something that I have done that they don't like and why, I have some options. A few of these are 1. Try to understand the complaint and find a solution that addresses it. 2. Explain why the complaint isn't valid. 3. Tell the complainant "stop bitching and do something", "come up with a better solution if you don't like it" or some other passive-aggressive response.
Personally I would go with 1 or 2. This is because I want to produce the best solution I can and my ego isn't easily bruised. People's complaints are helpful to me in understanding the problem I am trying to solve while their suggestions for resolutions are usually not helpful.
Option 3 is the worst one. It solves nothing and creates bad-blood.
> I find the complainers are often those who don't have the > marketability to leave. There's a correlation with > unwillingness to be change agents and a correlation to > complain about the pile of shit they're sitting in.
If someone, let's say one of your employees is doing something you don't like. How do you address it?
> > > My feeling is "Stop bitching and do something!" > > > > Technically, bitching is 'doing something' but I'll > agree > > that it's often non-productive. On the other hand, > this > > is often a bullshit argument that people in positions > of > > power use when they don't want to consider ideas > contrary > > to what they believe. > > By bitching, I mean complaining. Saying things are bad w/o > proposing a solution is more than unproductive, it > pollutes the well and it is irresponsible.
I disagree. I've affected change with the help of coworkers. What started the ball rolling was complaining to each other. Just because someone doesn't have a solution doesn't mean they haven't identified a real problem. Most employees who complain to each other and not their supervisors because they don't feel comfortable doing so. They fear retribution. This may be imagined but just assuming that it's not management's fault is a cop-out.
> > Communicating dissatisfaction is not 'doing nothing'. > I > > would argue that communication is the first step to > > problem resolution in a civilized environment. > > > > [punchee] stop hitting me! > > [puncher] here we go with the victim mentality... > > And the tone of this is that it is a foregone conclusion > that managers are power hungry, abusive, and unwilling to > change. I also get the sense it is getting close to > personal - like I am one of those managers.
No. The point is that victims and victimization exist. Saying someone has the 'victim mentality' suggests that feeling is not valid. If someone is actually being victimized, they don't have victim mentality, they are a victim. Would you claim that the people of Zimbabwe are not being victimized by their dictator? If they just stopped having a 'victim mentality' would everything be better?
Your foregone conclusion appears to be that all managers are not power hungry, abusive, or unwilling to change. I think it's pretty silly to think that power-hungry people don't seek positions of power. That doesn't mean all managers are power-hungry, but let's be realistic. The more you want something, the more likely you are to try and get it and end up doing so.
> As I said in my early post, I think it comes back to how > and who you hire. I am a strong believer in individual > accountability and taking responsibility. I believe every > employee is a leader of some sort. Therefore I hire > developers who have a tendency to drive positive change > and have an aversion to complaining w/o action.
I know it's hard to believe but this thread isn't about you specifically.
Flat View: This topic has 20 replies
on 2 pages
[
12
|
»
]
Previous Topic
