rss feed
In other words, if it weren't for the minor fact that you guys are completely competent at your jobs, you'd all be canned. The quote above is indeed a near word-for-word utterance from our development manager. Apparently, it wasn't enough to be good at what we did. It was also expected that we keep our mouths shut and do as we were told, rather than coming up with improvements to our development process or pushing back in the face of backseat coding (http://coderific.com/blog/post/474).Developers in general are highly educated people. Many have college degrees. Most have years of development under their belts. There exists a huge amount of perspective and knowledge among any team of developers. Then, why is it that developers are so often ignored when it comes to organizational decision-making?Well, there are many reasons, but a big one is that corporations in this country are typically structured with a command and control style of management (http://www.joelonsoftware.com/items/2006/08/08.html). To quote Joel:
This sort of approach might work in the military, but it doesn't work so well with knowledge workers such as software developers. Firstly, a developer who feels that they can provide valuable input into decision-making is usually right. No one is in a better position to understand the technical development trade-offs that may affect a particular organization than the person actually writing the code. Sure, there are many bits of information that a developer in the trenches cannot see, such as most things related to sales. But there is even more information that most managers cannot fathom, and that's what makes a developer's perspective so incredibly valuable.How about an example. Let's say that management hands down a request to your team to develop a poorly specified new product, and you have under three weeks in which to do it, on top of all your existing development responsibilities. Now, any developer giving even a cursory glance to the particular request can tell that three weeks won't be sufficient, and any coder who bothers to task out the work will realize that it's a multi-month endeavor.This exact scenario happened at one of my prior development jobs, and so my team pointed out how long the task would really take, about 13 weeks. We even backed this number up with a document detailing our estimates and the rationale for them. As a result, the project was yanked from my team, handed to another team comprised primarily of yes-men, and my team was then bad-mouthed as non-team-players. I'll let you guess how long the team of yes-men ended up taking to implement the new application. That's right. A little over 13 weeks.Why doesn't management have sufficient perspective and knowledge to figure this out on their own? Simply put, they're not developers, and they don't have the necessary experience and knowledge to make accurate estimates. This is especially so given that development management is usually under direct pressure from above to come up with estimates that are as short as possible, or even shorter than possible. Developers, on the other hand, while often under similar pressure, have the direct technical knowledge and familiarity with the code base to at least somewhat accurately break the task into its constituent parts and come up with good estimates. Developers are simply better at any decision-making involving technical considerations because they have more information directly relevant to those decisions.So ignoring the opinions of developers has obvious implications when it comes to good organizational decision-making. But a perhaps unintended consequence is that it causes otherwise good, hard-working developers to become alienated. Developers are some of the people most uniquely qualified to make decisions on technical matters, and yet their opinions are often given the least credence of anyone in the organization. This disconnect causes developers to feel like they're just being treated as replaceable resources rather than valuable members of the organization. If a company is at all interested in retaining its employees, there's no better way to do so than to actually listen to their opinions.
blog - ignore developers at your own peril
posted by witten on April 29, 2007
First, a little background. One of the development teams I used to work on was a fairly tight-knit group of coders. We got along well, and we even hung out occasionally outside of work. Our specialty was Python and C++ on Linux, but we did Windows development as well. This was problematic, because the rest of the organization in which we worked was populated largely by Microsoft apologists. However, we did generally produce good code. So other than the occasional half-hearted attempt to convince us to rewrite all our products in C#, we managed to get our work done in cross-platform Python and C++. And it was usually done on schedule despite our having little or no input into the scheduling process.Our team was also fairly vocal about development process changes. We came up with new ways to improve productivity, and we weren't shy about expressing them to management. We introduced a ticket tracking system that was eventually adopted company-wide. In general, we weren't content to just sit and code. We also wanted to be part of the decision-making process insofar as it affected development. This was also problematic, because management preferred that developers were seen and not heard.So with that in mind, imagine being told the following by your manager:
If it wasn't for the fact that you guys wrote high-quality code, got it done on time, and worked well together as a team, you'd all be fired.
In other words, if it weren't for the minor fact that you guys are completely competent at your jobs, you'd all be canned. The quote above is indeed a near word-for-word utterance from our development manager. Apparently, it wasn't enough to be good at what we did. It was also expected that we keep our mouths shut and do as we were told, rather than coming up with improvements to our development process or pushing back in the face of backseat coding (http://coderific.com/blog/post/474).Developers in general are highly educated people. Many have college degrees. Most have years of development under their belts. There exists a huge amount of perspective and knowledge among any team of developers. Then, why is it that developers are so often ignored when it comes to organizational decision-making?Well, there are many reasons, but a big one is that corporations in this country are typically structured with a command and control style of management (http://www.joelonsoftware.com/items/2006/08/08.html). To quote Joel:
Primarily, the idea is that people do what you tell them to do, and if they don't, you yell at them until they do, and if they still don't, you throw them in the brig for a while, and if that doesn't teach them, you put them in charge of peeling onions on a submarine, sharing two cubit feet of personal space with a lad from a farm who really never quite learned about brushing his teeth.
This sort of approach might work in the military, but it doesn't work so well with knowledge workers such as software developers. Firstly, a developer who feels that they can provide valuable input into decision-making is usually right. No one is in a better position to understand the technical development trade-offs that may affect a particular organization than the person actually writing the code. Sure, there are many bits of information that a developer in the trenches cannot see, such as most things related to sales. But there is even more information that most managers cannot fathom, and that's what makes a developer's perspective so incredibly valuable.How about an example. Let's say that management hands down a request to your team to develop a poorly specified new product, and you have under three weeks in which to do it, on top of all your existing development responsibilities. Now, any developer giving even a cursory glance to the particular request can tell that three weeks won't be sufficient, and any coder who bothers to task out the work will realize that it's a multi-month endeavor.This exact scenario happened at one of my prior development jobs, and so my team pointed out how long the task would really take, about 13 weeks. We even backed this number up with a document detailing our estimates and the rationale for them. As a result, the project was yanked from my team, handed to another team comprised primarily of yes-men, and my team was then bad-mouthed as non-team-players. I'll let you guess how long the team of yes-men ended up taking to implement the new application. That's right. A little over 13 weeks.Why doesn't management have sufficient perspective and knowledge to figure this out on their own? Simply put, they're not developers, and they don't have the necessary experience and knowledge to make accurate estimates. This is especially so given that development management is usually under direct pressure from above to come up with estimates that are as short as possible, or even shorter than possible. Developers, on the other hand, while often under similar pressure, have the direct technical knowledge and familiarity with the code base to at least somewhat accurately break the task into its constituent parts and come up with good estimates. Developers are simply better at any decision-making involving technical considerations because they have more information directly relevant to those decisions.So ignoring the opinions of developers has obvious implications when it comes to good organizational decision-making. But a perhaps unintended consequence is that it causes otherwise good, hard-working developers to become alienated. Developers are some of the people most uniquely qualified to make decisions on technical matters, and yet their opinions are often given the least credence of anyone in the organization. This disconnect causes developers to feel like they're just being treated as replaceable resources rather than valuable members of the organization. If a company is at all interested in retaining its employees, there's no better way to do so than to actually listen to their opinions.
2 comments
Write a comment!-
Re: ignore developers at your own peril posted by kmx on April 29, 2007 01:04 PM
This is a nice article. Your experiences tally with mine. However, I think that you've missed something in considering why managers ignore developers.In many companies, and certainly all large companies, career progression reigns supreme. Advancing one's career is at least as important as advancing the company's product(s).The problem is that it takes a certain type of mentality to become a career-oriented manager. Most worthwhile, self-respecting developers don't want to become management, but some do. Those people who are more inclined to politics than technology will become managers.As these people move up the career ladder, the only thing that matters is the next level, and how to get there. Usually they want to get to the next level as quickly as possible. They will specifically search out and employ the means of realizing this goal, even at the long-term wellbeing of the company. If achieving the next promotion requires that a task be done in three weeks, then its going to happen that way.Usually, the person who makes the decision is long-gone up the ladder before the consequences of the decision are realized. Alternately, these politicians also have the means for pushing the responsibility away from themselves, towards others who aren't as capable of defending themselves from such attacks.Tell me this, when management found out that the project took as long as your team had estimated, was any acknowledgement given to your team? I'd guess probably not. Probably the management made excuses for the other team.Just my cynical opinion. -
Re: ignore developers at your own peril posted by witten on April 29, 2007 01:22 PM
kmx wrote:In many companies, and certainly all large companies, career progression reigns supreme. Advancing one's career is at least as important as advancing the company's product(s).
I completely agree with this. The command and control management style often goes hand-in-hand with career managers concerned more about their own title than in actually making a good product. In fact, the manager quoted above was this very sort of person. He was instrumental in layoffs and firings of several developers, and was subsequently rewarded with a promotion.Usually, the person who makes the decision is long-gone up the ladder before the consequences of the decision are realized. Alternately, these politicians also have the means for pushing the responsibility away from themselves, towards others who aren't as capable of defending themselves from such attacks.
And I think this is at the core of the problem. In most organizations, managers are never held accountable for their bad decisions. If something goes wrong, such as a missed deadline, the developers are blamed. If something goes right, the manager claims all the credit with the coders getting perhaps a pat on the head. As long as this sort of system is in place, the incentives will be for managers to act like this.Tell me this, when management found out that the project took as long as your team had estimated, was any acknowledgement given to your team? I'd guess probably not. Probably the management made excuses for the other team.
You guess correctly. No one in management recognized that the project ended up taking as long as we had originally estimated. In fact, success was declared only a few weeks into the project, even though it took another several months to actually finish it.I think part of it is that in many companies, organizational memory is particularly selective. People remember that a development team pushed back against an unreasonable schedule, but no one seems to remember that in the end, the developers turned out to be right.