Friday, September 30, 2005

Any Other Contributors?

If anyone reading this feels like bitching about their company and/or the IT industry in general, just shoot a comment this way and I'll see about hooking you up with posting access on this blog. I'd recommend creating a different blogger account and remembering to properly anonymize your information. As always, I am in no way responsible for any harm that may befall you.

Be Careful What You Measure

Management loves to measure things. It's what they do. You can't manage it if you can't measure it, baby. And what better way to incentivize your employees than to tie some sort of reward to the metrics you have? Unfortunately, you usually wind up with a lot of metrics that are completely orthogonal to your real behavior and performance goals. For example, tracking whether or not an employee submitted their time sheet in a timely manner, while valuable, is not your core business. Therefore, any reward or penalty should be extremely small. In the grand scheme of things, there are much more important things to worry about.

Conversely, you need to be careful about how you measure the things that are important to you. As soon as you measure it and tie it to a reward system, you've created a set of rules that can be manipulated and abused, often to the detriment of your real goals.

On my current team, we've started tracking how many story cards we complete each iteration. Somewhere we've lost a little bit of the link between feature and story card, but that's ok. The real shame of it all is that the acceptance of a story card is handled not by a strong product manager that really understands the product and the features his customers want to see in it, but by a quality control group. This group doesn't even know how to test that a story card is complete except by asking the developer that implemented it. Since the completion of stories and tasks directly reflect how well you and your team are doing, you are "encouraged" by the system to deliver lower quality work in a timely manner and then perform a little misdirection when you're explaining how to test a feature to the QC group. Sure, we delivered shitty quality, but man, look at all those check marks next to our story cards. We rock.

Thursday, September 29, 2005

You're Fired, Stupid!

What the fuck ever happened to firing people that couldn't do their goddamn jobs? These days, thanks to some product lines being EOL'ed, we're getting all sorts of idiots in our group. In this case, management's heart is in the right place--they're trying to re-assign people rather than simply laying them off just because their product died. I can even go along with trying to train or transition existing developers to new technologies they've never worked with. God knows that if Java went belly up tomorrow and C# became the shit, I'd like a chance to transition to a new group before being laid off. However, I certainly wouldn't expect it and you can be damn sure I'd bust my ass trying to get up to speed on the new technology. This group of shit-wits we have working on my team have been here seemingly forever, and they still can't wipe their own asses. Don't get me wrong, I have nothing against stupid people--the world needs Visual Basic programmers, too.

Here's something I think every manager should do. If you know who the truly great people are on your team, ask them separately to pick one person that should be fired. If you get the same answer from each, think seriously about firing that person. They're dragging down your talented people and you can usually hire someone better for the same money. If your talented people balk at the idea of firing just one you might need clean house. I would recommend doing it one at a time. There is something to be said for having even an idiot on staff. However, now that you have identified them as being an idiot, delegate only simple tasks to that person. If you don't really know who the talented people are on your team, then you have no business managing them and probably work at the same company as I do.

Respect My Time

It's always been a pet peeve of mine that, at many of the places I've worked, management thinks that the personal time of a salaried employee can be used at will to make up for a lack of adequate planning. I realize in this industry that estimates will frequently be off, the job still needs to get done, and that it is often my job to work longer hours and / or the weekend in order to get something finished. I can accept that.

The part that I cannot live with is when people fail to plan or even ignore potential pitfalls and risks and expect the development staff to continually work longer and harder to make up for it. The "long hours and weekends" safety net has been abused too often where I work.

The most recent incident of this happening at my work was when two members of my team received new laptops. They were supposed to spend a day each setting up the new machine at the beginning of the iteration. The setup time was pretty much unavoidable and had to happen before they could work their tasks for the iteration. I pointed out that this was going to cost us time in the schedule and that we should account for it by trying to cram fewer tasks into the allotted time. The response I got back from the development manager was, "If they have to come in on the weekend to set up those laptops, I guess I'm saying they can go ahead and do that." This wasn't make-or-break the product functionality and we were talking about a known risk / schedule impact. The fact that he wanted to ram it through anyway by using someone's personal time was simply due to the fact that he wanted to look good for his boss by having more tasks complete than other teams.

What better use of my time could there possibly be?

Management on Autopilot

My latest complaint is about my management. On my current team we have both a product manager and a development manager. Both roles are filled with people I would consider inadequate to the tasks they should be performing. This problem is made worse by the fact that the product manager is actually managing the products of three teams while the development manager is managing two teams. This leads to a lot of conflicting meetings and a general sense that both managers are missing in action quite often. My product manager hasn't made it to a daily meeting in months and my development manager missed the morning meeting the day before our code complete day.

As you can imagine, this leads to a situation where developers are often guessing at requirements (the responsibility of the product manager) and spending too much time coordinating dependencies and clamoring for the necessary resources (the responsibility of the development manager). Of course, the metrics used to determine how things are progressing are very centered on how the developers are doing (rather than the management). Sure, the management may be "blamed" for poor team performance on some level, but ultimately the developer's ass is the one on the line.

In recent weeks (on my team at least) this has lead to a noticeable drop in quality with an increase in effort. Any situation that causes longer working hours with a final product that you can't even be proud of has a tendency to sabotage morale. To me, the solution is fairly straightforward. Hire additional management for the additional teams / responsibility and revise the metrics. Hold management more accountable for their team's failure to deliver. And don't let them just roll the shit downhill onto the developer.

I'm doing my job, I just wish other people would too.

Wednesday, September 28, 2005

My Bitch Blog

If you ask anyone that knows me, they'll likely tell you that I'm an incessant complainer (if they're being nice). This of course has a negative impact on the attitudes of some of the people around me. I'm going to start using this blog as a dumping ground for my complaining (primarily work related) in an attempt to spare some of the people that would rather not hear my bullshit in person. We'll see if it helps.