Most engineering teams have learned to live with Git's complexity. Interactive rebases, detached HEADs, the anxiety of running reset --hard, the dance of staging and stashing — it's all part of the daily workflow. Over time, many of these rough edges simply become accepted.
They shouldn't be.
A Different Take on Version Control
An alternative that has been gaining attention is Jujutsu (jj), which builds on Git's storage layer but rethinks the interface. It removes the staging area, tracks changes automatically, and allows workflows where undoing or reorganizing work carries less risk. Concepts like deferring conflicts or working with stacked changes are handled differently and, for some, feel more manageable.
You don't need to adopt it to find the conversation around it valuable. What it surfaces is more interesting than the tool itself.
What This Reveals: Developer Experience Debt
What's notable is not just the feature list, but what it reveals about developer experience debt. How much time do your engineers spend fighting their tools instead of shipping? How many junior developers avoid rebasing entirely because the consequences of getting it wrong feel too high?
This is rarely visible in dashboards. It does not show up as a failed deployment or a missed sprint. It hides in the half-hour an engineer spends recovering from a bad merge, in the senior developer being interrupted to untangle someone else's branch, in the PRs that never get split because nobody trusts themselves to rewrite history safely.
The Most Telling Signal
The most telling signal from the community: experienced Git users who switched report they now do things they always could have done — like maintaining clean stacked PRs or freely reorganizing commit history — but previously avoided because the effort was not worth the risk.
That gap between what is technically possible and what people actually do is where productivity quietly leaks. A tool that lowers the cost of "doing things right" changes behavior far more than a tool that just goes faster.
Friction Is the Hidden Tax
This is a pattern we see repeatedly in developer performance data. The biggest productivity gains often come not from working faster, but from removing the friction that makes engineers hesitate.
Concretely, that friction looks like:
- Avoided actions. Engineers who never split commits, never rebase, never clean history — not because it would not help, but because the tool makes it scary.
- Senior-engineer rescue work. Hours spent unblocking colleagues from situations the tool itself created.
- Quality compromises. Messy commit history because nobody wants to risk a rebase. Giant PRs because splitting them feels harder than reviewing them.
- Onboarding cost. Junior engineers building anxiety habits around tools they will use every day for a decade.
None of this is a Git problem specifically. It is a pattern that shows up wherever tooling friction is normalized. Build systems with twenty-minute feedback loops. Test suites everyone learns to skip. Deployment processes only one person on the team understands.
What Engineering Leaders Should Do
The best part of the jj story for our purposes is not the tool: it's that it is fully Git-compatible. One person on a team can adopt it without anyone else changing a thing. The cost of trying is low, and the signal you get back — whether that person reports more or less friction — is genuinely useful data.
More broadly, the question for engineering leaders is not "which version control system." It is: where in our toolchain have we stopped noticing the friction? The accepted-as-normal interactions, the workarounds that became habits, the rough edges everyone routes around without comment. That is where the productivity tax is being paid.
Removing it does not require new headcount or new methodology. It requires noticing what your engineers have stopped complaining about.
