The Management Delusion

A good friend of mine sent me this:

Subject: New Stroustrup quote

"The companies are complaining because they are hurting. They can't
produce quality products as cheaply, as reliably, and as quickly as they
would like. They correctly see a shortage of good developers as a part
of the problem. What they generally don't see is that inserting a good
developer into a culture designed to constrain semi-skilled programmers
from doing harm is pointless because the rules/culture will constrain
the new developer from doing anything significantly new and better."

Those companies are in a bed of their own making. They want software written on a schedule which means hiring warm bodies who have the minimum training, enough to run a compiler, and can crank out code on a consistent basis; consistently low quality and in a consistently long time. When the pain of low quality software finally registers through their management-induced fog, they look for answers. What keeps these "Leaders" from admitting their own contribution to the problem?

Leadership sometimes means making hard choices, almost guaranteed to make someone unhappy. Leadership sometimes means suspending self-doubt to enable making those hard choices without the burden of guilt. Consider car company executives contemplating closing a factory - let all the employees down through bankruptcy or let a smaller set of employees down through a layoff? The best example of this would be President Truman's decision to use the A-bomb on Japan. Good luck trying get them to second-guess themselves - to do so would mean letting self-doubt out of the tiny box in which they hide it. Now, for the leader of the free world, we can understand why self-doubt is a luxury they can't afford.

What about the corporate world? Well, the upper-level executives may catch a break when they have to make truly gut-wrenching decisions like the car company example above. Middle and line-level managers do not have those reasons to hide behind so what's their story? Even without earth-shattering, bet-the-company decisions to make, a manager faces the same dilemma, how to isolate their own sense of self-worth from being damaged by potentially bad decisions. One way of doing this is by never looking back, never re-examining prior decisions, not entertaining the idea that they made a bad choice which is, by the way, popular with leaders at any level.

This may keep them from being paralyzed with self-doubt or wracked with guilt but is also makes them oblivious to their own short-comings. It takes a strong leader to learn from their mistakes, to emerge from self-examination stronger because they own up to their mistakes and learn from them.

Here then is the key. Allow me to extend the quote to the next logical step. Companies that are complaining about the lack of good developers are in a state of denial. What they are really complaining about is how few good developers want to work for them. There can be many reasons from an environment that accepts mediocrity to the unwillingness to pay the good ones what they're worth. In the first case it could be the red-tape just to get their development workstation setup, "What do you mean I have to get each Eclipse plugin on the approved software list!?!?" In the second case it could be failing to attract good talent; after all its only fair for a programmer that is 10x better than average to get paid 10x the average, right? Describing your workplace as "We have reasonable development policies and reasonably good salaries" you should not be surprised that you have reasonably talented programmers. To deny this is effectively admitting to self-delusion.

So, when your boss complains about the lack of good developers, they are really trying to deny their own reality and shift the blame away from themselves.

This reminds me of a story about 10 hiring managers who all insist they hire only the top 10% but I'll save that for next time.

Process Paranoia

Is your manager part of the problem or the solution and how can you tell?

Allow me to tell a story.

You are a developer on a large project that involves a large portion of the IT department not to mention multiple external stakeholders and has lots of moving parts and many upstream project dependencies. There are a large cadre of contractors working on a bug-list that keeps growing. The test environment is so complex that features can't be tested outside of certain windows due to the difficulties in getting all the moving parts built and installed correctly (no disrespect here, I mean it's that complex of a beast). The powers-that-be freeze check-ins to the development environment to reduce the number of moving parts during a weekly (yes, not daily) build/package/deploy to test. We won't get into the easy ways to handle this like tagging or snapshots, the management, which includes the technical leads, of the project have been working extra hours for weeks and don't have mental bandwidth to discuss theories. The large influx of developers who are supposed to help fix bugs only further tax the original developers with requests to help setup dev environments, understand the database, or request additional access to various resources.

This is not new, Brooks wrote about it decades ago so why am I writing about it now? With a project like the one that I've described, change management becomes a key tool in maintaining sanity and enabling success. By predefining a process and a set of criteria by which change requests will be evaluated, management has the power to be in control of the project schedule. One such example would be "Once the project has begun User Acceptance Testing, no more change requests will be accepted without approval by the CIO." The level of approval needed would of course vary by the priority of the project. There can be many such rules so that the threshold for permitting a change request rises as the project gets further into the development cycle.

If 'Analysis Paralysis' is the tendancy to continue to analyze past the point of diminishing returns, 'Process Paranoia' is the tendancy to reject efforts to define processes from a misguided attempt to forstall Analysis Paralysis. How is this connected to my tale of development woe? One of the upstream projects wants to provide a function for their customers which otherwise would require said customer to log into a second system to perform a query and then use the results in the upstream system. Normally this type of integration is commendable and encouraged. Why not now? When the managers allow change requests to be considered on an ad-hoc basis, it becomes highly probable that some request will trigger a fire drill of effort in order to evaluate the feasibility or ramifications when that decision should have been simply a matter of saying "According to our change management process, no change requests are accepted even for evaluation once we enter the testing phase without CIO approval." End of story. To do otherwise is almost guaranteeing that a project that was chugging down the tracks will eventually become a large trainwreck waiting to happen.

So the question is, does your management believe/understand/support proper change management processes or just pay them lip service? The answer to this last question goes a long way to answering the initial question of this post.