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.