Features built on research, not feature requests

gittan is not shaped by feature requests. It is shaped by research. Specifically, the findings in Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim, and Team Topologies by Matthew Skelton and Manuel Pais. These books are not opinions — they are the result of years of large-scale research into what actually makes software teams perform.

What Accelerate tells us

The DORA research program studied thousands of teams across industries and identified four key metrics that predict software delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service. High-performing teams score well on all four. Low-performing teams score poorly on all four. There is no trade-off between speed and stability — the best teams have both.

The research also identified the capabilities that drive these metrics. Trunk-based development. Continuous integration. Small batch sizes. Fast feedback loops. Loosely coupled architecture. Team autonomy. These are not preferences or trends. They are statistically validated predictors of engineering performance.

Every feature in gittan maps to one or more of these capabilities. Gated push enforces continuous integration. Terminal feedback shortens the feedback loop. No long-lived branches means trunk-based development. Team metrics on the dashboard make performance visible, not as a management surveillance tool, but as a team health indicator.

What Team Topologies tells us

Team Topologies establishes that how you organize teams determines how your software is shaped — Conway's Law, applied deliberately. It defines four team types: stream-aligned, platform, enabling, and complicated-subsystem. The key insight is that teams need clear ownership, minimal cognitive load, and well-defined interaction modes.

gittan's permission model is team-centric because Team Topologies says that is how high-performing organizations work. Teams own repos, not individuals. Access follows team boundaries, not org charts of individual contributors. When a team is responsible for a service, they control its code, its pipeline, and its deployment. No tickets to a central platform team to change a CI config.

Org policies exist to give the platform team guardrails without bottlenecking stream-aligned teams. The platform team sets security gates and compliance steps. The stream-aligned team decides everything else. This maps directly to the Team Topologies interaction mode of "X-as-a-Service" — the platform provides the service, the team consumes it, and neither blocks the other.

Team metrics built into the product

Most teams that want delivery metrics have to bolt on a separate tool — Sleuth, LinearB, Jellyfish — that scrapes data from their git host and CI system, correlates it, and produces dashboards. This is expensive, fragile, and always slightly wrong because the tool is reconstructing intent from artifacts.

gittan owns the entire pipeline from push to acceptance. We know exactly when a commit was pushed, how long the pipeline took, and whether it passed or failed. We do not need to guess or scrape. Two metrics map directly to DORA, two measure the push gate instead of production:

• ‣ Push frequency — how often the team pushes to main. Maps to DORA's deployment frequency.
• ‣ Pipeline lead time — from push to pipeline result. Maps to DORA's lead time for changes. With gated push there is no branch or PR lag.
• ‣ Rejection rate — the percentage of pushes rejected by the pipeline. DORA's change failure rate measures production failures; gated push prevents those, so we measure the gate instead.
• ‣ Recovery time — how quickly the team ships a fix after a rejected push. DORA's time to restore measures production recovery; gittan measures gate recovery.

These metrics are shown per team on the dashboard. They are not hidden behind an analytics add-on or enterprise tier. Every team sees how they are performing. The goal is not to rank teams against each other — it is to give each team visibility into their own delivery health so they can improve on their own terms.

Paved roads, not walls

gittan is opinionated. But opinionated does not mean forbidding. The metaphor is paved roads: we pave the roads the research supports — trunk-based development, polyrepo, small repos, simple pipelines, flow — and leave the rest as unpaved ground. We do not block anyone from driving off-road. We simply have not laid asphalt there.

A few things are genuinely hard constraints — security gates, immutable tags, team ownership. These are walls, and they exist because the thing they prevent is wrong, not just suboptimal. We are absolutist about these because it is true, and because incumbents structurally cannot copy them without breaking their own user base.

Everything else is a strong default. You can use a monorepo — it is just not what the tool is paved for. You can run third-party modules — but first-party is the default, and you are explicitly taking responsibility. The data points one way, so the default goes that way. We are honest about what it costs you to go the other way, rather than pretending you cannot.

This distinction matters. If every claim on the site reads as "we forbid X" and half turn out to be "well, actually you can," the soft claims erode the credibility of the hard ones. For a data-driven audience, a discovered overclaim is fatal. So we keep the two voices separate: absolutist where it is true, honest where it is bias.

How we evaluate feature requests

When someone asks for a feature, we do not ask "do customers want this?" We ask: "does the research support this?" If a feature would improve one of the four DORA metrics without degrading the others, it is worth considering. If it would reduce team autonomy, increase batch size, or lengthen feedback loops, it is not — regardless of how many people ask for it.

This means we will say no to things that other platforms consider table stakes. Approval gates that require a manager's sign-off before deploy? That increases lead time and adds a bottleneck. The research says it makes teams slower without making them safer. We will not build it.

Branch protection rules that force multi-step merge ceremonies? That increases batch size because developers accumulate changes while waiting. The research says small, frequent integrations outperform large, infrequent ones. We will not build it.

Dashboard features that let managers track individual developer output? The research is explicit: measuring individual productivity does not predict team performance and actively harms it when used as a management tool. We will not build it.

Control vs. delivery

Many features in enterprise software exist to give managers a sense of control. Approval workflows, access reviews, activity dashboards, audit trails of who did what and when. Some of these serve real compliance needs. Many exist because someone in procurement asked for them, and the vendor said yes to close the deal.

We optimize for delivery and quality, not control. If a feature helps teams ship better software faster, we will build it. If it exists so that someone higher in the org chart can feel informed without talking to the team, we will not. The team's ability to deliver always takes priority over a manager's desire to monitor.

This is not anti-management. Good managers want their teams to be autonomous and effective. The DORA research shows that organizational culture — specifically, generative culture with high trust — is the strongest predictor of performance. Tools that enforce control undermine trust. Tools that enable autonomy build it.

Moving the industry

We know this position is not mainstream. Most git hosting platforms compete on feature count. The vendor with the longest feature comparison table wins the procurement spreadsheet. The result is feature bloat — products that do everything and do none of it well. Every feature adds configuration surface, UI complexity, cognitive load, and maintenance burden. Teams end up navigating a tool instead of using it. We will lose those feature comparisons. That is fine.

We believe the industry is moving in the wrong direction — more process, more ceremony, more features that exist to satisfy auditors and middle managers rather than help engineers ship. The research has been clear for years: the practices that produce the best outcomes are simple, fast, and trust-based.

gittan exists to prove that a tool built on those principles can work for real teams at real companies. Not as an experiment, but as production infrastructure. If we can demonstrate that fewer features and more trust produces better outcomes, maybe the rest of the industry will follow.

If not, at least the teams that use gittan will ship faster.