The Inequities of Chess Piece Software Management
I was at a small lecture at USC yesterday for a foundational MBA course where the subject of the talk was varying management approaches across assorted industries when dealing with common software management. It was a brilliant discussion, very well thought out by Professor Ashby of the Economics Department. I really enjoyed the latter section of it where it became a more open forum to people to ask questions.
One of the management techniques discussed was aptly called Chess Piece Management. From what I understand and took away from the discussion, it is used relatively heavily for software development within larger companies that incorporate a fair amount of delegation. I found the entire concept of it intriguing, because it looked great on paper, but real world applicability of it I found lacking. Basically, it seemed to be deficient of a fair amount of qualities that I would expect in any management technique. Apparently however, it is instructed at a fair amount of business schools and subsequently put to use with enterprise software development projects.
The name of the technique pretty much sums it up. Firstly, examine the game of chess. There are several levels and units that are involved. None are more visible in Chess Piece management then the pawns (that’s me!) which advance on the frontline providing support and position to later power pieces such as the queen, bishops, knights, and rooks. It’s comparable to business practices because using your existing materials you seek to accomplish a certain goal. It’s easy to relate to software development practices because it can be an internal goal of architecting and developing against a SharePoint portal where the developer and architects are the pawns, middle / project management playing the bishops, knights, and rooks (because later pawn movement will generally be tailored around the actions that are planned for such power pieces however architects and developers still set the initial stage), and upper management being the ultimate end line of the queen and king.
At its most basic form, chess piece management seems to make good sense in its simplicity and form. However, it’s a cold, calculating form of management, IMHO lending it more to failure than to success. The problem with applied game theories and management is that it lends itself to consistent patterns, and not to feeling of all the units involved. There is matter of human element missing, and software projects tend to require and foster relationships. Such relationships are crucial since people have to cultivate trust between each other; I have to trust the architect that the platform that he provides will appropriately sponsor my development for example. Chess has a series of rules that are applied to it, and using these constraints, moves and actions are taken. Essentially, it is very rigid and a balance of emotional and calculating management is required for more successful management when dealing with software projects.
So, while I understand its form, I don’t understand successful implementation of the theory itself. A book the professor recommended called “Competitive Innovation Management: Techniques to Improve Innovation Performance” by James A. Christiansen apparently discusses it a little more, I picked it up this weekend so hopefully I can dig into it a little this upcoming week. You know, little late night reading before I hit the sack :)