Another resignation

Another top performer’s resignation was announced today. When asked, he is reported to have cited discouragement and frustration with a system that is often unwilling to allow a developer to use his best judgment, slow to grant approval. It makes our company a difficult place to do your best work. As a company improvements are being made, he said, and he’s hopeful that someday things will be better here; but in the end he couldn’t wait for that day.

As the authors of Are Your Lights On? would ask:


  1. It’s the developers’ problem. They must learn to work within our company’s established boundaries. If they cannot or will not, that is their own responsibility. The fact that developers are leaving reflects on those individual developers, not the company. OR,
  2. It’s our (the company’s) problem. We cannot afford to keep losing our best developers. To remain competitive, we must give our developers what they need to feel they are supported in doing the best they can at all times.

In my day-to-day dealings, I am not hearing #2 very much. I’m hearing a lot of #1. I find that personally discouraging.


2 thoughts on “Another resignation

  1. I think I might state the reasons slightly differently. In talking with a number of people, I find it hard to articulate well the frustrations that a number of people you have left (along with a number of people who remain) seem to share. The best I’ve been able to do is that it is draining to have to fight to be able to do things right and to, at times, be told to do something in the wrong way when a developer knows there is a better way to accomplish a task.

    One key issue is that good developers should be allowed to be just that, good developers. On multiple projects that I’ve seen, top performers have spent as much time attending project status meetings and writing Word documents as they have designing and writing code (on one project, my ratio was actually 75% meetings and documents compared to 25% coding). A related issue is the volume of support work that developers end up handling. If much of the administrative and support work were removed, or if developers were shielded from dealing with it to the extent they currently must, I think that top performers would be able to produce better code more rapidly and would end up with less frustration.

    The other main issue, I think, comes down to flexibility versus control. A recurring situation is when a developer or a team of developers finds a way to develop software with better design, greater testability, higher quality, or a combination of these items but ends up thwarted, or at least stalled, in their efforts to develop in this new manner. Examples of this could include when a developer is pressured to not write code-based tests or when a group is told to steer away from alternative development processes (such as some form of agile development). Such control issues are also present when a developer is not allowed to use the right tool for a particular task either by forcing a developer to use the wrong tool or by making the process to get approval to use the right tool so burdensome as remove the likelihood of acquiring and using the appropriate tool in a timely fashion. In theory, software companies want innovative developers to come up with novel and well-designed solutions to problems. Whenever one is constrained by a heavy-handed, top-down process, innovation is stifled. I think that many find the process “improvements” put in place over the last couple of years stifling and a significant portion of the top performers bristle at such constraints.

    In the end, I think the question top performers ask themselves is, “If I could work somewhere else, using newer technology, using better design patterns, where I won’t have to fight to do things right, where innovation is encouraged and will probably get paid better for it, why wouldn’t I leave?” The only answer to this question that I think keeps people is that they still have hope, hope for change, hope for the freedom to develop as they would like. Once that hope is lost, it becomes hard to come up with another answer to the aforementioned question.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s