Bad Manager

How do you spot a bad manager? I read a whole article on the topic. Sure it was a humor piece. But many of the tendencies rang true. I guess I have worked for a lot of poor managers. Haven’t we all? I thought I would share some of these are they are precious.

One such trait is that a bad manager is a vacation policeman. In other words, they are a vacation Nazi. You have to fight just to get one day off from work. On the flip side, they never say no to more work. They don’t do resource balancing. They commit you to more work that means you must work longer days and the weekends too.

Bad managers are overly concerned with their physical appearance. This is because they cannot stand on their merits. They need other ways to look good. Bad managers spend all day in Microsoft Project. This software is not inherently evil (unless you hate Microsoft). However you will accomplish nothing by trying to perfect a schedule in a project plan.

You can spot a bad manager because all they contribute in meetings is recording action items. You only hear from them when they need clarification on an action item. Weak. Bad managers are good a blaming others. How else do you think they get away being slackers? Finally a bad manager will jump ship even before the ship sinks. Why should they stick around when they know the project is doomed under their lacking skill set?

Priorities

We are a little short handed on the software development team. The workload is increasing though. Things were getting just too crazy at work this week. We have production trouble tickets to attend to. We just released some new functionality to our customer’s acceptance test team. They are generating trouble tickets as well. Finally we have new features to implement. My head was turning with all of this work on my plate.

I put out a call for help. What I asked my team lead and manager was the relative priority of these tasks. The manager set a definite order of priorities from top to bottom. Then seeing how we had a number of high priority items, had me and the other key members of the team divide and conquer the list. The result was a less stressful environment. There is still a lot of work to do. But at least I am not getting killed.

These types of management tasks should have been done already. You need to either conduct resource balancing to ensure people are not over worked, or set priorities and let the low priority tasks slip. I would think that a proactive manager would attend to these tasks,. But I am not against encouraging this get done. After all, I am directed affected by the chaos otherwise.

Risk Management

I read a blog entry by Glen Alleman entitled “Risk Management is How Adults Manage Projects”. From the title, I get the impression that Glen has been on some projects that lacked adult supervision. The sad thing is that it sounds familiar. Glen had a lot to say about risks that hit home with me. I figured I would review some of his thoughts, and share some thing I learned after reading his blog.

You cannot hope that things will be done in software development. Estimates from developers are usually random. You need a risk management process, as well as a risk management plan. The factors involved include cost, schedule, and performance. If you do not mitigate risk, you are already failing.

Now I have been on some software projects which lacked risk management, and they turned out fine. That may have been luck. I have also been on project with both risk management plans and processes. However many of those project failed terribly. Therefore I would not say that the presence of such a plan does not guarantee success.

Perhaps you need to do risk management correctly. The first project I was with that bombed had a risk management plan. However it was taken straight out of Risk Management 101. And it was mostly lip service to impress the customer. I will say that the customer was not impressed when the project fell apart and was deeply behind schedule when they needed it delivered.

I have been on other disaster projects that had huge risk management plans. They did a little more than provide lip service. There were processes that tracked some top risks. However the mitigation plans were totally lacking. This too resulted in huge failure. Embarrassing.

Some people who commented on the original blog entry referred to the DoD handbook. I can say that I never heard of such a thing. So I researched it on the web. The official name of that document is MIL HDBK 1908B. It covers early risk reduction through prototyping. It defines risk as a “possible loss of function and/or degradation in performance”. There is a lot more to this handbook. I just skimmed it today. It might be required reading for managers.

Lead By Example

As the author of the Software Maintenance blog can attest, a great Project Manager will lead the troops by example. Developers often need to stay late due to strict schedules. This is accepted as part of the business. One would think that the project manager of such a developer would want to stay late as well. It does not matter whether the manager has any real work to do. There is something to be said about being in a tough predicament together.

Merely staying late does not immediately qualify you as a good project manager. A truly exceptional one will manager a project such that you normally do not have to stay later. However there are often circumstances beyond the best intentioned manager's control. So at the minimum you should be willing to stick around or pull the all nighter if your staff is doing the same. Otherwise the staff will be asking themselves why they should be making the sacrifice when you are not willing to do the same.

This principle is a specific case of the general one to lead your troops by example. You can make all the speeches in the world. However if your actions betray your words, even simpletons will see through your hypocrisy. Step up to the plate. Roll up your sleeves. Stay in the trenches with your developers. They will take notice.

No Miracles

Our development team migrated our code to use new development tools this year. The install package and build scripts had to be modified. Our customer decided to perform a functionality test to ensure nothing got broke during migration. The updated installation worked on development and internal test machines. However we were unable to procure any workstations that matched the customer configuration. We delivered the installs for the functionality test. Of course the install did not work. A developer spent at least a day speaking with a system administrator at the customer site. But there was little to no progress.

I got the message that the development manager wanted to have a conference call to discuss the problem. We got all the facts regarding what our install developer had found. The manager wanted to see if there was anything we could do to speed up the install process. We decided that we could have the system administrator manually install and configure our application on the test workstations. The estimated time to complete this task would be about noon the next day. Fearing increased risk and schedule slippage, the manager asked how we could reel in that estimate to 7:00am the next day. This is where the conversations broke down.

Development proposed that the install scripts could be broken up which might relieve some of the risk. However the estimate was still at 12:00 noon. And so the manager continued to ask what we could do to reel in the estimate. That’s when we heard crickets chirping. We had already factored in developers staying late and bringing the work home to complete. So the manager wanted to review what it was that we were going to do from the top. It was unanimous amongst developers that we could minimize risk and accelerate the task if we got a workstation configured like the client’s site. Apparently that was not an option. So the manager continued to ask what could be done to reel in the estimate.

There were all kinds of problems going on with our meetings to deal with this problem. One part was that the software development manager was wasting a lot of time by keeping the whole development team in a meeting. The other problem was that we were not given the correct tools to do the job. Yes this might be normal for those of us who work for a pointy haired Dilbert style manager. But there has to be a better way to work in the software development world.

Technical Work

Throughout the year I have dealt with a lot of software managers and project managers. Most often than not, they have no clue as to what work needs to be done. So they are lost when it comes to producing schedules. Then a developer like me comes in and must spend a lot of time explaining everything to them. This goes on until the manager can produce a meaningful schedule. To me this is the opposite of adding value. If the entire task of creating a schedule was left to me, I would be able to get the job done faster. Instead I need to waste a lot of time bringing a clueless manager up to speed on the assorted development tasks.

You will imagine my surprise on my current assignment. My manager told me we had a lot of change requests to review and cost. I dreaded a lot of wasted time. Initially my manager thought there would be minimal impact to the application suite that we maintain. I found this strange and dug into the technical aspects of the changes. It was nice to find out that my manager was right. There were a few exceptions that I mentioned to my manager. He asked me a couple questions on each of the tasks I thought we would need to do. The next thing I know, I get a whole level of effort document listing all tasks and anticipated hours required to complete them. The manager did this for my team and for a number of other teams as well.

I find myself having more and more respect for this current manager. Perhaps he was a developer in a past life, and knows how to get technical work done. This enables me to focus on the matter at hand. I am currently designing the changes required for another huge change to our application. There is not a lot of wasted time in this arrangement. I get to go home on time. And I do not feel disgruntled because some lackeys are using up all my hours at work. Why does this good setup have to be the exception rather than the norm. It might be due to the fact that are few really good technical managers out there. Or maybe the time wasting schedule sessions are a necessary evil and will be a way of life as long as I am in software development.

One thing is for sure. When I find a good manager, I really want to continue working under them. Hopefully this is a win-win situation. I get to work on the things that developers should be doing. And then we deliver good software on time that meets or exceeds customer expectations. Then the manager gets the big bonus for setting the team up for success. The only chore I have right now it to make sure this good manager does not get promoted to higher position or another project. I wonder how someone in my position can do that.

Manager Jokes

I work for a pretty conservative manager right now. He is known to call "short meetings" which last forever. And I have noticed that he is always good for a bad joke. When I say bad, I mean the joke is just no good (not funny). The funny thing is that the guy is trying at least. We all laugh because the jokes he produces are weak. That in and of itself is amusing.

A couple weeks ago I found myself in the office working by my manager. Some girls walk by and asked him if he was good. He replied, "No. I'm bad". And do you know what? That line actually worked. Finally my boss nailed the punch line. Everybody including myself was cracking up. The irony of the statement was that my boss is not a bad dude. He seems like a goody two shoes. That's what made it so hilarious. I have confessed to him that his game is weak in the joke department, but that the "bad" comment was priceless.

You got to give the manager proper credit for trying to lighten the mood with weak jokes. I do.