Nine months ago my entire team went remote overnight. Not the planned, phased, “let’s pilot this for a quarter” kind of remote. The kind where you close the office on a Friday and hope Zoom works on Monday.

Some engineers barely missed a beat. Others struggled for weeks. The difference wasn’t seniority or technical skill. It was how quickly they could rewire their working habits.

I keep coming back to that observation as 2020 wraps up.

Learning velocity over fixed expertise #

The DORA State of DevOps report has been measuring engineering team performance for years. The 2020 edition makes something explicit that I think most managers already felt: the highest-performing teams weren’t the ones with the deepest expertise in specific technologies. They were the teams that could absorb new information and change course without falling apart.

I’ve started calling this “learning velocity” in conversations with other engineering leaders. It’s not what you know; it’s how fast you can acquire and apply what you don’t know. An engineer who’s mastered PostgreSQL but can’t pick up DynamoDB when the architecture shifts is less valuable than someone who’s proficient (not expert) in both and comfortable being a beginner again.

This year forced that trade-off into the open. Teams that had optimized for stability — deep expertise, rigid processes, well-oiled routines — hit walls when the ground moved. Teams built for change adapted.

What “built for change” actually looks like #

It’s not about being chaotic or lacking structure. It’s about designing processes that bend instead of break.

At TaskRabbit, a few things helped us this year. We shortened sprint cycles from two weeks to one. Not because shorter sprints are inherently better, but because they reduced the cost of changing direction. When priorities shifted (and they shifted a lot in 2020), we lost days of work instead of weeks.

We also invested heavily in async communication. Design docs instead of meetings. Loom recordings instead of standups. Written proposals instead of whiteboard sessions. This wasn’t a philosophical stance on remote work; it was a practical response to having engineers across four time zones. But it had a side effect: decisions became more deliberate. When you have to write your idea down before presenting it, you think harder about it.

The Accelerate research (Forsgren, Humble, and Kim) frames this around capabilities rather than maturity models. High-performing teams don’t arrive at a destination and stop. They continuously improve specific capabilities. That framing maps well to adaptability; it’s not a state you achieve, it’s a muscle you build.

Building adaptable teams #

A few things I’m planning to carry into 2021:

Hire for learning trajectory, not current skill set. The best interview signal I’ve found this year is asking candidates about something they learned recently and poorly. Engineers who can articulate their own incompetence and describe how they worked through it tend to be the ones who adapt fastest.

Rotate engineers across domains more frequently. Specialization is comfortable but brittle. Cross-training creates redundancy and (more importantly) builds the “beginner’s mind” muscle that makes people comfortable with ambiguity.

Reduce process dependencies on specific tools or platforms. The teams that struggled most this year were the ones whose workflows were tightly coupled to in-office tooling — physical kanban boards, in-person code reviews, hallway conversations as a decision mechanism. Every process should survive a tool change.

2020 wasn’t the year anyone planned for. But the engineers who came through it strongest were the ones who treated uncertainty as a feature, not a bug. I think 2021 is going to demand more of the same.