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:
- Delegate decision making authority wherever appropriate. This keeps detailed
decisions at the optimal level.
- 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.
- 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 .
