Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

How to run a focused and efficient team when you're still wet behind the ears.

Congratulations! You’ve just been promoted to technical lead. Now what? Any promotion can be stressful, but if you were previously an engineer (in title or practice), this represents your first venture into the lowest tiers of project management. In your new role, "soft" skills such as running meetings, communicating effectively, reviewing performance, scheduling and reviewing code will be as important as your technical background–and if you leave the human issues unattended, they can lead to hard problems. What’s more, whether you have been promoted from within the organization or not, you’ll face the challenge of earning your colleagues’ respect.

Starting Off Right

New teams are rarely cohesive or efficient, even if team members have worked together on various parts of the same project. Members have to get to know each other and the team leader to learn who possesses what skills (the so-called hidden organizational chart). Unfortunately, this process takes time, something most projects have little of.

In my experience as a technical lead, I’ve found that a "kickoff" meeting at the beginning of a critical phase helps my team crystallize quickly and clears up any misconceptions regarding individual roles. If you have ever been subjected to a project that transitions from phase to phase with little or no acknowledgment of the milestones, you’ll appreciate the effect of such a meeting.

On a project that I led for the U.S. Navy, I prepared for the kickoff meeting by reviewing the existing documents and writing some additional ones. We had completed a prototype phase, a lengthy analysis and finally a high-level design phase; this resulted in a set of documents describing the system architecture and specific processing requirements for the distributed applications (of which there were three types). These documents stated what needed to occur in the system, but not how it should be done. I knew from experience that developing from high-level documents rarely produced the desired result. Hence, I created a low-level design for a generic, modular distributed application–in accordance with the feedback I had received from seasoned developers–and then e-mailed this document to the team several days before the meeting. This generic model could be easily extended to encompass the specific requirements of each of three types of distributed application. It relied on a plug-in type of architecture, allowing for swapping functionality in and out, though at build time rather than run time.

I told the team that this document, in whatever form it was to become, would be the basis for our work for the next year, and then I allowed everyone to assimilate the proposal. Even if you believe a given design is the best, your team must reach that conclusion on its own. The team’s response was astounding: Everyone was familiar with the document. And although it was modified during and after the meeting (thanks to the developers’ comments), the core remained the same.

On that occasion, our meeting took a whole day, but kickoff meetings may last just an hour. Make sure to take breaks, and have the company pay for a meal. We also invited teams who working on other aspects of our project; this helped lay the groundwork for interfaces between the various software modules.

As for the meeting’s structure, I began by stating the project goals in the form of requirements–you could also review the high-level design or architecture–before I moved into the low-level design. During the meeting, the team critiqued and refined my ideas, which allowed them ownership of the process. Your team’s critique should take about half of the allotted meeting time. After that period is over, review and record the agreed-upon design. Then assign individual tasks, keeping in mind that tasking should take no more than one-fourth of the total meeting time. (A side benefit of tasking in this semi-public setting is that each team member will immediately know who is doing what.)

To wrap up, I reviewed our accomplishments at the meeting and had each team member restate his specific tasks. This "briefback" reduces confusion and limits the number of follow-up questions. Obviously, your team needs to be comfortable asking questions at any time, but it’s more efficient if they ask their questions during the meeting rather than after the project is underway.

Kickoff meetings are always a good idea, even for a team of two assigned to a one-week project. Not only will you keep your team leading skills sharp, you’ll also have an audit trail (that is, if you remember to take notes). You should never have to ask "What did I do that week?" And since small projects have a habit of ballooning into large ones, taking some extra care early on may reduce your stress level if the project continues longer than anticipated.

Keep Everyone Informed

In the late ’80s, I enjoyed reading the daily space shuttle status reports on a NASA mailing list. Each report recorded that day’s activities and outlined what was planned for the next day. I had fun interjecting into random water cooler conversation comments like "Hey, did you know they just moved Columbia to the vehicle assembly building for mating with an external tank?" (Yes, I received some strange looks.)

I wanted to create a similar report for my team, but make it weekly instead of daily. I adopted the same matter-of-fact tone I had seen in the NASA communiques:

From: Andrew

To: Communications team, other first-line leaders

Subject: Communications team status report for 12/12/99

Tasks completed:

• Joe wrote the low-level thread interface API.

• Ivan on vacation.

Work planned:

• Joe will re-implement the application event loop using the new thread interface.

• Ivan will assist with unit testing of database update module.

My report included the tasks completed in a given week and the projected tasks for the upcoming week. It also assigned tasks to specific developers. I didn’t specify how long a task took to complete because we tracked our hours through timesheets; however, adding man-hours would be a good way to measure productivity.

Your boss should also receive your status report, so she can follow your progress. A good boss will query you about tasks that keep appearing on the to-do list for the next week, but are never moved to the "completed" section. Be ready to explain why a particular task is perpetually unfinished, or move the task to an "unscheduled but required" category. Just don’t forget to address it later.

More Meetings?

Depending on project length, status meetings can be informal and infrequent. For our large project, weekly one to two hour status updates involving all team members were appropriate. The weekly e-mail reports formed the basis for discussion.

The final encounter should be what is affectionately termed a "postmortem." Whether you hold this analysis meeting to discuss the entire project or just a particular stage, make it a positive experience. Ask questions like: What worked? What did we learn? What would we do differently? Everyone will probably have different responses. Write them down.

An additional form of feedback may not immediately impact the project, but will provide future help: Insert yourself into the review process for each team member. At a minimum, summarize each member’s accomplishments and send it, well in advance, to whoever conducts performance reviews. (For an annual review, submit your input a month in advance.) Follow-up to make sure the reviewer received it, then lay off: You’ve done your job.

But I Want to Code!

You may still write some of the code, but your role as technical lead is to ensure that the rest of the team writes code that efficiently fulfills the project requirements and matches the appropriate level of design.

Scheduling and conducting code reviews is an essential part of achieving that goal. Code reviews keep people honest and concerned with the quality of their code. Plus, a second or third set of eyes on a piece of code will always uncover things the author can’t see. Follow up on problem areas at subsequent meetings, so that your team knows how important the reviews are. For small teams, you can conduct code reviews with just a few formal roles:

• The moderator should ensure that everyone attending the review receives copies of the code well in advance. He or she also assigns a reviewer for each code item (file, routine, and so on.)

• The reviewer should be a senior developer if possible, but this can be used as a training exercise for experienced junior developers. (This is one way in which you train them to become senior developers.) The reviewer should have a copy of any design documents that pertain to the code item under review.

• The author may walk the reviewer through the code and clear up any obscure items.

• The note-taker records the disposition of each item. On our project, we filled-out a simple status form for each item, stating when and by whom it was reviewed, any problems found, and if it passed or required revision (and subsequent review).

We often only pay lip service to documentation, even though most would agree that any project will suffer from poor documentation. Good programmers who write well and enjoy writing something other than code are rare. If you have some of these creatures on the team, hold on to them! If not, write the documentation yourself.

Grow the Team

Good team leaders give everyone a chance to excel. I tend to task others conservatively, which means some people have to ask for additional work. However, you shouldn’t be afraid to give your team members more work to see how they react. Also, assigning tasks becomes easier once you understand another’s style. Provide tutorial –in the form of documents or short courses–for both rookie and veteran team members. Consider including nonteam members, because sharing information (especially high- to mid-level design details) can result in greater overall design efficiency.

On my project, at least one half-day overview session (with numerous mid- and low-level design details) was attended by other teams, most notably the user interface team. This eventually led to a simplified system design: Once they were able to peer inside the "black box" that comprised our background applications, the interface team members were able to streamline both their design and ours.

You should also assign more complex tasks to senior developers and, perhaps, have a junior developer assist. If practical, assign the task to the junior developer, and have a senior developer act as a mentor. The mentor can help refine the design or provide a suitable code skeleton with which to work. Let the senior review and refine, but not write, the additional code.

Find someone who is both senior and an excellent developer to become your second-in-command when you’re not available. He should also be a sounding board for any new ideas you may have. You may not always see eye-to-eye, but you should at least agree on what tasks need to be done in the short-term. Everyone has a unique personality and style; don’t expect a clone. Focus instead on the results attained by your partnership.

Play Well With Others

Since many projects require multiple teams, you will need to occasionally run interference. On a large project, you may be the official liaison between your team and other players that include outside companies or contractors. To effectively defend your team’s interests, you must know your team’s responsibilities. I found that a statement of work (SOW) is useful for this purpose, but it must be written in very specific terms. If a SOW is not available, the system architecture and design may dictate or constrain your team’s responsibilities.

Remember, you may have to say no to another team’s requests. Don’t refuse in an arrogant or malicious manner, or others will repay you in kind. Instead, explain why something can’t be done. Relate it to time or money constraints if possible; this always gets attention.

Take This, Brother...

Handing off part or all of a project to another team can be difficult because many developers become attached (intellectually and emotionally) to their code. How can they trust their creation to someone else? The transfer of responsibility can also be a political issue: Another vendor may offer the customer additional modifications (using your source code as a starting point) at a lower rate than your company charges, or the product may be modified by the software maintenance team. Either way, the project and code belong to the customer, unless otherwise stated in the contract. Do your best to assist the new group, without compromising your team’s objectives or performance.

You can successfully move from engineer to technical lead. And although you’re leaving behind the carefree days of writing code, your new role will allow you to have a greater impact. As technical lead, you will be able to directly influence the work of others; junior and senior developers will rely on you for design and implementation guidance. And whether the project is large or small, applying "soft" skills will ensure that your team is focused and efficient, while preserving a record of its actions for later analysis.

RELATED ARTICLES This Week's Developer Reading List This Week's Multicore Reading List A Structured, Unified Approach to Multi-Core and Many-Core Computing -- with Applications Logging In C++ : Part 2 OutSystems Updates Agile Platform		TOP 5 ARTICLES No Top Articles.