Sunday, October 14, 2007

Herding cats - learning to lead

You have heard the expression, "herding cats", I am sure. It means trying to maneuver independent creatures into the direction you want them to go (and if any pet is independent, it is a feline). Well, I recently moved into the tech lead position of very high end developers. Now, I have been in tech lead positions before, but never with the caliber of these folks.

A quote from the movie Blow, "My ambitions far outweigh my talents". Well, I feel that way around these folks. They are very good at what they do. In fact, they are more than developers, I would say they are thought leaders in their field. But I think they subscribe to the opposite, "Their talents far outweigh their ambitions". It is scary. Maybe I am the obtuse one, in the fact I want to lead instead of being led. I will say this, on this team, I am finding my skills are changing. Moving from technology to more management (well not management, but leadership, and they are not the same, trust me). I don't want to manage anyone. I would like to lead. They are different, and difficult if you have not been in the position prior (either through you own actions/inactions, or by stature in life). Some people are born leaders, others have it thrust upon them (yeah, that is not the quote, but it is my blog damn it).

Back to these folks. I have found that the use of Foursight to be helpful in assessing my team (my manager directed me to it, and although I have only an inkling of its uses, what I have seen is really helpful). As I understand it, the basic premise it to find people's preferences (which will generally be their strengths) and work them into the goal accordingly. It is based on the idea that people generally will have a preference in 4 areas, Clarification, Ideasation, Development, and Implementation. Mine tend to be Ideasation and Implementation. I have the least preference for Clarification and Development. This leads to one of my pain points in leading these folks. I tend to go from my head on my project plan. Some of my team (notably the ones that prefer Clarification and Development) want it designed out on paper and documented.

So, I have tried to get them to just work it out themselves as to how it would designed. Now why they are like this I don't know. They are all thought leaders, so I know they know independent thinking. So whether they have been brow beat by the trade to ask exactly what the customer wants, or they never knew how, I don't know (nor do I really care). I know now that I must clarify their tasks down to gnat's ass for them. So be it, as long as they get the damn project in on time.

I have done my best not to spoon feed the "detailers". It can be a fine balance. You have to account for their ego's and their laziness. People tend to work only to what you ask of them directly, very few go beyond. However, my take has been to formulate high level requirements from the user perspective, and come up with high level components for each developer's area from those requirements. I then take those to the developers and ask them to work through to come up with their line items, sizings, and dependencies. If I need to massage them into a project plan, it is easier doing the way above (however, you have to be using an iterative development process, and you have to have a degree of freedom from users... I work mostly on prototypes that are evolving as they are being developed... a very different model than most IT people get to work under).

All and all, I think I can apply the above thinking to any project where you work with a degree of intelligent and creative people that are passionate about their jobs. However, look for the mentioned pitfalls above.

No comments: