Back in my days as squad lead at LinkAja, I made a decision that went against the common ways.

In the golden days of microservices hypes, while most of us were hyping up toward microservices, I decided to actively refactor back into a monolithic architectures. I was technically questionied at first of this but I go on. Then things changed: we went from a team working over the nights to a team with zero works past 4PM for two years. We deliver all business-requests fast. We donned strategic initiatives for fun. We even started helping up other teams’ backlogs.

From that one decision, I learned that: dropping teams workload should always be core targets.

Everyone Wins When We Cut Workload

Let’s go back to the regressive-sounding decision I made: my team was a small 4-person squad responsible for governmental projects. We frequently faced sudden development requests with urgent deadlines. People were asking us to create an E2E mobile app from scratch integrating with 4 national banks within <20 working days (this actually happened; and please mind Indonesian banks are bureautically slow). You can imagine the pressure we were giving to ourselves spinning up multiple services every time a project came up. That’s why handling lots of microservices was not for us. Switching to a monolith was to make things simpler, help us deliver faster. The strategy worked wonders in the long run with our next big government projects.

But let me be clear: this isn’t about advocating for monoliths over microservices. Not about being rad and going against the current. The core principle is about leaning things up—removing current states that doesn’t serve your team’s specific context and constraints, and in the process, reducing engineers workload.

Whether that means consolidating microservices into a monolith, simplifying deployment pipelines, reducing the number of tools in your stack, or streamlining processes, the goal is the same: eliminate overheads that prevents your team from doing things agile-ly. (TODO: write about this) I argue that simplifying work processes shouldn’t be something that requires extensive justification. Leaning up processes should be as northstar as gaining more revenue. It should not require sophisticated business justification. It’s a just common sense.

The Benefits for Manpowers

You might think that the direction I’m going with this post is about work-life balance. While that’s part of it, the real benefits of reducing manpowers workload go far beyond just avoiding manpower burnout.

When manpowers aren’t constantly firefighting or context-switching between fragmented systems, they unlock cognitive space for meaningful work. This isn’t just about work-life balance—it’s about creating conditions where people can actually excel at what they do.

1. It Fosters Technical Growth and Innovation

Sustainable workloads create space for continuous learning. Manpowers can stay current with technologies, explore new patterns, and make informed architectural decisions. This isn’t just professional development—it’s competitive advantage through better technology choices.

2. It Enhances Agility and Maneuverability

Manpowers with capacity remain agile when priorities shift or emergencies arise. An underutilized manpowers isn’t wasted—they’re prepared for opportunity. At LinkAja, this agility meant handling urgent government pilots while maintaining core product quality.

3. It Enables Sustainable Performance

Optimized workloads enable consistent high performance over months and years rather than unsustainable sprints. When people feel sustainable in their work, they bring full creative capabilities to problems, writing code that works elegantly and extensibly.

The Benefits for Customers

Customers don’t care about development processes—they care about product quality and reliability. But overworked manpowers create technical debt, introduce bugs, and make rushed decisions that compound over time, directly impacting user experience.

When development teams operate with optimized workloads, the benefits flow directly to end users in measurable ways:

1. It Increases Product Reliability

Manpowers with adequate cognitive bandwidth write more defensive code, consider edge cases, and implement proper error handling. They have time to write comprehensive tests and conduct thorough code reviews. This translates to fewer production outages, reduced downtime, and more stable user experiences.

Teams operating at sustainable capacity also can respond to critical issues immediately without derailing existing work. When manpowers aren’t already at 100% utilization, they have the mental clarity to diagnose problems quickly and implement proper fixes rather than temporary patches that create future issues.

2. It Improves Feature Quality

Features built by well-rested manpowers are more intuitive, performant, and user-friendly. Manpowers have time to consider the user journey, optimize performance, and polish interactions. They can iterate on designs based on user feedback rather than shipping the first working version due to time pressure.

3. Responsive Customer Support

When development teams aren’t firefighting constantly, they can allocate resources to address customer feedback quickly. Feature requests get proper evaluation, bugs get prioritized appropriately, and improvements ship on predictable schedules.

The result? More reliable products, faster feature delivery, and better user experiences. Customers benefit from the downstream effects of sustainable development practices, even when they’re unaware of the engineering processes that enable them. They simply experience products that work consistently, features that make sense, and support teams that respond quickly to their needs.

The Benefits for Business

Some might raise up a question “Things are already going fine. What we are freeing capacity for? Aren’t we just paying people to do less?”

I would say that is a very misconception. Leaning the process just to free up workload is not wasting money. We always need to have free capacity. Capacity is not waste. Capacity is a strategic asset. To do things. To plan things. To actually figure out what to do if we are having free capacity.

Optimizing manpowers workloads isn’t just a “nice to have”—it’s a strategic business decision that drives measurable financial benefits. While it may seem counterintuitive to reduce what we are making the manpowers do, the reality is that this is actually a practice that will win in the long run.

1. It Eliminates Technical Debt Interest Payments

Rushed stuffs created from a bad working environment generates maintenance overhead that compounds like financial interest. It especially come back faster in a fast iterating business like software businesses. Every shortcut taken under pressure becomes a future tax on development velocity. Technical debt doesn’t just slow down feature delivery—it creates hidden operational costs through increased debugging time, more production incidents, and expensive refactoring cycles.

Teams with sustainable workloads write cleaner code initially, reducing long-term maintenance costs by 30-50%. This isn’t perfectionism—it’s fiscal responsibility.

2. It Enables Strategic Business Engagement

When manpowers aren’t overwhelmed with firefighting, they can engage meaningfully with business objectives. They understand customer needs, contribute to product strategy, and make technical decisions aligned with business goals.

This deeper involvement creates better products because engineers who understand the “why” build solutions that truly serve users and business needs. They catch misaligned requirements early, suggest alternative approaches that save development time, and architect systems that support business growth rather than constrain it. (TODO: write about this)

3. It Will Reduces Hiring and Retention Costs

Replacing a burned-out senior engineer costs 6-12 months of their salary in recruitment, onboarding, and lost productivity. A $120K engineer costs $60-120K to replace—not including the knowledge loss and project delays. Sustainable workloads prevent this expensive churn cycle.

Organizations with optimized manpowers workloads report 40-60% lower turnover rates in engineering teams. The savings compound: reduced recruitment costs, less onboarding overhead, and retained institutional knowledge that prevents repeated mistakes.

Teams with optimized workloads also achieve the same output with fewer people or deliver significantly more value with existing teams. This isn’t about layoffs—it’s about resource efficiency. A team that can deliver the same results with 20% fewer engineers or 20% more features with the same headcount creates direct cost advantages.

This efficiency multiplies across the organization. When one team demonstrates that sustainable practices enable higher per-person productivity, it creates a template for scaling without proportional hiring increases. Companies can grow revenue without linearly scaling engineering costs, improving unit economics and profitability.

4. It Creates Scalable Competitive Advantage

While competitors burn through talent delivering rushed features, organizations with sustainable practices build systems that compound in value over time. This creates durable competitive advantages through:

• Organizational resilience: Teams with capacity respond to market changes and pivot quickly when conditions shift
• Quality consistency: Maintaining standards during high-pressure periods instead of accumulating technical debt
• Surplus capacity: Ability to support other teams and take on strategic initiatives without proportional headcount increases

At LinkAja, my squad’s optimized workload didn’t mean reduced productivity—it meant surplus capacity that demonstrated organizational strength rather than resource waste.

Closing: Why This Matters

I think we needs to start accepting workprocess leaning (a.k.a lessening workloads) as a strategic action. We need to constantly put creating conditions where people can consistently do their best work, as our top priority along with other business purposes. When teams have breathing room, it opens up capacity, we can get strategic. We can solve harder problems. We build systems that last.Not about being soft on performance or lowering standards.

Everyone wins when manpowers workload drops strategically. The challenge isn’t proving this works—the results speak for themselves when you try it. The real challenge is shifting mindsets in cultures that still believe more hours equals more value.

The best way to go faster is: to always have a space to find out about how we can go faster.