🛰️ Signal Boost

Early in my leadership career, I found myself constantly asking teams for updates on velocity. Were we faster this sprint? Could we push more tickets through next time? When things slowed down, I’d press harder. Standups turned into status checks. Planning became pressure. I thought if we could just “get more efficient,” we’d solve our problems.

We didn’t.

Because here’s the truth: velocity is a trailing metric. It’s the output of dozens of invisible systems — not a thing you can will into existence. In fact, trying to squeeze more speed from a team without improving those systems usually leads to burnout, churn, and eventually less velocity.

What actually works?

Start treating your team like an engine — and velocity like the speedometer, not the gas pedal. That means focusing on the inputs that make great teams work:

• Clarity of purpose: Do we know why we’re doing this work?

• Consistency of process: Are we minimizing thrash and last-minute pivots?

• Psychological safety: Can engineers surface concerns without fear?

• Team cohesion: Are we solving problems together, or just handing off tickets?

Teams that feel trusted, respected, and well-aligned don’t just go faster — they build better things while doing it. They catch bugs earlier, make smarter tradeoffs, and recover from mistakes quicker. They get in flow. And that’s when velocity takes off — but as a result, not a goal.

Try This:

Instead of asking, “How do we increase velocity?” ask:

🔁 What’s slowing us down?

🤝 Do we trust each other to speak up when something’s broken?

🧭 Does this team have clarity on what matters most — and why?

Velocity is valuable, but it’s not your steering wheel. It’s your dashboard. Read it. Learn from it. But if you want to drive real performance, fix what’s under the hood.

🔗 Lead Link

Title: Your Dev Methodology Doesn’t Matter

Byline: LinearB sat down with me to talk about what actually drives delivery — and why process frameworks alone won’t get you there.

Why this link?

Velocity, delivery, predictability — these don’t come from following a textbook methodology. They come from healthy, cohesive teams who understand their goals and trust each other to get there. In this interview, I talk about how we’ve embraced flexibility over dogma at GigSmart, and how our best teams share context, solve problems collaboratively, and keep their focus on outcomes instead of rituals.

If your team is endlessly tweaking its Agile board but still missing delivery goals, this might be the reset you need.

👉 Read the interview →

🛠️ Tactical Byte

Velocity is a byproduct — not a goal.

If you’re trying to “fix” your team’s velocity, beware of optimizing too close to the metric. You can’t scrum your way out of unclear goals or burn-down a lack of trust. Instead, zoom out. Look at what’s driving the delivery pattern.

Here’s a 3-part tactical lens I’ve used when velocity trends go south:

1. Clarity: Does the team know what’s most important right now? Are business goals translated into engineering priorities?

2. Flow: Are handoffs, dependencies, and decision-making processes slowing things down? Where are they waiting?

3. Health: Are people stretched too thin? Are they collaborating effectively? How’s morale?

Often, a small improvement in one of these areas will do more for velocity than another retrospective ever could.

🎙️ From the Field

We once had a team that looked good on paper. Talented developers, a clear roadmap, solid tooling. But their delivery pace was erratic, and over time, their velocity trended downward. Stakeholders started getting nervous. So did I.

At first, we assumed it was a process problem. We tweaked planning rituals, reviewed estimates, adjusted sprint lengths. Nothing moved the needle. Then we looked deeper.

What we found wasn’t in the JIRA board — it was in how people were working together. Engineers weren’t clear on priorities. Communication between teams was inconsistent. Trust was low. Fixing those things — not the process artifacts — was what turned the ship around.

Once the team had shared purpose, better communication channels, and a bit more psychological safety, their output stabilized. Not just the amount of work, but the quality. We didn’t “optimize” our way into it. We invested in the team — and the results followed.

👟 Try this:

• Instead of asking, “How do we increase velocity?” ask, “What’s preventing this team from delivering consistently?”

• During retros or 1:1s, look for friction that isn’t in your sprint board — misaligned expectations, overlapping responsibilities, or places where engineers feel stuck.

• Get curious about the invisible systems around your team. That’s where velocity is really born.

💬 Open Threads

A few questions I’m thinking about this week — hit reply and let me know what you think:

• How do you actually know when a team is performing well before the output shows it?

• Have you ever made a team faster by removing process?

• What’s one invisible blocker your team solved recently — and how?