September 25, 2003 at 11:45 am #24942Unknown,UnknownParticipant
Is there a “Ken’s rules of thumb for proper development team management” … a list of things that Ken W. would do/not do when managing a team of developers? Observing my current development environment, I would say that there are 2 key factors that are contributing to what I believe will be the demise of the project and its future:
the team leader does not have the respect of the developers. (without the respect, expecting and enforcing late night and weekend work from your developers will only cause more frustrations, and although it might hit a deadline in the short term, the developers will only grow to resent you even more into the future) the type of technology that was used to solve the business problem was chosen strictly because it was cool technology and not because it addressed our business’ needs. (this “cool technology” has surfaced some system limitations that we are currently not able to work around. by choosing technology that had not been proven, we are being forced to create “kludges” that only compromise the product’s future)
These are just 2 of the larger problems, but there are many more subtle problems that are hurting us. Could you offer some insight into development team management? perhaps a couple of particular things you did that helped you to gain the respect of your teams?
September 25, 2003 at 8:46 pm #24943Unknown,UnknownParticipant
(re: Development Management) Wow — a great question. I do think that one of the major reasons that Sierra did so well was that we managed development better than our competitors.
We did a terrible job. Most projects finished late and over budget. We had a bit of an excuse, in that there were lots of factors that could radically impact a project in development. For instance:
A competitor comes out with something comparable (I never wanted to be “second to market” in a product category) This could result in radical redesign If it just isn’t fun. This happened a lot. The game would be playable, but just “wasn’t fun” – this always meant LOTS of additional work Someone had a cool idea for a new feature – that we all agreed would make the product sell a LOT better
Generally though, our problem was that our staff, like me, were all perfectionists. Everyone was always wanting to do things over and over until “it was just right”. This meant redoing a particular animation dozens of times. Rewriting a routine over and over until it ran in the fewest number of milliseconds possible.
Our industry was different than most. A competitor of ours, Blizzard, always refused to establish a budget or ship date (or, so goes the rumor). They would agonize over the smallest details, and throw away major chunks of code – over and over again, for years. As crazy as this sounds, I loved them for this. When they shipped a product, it was awesome. The problem was: how do you do this in a public company? Shareholders demand ship dates and revenue projections. On the other hand, perfection takes time. I always had trouble balancing these two goals.
None of this may be relevant to your question. One good thing we had at Sierra was an amazing staff. We were in the fortunate position that the industries best talent wanted to work for us. Generally, we never shipped a product late due to incompetence. We shipped late because of wanting to ship a perfect product.
That can be different than the problems one might see at a “normal” company. Sometimes, in the normal IT world, there really are project managers who don’t know what they are doing – and, who can’t manage people. It happens all the time. My best advice here is to look at someones track record before hiring them. If someone ships a product over budget, late, and buggy – they will ship their next product exactly the same way. Most projects (that fail), fail before they start, through bad staffing. I can’t say this strong enough. If you hire leaders who shipped their previous products late (or, quite often not at all) – you have my word that they will almost certainly do it again Avoid hiring people who always seem to fail, but have really good excuses. I don’t like excuses. Great people get things done under adverse circumstances. People who claim to be good, but who have constantly failed because “the dog ate their homework” are best left to competitors.