Wednesday, January 21, 2004
To Code or Not to Code: Leadership versus Management
Recently I’ve been coding!
Back in the days when I worked at IBM as a contract coder - in the mid 1990’s - my line managers were both young and recently promoted to their first management job. The management training involved as many as 5 weeks away from the team and was referred to as “the brain washing” by the former colleagues (now staff) of the new boss. One of the key tenets which was drilled into these young managers was “thou shalt never code again”.
The position of line manager is key in any firm. The line manager is the one who manages the economic engine of the company. Without good line management, there is no business. The transition from individual contributor to line manager is also perhaps the most difficult and the most important for any business. For the first time, new line managers must learn to live vicariously through their staff. They must learn to coach the best performance out of their staff and to accept that some jobs will never be done as well as they would have liked them to be done or might have done themselves. This behavior of accepting life as a vicarious pursuit and learning to accept “good enough” rather than “perfect” is a measure of how well a manager is progressing and something on which further promotions to higher levels are measured.
It seems obvious then that if former developers are to learn to live vicariously, they must never code again. The temptation to “just do it” might otherwise be too great and they will never be good managers - always down in the noise and not defining the governing rules for their systems and the metrics with which to monitor and control them.
However, management is all very well but occasionally the troops need leadership. Developers need to be shown the way. This is particularly likely in new and uncertain territory. The greater the uncertainty - the greater the leadership required. Uncertainty can be caused by the domain - a new market being entered, or the technology, or the tools being used, or the working practices being adopted. In any or all of these circumstances, if the manager has the hands-on experience then it makes sense to lead by example.
When introducing FDD, for example, don’t be afraid to lead a Feature Team as Chief Programmer! Don’t be afraid to demonstrate how to Design-By-Feature by convening a Feature Team and facilitating the drawing of a Sequence Diagram! Don’t be afraid to hold a code review! When developers are unsure of how to implement behaviors such as “blue” <<description>> classes on a domain model, don’t be afraid to pair-program with a developer to make it happen. Pair programming is perfectly acceptable in FDD as part of the early lifecycle of a project whilst the architecture and design templates are being created. Don’t be afraid to fuzzy the line between Step 1 - Build a Domain Model and Step 4 - Design by Feature. It doesn’t matter if you have to go and build a dozen Features to prove a model. If seeing is believing then make your development team believe. Lead them to belief through example. Don’t let “analysis paralysis” bog you down. Don’t let subjective debate and belief cost you inertia and velocity. Lead by example.
It is OK for managers to code when they are leading! Once momentum builds and the team feels comfortable then the manager can quietly slip back into the vicarious life of monitoring metrics.