Special Reports

Technical Leadership is Not Project Management

Application development is messy and unpredictable. Here are three key things a technical leader should do to deliver software in spite of the chaos and change that can accompany a project.

• By Rob Keefer
• 06/01/2006

Technical Leadership is Not Project Management
Here are three key things a technical leader should do to deliver software successfully.
by Rob Keefer

June 1, 2006

In his book Blink, Malcom Gladwell relates a story about Paul van Riper, a retired marine. In 2000, the Pentagon asked van Riper to play the part of a leader of a country that was harboring terrorists in a war game called Millennium Challenge. The stated purpose of Millennium Challenge was for the Pentagon to test a set of new military philosophies. These philosophies called for much planning and the heavy use of technology.

On the opening day of the war game, the "good guys" showed up in full force. Thousands of troops were deployed into neighboring countries, aircraft carriers were posted offshore of the rogue country, and they knocked out all satellite communications. They issued an ultimatum to the rogue commander and waited.

Van Riper didn't cower. He led his troops to battle, firing off a large number of missiles and sinking many important ships that had been posted off his shore. This took the planners at the Pentagon completely by surprise, and caused them to reevaluate much of the philosophy they were testing.

War is messy and unpredictable. So is software development. Project managers can plan a software development project, but once the project gets underway, it rarely follows the plan. A technical leader understands this, accepts it, and knows how to deliver the software in spite of the chaos and change that accompany a software development project.

Three distinct differences in philosophy differentiate a project manager from a technical leader: Project managers focus on a plan, tend to find fault, and focus on process; technical leaders focus on purpose, provide feedback, and set a pace for the team.

Plan vs. Purpose
Project managers are often chided for not understanding what goes into software development. They are trained to focus on a schedule and need to know how the work is progressing according to the plan. Unfortunately, software development isn't as easy to predict as most project managers would like, so developers are often behind schedule.

Good technical leaders, on the other hand, keep the purpose of the project in mind and want to know how the work is progressing toward that goal. Technical leaders know that there are hidden problems in every software development project, and exhibit the courage and expertise to press through issues and arrive at a solution that meets the overall objective. Leaders evaluate the progress of the team according to the ultimate goal of the project, not according to a plan.

A good technical leader also knows that teams need small successes to stay motivated and build camaraderie. He or she organizes the initial phases of a project in order for the team to achieve early success. These tasks should be relevant to the overall purpose of the project, but not necessarily difficult. When the team meets these objectives, the leader celebrates the success and then focuses on the next objective.

Fault vs. Feedback
Because typical project managers are unfamiliar with the day-to-day activities of software developers, they often want to know who to blame when issues arise. Someone is singled out as the fall-guy. Unfortunately, this fault finding leads a team to learn how to shift blame onto others.

A technical leader understands that when problems arise within a project, the whole team is responsible for finding a resolution. He or she can bring a strong technical background to bear on the problem, and provide proper feedback in a timely manner. This feedback can help the whole team learn from mistakes without singling out one individual, thus providing a safe learning environment for the whole team.

One note of warning: Positive and negative feedback provided through e-mail can be easily misinterpreted because it lacks facial expressions and other body language. A good technical leader will follow up such e-mails with a quick conversation to make sure that the person receiving the feedback understands the tone implied.

Process vs. Pace
Project managers often want the project development team to follow a set process. This allows them to monitor progress at a higher level and not concern themselves with the details of the work involved.

Technical leaders attempt to ensure that the team provides the most value to the project as early and as often as possible. With this in mind, he or she will set a pace that the team can maintain. This pace is monitored to ensure that each individual on the team is performing tasks that provide the most value to the project. Work products such as documentation, prototypes, and source code might provide value to the project. The order in which each of these work products is produced, and the time taken to produce it, can affect the value and success of the project. A good technical leader understands this and will work to maximize the value of the project at any given time.

By leading his troops into battle, Paul van Riper surprised the planners in a big way. He was able to embrace the chaos of war and use it to his advantage. Good technical leaders learn to embrace change by keeping the goal of the project in mind and helping the team fulfill its objective.

About the Author
Rob Keefer is the director of the Agile Development Center at Strategic Data Systems in Dayton, Ohio. In this role, he has architected and led the development of a number of software systems. Rob has also written a number of articles, and frequently speaks on the topics of agile software development, software architecture, and user-centered design.