Return of the Mac

Sometimes you get to escape bad management. Other times bad management comes back to haunt you. This is the case with me and Mac. I worked under him in a failed, huge project. The details of that project are not important. What is amazing is that a lot of people got fired. However Mac stayed clean. He somehow had the ability to avert blame for failure that was clearly on his watch. Nevertheless I found myself working for a better manager eventually.

Then came the horror. My good manager moved on to greener pastures. And who comes back to take over my project? Yes. It was Mac. I knew we were back to bad times when Mac started making decisions. Decisiveness is actually a desirable quality. The problem with Mac is that he never informed the customer of his decisions. I guess that is because they were unpopular command decisions. So I had to call him out this on. The result was that a subordinate had to do the dirty work and give the customer the bad news. Little did we know that this subordinate would be the first of many to leave the project.

There are a lot of other problems working for Mac. He tries to delegate everything, especially the responsibility. I somehow got dragged into a meeting with him and other leaders. Turned out to be a very depressing sight indeed. Lot of wasted time with nobody taking any real stances or accepting any responsibility. I often wonder how Mac remains in the organization. Perhaps it is because on paper he looks like a star. He has all kinds of degrees (like an MBA) and certifications (like the PMP). Perhaps it is time for me to high tail it out of here too. It appears the smart ones are jumping ship.

The Right Stuff

So many of my posts have been about bad managers. Now I would like to focus on a good one. Peter Giles started out leading a team. Then he quickly became the manager of that team. I was not on the team that he managed. But I moonlighted helping them out. I found Peter's skills exceptional. He knew how to keep morale high when times were tough. More importantly, he knew how to protect rank and file employees from being bothered by customers. This allowed members of his team to get things done.

I recall one specific instance where the customer asked if we could oversee an integration test for the customer. I told the customer that I thought this was acceptable. But Peter came out and stated that this work was out of scope and we would not be doing it. He was nice but firm with the customer. Basically he said this was not our job and we needed to focus on our contractual tasks. In the end, the customer found somebody else in their organization to do the work. That's a leader I want to work for.

In a few months I got my wish. Peter was promoted to manager of the entire project. We have quite a large project too. When I went to Peter's cubicle (now a corner office), I recall noticing leadership books on his bookshelf. I guess these were not for show. Peter was easy to deal with because he started out as a developer and then became a team lead on another project.

The irony of this good manager is that the customer decided to get rid of us and let another company take over the contract. I almost wanted to follow Peter on whatever project he transitioned to when he was done. Pete seemed unconcerned about the project ending. He made a couple calls to some friends of his, and got a couple jobs offers immediately. When you are good you get many options I suppose. I think I want to dissect more of Pete's outlook and track record in the months to come on this blog.

Working For a Sub

I guess working on troubled projects is the story of my life. At one such problem project I found myself reporting to Pradeep Kumar. Pradeep was unique in that he was not an employee of my company. He was a subcontractor. This posed a number of problems for me. I could not get straight answers to questions on company policy. Pradeep had to consult someone else before giving me even the most elementary of guesses.

Pradeep had other problems like not having the right clearance level to view sensitive data from the client. So he had to use a hands-off policy of managing. Pradeep also came in when there was way too much work promised in too short a time. He told me he had success in many other projects. At first I thought they hired him to turn the project around.

In the end, Pradeep just turned out to be the fall guy. There were already prior managers that were coolateral damage on our doomed project. Pradeep was just another one that got fired instead of reassigned. I actually liked Pradeep personally. But he was unable to excel and overcome the obstacles of a bad project. And a lot of it was due to the fact that he was not a direct employee of our company.

Too Little Too Late

When working for another problem project, the project manager was "moved" off the project. The replacement manager did not last long either. He was promoted away from our project. During the couple months when this 2nd project manager was in charge, the company hired Keith Littleton to assist. Keith jumped around getting a number of titles. One thing that stuck out in my mind was Keith's first day. He stood up in a meeting of the entire project and asked where the documentation was. This struck me (and a lot of other people) as odd.

Keith had a lot of catch phrases he would utter. But I do not think they meant anything tangible. After a while Keith ended up in control of the whole project. He hired a bunch of his buddies to staff the project. Some of these buddies were OK, others were lackeys. I will give Keith this. He worked a lot of hours on the job. But his management skills could be summed up as incompetent. He seemed to let the customer dictate how the project would be managed. All kinds of craziness ensued.

On paper, you would think Keith was a genius. He had a lot of credentials. You know, things like degrees and certifications. But none of these appeared to help with his management skill set. Eventually Keith was also "promoted" away from the project. Last I heard he staffed up a small team that had nothing to do with software development. The company, I believe, is benefiting from this arrangement.

Used Car Salesman

I joined a problem project a number of years ago. The problem started by a decision to reengineer and reimplement the entire project. So all changes in the old system that were slowly being phased in were accelerated to production. The result was a bunch of production software that was not ready for prime time. The maintenance team was managed by one Sally Mayner.

The best way to describe Sally was that she resembled a used car saleswoman. And she was a good one at that. Sally could talk her way through unhappy customer meetings. However she was severely lacking in technical knowledge. And it appeared her goal was to cover herself from blame. The result was that a lot of team leaders under her were frequently put in front of the customer to explain the details of every single problem that was wrong with the system. This meant they were unable to spend a lot of time leading the teams that were supposed to resolve these problems.

Like many doomed projects, the direct effect was that everybody had to work a lot of unpaid overtime. The customer demanded it. And Sally caved in to their demands. After a couple months the developers got tired of working every single weekend. Many good developers left. The others just revolted against Sally. Sally was sure to document this and inform senior management and the customer. I think you could call this un-management or non-management.

In the end Sally left the company. While departing she said the reason was that she could not take the stress of facing the customers on the job. When I heard this I was puzzled. Sally did have to listen to some unhappy customers. But she passed the blame and the customer management tasks down to team leaders. So I am not sure what type of stress she was concerned about. I guess we may never know. But given a poor example of how not to manage irate customers, I can think about the anti pattern of better customer management and learn something.

You Schmooze, You Win

I spent a good deal of time on a large software project for an unspecified government organization. The top dog on this project was John Hopper. John was a very personable fellow. He had a lot of technical experience. However on this project he concentrated only on project management.

John delegated all technical decisions to another leader. He actually delegated most of the project management details to another company working on the project. This did not mean that John was not doing a good job. On the contrary, John did a lot for the project. He would keep the customer happy. You cannot put a price on that skill.

Years later after John had moved on, I learned just how important John was. Under new management the customer had grown unhappy. It is bad enough when there are many software problems that you need to fix fast. But it is double trouble when you need to continue to meet with the customer to explain why everything is screwed up. Under John Hopper's leadership, I almost did not know who the customer was because the project was being managed so well.

Experience Count Some

I was working on an interesting project. But my manager was not working out. So he got the boot and was replaced by Paul Sophos. I got the impression that Paul had some experience leading teams. That did not necessarily mean he was good at it. Just that he had done it for a while.

One good thing that Paul did was appoint employees of our company to lead each of the teams under him. This kept out company in control, and the subcontractors working for us. However Paul did not seem to keep up with the details of what the leads were doing. This works fine when things are going right. Things in software development usually do not go right.

In the end out company lost the contract for this work. I do not know if this was due to any shortcomings in Paul's management skills. It does not speak well of the situation though.