Last year I wrote about stretch culture - the idea that sustainable pace isn't about avoiding pressure, it's about managing energy. A year on, I want to add the other side of that argument. Because the bigger risk I'm seeing right now isn't teams that burn out from too much stretch. It's teams that stagnate from too little.
What You Need to Know
- Teams that never face challenge lose their edge over time
- Comfort becomes complacency when there's no growth stimulus
- The stretch zone sits between comfort and breakdown - finding it requires knowing your team
- Leaders who only protect their team from pressure are doing half the job
The Comfort Trap
COVID has created a strange dynamic. Many teams pulled together during the initial crisis. They stretched. They adapted. They shipped things they didn't think were possible. And then the crisis became the new normal, and something settled.
The urgency faded. The routines returned. And some teams found themselves in a comfortable groove that felt like stability but was actually stagnation. The same types of projects. The same technical approaches. The same level of challenge. Nobody was struggling. Nobody was growing either.
I noticed it in code reviews first. The code was fine. Clean, functional, well-tested. But it was the same kind of code as six months ago. The same patterns, the same tools, the same level of ambition. The team had found a formula that worked and stopped experimenting.
46%
of employees say their skills have stagnated in 2020 due to focus on maintaining rather than building
Source: LinkedIn Learning Workplace Report, 2020
The Stretch Zone
Sports science has a useful concept: the zone of proximal development. Below it, you're not challenged enough to adapt. Above it, you're overwhelmed and break down. In the zone, you're uncomfortable but coping. That's where growth happens.
For software teams, the stretch zone looks like:
- A project that requires a technology the team hasn't used before
- A deadline that's ambitious but achievable
- A client problem that doesn't have an obvious solution
- A quality bar that's slightly higher than what the team is used to hitting
None of these should feel impossible. All of them should feel uncomfortable. The discomfort is the signal that adaptation is happening.
Stretching Without Breaking
The distinction between healthy stretch and burnout is support. A team that's stretched without support breaks. A team that's stretched with support grows. The support looks like:
Psychological safety. The team needs to know that struggling is acceptable. If stretching into a new technology means slower delivery for a sprint, the leader absorbs that pressure from the client. The team needs space to be bad at something before they're good at it.
Skill investment. If you're asking the team to use a new technology, give them time to learn it. Not "learn it on the weekend." Actual, budgeted, protected learning time. A day or two of investment before the project starts saves a week of fumbling during it.
Stretching a team is a leadership responsibility, not a management tactic. You have to create the conditions where harder problems make them better instead of breaking them.
Isaac Rolfe
Managing Director
Recovery time. After a stretch period, the team needs to consolidate. A sprint of maintenance work, tech debt cleanup, or documentation after a challenging project isn't a waste. It's recovery. Athletes don't train at peak intensity every day. Neither should delivery teams.
What I Got Wrong Last Year
In the original stretch culture post, I focused heavily on protection. Don't burn out the team. Manage energy. Protect sustainable pace. All true. But incomplete.
I didn't say enough about the leader's responsibility to challenge the team. To push them into the uncomfortable zone deliberately. To choose projects and tasks that force growth rather than just choosing the safest path.
The best teams I've worked with have a rhythm: stretch, recover, stretch, recover. The worst teams are either always stretched (burnout) or never stretched (stagnation). Both failure modes look different. Both produce the same outcome: a team that stops improving.
The Practical Balance
For us at RIVER, the balance looks like this:
One stretch project per quarter. Not every project needs to push the team. But at least one should involve something new - a new technology, a new domain, a new type of challenge.
Individual stretch assignments. Not everyone needs to stretch in the same direction. A frontend developer might stretch into backend work. A senior might stretch into client-facing presentations. The stretch is individual even when the project is shared.
Explicit conversations. We ask each team member: "What do you want to get better at this quarter?" Then we try to create opportunities for that growth within client work. Not always possible. But asking the question changes the dynamic from "assigned stretch" to "chosen growth."
The goal isn't constant discomfort. It's periodic, supported, intentional challenge that keeps the team sharp. Comfortable is fine for a sprint. Comfortable for a year is a problem.