Building Engineering Teams That Actually Ship

When I took over as Director of Engineering at a previous company, the team's velocity was objectively poor. Features were late. Defect rates were above 40%. Morale was low. The CEO's summary: "We need to move faster."

Within months, we increased velocity by 30% and reduced the defect rate to under 5%. Here's how — and it wasn't by asking people to work harder.

Diagnose Before You Prescribe

The instinct when velocity is low is to add process, add people, or add pressure. All three are usually wrong.

Before changing anything, I spent the first two weeks listening. I sat in sprint ceremonies. I reviewed the backlog. I did one-on-ones with every engineer. I looked at the commit history, the bug reports, and the deployment logs.

What I found wasn't a talent problem. It was a clarity problem. Engineers were building the wrong things because requirements were vague. They were building things twice because the feedback loop was too slow. They were spending 30% of their time on context-switching because priorities changed mid-sprint.

The Three Fixes

1. Clear Acceptance Criteria

Every ticket that enters a sprint must have clear, testable acceptance criteria. Not "improve the search experience." Instead: "Search results return within 200ms for queries up to 1000 characters. Results are ranked by relevance. No results returns a helpful empty state."

This sounds basic. It eliminated an enormous amount of rework.

2. Smaller Batch Sizes

We went from 2-week sprints with 8-10 large stories to 1-week sprints with smaller, well-defined tasks. Smaller batches mean faster feedback, less work-in-progress, and fewer mid-sprint priority changes.

3. Protected Focus Time

I implemented "maker hours" — blocks of 4+ hours with no meetings, no interruptions, no Slack expectations. Engineers need deep focus to do their best work. I made protecting that focus my responsibility.

The Scrum Transformation

The team was nominally doing Scrum but had drifted into what I call "Scrum theater" — the ceremonies happened, but they weren't producing value.

I reestablished the fundamentals:

• Standups that were actually 15 minutes, focused on blockers, not status reports
• Retrospectives that produced specific, actionable changes (not just venting sessions)
• Sprint reviews where we demonstrated working software to stakeholders, creating real accountability

The key insight: Scrum isn't a framework you install. It's a discipline you practice. And like any discipline, it requires a leader who models it consistently.

Hiring Right

I hired four engineers in my first 90 days. Each hire was deliberate:

• One senior engineer who could mentor the juniors
• One specialist in our weakest technical area
• Two mid-level engineers who were hungry to grow

Cultural fit mattered as much as technical skill. I looked for engineers who were collaborative, curious, and comfortable with feedback. A brilliant engineer who can't work with others is a net negative on a team.

The Defect Rate Drop

The defect rate dropping from 40% to under 5% wasn't the result of one change. It was the compound effect of everything else:

• Clearer requirements meant fewer misunderstandings
• Smaller batches meant faster feedback on defects
• Code review standards went up because engineers had more focus time
• A culture of quality became self-reinforcing — nobody wanted to be the one introducing bugs into an increasingly clean codebase

The Lesson

Velocity isn't about speed. It's about removing friction. When you give talented engineers clear direction, protected time, and a culture that values quality, they will ship faster and better.

The leader's job isn't to push the team to move faster. It's to remove the things that are slowing them down.