Tuesday, August 25, 2009

I enjoy acting, but what I really want to do is be a director!

If you've ever watched interviews with actors, it's almost invariable that at some point they'll utter the phrase "While I really enjoy acting, what I really want to do is direct." It's almost comical in it's predictability.

The thing is, programmers aren't much different. At least that was the case at my former job, where rampant title inflation meant that the title of 'Director' was roughly equivalent to a lead anywhere else. Of course, in that context, 'Director' meant 'Director of Software Engineering' or 'Director of Technology' or something. Forgetting nomenclature for a moment, though, there is still the common that many a programmer has toiled away in obscurity day and night only to suddenly see one of his co-workers elevated to a higher position for no discernable reason. Now at my old job a lot of it had to do with politics, but I even there it caused to me think about a few very basic questions, namely, what causes one person to rapidly ascend the ranks, while another toils endlessly in obscurity and how, as a manager, do you make sure that you promote people who are truly deserving and who don't merely appear to be deserving?

Most software engineers expect that promotions should be based on merit. Of course presumes that the world is a fair place, which I think most adults accept as a laughable assertion. I suspect there are no professions where promotions are based soley on merit. It's especially grating for hard working programmers it's usually not necessarily the most skilled or hardest working person who's promoted, but rather the one that *appears* the best.

Now, often such promotions will be chalked up to 'politics', and I think that's a fair point. As I said, at my last company most of the promotions were. In such instances, there is little one can do. At the same time, however, there is a ring of fatalism to such statements. By using 'politics' as an excuse you are essentially saying you have no power to affect change. The word also implies that those promoted are completely undeserving of promotion. I'll cop to the fact that they may not be the most deserving, but more often than not they are doing something right.

Having now managed a total of somewhere between 70-100 different individuals over the course of the last 3 years, I myself have "promoted" the wrong people a number of times. In most cases, I didn't even realize my mistake until it was too late. That probably says more about my own failings than anything else, but it is interesting to go back and ask myself why I made the decisions I did.

One telling example is from one of my more recent projects. It was a large migration effort from an existing software stack to a roughly equivalent one. There were a total of about 25 programmers, half onsite, the other half offshore, all formally reporting to me. We had about 3-4 Scrum teams. We had a few leads already established, but due to some reorganization of teams, we needed a few more. This is where I made some flat out bad decisions.

One of the new leads, whom I'll call Jason, was picked based on merit. By at least one of the senior programmer's accounts he was 'the best programmer on the team'. I heard some grumblings that he did things here and there that were a bit goofy, but for the most part everyone agreed he turned out fairly solid code.

Of course, I thought giving him more responsiblity was a no brainer. But soon questioned my decision. He could not delegate work to others, instead having to do it all himself. He would make commitments to a given schedule, saying it wasn't a problem, only to later reverse himself and start saying he had too much on his shoulders. I never had any faith that when he said something was a 'day from being done' that it was anywhere near complete. He took a great deal of time escalating minor issues to me that I thought he should be handling. When the project ended he left, of course, but had he stuck around his performance would have caused me to put him back in a purely dev role and remove the extra responsibility from his shoulders (i.e. I would not have formalized his promotion).

Now the other lead, who I'll call Scott, was mostly self-selected. He had a military background which tended to make him a bit more authoratative, more familarity with Scrum (which was generally lacking on all teams), and he seemed to 'know what was going on'. When I asked him how things were going he gave compelling, concise answers. He made decisions on his own rarely escalating to me, help coordinate onsite and offshore resources, and I largely stopped worrying about his teams progress. I *trusted* him.

The thing of it is, though, Jason (though hardly a leader) was less of a disaster than Scott. From his utter panic, constant escalations, and inability to meet targets, I *knew* his stuff was in a bad shape. He *was* a failure as a leader, but I *knew* it and so could work to mitigate it. In constrast, I didn't know Scott had been a disaster and his team was totally off track until *after* he had left. Where he had been saying 'things are almost done', they were not even close. Looking more closely at his work, he had made bizarre arbitrary decisions that according to him were 'best practices', yet flew in the face of every internal convention established within the company. What's most interesting to me is that he had the classic qualities one looks for in a leader, the type of personality traits that cause one to be promoted. The problem was that his underlying decision making, the real crux of what he was doing was complete crap.

I'm not sure I have a great answer as to how to ensure those promoted are the right people. The obvious answer is to is to look closely at the work the person is doing, but a large portion of hte time those making decisions about promotions don't even have to the techincal background to make such an evaluation. Even for people like me, though, it's really easy to say that you'll look carefully at every line of code and every decision and quite a bit harder when you are managing large teams. When you have 20 or 30 people reporting to you on multiple teams, you have to choose where to direct your efforts or you'll get nothing done. When someone seems to be making the right decisions, who's reporting good progress, one is inclined to accept it. In the example mentioned above, I felt all my time needed to go to managing Jason, whereas Scott had things under control. I thought if I spent time on Scott, I wouldn't have enough to keep Jason on track. Scott made my life easier, whereas Jason ate in my time day after day. It's only natural that a manager will look kindly on those who seem to make life easier.

As for what you yourself can do to help raise your visibility, they're again simple things on paper. Don't escalate every tiny issue to your manager. Follow through on your commitments. Don't get angry (this has always been a big one), when people seem to make unreasonable requests, and try to say 'I'll see what I can do'. And more than anything else, market yourself. If you're not making others aware of your accomplishments, it's unlikely anyone else is. That's not to say you should negate what your team is doing, but an offhanded word here and there goes a long way. You may feel like a car salesman, but no one will look out for your best interests but you. Again, as with all things, on paper this stuff is easy.

In the real world, it's tough as hell.

3 comments:

Unknown said...

You hit it on the head at the end with self promotion.

The decision maker promoting others rarely has the time to know what is really happening on the floor. They only know what they see and they rarely see things that aren't shown to them. Show them something.

As a bigger fish of course you need to make people earn trust especially when changing their roles. Verify until that trust is earned, and verify less afterwards.

Joshua DeWald said...

Yeah, I totally agree with the 'selling yourself' part. The people who *want* to have leadership (or even management) roles will make sure that they are making themselves "heard" in that direction. This doesn't meant that they are necessarily doing better *work* than others, but more than they are selling themselves as leaders in some way.

Thankfully I've never been in the role of having those leaders underneath me, but have only been parallel (mostly I've never wanted to be that high) and, as you've pointed out, those people who are good devs don't actually necessarily make solid leaders. The mentality of "if you want to get it done, do it yourself" simply doesn't scale.

I think a lot of it comes down to that trust in the people underneath you. If the newly-promoted leader doesn't have confidence (rightly or not) in the team under them, they end up being a poor leader by trying to do it all themselves.

Shaun said...

I'm only going to get enraged if I enter this conversation. So I won't :)