itmWEB Research

An itmWEB Classic Whitepaper

The Mythical Team Leader

Focus Area: Project Management for Systems Development

Author: Russ Finney

Year: 2000

Published: The Quality Observer

John Erskine once observed that "in the simplest terms, a leader is one who knows where he or she wants to go, then gets up and goes". Joel Barker defines a leader as "a person you would follow to a place you wouldn't go by yourself". A good definition for a development team leader might be:

The person who understands the ultimate project objectives, each step of the way, and who guides the rest of the team down this path through clear vision setting and effective communication.

An interesting observation regarding development projects is that occasionally, the person who fits this bill is not always the person who is formally leading the project. Even when this situation occurs, this individual can still wield great influence and ultimately make significant contributions to the teams success. Obviously, the better situation is when the formal Team Leader is also a possessor of effective leadership skills, vision, and experience.

Some of the major challenges facing the systems building Team Leader are:

Creating the System Vision

One of the Team Leader's more vital responsibilities, and one which never fails to present an incredible challenge, is the creation of an overall "vision", within the minds of the project team members and the business clients, of both the proposed system, as well as the necessary steps to insure its completion. These images should convey the functional depth and breadth of the system, the direction and proposed steps of the project, the overall expectations and responsibilities of each team member, and the creative "boundaries" and limitations of the development effort. This system "vision" represents clear, common, shared objectives upon which all activities will be grounded throughout each successive project development stage.

Determining Task Assignments

Another difficult responsibility is the dividing up of the work. This is the part which seems to give every project manager premature gray hairs - if it hasn't already happened on a prior development effort! It is important to assign tasks, responsibilities, and deliverables early for each upcoming phase. Make certain each team member has both a primary and a secondary list of assignments. This insures that when decisions or issue resolutions are pending, secondary tasks can be focused on instead of the individual having to shift into an idle period.

Consideration must also be given to the experience level, the technical ability, the management skill, and the availability of each team member. These all have an important bearing on the nature of the assigned tasks. Care must be taken to avoid putting anyone into a situation where he or she feels "in over their head" - yet, at the same time, each team member must feel a sense of challenge, and believe that his or her work is relevant and important.

An even higher consideration is the willingness, as well as the ability, of each individual to accept and carry out the assigned responsibility. For the team leader, this represents an act of trust, for the team member, it represents challenge and opportunity. These interests can sometimes seem to compete with one and other, but the overall objective is to optimize each person's individual talents and to avoid useless busy work or idle time. Making appropriate assignments which are important, challenging, and consuming, along with the additional responsibility for reviewing and reassigning tasks when necessary, all make the team leader's job one which which requires a keen human insight as well as the willingness to let people grow.

Making Decisions

A team leader is a decision maker. This fact for some may seem to be a blessing, but for others it may feel like a curse. With decision making ability comes both control (which most leaders like) and accountability (which most leaders fear). In some cases, a decision is strikingly apparent to everyone, and the team leader serves only to confirm the choice and to set the dependent actions into motion. In other cases, the decision is between two or more choices with equal merit. Most decisions are somewhere in between. As a team leader, being a perfect decision maker is simply not possible - but being an effective decision maker is! The following rules of thumb can help to increase decision making effectiveness:

  1. Delegate decision making authority wherever appropriate. This keeps detailed decisions at the optimal level.
  2. When all relevant facts, opinions, and viewpoints have been collected and assessed - Make the decision! If no more light can be shed on the situation, delaying the inevitable only wastes time and team goodwill.
  3. If time is truly available to improve the quality of a decision - take it! This is especially true if the decision will have significant long-term impact.

Thomas Jefferson once advised back in 1792, when making critical decisions that "delay is preferable to error". Many times an iterative, focusing decision approach can result in the highest quality outcome and the broadest consensus and support.

Monitoring Progress

The way in which team leaders monitor progress tends to be a matter a management style. Some may have quick team meetings, others may require written reports, and others may put into place formal time collection procedures. In all cases, a few fundamental elements should be present. First, clearly identifiable units of work must be assigned to each team member. These may range anywhere from a broad mandate to a detailed programming task. Second, a milestone date for each defined deliverable should be agreed upon. These both should present reasonable yet challenging objectives. Third, a formal accounting of these objectives and goals must periodically be required. This aids in keeping a sense of urgency in place, in providing a basis for later performance evaluations, and in keeping a sense of accomplishment alive and well through each successive phase.

Opening Communication Channels

This sounds so easy, yet many team leaders tend to gravitate toward one of two extremes. One is the "keep your fingers crossed" approach. This is where a team leader hopes that the clients, analysts, and programmers are all busily communicating away with each other about every aspect of the system without him or her having to do anything. The other is the "my way or the highway" approach. In this situation, the team leader controls all of the communication opportunities and only lets others into the loop on a "need to know" basis. Both extremes eventually lead to frustration or resentment.

The team leader must achieve proper and balanced communication between everyone involved. This means that he or she must organize, orchestrate, prod, and maneuver both business clients and system builders into meetings, sessions, and informal encounters:

  • to collect information
  • to resolve issues
  • to heighten awareness and
  • to make decisions.

This applies across the board - the team leader is ultimately responsible for ensuring steady progress and for making things happen. At the same time the he or she should not stifle informal communication. Most system builders thrive on learning, sharing, and comparing. A certain amount of this is to be expected and is productive as long as milestones are being met.

The last challenge facing the team leader is his or her own communication style. As a manager, the team leader must discipline himself or herself to react to both good news and bad news with moderation and maturity. A balanced reaction to both increases the odds of actually hearing both, and this awareness keeps project surprises to a minimum.

Deflecting Unnecessary Distractions

These sometimes seem to come from every direction! Clients may ask for a little help in an unrelated area, management might put the team through a "fire drill" to rejustify the project, or a new software tool may arrive which seems to fascinate everyone. The team leader must strive to keep these distractions to a minimum. Keeping the team focused on the primary objectives while at the same time running interference with the client or the team can keep a team leader hopping! Sometimes interruptions can be handled through subtle deadline reminders, other times it may take creative thinking to find alternate means of handling the unplanned requests. In the worst case, no choice is given, and the team must react. When this happens, the team leader must make sure that the distraction is taken care of as quickly and effectively as possible - then get back to the primary mission: building the system.

Enforcing Quality Standards

Sometimes team leaders seem to get so engrossed into the minute details of standards enforcement, they begin to bare more resemblance to the programming police rather than mere human system builders. This is unfortunate, quality should be inspired rather than dictated. Quality standards should be a reflection of the desire for excellence on the part of the team. This is tough assignment for the team leader since it requires discipline and temperament.

The spirit of the review process should be one of both confirmation of quality as well as identification of improvement opportunities. Make no mistake about it, work product reviews are an essential ingredient in making high quality a reality; they provide needed recognition for sincere efforts toward the creation of high quality products. In addition, team leaders should dedicate themselves to the "review it once" rule. This means that all observations, input, and changes are brought out in the first review. A second review should be called for in only very rare cases. This puts the burden on the team leader to be equally complete and penetrating when reviewing each team member's work.

Watching Scope Boundaries

This is the part which is kind of like being a sheep herder. No matter how hard a team leader tries to keep the delivered functionality in scope, someone always seems to come up with a clever new feature, or an undiscovered requirement, or a "twist" on the original vision which will require more time. Sometimes these may seem to be just a little time here or a little time there, but it all eventually adds up to a significant amount of time, and a missed deadline.

So how can this be prevented? The answer is it can't.

Changes to scope are an inevitable part of system building; the key is to keep the changes in control. Each proposed change must be evaluated as to both its importance and its necessity. If the change doesn't pass the "gotta have it" test, direct the effort back within the established project boundaries. Otherwise reasonable change control procedures should be utilized to recognize and plan for the effect of the work increase.

An alert project manager should be able to spot true improvement opportunities, and then either build the case for a scope increase (if the benefits merit the effort), or identify sensible design trade-offs for the more beneficial features.

Supporting a Career Development Atmosphere

Sherman Hamilton, while writing on teamwork, pointed out that "a leader inspires his or her staff to believe in themselves and their ability to succeed long before they could recognize their own potential". This is a frequently overlooked responsibility of the development team leader. Meetings, issues, and deadlines can sometimes lower the priority for ensuring that a learning environment exists for the less experienced project team members. This is unfortunate, since the investment in making sure that every team member is ascending his or her personal learning curve can pay off in many subtle, unexpected ways with surprising impact.

The inexperienced programmers gain by learning efficient and sensible approaches to creating high quality software from the more senior team members. This not only contributes to their personal confidence, it also reduces the potential for easily avoided program re-work and testing problems. The more experienced analysts and programmers gain by being given greater levels of responsibility and challenge. This provides an opportunity for them to stretch and grow to the point where they are ready to be entrusted with increasingly significant leadership roles.

As long as individual team members are not put into situations where they are "in over their heads", a sensibly managed learning environment can not only produce systems, people, and results of exceptional quality, but it can also invigorate overall team morale by reassuring everyone that they are being given the opportunity to advance through performance.

Managing Issues and Problems

Some people make a career out of doing nothing but this, and they even enjoy it! What these team leaders have realized is that being an effective problem solver requires both discipline and organization. But this isn't enough, the most important rule for managing issues is: when you hear it, write it down. This ensures that the issues and the related details are really captured, and can be subsequently reviewed, prioritized, and organized.

Warning: If human memory is all that is used to keep track of the issues for a complex project, eventually selective system builder thinking will begin to creep in, and before you know it - zap! Those nagging, unwanted, negative thoughts will be forgotten within a matter of seconds, and they will silently wait to be remembered at the least opportune and inconvenient moment (like during prototyping or acceptance testing).

Another important point is made by Robert Townsend when he states that "an important task of a manager is to reduce his or her people's excuses for failure". These excuses sooner or later appear to the team leader as issues or problems. As long as they remain unresolved, safe, valid excuses for delay, unaccountability, and failure will exist within the minds of the affected team members. Not only should the team leader swiftly and effectively act to resolve each new issue or problem, he or she must also be on constant guard to make sure none slip by unnoticed.

In many cases, the issues are just too numerous for one person to possibly be able to work through without help. When this situation occurs, the team leader must assign the responsibility for each specific issue resolution to either a business client or to another person on the project. By doing this, the team leader effectively delegates all of the tasks required to arrive at acceptable answer to others. What he or she is not giving up, is the responsibility for making sure that all outstanding issues ultimately do get resolved.

Counteracting Project "Threats"

This last category can be one of the most difficult. It deals directly with the impact of "Murphy's Law" (if it can go wrong it will!) on the project. Arnold Glasow once observed that "one of the tests of leadership is the ability to recognize a problem before it becomes an emergency". Some examples of typical project threats are:

  • Unreasonable business requirements
  • System performance roadblocks
  • Unproven technical solutions
  • Hostile business clients

The astute leader remains on the alert for these potential treats, and as soon as they are recognized, he or she then deals with them in their early stages .