Your first stretch project: agree the decisions before you start

“Would you like to lead this piece of work?” can be an exciting invitation. It can also leave some important questions unanswered. Can you choose the approach? Who resolves a disagreement? Which commitments change so you have time to do it?

A stretch project gives you responsibility that extends your current experience. That might mean leading a small technical change, coordinating a pilot or presenting a recommendation. A useful starting point is a shared agreement about the decisions you own and the support around them.

This guide helps you prepare that agreement with your manager or project sponsor, the person who backs the work and helps resolve obstacles. You can use it when moving into a lead role across development, product or delivery.

Make the opportunity concrete

In The unseen work of engineering management, published on 21 October 2026, Atila Ekimci argues for giving people their first opportunity to lead, alongside attention to sustainable workloads. The agenda for techUK’s 22 October women-in-tech event also highlights progression and retention. These recent discussions prompt a practical question: what conditions make an opportunity workable?

Begin with the result the team needs and the capability you want to practise. “Lead the project” is broad. “Coordinate a two-week pilot, make routine planning decisions and present a recommendation” is something you can discuss and review.

The agreement should clarify responsibility, authority and access to help. It should also identify decisions that belong to someone else, so you can bring the right question to the right person.

Sort the decisions into three groups

A worked example: leading an onboarding-guide pilot

Illustrative example: Priya is a developer taking the lead on a revised internal onboarding guide for one support team. Her development goal is to practise coordinating feedback and explaining trade-offs. The proposed pilot lasts two weeks; replacing the organisation’s whole onboarding process is outside its scope.

Priya and her manager agree the following decision map:

• Priya decides: the order of draft sections, the feedback-session agenda and the format of the findings.
• Priya recommends: which troubleshooting walkthrough to include. The technical lead reviews its accuracy before the pilot.
• The manager resolves: requests for extra team time, a changed pilot date or work beyond the agreed scope. Access changes follow the organisation’s existing approval route.

The manager moves a routine documentation task to another colleague and agrees that colleague’s capacity. The technical lead reserves a review slot. Priya has a named contact for questions and a backup if the reviewer is away. These are proposed arrangements in the example, rather than measured results.

During the pilot, someone requests a walkthrough for an additional service that would require new account access. Priya can record the request and explain its value. The new service exceeds the agreed boundary, so she takes the options to the manager instead of quietly adding it. The original pilot can continue while that decision is considered.

At the review, the team can assess Priya’s coordination and reasoning separately from decisions she was not authorised to make. A delay waiting for an access decision needs to be recorded accurately, alongside any action she could reasonably have taken.

Write a seven-line project agreement

Complete these prompts together before the first planning session. Keep the note somewhere the people involved can find it, and update it when the arrangement changes.

Test the note with three likely requests: a routine choice, a disputed recommendation and a larger change. Can you both identify the decision owner and the next action? If you give different answers, resolve that difference before work depends on it.

What managers need to put in place

A first lead should have a realistic chance to succeed. Make space in the workload, confirm reviewers’ availability and explain the arrangement to colleagues. Check in early enough to adjust it, rather than waiting for the final presentation.

Offer opportunities openly and explain the selection criteria. Look beyond the colleagues who volunteer first, and ask what support would make participation possible. Allocate necessary coordination fairly, alongside opportunities to practise technical and product judgement.

Agree how feedback will relate to the person’s development goals. Completing a stretch project does not guarantee a promotion. If a temporary responsibility becomes regular, revisit its scope and how it fits the person’s role.

For your next opportunity, start with one question: “Which decisions would I own?” Bring two realistic requests to the conversation and work through who handles each. Leave with an agreement that gives you enough authority to act and a clear route to support.