Why we don’t use Jira: Reducing Cognitive Tax

Even before we start as the sole engineering team on a client engagement, we make our preference clear: we do not default to Jira, Confluence, or Pivotal. If the organisation requires them, we will use them, but reluctantly. Our preference is to run the work through GitHub, GitHub Projects, pull requests, issues, repository documentation, and GitHub Actions.

This is not ideology. It is the result of seeing the same pattern repeat.

After years of working with small, high-agency engineering teams, I have found that multiple tools almost never improve delivery quality, communication, or speed in proportion to the friction they introduce. More often, they spread context across too many places, create duplicate effort, and force engineers and stakeholders alike to spend mental energy navigating systems instead of solving problems.

Most teams do not have a delivery problem. They have a tool sprawl problem.

They mistake coordination overhead for rigour, reporting exhaust for management insight, and extra process for operational discipline. Then they wonder why engineers are overloaded, stakeholders are confused, and delivery feels slower than it should.

One of the simplest ways to reduce cognitive overload across an engineering team is not to add another dashboard, another ceremony, or another work-management platform. It is to consciously reduce the number of tools the team is forced to live in every day.

Tool Sprawl Is a Cognitive Tax

Every additional platform claims to solve a specific need.

One tool for tickets. One for documentation. One for CI/CD. One for approvals. One for roadmaps. One for chat. One for reporting. In isolation, each decision sounds reasonable. In combination, they create a fragmented operating environment where no one is fully sure where the real state of the work lives.

That fragmentation becomes a tax on attention.

Engineers must remember where requirements were written, where decisions were captured, where status is updated, where blockers are tracked, and where approvals happen. Product managers and stakeholders end up doing the same. Every tool adds another interface, another workflow, another notification stream, and another source of truth that has to be mentally reconciled with the rest.

This is the part many organisations miss: cognitive overload is not caused only by technical complexity. It is also caused by administrative fragmentation.

When a team’s working memory is spent on navigating tools, updating parallel systems, and reconstructing context, less of it is available for design, judgment, debugging, and delivery.

Most Teams Need Less Tooling, Not More

If the code already lives in GitHub, much of the surrounding work can live there too:

• issues for scoped work
• pull requests for implementation and discussion
• project boards for prioritisation and flow
• markdown in the repo for engineering documentation
• GitHub Actions for CI/CD and automation
• branch protections and reviews for approvals

This is not about claiming GitHub is perfect. It is about reducing context switching and keeping related information close together.

The benefit of a more consolidated workflow is not elegance for its own sake. It is that the team spends less time translating across systems and more time staying aligned around the actual work. A design note tied to a pull request is easier to trust than a page in a separate wiki that may or may not reflect current reality. An issue linked to a code change is easier to follow than a ticket that lives in a disconnected project-management system.

The closer decisions are to code, the easier it is to maintain coherence.

Many Tools Serve Management More Than Delivery

A lot of engineering process tooling is justified in the language of teamwork, but often designed around management visibility.

Tools like Jira can absolutely have a place in large organisations with real dependency management, audit requirements, or compliance constraints. But in many teams, they become systems for reporting on work more than systems that help work happen.

That is where things start to drift.

The people doing the work now have to maintain a second reality for the benefit of observers. Tickets must be updated. Statuses must be moved. Estimates must be preserved. Dashboards must remain legible. Soon, the team is spending meaningful time feeding the system that is supposed to be helping them.

This is also where vanity metrics creep in. Velocity is the classic example: a number presented with confidence, often built on subjective estimates and inconsistent ticket sizing, then treated as if it carries objective truth. Once leadership begins to trust the number, teams begin shaping behaviour around the number.

That is how process stops being descriptive and starts becoming distortive.

SAFE and Overgrown Agile Often Miss the Original Point

The same pattern shows up in how organisations adopt agile frameworks.

Agile was supposed to shorten feedback loops, empower teams, reduce waste, and keep attention on working software. In many companies, that spirit has been replaced by ceremony-heavy operating models that produce the appearance of alignment while increasing the cost of execution.

SAFE is one of the clearest examples of this tendency. It gives large organisations a language for coordination, but it also often turns agility into bureaucracy with agile branding. Teams end up trapped in layers of planning rituals, abstract reporting, and process compliance that make adaptation harder, not easier.

The problem is not only SAFE. More broadly, agile itself is often taken too far in the wrong direction. Instead of reducing overhead, organisations add standups, refinements, plannings, retrospectives, syncs, demos, quarterly ceremonies, and tool workflows until the process consumes the time and clarity it was meant to protect.

When agile becomes an industry of rituals and artifacts, it stops being agile.

The test is simple: does the process help the team learn and ship faster, or does it mainly help the organisation feel in control?

Documentation Does Not Need a Separate Empire

Documentation is one of the first things to decay when it is separated from the system it describes.

When engineering documentation lives in a dedicated platform far from the code, it becomes easier to ignore, easier to duplicate, and harder to keep current. The problem is not that separate documentation tools are inherently bad. The problem is that they encourage distance between technical truth and technical description.

Repository-based documentation has clear advantages:

• it is versioned
• it changes alongside implementation
• it can be reviewed in pull requests
• it is easier to search in the flow of work
• it is more likely to stay grounded in the system as it actually exists

Not every document belongs in a repo. Some organisation-wide or executive material will live elsewhere. But operational and engineering documentation usually benefits from being as close as possible to the code and decisions it describes.

Distance creates drift.

Consciously Reducing Tools Is an Engineering Decision

The right question is not, “What is the best specialised platform for each separate concern?”

The better question is, “What is the minimum number of systems this team needs in order to deliver responsibly and clearly?”

That shift matters because every additional tool imposes a maintenance burden. A tool should be judged not only by what it enables, but also by the coordination cost it adds.

A consciously smaller toolchain usually gives teams:

• lower onboarding friction
• fewer duplicate updates
• less ambiguity about where information lives
• better connection between decisions and implementation
• less process fatigue
• more mental space for actual problem-solving

For small teams especially, this matters enormously. The smaller the team, the more expensive unnecessary process becomes.

Constraints Are Real, but Sprawl Should Still Be Resisted

Of course, not every team gets to choose its environment. Some organisations require specific tools for governance, procurement, security, or portfolio reporting. In those cases, the answer is not to be difficult. The answer is to contain the damage.

Use mandated tools when necessary, but keep one primary home for execution. Keep implementation context near the code. Avoid maintaining multiple detailed sources of truth. Treat external systems as organisational interfaces, not the centre of gravity for the team’s daily work.

That is often the best compromise available.

Fewer Tools, Clearer Minds

Teams routinely underestimate how much productivity is lost not in building software, but in maintaining the machinery around building software.

If answering basic questions like these requires visiting five platforms, the team is already paying too much:

• What are we doing?
• Why are we doing it?
• What changed?
• What is blocked?
• What needs review?
• What was decided?
• What is the current source of truth?

Consciously reducing tool sprawl is not anti-process and it is not anti-management. It is a practical recognition that attention is finite. Every extra system consumes some of it. Every duplicate workflow drains some more. Eventually the team becomes busy administering delivery instead of improving it.

For engineers, and for teams overall, reducing cognitive overload often starts with a simple discipline: fewer tools, less ceremony, closer context, clearer ownership.

That is not minimalism for its own sake. It is how you leave more brainpower for the work that actually matters.