Practices

Introduction

Building good software takes more than writing good code. Testing, design, product management, continuous delivery, and reliability engineering each play a part, and the outcome depends as much on how well they fit together as on how well each is done.

This section covers those practices. Where Ways of working describes how a team organises and flows its work, this section describes the practices applied within that work.

They matter to a Tech Lead because they are accountable for the technical outcomes of their team, and those outcomes depend on these practices. A Tech Lead is also often the person best placed to see where they meet, and where things fall through the gaps between them.

As elsewhere in the handbook, the pages give an opinionated view, based on practical experience, of an approach that is a good default. They don’t attempt to survey every alternative.

Guiding and working alongside

A Tech Lead has one of two relationships with each practice.

• Guiding. For some practices, the Tech Lead sets the standard, coaches the team, and makes sure the practice happens. They may draw on specialists who advise on the detail, but the responsibility stays with them. Testing is a typical example: the Tech Lead is ultimately responsible for ensuring appropriate testing is done, even where dedicated testers shape much of the approach.
• Working alongside. Other practices are led by someone else, such as a designer or Product Manager. Here, the Tech Lead needs to understand the practice well enough to collaborate effectively, contribute the technical perspective, and make the joins between disciplines work. In Product design, for example, the Tech Lead works with the Product Manager and designer as part of the product trio, and leads on feasibility.

Which relationship applies depends on who else is around. Reliability practices are largely a matter of working alongside if there is a dedicated SRE or platform team, but fall to the Tech Lead if there isn’t. Similarly, if a team has no designer, someone still needs to make sure the design work gets done. As What is a Tech Lead? puts it, if an area has no clear owner, assume it falls to you until agreed otherwise.

What good practice looks like

Although each practice is different, the approaches recommended in this section share some common themes.

• Quality is built in early, not checked at the end. Problems are cheapest to fix before the work starts, so each practice moves effort earlier. Testing starts with prevention rather than cure, and design agrees the conceptual model first, because it is the most expensive part to change.
• The work runs alongside delivery, not in a separate phase. Testing happens as part of implementation, and design runs alongside delivery, only a little ahead of it. Separate phases create hand-offs, queues, and late surprises.
• The work is shared, not handed off. Developers write the tests, the product trio shapes solutions together, and engineers need contact with users too. Each hand-off loses context, so the fewer the better.
• Automate by default. Anything that needs to be done repeatedly and reliably, such as running tests, scanning code, and deploying, is automated as far as possible, leaving people free for the work that needs judgement.
• Feedback comes quickly. Tests run at the right time so problems are found within minutes, and design is iterative, so ideas are tested with users before too much is built. The sooner the team learns it is wrong, the less there is to undo.

These themes echo what agility actually means, applied to the practices rather than to the process.

In this section

• Testing describes an approach to testing that is continuous, mostly automated, and shared across the team, with specialist testers shaping quality rather than executing tests.
• Product design explains how the Product Manager, designer, and Tech Lead shape solutions together, and how design can run alongside delivery while staying grounded in contact with real users.