Strategies for Successful Development

Process and technology for small teams building real software

Dev Leads pt 1: What is a Lead?

Posted by S4SD (Seth Morris) on 2008/09/17

This is part one in a series on the role and practice of the Technical Lead, Lead Engineer, or whatever your company calls them.

What is a lead?

The software industry doesn’t have any standardization of titles, responsibility, team structure, or levels of experience and skill; the industry as a whole is certainly too young and too dynamic for all that. But at many— maybe most— companies, teams have technical people who perform both technical and non-technical leadership. Many companies mark these people out as development leads; at others they may be called technical managers, managers of technology, or even some untitled subset of senior engineers.

These people are in roles with duties they have not been trained for; they are often neither appreciated nor compensated for the role; and they often have no explicit authority to perform many of the day-to-day tasks required of them. The dev lead’s job usually falls to them for non-technical reasons: the respect of their peers, their ability to communicate and mediate within the team, and their appreciation of the entire project context and business needs, as opposed to just technical skill.

At many companies, the people in lead roles are never told exactly what is expected of them as the lead, where it can go as a career within the company, or how their performance as a lead will be evaluated. And very, very few companies provide any real training in being a lead.

To make matters worse, most leads are also expected to continue owning crucial sections of code, but the work of the lead requires an interrupt-driven and meeting-heavy day showing a level of confidence that is in direct opposition to the requirements of deep coding: uninterrupted time, introspection, and repeated failure. Many leads work much of the regular workday as a lead, doing procedural things, answering questions, and firefighting; then they work into the evening or night writing their code. 

 

Working Styles

 

Lead

Contributor

Work day

interrupt-driven

scheduled

Attention direction

external

internal

Focus on

many things

one thing at a time

Primary context

the project

one piece of the project

Scope

big picture

details

Validation

external (see/hear evidence that the project is running well)

internal (individual work known to be good by internal judgement)

Temporal structure

perceives time from outside for comparison and planning

varies, but generally contains a strong component of immersion in the moment of work (c.f. "Flow")

Motivation direction

often identifying risk or problems and motivating away from them

often motivating towards a planned course of action (function contract, workflow, test plan, etc.)

Responsible for

everyone

self

If leads are to get the support they require—if you, as a lead, are to get the support you need—we need to identify what a lead is, what a lead does, and why almost every company comes to a similar recognition of a special technical-cum-leadership role but we as an industry still fail to articulate and support it.

Who is a lead?

The role of development lead isn’t always spelled out to the team. Who is a lead? At different companies, different job titles may have the de facto lead role. Sometimes, several titles at the same company are leads, depending on the team or individuals. Sometimes, the lead isn’t recognized by any title or even acknowledged by management. Some leads are self-selected and lead by personal authority.

Commonly, development leads can be found with these titles:

· Dev Lead

· Technical Lead

· Technical Manager

· Senior Software Engineer (although not all Sr Engineers act as leads, of course)

· Manager of Technology

A lead is recognized by the role s/he performs, however poorly that role may be articulated; the title is secondary. As an industry, software is averse to titles, established levels of skill, defined strata of experience, or other standardizations common in some industries.

What isn’t a lead?

A lead isn’t a manager. Some managers are also leads, and some leads are acting or de facto managers, but the role of being a lead is about the project and the technology, not managing the people.

People go to a manager as a liaison with the company: other departments ask to know who is assigned to do what, team members get their priorities and deadlines, or team members ask use the manager as their primary interface to company policies and HR. The manager role operates in a framework of company needs and company policy. Who has sick time available? How is the new hire doing in his or her first 90 days? The scope of the management role includes the project, but is focused more generally on the company and its rules. Managers may insulate team members from too-rapid change outside the team or from maneuvering and posturing that would just distract the team, but the manager role doesn’t have to have to have anything to do with the details of the project.

The Role(s) of the Lead

Leads, on the other hand, are the interface to the project. The lead represents the team to people who don’t interact with the project daily—and the lead interprets and translates the rest of the company back to the team. On a technical front, the lead maintains the state of the project: what is complete, what is at risk, what piece is necessary for what other piece and provides guidance on the implementation as a whole, maintaining consistency, training less-experienced developers, and keeping the broad view of what-impacts-what so other developers can focus on individual pieces.

(Click for full-size image)

Leads perform many roles within a team: designer, communicator, negotiator, mentor, taskmaster, and more. Not every lead has the same responsibilities and every company has a slightly different mix of tasks a lead spends time on. Often these tasks have conflicting needs: uninterrupted time versus interrupt-driven behavior, alone versus interactive, short-term versus long-term. Balancing these tasks is the art of being a good lead, and it varies from company to company and from project to project.

Why does the role vary so much? Because a lead fills in gaps that the organization has institutionalized.

Larger view, split attention

The common themes of the lead’s roles are larger view and split attention. The lead must take a larger view than just one section of the code, or even just the code, and the lead’s attention is split between the project and its goals, the team members and their activities, the lead’s own development, and the business situation and business purpose of the project.

The lead has to communicate the business purpose of the project to the developers and moderate between the project’s business needs and the team’s technical desires. The lead also balances the technical activities and needs of individual team members.

It is the lead’s job to bring this larger view and understanding of the whole situation—technical and non-technical—to technical discussions with the team and planning and status discussions with management.

Technical decisions

The most obvious responsibility of a dev lead—and the one that usually gets mentioned first by their managers—is to mediate and lead technical decisions. This requires knowing the technology and its capabilities, knowing the abilities and experience of the team members, and knowing the requirements and specifications of the product. It also requires an understanding of any sales and marketing limitations on technology, assessing schedule impact, predicting risk, and navigating interpersonal politics on the team.

In addition, the lead must often make quick, confident decisions an present them convincingly to the team.

Owns shipping

On most teams, the lead is the one looked to by management to see that the team’s piece ship. This involves knowing what’s working, what isn’t, and what’s risky. The lead needs to raise problems with management quickly, predict technical problems before they happen, and keep the team focused on shipping the product.

Managing up

The dev lead is the voice of the team to management on anything technical. The lead is responsible for bringing technical problems, hardware, software, or facilities needs, ideas for new approaches, or anything else requiring the company’s assistance to management. Even if the lead is not also to titular manager, personnel issues will often become apparent to the lead first or manifest as technical issues; the lead is often the only way management is informed about what’s actually going on with the team.

It is the job of the lead to "manage up" for the team: to reduce the amount of overhead management requires, to filter management’s activities to only those relevant to the team, and to convince management to listen to the team’s concerns and needs.

Interpret management

As the flip side of being the voice of the team, the lead interprets management’s directives and business needs into technical needs. This includes developing development plans, validating technical specifications, and making technical decisions. This puts the lead in a position of influencing how the team reacts to management’s decisions and communications.

Oversee design

The lead oversees design. This can lead to a tension with team members depending on how much autonomy the team members have to do their own design. It can also lead to conflict with team members over the design decisions. The lead needs strong technical decision-making skills, but also needs good skills to communicate the reasons for decisions and the requirements decisions are made on, as well as good communication, rapport, and influencing skills.

As a corollary to this, the lead determines the criteria used to make technical decisions. Internal conflict can be reduced by making these criteria explicit at the outset. (But that’s the subject of another post.)

Mentor juniors

The lead is the person junior engineers look to for technical growth, evaluation, and inspiration. The lead is in a position to shape their expectations, their work ethic, their interaction with their peers and with management, and their career path.

How the lead interacts with juniors can be especially important when there are other senior, non-lead developers who do or do not want to mentor juniors.

Model engineer

The lead is the model engineer for the team. He or she is the example of what is expected. The lead’s code and design must be of acceptable quality, the lead’s communication must be acceptably clear and helpful, and the lead’s focus sets the tone for the team and tells them what is important. Leads are in between developers and managers. Even if they are also managers, when they are acting as a lead they are a developer as well. Leads must be familiar with the complete design and much of the code the teams produces.

As a developer, different leads have different levels of code-producing involvement. Some leads take critical pieces of code and keep them to themselves; others refuse to take code on the critical path. This usually depends on the amount of time and attention other tasks are requiring of the lead.

The lead’s code has to be of acceptable quality, but it doesn’t have to be the best on the team. There may be brilliant developers who aren’t leads for many reasons. As the holder of the project state, the lead needs to acknowledge that someone else’s code is a better model for junior developers to learn from.

Implement technical process

The lead implements the technical, team-facing portion of the development process. The lead sets the pace, tone, and structure for code reviews, design walk-throughs, and technical documentation. How the process is reified comes from the lead.


Listening to: Dusty Springfield – Dusty in Memphis – The Windmills of Your Mind

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: