« Corporate Culture | Main | Restructuring »
October 02, 2005
If The Phone Don't Ring, You'll Know It's Me
Continuing the trend of how to make developers happy.... management.
Management has the awful challenge of balancing out business needs with those of the staff, and often those needs are at polar opposites. While working at AGI I experienced one of those rare environments where both needs were inline. It was a glorious couple of years.
Part of the problem is managers put into positions they don't understand. In smaller companies this is less of an issue, as the manager can typically be a former member of the group or have been there when the group started. In larger companies this issue is more pervasive. Some companies, like Microsoft, have tried to solve this by creating the PM, usually an employee with a strong background and a lot of interest in the subject. This works to a point as the projects stay small. Once again as projects get larger and more visible, the interest builds, people with different interests, backgrounds, and agendas move in to complete their tasks and suddenly you're back to the setup not working.
None of this is new though. As a society we've invented entire schools of research towards this task, and pump out enormous amounts of graduates who are "qualified" to handle such problems. Between HR departments, and effective management books and training, there is an entire industry dedicated to help "solving" this problem. I sleep better at night knowing that "How to Be an Effective Manager" has helped saved groups. Really, I do.
The largest problem software managers have is visibility. I'm sure this applies to a few other realms of engineering as well, but software is the one I'm most familiar with. On a properly executed project, a large amount of time is spent understanding the requirement, designing the right answer, and finally implementing it. Oh, and testing, lots of testing added with refining the design. This process has pretty much become standard for every project ever done (even outside of engineering). Where this changes is in the final producable. In the case of other departments, i.e. marketing or sales, there is a tangible to be measured against. Total sales may fluctuate, advertisements may be more readily seen, or the AC may actually work again in the building. Within the software world, especially in the confines of project maintenance, the final product still looks, (generally) behaves, and smells the same as it's predecessor.
Under the assumption that testing resolved 80% of the most commonly annoying bugs, the last 20% are often bugs found in obscure methods that no one really uses, what did take all this time, effort, and money? The word processor function was working just fine before being re-factored, so what was the purpose? And why change it at all? End users are already familiar with the interface and expect to easily use the next version.
At this point, the commentary begins to loopback into the first issue of keeping software development happy; projects. Why are new projects so important? The secret is in the corporate culture.
Most large companies have an advancement process. Once or twice a year management asks you to collect "360 feedback", the process of having your peers (as defined by you) rank your performance. After that you write up your "brag sheet" which your manager takes into a closed door meeting and champions your case for performance. Out of this meeting you are now ranked corporate wide as either being 'needs improvement', 'average', or 'exceeding expectation'. Only the last will actually get a raise and be assured some type of job security.
This type of corporate advancement has an adverse effect of forcing employees to constantly search out new avenues of work. The newer avenues of work will allow a greater internal corporate exposure, thus advancing a programmers ability to get job satisfaction through recognition. Further feeding into the source of the problem, a lack of developers willing to work on code maintenance due to minimal amounts of company exposure. This vicious cycle will leave projects dead by the wayside and programmers burnt out.
[EDIT: grammatical correction]
Posted by Dan at October 2, 2005 03:19 PM