The art of engineering team focus: less is more

Published via GitHub Executive Insights | Authored by Jakub Oleksy and Matt Nigh

As engineering leaders, we’re always being asked to get the most out of engineering teams. This is most often measured by what things we can ship, and how fast. But it can be easy to fall into a common trap: doing too much at once, convinced that more parallel work means more output.

We often fool ourselves into thinking that we’re making progress by simply having at least someone spending cycles on each thing.

But what if the key to shipping more is actually doing less?

First, we have to acknowledge that until we ship something and it is being used, it’s not valuable. So our goal should always be to get things out.

Once things are out, we can learn, adapt, and adjust—including deciding to not further pursue.

This seems obvious; we should, after all, always prioritize finishing what we deem most critical.

So, where do we fall short? Most often it is simply our inability to say no. The other things are also great ideas and it's hard to not at least try to do them. But each of these decisions (or, really, lack of decisions) only delays the things that are most important.

The other, related problem, is that even if we do select the most important work, we often execute on it in a monolithic fashion. That means it’s hard to pivot if needed, until we finish.

There are some core principles we should follow as we look to run nimble engineering teams that ship ongoing value to our customers:

Make all work visible
Define work in small chunks
Limit work in progress
Fund to capacity
Bonus: leave capacity for the unknown

Make all work visible

As engineering leaders, we often think we have a clear picture of what our teams are working on.

Making work visible makes it impossible to ignore reality. When you see everything written down in one place, you can't maintain the fiction that your team can handle "just one more small feature."

The list becomes your reality check, your shield against overcommitment, and your tool for having honest conversations about capacity and priorities. But visibility isn't just about seeing problems—it's about enabling solutions.

When you can see all the work your team is focused on, you can:

Make informed decisions about what to prioritize
Identify which work to stop or pause
Keep teams focused on completing rather than just starting

Think of it like packing a suitcase. You can keep cramming things in until the zipper breaks, or you can lay everything out on the bed first, see what you're really dealing with, and make conscious choices about what makes the cut.

Remember: the goal isn't to track everything forever. The goal is to see reality clearly enough to make better decisions about where your team's time and energy should go. Because in the end, the most productive teams aren't the ones doing everything—they're the ones doing the right things, and finishing them.

Define work in small chunks

One of the most powerful shifts you can make in your engineering organization is breaking work into smaller pieces. I learned this lesson repeatedly throughout my career, most often when I needed to adjust course and had to deal with the consequences of stopping things mid-flight.

When you let work items grow too large, they become black holes that consume your team's energy without showing meaningful progress. Talented teams can get stuck in months-long development cycles, their momentum grinding to a halt as they chase ever-moving finish lines.

The magic happens when you constrain work to one-to-two week increments. This isn't arbitrary—it's about human psychology and team dynamics. When developers can complete meaningful work within a week, they experience regular wins. They stay motivated. They maintain their flow state. Most importantly, they can pivot quickly when needed without throwing away months of work.

Breaking work into smaller chunks also creates moments in time for reflection and adjustment. At GitHub, this approach helped us evolve from shipping massive internal tools to making iterative improvements that benefited both our internal development teams and our customers. Each small chunk gave us the opportunity to ask: "Is this still taking us in the right direction?"

Small chunks enable better collaboration too. When work is constrained to one-to-two weeks:

Code reviews become more manageable
Knowledge sharing happens naturally
Teams can pair effectively
Feedback loops tighten
Deployment risk decreases

But here's what really matters: small chunks of work help support developer flow. When developers can see the finish line, when they know they can complete something meaningful in a short time frame, they stay focused. They don't get lost in the complexity of massive features. They maintain momentum.

I've seen the difference this makes in code quality too. Smaller chunks mean more focused testing, more thorough reviews, and fewer risks in deployment. It's the difference between trying to review 1,000 lines of code at once versus reviewing 100 lines five times over a two-week period. Which do you think gets better scrutiny?

This might feel slower. And in fact, if you could plan a feature perfectly from day one that takes X months to finish and then just execute on it straight through, you would likely get it done faster.

However, it’s important to consider the risks. First, the risk of having the wrong plan from the onset and not having any defined milestones to reflect. Next, the cost of pivoting the team's work if something else, unforeseen, becomes a higher priority. And finally, scope creep will inevitably occur, the size of which is often proportional to the total size of the project.

You're not trying to slow down development by breaking things into smaller pieces. You're actually speeding it up by making progress visible, maintaining momentum, and enabling your team to deliver value continuously rather than in sporadic, massive chunks. And when you cross that finish line, you’re doing so while still feeling good, instead of exhausted from an unpredictable race.

One key practice to make this successful is starting every 1-2 week sprint with a deep planning session that outlines exactly what the exit criteria are, who is doing what and breaking that work down to even smaller pieces, often by identifying tasks that will take half a day or even less.

Limit work in progress

Multiple features per developer might seem like a path to higher productivity, but it's actually a productivity killer.

When developers juggle multiple projects, it can be challenging to make meaningful progress on any of them. It's like trying to cook five meals at once—you'll likely burn something, forget ingredients, or end up with everything taking twice as long.

Context switching becomes particularly costly. Every time a developer shifts between features, they need to reorient themselves around the entire context of a new feature—the requirements, the technical constraints, the related code, and the outstanding questions, among other things. Research suggests it can take up to 23 minutes to fully regain focus after a switch. With multiple features in flight, developers spend more time context switching than actually writing code.

Quality may suffer too. When attention is divided across multiple features, important details can get missed, edge cases go unconsidered, and technical debt accumulates. We've seen this pattern repeatedly at GitHub: the more work in progress, the higher the bug count and the lower the overall code quality.

Perhaps most importantly, team frustration sets in. Developers thrive on the satisfaction of completing work and shipping features to users. When everything is "in progress" but nothing is getting done, morale takes a hit. I've watched talented teams become discouraged simply because they couldn't see their impact. Instead,they were too spread thin across too many initiatives.

The solution isn't working longer hours or pushing harder. It's doing less at once. When we limit the work that’s in progress and focus our teams on one or two features at a time, we actually ship more—and we ship better quality work with happier developers.

How do we know when teams take on too much work simultaneously?

Indicators at the team-level include:

Multiple active features per developer (e.g., four-plus concurrent tasks)
Features taking weeks or months longer than estimated
Many partially completed features, few shipped ones

Indicators for individual developers:

Difficulty maintaining focus or getting into flow state
Long delays in responding to code reviews
Increased time spent in status meetings explaining in-flight work
Difficulty articulating current priorities
Large pull requests (PR)

Morale symptoms

Team frustration from lack of completion
Decreased sense of impact and accomplishment
Rising stress levels from juggling multiple priorities
Burnout from constant task switching
Loss of enthusiasm for new initiatives

Delivery patterns

Many features at 80% complete, few at 100%
Increasing time between deployments
Features being abandoned mid development
Rising number of emergency fixes
Longer cycle times from start to completion

Fund to capacity

This is the idea that you should fully fund your highest priority work before moving on to the next thing. It's a simple concept that challenges a common anti-pattern I've seen across many engineering organizations—the "one developer, one feature" approach.

Here's what typically happens: You have a team of eight developers, so you assign eight different features, one to each developer. It seems logical, right? Everyone's busy, everything's moving forward. But this is actually a recipe for slower delivery and fragmented knowledge.

I often see managers do this because every individual on the team wants projects that can get them promoted. Managers think the only way to do this is for every developer to lead a project, so naturally, they create a project for every developer.

Try this: Take your top priority and put as many developers on it as you can—until they're literally stepping on each other's toes. Only then should you move on to the next priority. This is what we call "funding to capacity," and it's transformative.

Let me be clear about why this works. When you swarm as a team on a single feature:

Knowledge spreads naturally across the team
Solutions emerge faster through collaboration
Code quality improves through real-time peer review
The feature ships significantly faster
Team energy builds through shared accomplishment

At GitHub, we've seen this approach repeatedly outperform individual assignments. For instance, when we tackled our deployment pipeline improvements, we didn't distribute the work across individual developers. We swarmed it. The result? Not only did we ship faster, but we ended up with a team of developers who all understood the deployment system deeply, rather than just one or two experts.

Here's something that might be controversial: in this model, it can be helpful to pair developers to work on a discrete task. Yes, it might seem like you're "wasting" a developer's time by having them work together. But think about the hidden costs of isolation—knowledge silos, longer review cycles, lower code quality, and the bus factor of having only one person who understands each feature.

When you fund work to capacity, you're not just optimizing for speed.You're building team resilience. Every feature becomes a shared learning opportunity. Every challenge becomes a chance for collective problem solving. You're creating an environment where developers aren't just coding—they're growing together.

And reflecting on the desire for individuals to get promoted, this is where what you reward is what you get. Promote those individuals that embrace the team over individual accomplishments, those that strive to improve the outcomes, together, rather than those that think individual productivity is the key to success.

Leave room for the unknown

A highway operating at 100% capacity isn't a highway—it's a parking lot. The same principle applies to engineering teams. You need space to absorb the unexpected. Some teams might need less, others more.

If your team is working at 100% capacity, you're actually operating at a deficit. Because here's the reality—unplanned work isn't actually unplanned. It's inevitable. What's unplanned is just the timing and the specifics.

Here's what happens when you don't leave room for the unknown:

Teams become reactive instead of creative
Quality suffers as corners are cut to "make up time"
Developer satisfaction plummets
Innovation decreases because there's less space to experiment
Technical debt accumulates because there's never time to address it

But when you deliberately maintain buffer capacity:

Teams can respond to issues without derailing planned work
Developers have space to think creatively about solutions
There's room for learning, experimentation, and innovation
Quality remains high because teams aren't constantly rushing
Morale stays strong because the pace is sustainable

Here's a counterintuitive truth: Teams with built-in buffer capacity often deliver more than teams running at "full" capacity. They're more innovative, more resilient, and ultimately more productive. Because when everything is an emergency, nothing gets done well.

So what's the right amount of buffer? Start with 20% and adjust based on your team's needs. Infrastructure teams might need more, feature development teams might need less. The key is to be intentional about it. Don't treat buffer capacity as waste—treat it as a crucial investment in your team's ability to handle reality.

Your team's capacity isn't just about the work you can predict. It's about maintaining the resilience to handle what you can't predict while keeping your developers creative, engaged, and doing their best work.

Take this with you

We learned that the path to shipping more wasn't about increasing our velocity or adding more developers—it was about having the discipline to do less at once. The formula is deceptively simple:

Make work visible so you can't hide from reality
Break it into small chunks that maintain momentum
Limit work in progress to enable focus
Fund priority work to capacity
Leave room for the unexpected

But simple doesn't mean easy. These principles challenge our instincts as leaders. They require us to say no more often than yes. They demand that we resist the siren call of parallel work and trust that focusing on fewer things will actually help us ship more. Your team's true capacity isn't measured by how many features they can juggle, but by how effectively they can deliver value to your customers. Sometimes, the most powerful thing you can do as a leader is to take something off your team's plate rather than add to it.

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore Executive Insights for more thought leadership on the future of technology and business.