Authors: Jakub Oleksy | [@JakubOleksy](https://github.com/JakubOleksy) and Matt Nigh | [@mattnigh](https://github.com/mattnigh)

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](https://lifehacker.com/how-long-it-takes-to-get-back-on-track-after-a-distract-1720708353) 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.


What if the key to shipping more is actually doing less?

DevOps - Productivity pillar - Dark 3

Resource Page for /developer-productivity/engineering-team-focus

The art of engineering team focus: less is more

Authors: Jakub Oleksy | [@JakubOleksy](https://github.com/JakubOleksy) and Matt Nigh | [@mattnigh](https://github.com/mattnigh)

It's a question that haunts engineering leaders, spawning an industry-wide obsession with metrics like lines of code written, pull request velocity, and deployment frequency. We've built dashboards, created frameworks, and spent countless hours trying to quantify developer output.

__But what if we're measuring the wrong things entirely?__

At GitHub, we've learned through scaling our own engineering teams that the best indicator of productivity isn't found in commit counts or deployment metrics---it's in developer satisfaction. Happy developers don't just write better code; they solve harder problems, collaborate more effectively, and build better products.

In this post, we'll explore why developer satisfaction isn't just a feel-good metric---it's a powerful tool for measuring and improving engineering productivity.

### The productivity measurement problem

Despite the tech industry's obsession with metrics and optimization, there's a striking paradox at its heart: *most organizations have no systematic way to measure developer productivity.*

This measurement vacuum isn't an oversight---it reflects the complexity of quantifying productivity where individual contributors might spend days solving problems that no one was even aware of when the week began.

The industry's attempts to tackle this measurement challenge have largely centered around deployment metrics popularized by DORA and others: 

-   __Deployment frequency (DF):__ This tells you how often code is getting shipped to production. High frequency indicates your team is iterating fast, delivering value, and unblocking work instead of letting it pile up.

-   __Lead time for changes (LT):__ Measures how long it takes to get code from commit to production. If this is slow, your process has friction---slowing down innovation and killing morale. The faster your lead time, the quicker you get ideas into users' hands and keep devs happy by letting them see their work live.

-   __Time to recover (TTR):__ Aka MTTR, this is how fast you can get things back to normal after an incident. Incidents will happen---no team is perfect. But if you can recover quickly, you're building a resilient system and protecting your team's (and users') sanity.

-   __Change failure rate (CFR):__ This is the percentage of changes that cause problems in production. Lower is better; it means you're shipping quality and aren't stuck firefighting all the time. If every deployment breaks things, it's a sign your systems and testing need help. Aim to reduce failure without slowing down, so your team can deploy with confidence.

While these metrics provide valuable operational insights, they capture only the mechanical aspects of software delivery--the "how fast" and "how often" of code deployment. They fail to account for crucial elements like satisfaction, innovation, and toil.

A team could excel at rapid deployments while building the wrong features or accumulating crippling technical debt. It's akin to measuring a restaurant's success solely by how quickly it serves food, while ignoring the quality of the cuisine or the opinions of the chefs that make the food.

> The most promising path forward may be counterintuitive: instead of focusing on direct productivity metrics, organizations should prioritize developer satisfaction. 

Research from [Dr. Nicole Forsgren](https://nicolefv.com/) and others [suggests that high-performing engineering organizations consistently correlate with high developer satisfaction scores.](https://queue.acm.org/detail.cfm?id=3454124) This makes sense--developers who feel equipped, empowered, and engaged are more likely to solve complex problems effectively, collaborate productively, and make sound technical decisions.

Developer satisfaction encompasses crucial factors that traditional metrics miss. Things like the quality of tools and workflows, the effectiveness of team structures, the amount of toil in daily work, and the balance between feature delivery and technical investment. 

When developers report high satisfaction, it indicates they have the resources, autonomy, and support needed to deliver their best work.

### Why developer satisfaction matters

At GitHub, we've discovered that developer satisfaction is the foundation of engineering excellence. Developer satisfaction isn't just about having a pleasant workplace---it's about creating an environment where people can do their best work. Said another way, happy developers are engaged developers. 

> When engineers feel supported and valued, they don't just write code---they invest themselves in solving your organization's hardest problems. They bring their full creativity to work, question assumptions, and push boundaries that others might accept as fixed.

This engagement naturally flows into better problem solving. A satisfied developer isn't just going through the motions of completing features or fixes; they're thinking deeply about architectural decisions, considering edge cases, and anticipating future needs. They're more likely to speak up when they see potential issues and propose innovative solutions rather than band-aid fixes.

But perhaps the most compelling aspect of developer satisfaction is its impact on retention. When developers are satisfied, they stay longer, building deep institutional knowledge and expertise that compounds over time. Each year a talented developer remains with your team isn't just another year of code---it's another year of accumulated context, refined judgment, and strengthened team relationships.

The simple truth is this: satisfied developers do their best work. Everything else---from code quality to system reliability to innovation---flows from this fundamental principle.

### The virtuous cycle

When you invest in developer satisfaction, something remarkable happens: you create a self-reinforcing cycle of improvement. At GitHub, we've witnessed this firsthand in how we build and evolve our own platform.

It starts with making meaningful improvements to your developer experience. These don't have to be massive overhauls---they can be as focused as streamlining a deployment process or automating a repetitive task. What matters is that developers see their pain points being addressed.

> When developers see their feedback turning into real changes, they become more engaged in the improvement process. They're more likely to provide detailed, thoughtful feedback about what's working and what isn't.

This high-quality feedback becomes the fuel for your next round of improvements. Your team can focus on changes that will have the most impact because you're working from real, ground-level insights rather than assumptions. Each improvement builds on the last, creating momentum that transforms your engineering culture.

The end result is a team that doesn't just adapt to change---it drives change. Your developers become active participants in shaping their work environment, leading to better tools, processes, and ultimately, better products.

### Conclusion

The path to exceptional engineering output isn't found in counting lines of code or measuring pull request velocity---it's built on the foundation of developer satisfaction. At GitHub, our journey has consistently shown that when developers are happy and engaged, everything else falls into place: code quality improves, innovation accelerates, and teams deliver better products.

Start measuring developer satisfaction today. Not next quarter, not after your next planning cycle---today. Begin with a simple survey, act on the feedback you receive, and watch how this fundamental shift in focus transforms your engineering culture.

If you don't know to start, begin by asking your developers some basic questions:

-   What are the top Developer Experience (DevEx) areas you think should be improved?

-   How satisfied are you with the tooling and workflows for your work in general?

-   How satisfied or dissatisfied are you with the following tooling and workflows around testing?

-   With regard to tools and workflows, what is your biggest pain point?

-   With regards to shipping changes, what is your biggest pain point?

-   Imagine you have a magic wand to improve one thing (even if it seems impossible) about our DevEx. What would it be?

If your organization leverages GitHub Copilot, consider adding questions like the below, [or use our survey](https://downloads.ctfassets.net/wfutmusr1t3h/66acuCKYqXme0aukY8Rn3x/a8c682946b0176db5860544ad85fffe7/2024-04-23-GitHub-CCI-LP-Copilot-Impact-Survey-NT-V003.pdf):

-   How satisfied are you with GitHub Copilot?

-   Which workflows do you want GitHub Copilot to help with?

-   Why are you not using GitHub Copilot?

-   Do you have any feedback on GitHub Copilot?

Developer happiness isn't just a nice-to-have; it's a critical success factor and a leading indicator of long-term productivity. When you prioritize developer satisfaction, you're not just investing in your team---you're investing in better software, stronger innovation, and a more resilient engineering culture.

In the end, it's simple: happy developers build better software. Start today, and see the difference it makes.

"How do we know if our developers are productive?"

/developer-productivity/

The art of engineering team focus: less is more

Why developer satisfaction is your best productivity metric