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.

Putting Lessons to Work

Through some unfortunate circumstances, I got drafted into leading a software development team again. I don't like doing management type work. But I might as well do a good job while I am there. It is easier to lead when you have seen examples of good and bad leadership to learn from.

One thing I try to do it make sure I disseminate information to my team. It is no fun when you are a rank and file employee, but don't get important info from your boss. Some managers try to do this by holding regular meeting. I personally think meetings are evil and a big waste of time. So I just pass information along via e-mail. If we need a face to face, I keep the invite list small and do the meetings ad hoc.

Another thing I do is try to help developers when they get lost. I don't want to step in and do the work for them. But they frequently need guidance to make sure they do not get into trouble. And I try to take over the administrative tasks so developers can do what they do best. A developer needs access to some data? I fill out the paperwork and make all the calls to make it happen. Another developer needs some the ability to do a new task in our trouble ticket system? I submit a ticket to system administration on their behalf. I like it when a manager takes care of these things for me. I just do what I would want somebody in charge of me to do.

However not everyone is cut out for management and/or leadership. In fact, I do not think it is a good role for me. Yes I can get the job done effectively. But my self satisfaction is sacrificed. Time to see how I can get out of this role and back into development full time.

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.

Out of Control

At one slow point in my career, I found it hard to find work aligned with my skills. I could pretty much do any type of development. But I wanted to focus on Windows application development. So when Tony Dickerson offered me work on a perfect match for my background, I jumped at the opportunity.

Once I came to work for Tony, I found he had a number of subcontractors on the project. This in of itself does not necessarily mean trouble. However the subcontractors were pretty much in charge. It seemed like Neil was working for the subcontractors. Now these subcontractors were all very good. But the direct employees were left having to deal with out of control subcontractors.

I think as a manager you need to understand the goals of who works for you. Employees need to be your bread and butter. They need to be trained to help achieve the company's objectives. Subcontractors and consultants usually have one goal - make the most money possible. When this goal aligns with the company goal you get a win-win. But often this is not the case.

I stayed on this project for many years. Eventually Neil was let go, and the subcontractors were shown the door. But by then a lot of damage had been done. A lot of key employees left because of the weird organizational structure.

The Great Overseer

In my area we have a lot of government contractors. They are good to work for because they have a solid flow of income from working the contracts. I joined a project at one such company. However I worked for a separate subcontractor. My boss at the client site was Neil Mollard.

Neil had a hands off policy with the software development we performed. He let team leaders work the technical issues and the software process. Neil only required status updates from his team leaders.

Most of the staff under Neil were direct employees of the company. A few of us were subcontractors. But our tasks were well defined and our contract lengths were limited. Neil only had one consultant working with us. But this consultant billed minimal hours.

Neil was shrewd in negotiating subcontract agreements under which he could hire the subcontracting employees if need be. He did this with at least one subcontractor while I was there. And even though I assumed a technical leadership role on his project, when my subcontract was over I had to go.

While there, Neil and company had a very successful software launch. Nobody worked overtime. The process was disciplined. The goals were clear and achievable. Subcontractors were managed well. I almost wish I was able to also join the company as a permanent employee. Perhaps some day I will get the chance. I left with an example of how to successfully manage software development. Cheers Neil.

Construction Mentality

I joined a commercial software company for one gig. At first I tried to get my manger Hakeem Moustaf to pay me as an hourly contractor. But we could not agree on a rate. So I signed up as an employee with full benefits.

We had a successful old product. And the team was tasked with implementing a newer version from scratch. This was a massive undertaking. Hakeem's title was VP of Software Development. His background was managing construction projects. And so he was used to hiring contractors to do the work.

Only two of us on the development team were direct employees. Everybody else was an hourly contractor. These contractors were sharp. I am not sure how much they cost the company. But we ran out of money quickly. Part of the problem was slow sales. But I cannot help but think the hourly rates of all these contractors milked the company dry.

There was one benefit to having contractors. When we were low on cash, the contractors did not get paid. But after a while the contractors bolted. I followed them shortly when the company started having trouble meeting payroll.

Use of contractors is not inherently evil. But the costs must be managed carefully. When you rely on too many high paid contractors, doom may be near if your budget is limited. Lesson learned.

Work Harder

I joined a really cool team of developers. My new boss was Bill Hickman. He was another guy with a lot of software development management experience. The staff was really good. So even with ambitious schedules we were able to deliver pretty well.

Like most managers, Bill's idea to get on track when behind was to work more hours. I guess I can understand where this thought comes from. One might think if a developer can code 5 widgets per week when working 40 hours, they can produce 6 widgets if they work an extra 8 hours a week. Luckily I knew that the extra hours would not linearly turn into extra output. So I just refused and went home after my 40. But during those first 40 hours of each week I produced like crazy. The result was successful software that came in a little later than the original estimates.

Why do most managers like Bill fall for this fallacy? The solution to falling behind schedule is not to institute a death march. The last time I signed up for such madness, me and other key developers were booking 80 hours a week. We did this for months. The result? Failed project. You get tired and you start making so many mistakes that extra hours actually move progress in the wrong direction.

It is not that Bill was a bad guy. He just drank the kool aid of clueless project managers. You got to do your due diligence in managing a project, its schedule, and its risks. Don't expect that adding mandatory unpaid overtime will get you out of a mess you created. We need more developers to fight this insanity, myself included. Note to self: "Just say no".

Remote Management

I worked for one company that did most of their business in the mid-west. The had a small office near my house to do some software development. When the software manager there got fired due to mismanagement, he got replaced by Kevin Montana. The funny thing was that Kevin was located in the mid-west branch of the company. So he tried to manage the project remotely.

Every couple weeks Kevin would fly in to check up on the development team. And he would hold conference calls frequently to keep up with our progress. In theory you would think this would work. I guess they wanted to save money by not hiring another local manager. And for a while this seemed all right with my.

But when problems started to occur, I could not walk into my manager's office. I had to try to call up my manager instead. And Kevin was in charge of other projects back home. This double whammy took its toll. Had there been a local manager, maybe we could have communicated better and addressed a lot of the problems that kept popping up. Rather than continue to deal with this remote management situation, I switched to another company where my boss sat in the office next to mine. This arrangement had some other drawbacks. But at least I could walk over and chat about potential issues before they became huge problems.

Signs of Doom

As I have previously posted, I spend a lot of time on projects that are in trouble. Maybe problem projects are the norm in software development. Or maybe these are the only firms desperate enough to pay a high salary. Whatever the case, I found myself working for Pete Fedrali on one such project.

On the surface the project was cool. We had to replace an old hardware system by implementing a lot of it in software. That meant writing a lot of code from scratch. The company I was working for had little to no experience in software development. Pete seemed to be an experienced software development manager.

The project itself was doable. But there was no way we could design, code, test, and release such a complex project in a couple months. We had actually collected and documented requirements for the project. So I wrote down each requirement number on a big white board. Then I marked off each requirement as I thought I had coded the implementation for it. Just looking at my white board, you could tell we were never going to come close to the completion schedule. Pete mainly did not want to look at my white board.

As the delivery date came and passed, Pete acted surprised that we were behind schedule. Maybe Pete was not such a good software development manager after all. Once the customer realized we were doomed, the party was over. All developers were instructed to stop coding. Another firm was hired to analyze the situation and figure out it the project could be salvaged. One by one the developers left for other jobs. I was the last developer from my company on the project. By then Pete had left too. I told the new manager that I would turn the lights out as I too left for a new job.

There must be a right way to manager projects that fall behind schedule. One wrong way is to ignore the obvious until it is too late to do anything about it. A highlight from this debacle was when the owners of this huge company invited me to come to their executive offices and explain what the problems were and whether we could recover. I told them we could definitely implement this system successfully. But realistically it would take a whole lot longer. Owners were not too happy that day.

The Workaholic

It seems that I have the knack of joining projects that are doomed. On one such project I reported to Judy Simmons. She could be summed up in one word as a "workaholic". I am not sure if this was a personality disorder, or whether this was just how she wanted to live her life.

The problem with working for Judy was that she could not say no to unreasonable requests. This impacted the development team when Judy accepted more tasks for us even when we were already overwhelmed. I think a necessary trait of a good manager if having the gumption to stand up and tell people no. Even if those people are the customer. Now there is a politically correct way to communicate this. But I believed it is a rare and acquired skill.

In the end, Judy burned out and quit the project. Not everything was bad working for Judy. It was surely a wild ride. I like to learn new stuff and pump out new code. With all the tasks that came in and got assigned to me, I got a lot of experience in a very short time. However the end result was a failure that made the company look bad.

Middle Management

After my years working for little contracting companies, I started working for big companies. At one such company I found myself hired by Tim Korpal. Tim's actually title had vice president in it. However I think he was a junior vice president based on his duties. The company was a privately owned one. The owners seemed to rely on the advice of consultants over that of guys like Tim.

One problem with Tim was that he knew there were problems on our project, but he did not know the details of them. Tim seemed to be caught in a middle management nightmare. The owners of the company wanted him to fix the problems. But Tim seemed clueless. It was not that he was not ready to do what needed to be done. I saw him come down and fire people when necessary. But he still could not get his hand on the trouble that was preventing success.

Even though Tim was out of touch with the project mechanics, he seemed able to determine that I quickly became a key member of the project. He gave me a 10% raise on my first review. For all the value I was adding, I thought this raise was mediocre at best. So I called up Tim and told him so. I told him I liked working on our troubled project, but I needed a whole lot more money. To Tim's credit, he went to bat for me and got me another 33% pay increase. Maybe I was already a bit underpaid so this was no big deal. But when you are in charge of a problem project, and you have to tell the owners that a key guy needs money, I bet it takes a lot of leadership ability to not fold.

In the end I moved on to another project. But it was not due to problems with manager Tim. The project was basically doomed. The only guys that stayed were subcontractors that were billing the company at a very high rate. Tim may have fared better if he was able to figure out and resolve the problems on our project. But software management is hard. And I consider Tim one of the better mangers I have served under.

Tiny Company

For a couple years of my career, I found myself working for a lot of small contracting firms. Maybe it was the area I lived in. Or maybe it was the sign of the times. Either way, I ended up working for Frank Sellers. He had a shop of about 30 technical people. Some of us were programmers. Others did system administration. You knew we were small because Frank's wife did the books.

One benefit of working for a small company was that you felt significant. And Frank made sure all employees felt the family love. It was not that Frank was not professional. Rather he created a cozy environment that was very positive. Even when I had to spend most of my time at client's sites, I still felt like I was part of the small company family.

Another good thing about Frank was that he made sure that any problems I had with the company were resolved quickly. He answered his own phone. And he would get things done when I needed help and it was in his power to do something about it.

The only detriment to Frank's operation was that he was small. He said he was not able to pay me much. So I stayed with him as long as I felt like I was learning the skills necessary for my career. Frank's company had no budget for me to attend even the cheapest of training seminars. Frank said he had an obligation to the bottom line, since it was his money at stake.

I can only hope that Frank was able to grow his business and grow the value he gave to his employees. There were some sharp guys working for him. Maybe they paid them better than me. Because some of them worked for Frank for many years. I do look back fondly on the time I was employed by Frank.

The Little Guy

I worked for a mom and pop job shop. The sent me to their client's site. I reported to Tony Amadi, who was an employee of the client. Tony was a little guy. He had a window office to himself. But he had so many files stacked up all over the place, you could not tell there was light from the outside.

Tony had me working on a system that was put into production a bit too early. This was tragic because it was a high profile system. My job was to fix all the bugs. More importantly, I was to demonstrate that there was a competent developer working full time to get the system working right. The guy who initially developed the system took off.

Tony worked on a number of other projects. He did not have time to babysit this broke down system. That is why I had a job. To be fair, Tony was not really my manager. He just worked for the client and was responsible for getting my company a contract. But I had little contact with my own company. So I treated Tony as my manager.

There was a lot of politics going on at this client's site. Tony had me work on writing up some papers and doing other work for publications. But I could not claim ownership of any of these works for "political reasons". Hey. As long as I was getting paid, I did not mind too much. But deep down inside I had some regrets.

I understand that contractors like myself often get the short end of the stick. But this contract was pretty bad. I brought a number of issues to Tony. He answer was normally to just deal with it. Not good. When I got to a point where I fixed a good deal of bugs, and figured I was not learning anything new, I moved on to another job. Did not stay long at this location.

Turns out my replacement on this job was a lackey. Tony had my contact information. So the new guy called me up and asked me to debug a bunch of problems and give him the fixed code. I told him (in a diplomatic manner) to do his own work. Tony tried to get me back as a consultant, but I had better things to do.

If you want to keep good people, you need to give them the tools they need. Otherwise good people always have many other options. Be careful or you may regret it in the future. Sometimes you need to manage your contracts even though you are not their true manager.

Rising Up

Lenny London was promoted up to senior management. He had apparently started out as a developer and worked his way up the food chain. Lenny had respect from above and below. That is, the rank and file programmers respected him for his deep domain knowledge of the system. And vice presidents loved him too.

Every once in a while, when times were tough and our huge development staff needed help, Lenny would roll up his sleeves and fix problems. But these times were few and far between. In the couple years I spent on the project, I only heard stories about this happening. However knowing Lenny, I believed that these stories were true.

I would always say hi to Lenny. Even thought he was high up on the management chain, he was a down to earth type of guy. I remember going to his office once or twice to talk to him at his request. He explained how at one time he worked on the team I was on and loved it. He said that over the last couple years, all he did was strategic planning for the project and the company.

The activities of senior management were beyond my view. They would have said that these activities were beyond my comprehension. Somehow I got the feeling that Lenny was promoted up high enough so that he was no longer relevant to the software maintenance we performed. And I think this was our loss.

High in the Clouds

Early in my career I had to report to Simon Gluckman. Simon was a big guy. He usually smiled. And he got along well with all the other senior managers. The problem was that Simon had no clue about any of the work I did. And he did not seem to want to know either.

Simon had a lot of people under him. He delegated most of the hands-on technical leadership to lower level managers or even team leads. This actually seemed to work. But all the developers in the trenches did not have much respect for Simon. They considered him a lightweight.

When it came time for Simon to review my performance, he did not have much data himself. But he was OK because he just asked other people. Every so often we had to write status reports for the customer. Simon was supposed to do this. But as I mentioned before, he was clueless as to what was going on. So the arrangement was that developers would ghost write the reports for him.

In summary, Simon was a nice guy. Not sure if he was ever technical. But his lack of even basic knowledge about what us developers did cause him to be irrelevant. You don't have to be able to do a programmer's job in order to lead them. But you have to at least have a clue.

Charisma Not Enough

Long ago at my first programming job I worked for Bill Footman. We did not write any new code on the project. New development was done by another contractor. We just did maintenance. Sometimes we fixed bugs in a high level language. But when the code got frozen we patched using assembly language.

Bill was something of an anomaly. He was promoted up to a high level in our company at a very young age. This may have been due to his charisma. Maybe it was because he worked long hours when needed. I don't know. By the time I got there he was already a big cheese.

To Bill's credit, he was very interested in the work we did. He wanted to do a lot of coding himself. And he just happened to also be the manager of our team. Bill was good buddies with the manager in our client's organization.

A problem with Bill was that, even though he may have been brilliant, he thought everybody else was incompetent. This included everyone on our team. That right there is a morale buster. Now coming straight out of school I may have indeed been very green. But we had other developers who were actually excellent. They were all labelled morons by our boss.

Another negative for Bill was that he was a code cowboy. We would all work on fixes to be released to lengthy test cycles. But Bill thought he could come in, work a lot of hours, hack out last minute solutions, and everything would be OK. This got out team in trouble many times. Luckily Bill also took the blame for this.

Bill was not only problematic for those who worked for him, but also for senior management. He considered most of the executive management above him a bunch of clowns. I am not sure how they put up with him.

In summary, Bill had a lot of charisma, drive, and skills. However some "personality problems" got in the way of him being a good leader. Luckily he was usually busy saving the world, so those of us who worked under him were safe most of the time.

So It Begins

I work as a software engineer. Right now I am lucky to have a really good manager. This seems to be the exception to the rule. I know that management of software projects is no easy task. But can't we identify the good traits and build those in our future managers?

There are some management skills that transcend the software field. However software projects have their own pitfalls that make this role even more difficult to do well. I want to focus in on those skills specific to success in the world of programming.

How better to approach this task than to share stories of managers past and present. This won't be all horror stories. Unlike Dilbert, I have actually worked for a couple excellent manager. Analyzing the good and the bad will hopefully uncover the key characteristics we need for good software development.