Your Stack Isn't the Problem. Your Workflow Is.

Your Stack Isn't the Problem. Your Workflow Is.

When a team starts to slow down, the instinct is to blame the tools.

The framework is too heavy. The language isn't performant enough. The cloud provider has too much vendor lock-in. So the team rewrites, migrates, or evaluates. Six months later, they are still slow, now with a newer stack and a bigger backlog.

The problem was never the stack.

According to Atlassian's 2025 State of Developer Experience report, 50% of developers lose more than 10 hours per working week to workflow inefficiencies. Not bugs. Not legacy code. The friction around the code: slow pipelines, contested environments, approval queues, unclear ownership, and context switching between five tools to complete one task.

The stack is visible and concrete. Workflow friction is diffuse and easy to misattribute. That asymmetry is exactly why teams keep solving the wrong problem.

What actually slows a team down

The DORA research programme, now spanning nearly a decade, has repeatedly shown that the gap between elite and low-performing engineering teams is not driven by language choice, framework preference, or cloud architecture. It is driven by delivery workflow: how fast changes move from committed code to production, and how confidently a team can ship.

The five core DORA metrics (lead time for changes, deployment frequency, failed deployment recovery time, change failure rate, and rework rate) all measure the health of the workflow, not the sophistication of the stack.

Elite performers on these metrics are twice as likely to exceed their organisation's goals for profitability, productivity, and customer satisfaction, according to Google Cloud research. The stack these teams use varies enormously. The workflow practices do not.

The five bottlenecks worth diagnosing

Most workflow slowdowns trace back to a short list of structural problems.

1. Slow CI pipelines

When a build takes 20 minutes or more, developers stop deploying frequently. That sounds like a mild inconvenience. It is actually a compounding problem.

Infrequent deploys mean larger batches of change per release. Larger batches mean harder debugging when something breaks. Harder debugging means more developer time sunk into forensics rather than features. Slow pipelines do not just delay code: they change how people work, and rarely for the better.

2. Shared staging environments

One staging environment. Three teams trying to push changes at the same time.

This is one of the most underestimated sources of friction in growing engineering teams. When environments are a shared resource, deployments require coordination. Coordination means waiting. Waiting means blocked work, inflated lead times, and the kind of "it was fine in my branch" incidents that erode trust between teams.

The fix is not better coordination protocols. It is isolated, per-branch deployments that each team controls independently, without waiting for a shared environment to be free.

3. Long-lived feature branches

The longer a branch lives, the more expensive it becomes to merge.

Teams that keep branches alive for days or weeks accumulate merge conflicts, drift from the main trunk, and require integration sessions that take longer than the feature itself. The problem is not Git: it is the deployment model that makes short-lived branches impractical. If merging to main means triggering a production release, developers will delay merging. The branch lives longer. The cost compounds.

Trunk-based development and branch-based deployments break this cycle: every branch can be deployed and reviewed independently, so merging early is safe. Tools like GitHub and Bitbucket make the branching model straightforward. The question is whether your deployment setup can keep up.

4. Approval gate overhead

If a standard release requires more than two human checkpoints, the team is bottlenecked by process, not capability.

Approval gates feel safe. They create the illusion of oversight. But in practice, they queue changes behind whoever is responsible for signing off: a senior engineer already overloaded, a manager who only reviews on Thursdays, a security review that runs fortnightly. The work sits. The developer context-switches. The queue grows.

High-performing teams replace manual approval gates with automated quality gates: tests must pass, coverage must hold, build must succeed. Human review happens in parallel, not in sequence.

5. Context switching and unclear ownership

Tool sprawl is a quiet killer.

When developers switch between five or more platforms to complete a single task (issue tracker, CI dashboard, staging environment, deployment tool, communication channel) the switching cost is real. Studies consistently show it takes 20 minutes to recover full focus after an interruption. Multiply that by the number of context switches in a typical day.

Unclear ownership compounds this. When nobody is certain whose job it is to fix the flaky test or resolve the blocked deployment, the problem escalates by committee. The fastest teams move decision-making as close to the team as possible and treat their delivery pipeline as a product with clear owners.

The AI paradox that makes this urgent

Teams hoping that AI coding assistants will solve their delivery speed problem are running into a structural wall.

Faros AI research on the DORA Report 2025 found what they describe as the AI Productivity Paradox: AI tools produced 21% more tasks completed and 98% more pull requests merged per individual developer. But organisational delivery metrics, deployment frequency and lead time in particular, stayed flat.

The reason is straightforward: AI amplifies existing systems. When an individual developer is more productive but the pipeline, environments, and approval process are the same, the bottleneck just moves upstream. Code is written faster and then waits longer.

This is not an argument against AI tooling. It is an argument for fixing the workflow first. AI built on top of a healthy delivery system compounds. AI built on top of a broken one accelerates the pile-up.

What high-performing teams treat differently

The teams that consistently ship fast share one habit: they treat their delivery pipeline as a product, not an afterthought.

That means:

• CI pipelines are owned and optimised continuously, not inherited and ignored.
• Environments are self-service and ephemeral, not manually provisioned and contested.
• Deployment frequency is a metric that leadership watches alongside revenue.
• Process changes are tested and iterated, not instituted by decree and forgotten.

A concrete example: after implementing shared CI/CD pipelines and containerised deployments, one team reduced cycle time from four weeks to three hours. Deployment frequency improved 1,100%. Not through a stack rewrite. Through a workflow rewrite.

The question worth asking

Before your next framework evaluation, ask a different question: if we shipped every day, what would break?

Not the code. The workflow around it.

Would the CI pipeline be too slow? Would the staging environment be the bottleneck? Would an approval gate queue the release for a week? Would the on-call rotation need rethinking?

The answers tell you where the real friction is. The stack is rarely on the list.

Forge's POV: deployment should feel like saving a file

Hosting and deployment should not be an engineering discipline in itself. That is the premise behind Forge's developer platform.

The platforms that move fastest treat deployment as a default, not an event. Branches are deployed directly. Changes are reviewed in production conditions before they land. Merging and shipping are the same action.

That model is not aspirational: it is achievable with the right setup. The constraint is almost never the stack. It is the workflow that surrounds it.

Forge is built around that principle. Git-driven deploys, branch-based staging, and a build pipeline designed to get out of the way. The goal is for deployment to feel like saving a file.

Fix the workflow, and the stack becomes fast. Leave the workflow broken, and no stack will save you.