liveBook · Manning

Developer productivity

As explained in Think Like a Software Engineering Manager

A measure of output produced relative to the time, effort, or resources used, applied here to a team.

Developer productivity is the output a team produces relative to the time and effort it uses. For an engineering manager, the practical question is not simply whether everyone looks busy: it is whether the team can deliver important work while supporting the people doing it. Clear goals, trust, collaboration, and opportunities to grow all matter. section 1.0 section 3.0

A simple output comparison

Six engineers each complete two tasks per day, or 12 tasks together. After code reviews are streamlined and the team uses agile practices, training, and cross-training, each completes three tasks per day. That is 18 tasks together—a 50% increase in this example. The count makes the change easy to see, but managers still need to ask whether the work meets the team’s priorities. section 1.0 section 4.1.1

Do not equate team productivity with the sum of individual performance ratings. Individual performance concerns how someone operates within the team and company; team productivity also depends on team dynamics and conditions around the team. A developer can exceed a stretch goal yet miss a critical deliverable, so performance conversations should consider both effort and alignment. section 3.3.4 section 4.1.1

To make productive work easier:

  • Set clear goals and expectations, build trust, and address morale or conflict so the team can collaborate. section 3.0 section 3.5
  • Use feedback and performance conversations to keep work aligned with important deliverables, not just visible activity. section 4.1.1 section 4.1
  • Protect time for important work: remove unnecessary meetings, consider asynchronous updates, and revisit tasks that consume time without enough value. section 14.2.1 section 14.3.3
Figure 14.1 Declutter your calendar by creating focus blocks, lunch breaks, and free time blocks.
figure

The sample calendar shows how focus blocks, breaks, and free time can sit alongside meetings. section 14.2.1

Start with one obstacle the team can name—such as slow reviews or meetings that crowd out focused work—and check whether changing it helps the team deliver its priorities. Make room for breaks, too. A manager’s habits set an example; late-night messages can suggest that late-night work is expected. section 1.0 section 14.1 section 14.2.1

How Think Like a Software Engineering Manager covers it

How deep it goes
Illustrates a task-count increase and gives management practices, but does not establish a general productivity metric.
Examples
Uses a six-engineer task-count comparison and a sample calendar with focus blocks and breaks.
What you can do after
Practice/perform it by identifying barriers to priority work and adjusting team practices and calendar time.
How it connects
Connects team productivity to performance management, team dynamics, goal alignment, and time management.

Also explained in

Compare how 4 books explain developer productivity →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a Software Engineering Manager. The section links point to the parts of the book it draws on.