About

This page contains a single entry from the blog posted on June 8, 2007 10:38 AM.

The previous post in this blog was Accountability, Part One.

The next post in this blog is I'm Still Here....

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33

« Accountability, Part One | Main | I'm Still Here... »

Accountability, Part Two

Even my good experiences contain scattered bits of disappointment. I set a longetivity record at Hotelecom, but it wasn't without some headaches, mostly centered around accountability.

I was a lead developer on the systems there, and responsible for balancing the project schedule from our product managers, with the capabilities of our engineering staff. Basically, I was the go-to engineer to answer the question "how long will it take to do X?"

A very large and significant feature came up, and it was deemed exceedingly important. It was not an insignificant feature, and would affect the entire product. It was expected to probably take at least two product cycles (we tried to put out a release of our product every 3 months). One of the original engineers, a guy who is inarguably very bright, was assigned to work on the project.

He came up with a very ambitious and overly complicated idea for implementation. I sent him numerous questions via email, which were never returned with answers. I raised several issues with management around the project, because I wasn't getting the sense that this engineer was thinking the problem all the way through. Months went by, and progress wasn't being made. This engineer was moved into a conference room so that he would "be able to concentrate", but oddly enough, this was about the time that, apparently, he decided to take up learning to fly planes, and so was never often seen in his new "office".

Shortly before the Christmas holiday season, a sit-down was had with management, myself, and this engineer (let's call him "Phil"). I re-raised the issues at hand. The CEO even came in and gave a little spiel about how he'd like to be able to sell the feature, and it mirrored the solution I'd put forth. Instead, I was told that the plan was that Phil was going to work most of the holiday break, and was to have an initial version of the system checked in when we returned on January 2nd. If it wasn't done by then, we'd scrap it and rethink the project at that point.

We returned from the break and I found nothing new in our source tree. I was told he didn't actually get around to finishing things. We met again, and the deadline was pushed to the end of January; if it worked at that point, we could still get enough testing done to fit it into the end-of-March release we hoped to have.

The weeks sped by, and still nothing was to be seen. The deadline was pushed to mid February. At this point, I was getting annoyed; the agreement made a month and a half earlier was to scrap the design if the project wasn't done on time, and now, we were not only pushing our deadlines out further, we were ignoring our own decision as to how to handle the problem. The engineer was not being held accountable for his ill-conceived design, and management was not holding themselves accountable to their own planning.

An initial design of the system was eventually added into our source code in mid-March. This resulted in a significant delay of our system, because although we weren't going to release the system, our QA team had to test to make sure that the massive changes didn't destabilize everything else.

Work continued on the project. More engineers were added to it. My alternative, simpler solutions were basically ignored. When I left the company that September (more to pursue a chance to work with someone I had worked with before, than because of this particular aggravation), the system was still not done; it had now been a year working on a solution that, at this point, didn't even meet customer demands for design (in the months that followed the initial discussions, it turns out customers would've preferred my alternative designs). It would be close to two full years from inception to release. The management never pulled the trigger to change course.

I would later find out that this engineer was permitted to pursue his pet design because management was afraid he would quit. He had worked for a successful startup before, and had plenty of money in the bank. An initial member of the company, he already had plenty of stock. They figured, if they wanted to keep him, they had to let him do what he wanted to do, because they wouldn't convince him to stay on the basis of money or stock option grants.

This might've been true, but was it worth it? I don't think so. It generated resentment among the other engineers, who were working hard on projects handed down to them from product management, and being held to deadlines. Customers were forced to wait for the solution, which they'd been asking for, and were ultimately given a system that didn't actually directly address their requests, nor did it pair up with the CEO's desires.

Accountability is not just the placing of blame. Blame is easy. The hardest part of accountability is following through on your contingency plans. Phil was not held accountable, but there were no repercussions. Management did not follow through on their plan to switch to the easier, alternative solution, which, by most accounts, could've been implemented within three months. Instead of delivering three months late, the project took six times longer.