The Art of Engineering Team Focus: Less Is More

The Trap of "More, Faster"

As engineering leaders, we're constantly pressured to maximize team productivity. This is typically measured by "how much can you ship and how fast." But there's a common trap: the illusion that "doing more things simultaneously produces more results."

"We fool ourselves into thinking we're making progress just because someone has a hand in every task."

But the real important question is: "What if the key to shipping more is actually doing less?"

Value Only Exists After Shipping

A critical point to remember: nothing has value until it's shipped and actually used. Our goal should always be "shipping something." Only after shipping can we learn, adapt, and course-correct when needed.

But in reality, failing to say "no" is often the problem. With so many good ideas, we want to try everything. But this decision (or failure to decide) ultimately delays the most important work.

Core Principles: 5 Methods for Agile Engineering Teams

1. Make all work visible
2. Break work into small units
3. Limit work in progress
4. Swarm on priority work
5. Leave slack for the unexpected

1. Make All Work Visible

Making work visible means clearly understanding what the team is working on. This isn't just about revealing problems — it's a tool that enables solutions.

"When you make work visible, you can't ignore reality. When everything is visible, you can't maintain the illusion that 'one more small feature won't hurt.'"

Benefits of making work visible:

• Clarify priorities.
• Identify work to stop or defer.
• Help the team focus on "finishing" rather than "starting."

Making work visible is like packing a suitcase for a trip. Instead of stuffing things in randomly, lay everything out on the bed and carefully select "what's truly needed."

2. Break Work into Small Units

Breaking work into small units is one of the most powerful ways to maximize team productivity. Large tasks can become "black holes" that drain team energy.

"When tasks get too large, the team spends months with no visible progress, chasing endless deadlines."

Breaking work into 1-2 week units is crucial. This isn't just a scheduling issue — it's an approach based on human psychology and team dynamics. Small work units produce these effects:

• Developers experience frequent "small wins" to maintain motivation.
• Quick pivots are possible when needed.
• Code reviews are simplified, and collaboration happens naturally.
• Deployment risk decreases.

"Small work units keep developers from getting lost in complex features. They gain confidence that they can complete something meaningful in a short time."

Breaking work into small units may look slower, but it actually enables faster shipping by "making progress visible, maintaining team momentum, and continuously delivering value."

3. Limit Work in Progress

Having a developer work on multiple tasks simultaneously may seem productive, but it's actually the opposite.

"Working on multiple projects simultaneously is like trying to cook five dishes at once. You'll end up burning something, forgetting ingredients, or everything taking twice as long."

Context switching (moving from one task to another) is especially costly. Research shows it can take up to 23 minutes to fully regain focus after a single switch. Working on multiple tasks simultaneously causes:

• Reduced code quality
• Lower team morale
• Decreased task completion rates

"Limit work in progress and have the team focus on just one or two tasks — you'll ship more. And you'll ship higher-quality work with happier developers."

4. Swarm on Priority Work

The "one developer, one feature" approach is common but leads to slow shipping and knowledge silos. Instead, swarming team capacity on the highest priority work is key.

"Put as many developers as possible on the top priority. To the point where they're stepping on each other's toes. Only then move to the next priority."

Benefits of this approach:

• Knowledge naturally spreads across the team.
• Collaboration leads to faster solutions.
• Code quality improves through real-time peer review.
• Features ship much faster.

"When a team focuses on one task, it goes beyond just coding — it creates an environment where everyone grows together."

5. Leave Slack for the Unexpected

Just as a highway operating at 100% capacity creates traffic jams, a team operating at 100% capacity creates gridlock. Unexpected work always comes up — the timing and specifics are simply unpredictable.

"If your team is working at 100% capacity, you're effectively operating at a deficit."

Benefits of leaving slack:

• Flexible response to unexpected issues
• Room for creative thinking and experimentation
• Quality maintenance
• Higher developer satisfaction

"Teams with slack are more innovative, more resilient, and ultimately more productive."

Conclusion: Less Is More

The lesson from GitHub's experience is simple. To ship more, you must do less. Remember:

• Make work visible to face reality.
• Break work into small units to maintain momentum.
• Limit work in progress to increase focus.
• Swarm on priority work.
• Leave slack for the unexpected.

"A team's true capability isn't how many tasks they can handle simultaneously, but how effectively they can deliver value to customers."

Less truly is more. As a leader, your most powerful action may be reducing your team's workload.