Fixing Engineering’s Biggest Time Waste: Finding Information

Developers’ workflows are fragmented, knowledge is siloed, ownership unclear, and coordination work is eating away at the time saved by AI.
Ankit Jain is a Co Founder and CEO of Aviator, an AI-powereddeveloper workflow automation platform that automates ownership, code reviews, merges and deploys. He also leads The Hangar, a community of senior DevOps and senior software engineers focused on developer experience, and Xoogler, the ex-Google alumni network. Previously, he led engineering teams at Sunshine, Homejoy, and Shippo, and was also an engineer at Google and Adobe.

Fixing Engineering’s Biggest Time Waste: Finding Information

Developers’ workflows are fragmented, knowledge is siloed, ownership unclear, and coordination work is eating away at the time saved by AI.
finding-information-developers

The leading cause of friction and time waste for engineering teams is not tech debt, testing or code reviews, but finding information.

This unexpected but revealing insight comes from Atlassian’s “State of Developer Experience 2025” report. Finding information has overtaken technical debt, which topped the list last year, as the top source of developer friction. The key finding from surveying 3,500 developers and managers is:

While more development teams perceive they’re gaining more time from AI, they’re also reporting greater organizational inefficiencies than before.

According to the report, over 50% of developers lose more than 10 hours per week to organizational inefficiencies. Even more concerning: 90% lose at least six hours weekly. And while 68% developers report 10+ hours of weekly time savings due to the use of AI tools, much of that gain is offset by friction outside the code editor.

This just confirms that throwing AI at developers won’t solve their problems. Despite all the investment in tooling and AI, developers are still wasting the most time simply trying to locate what they need to do their jobs.

The Hidden Cause of Developer Friction

The real problem isn’t that developers don’t have enough tools. According to the same report, the second and third causes of friction are new issues, and both are related to increasing complexity and cognitive load: new technology and switching context between tools. 

Developers’ workflows are fragmented, knowledge is siloed, and coordination work is eating away at the time they want to spend actually building software. 


Talk to any engineer long enough and you’ll hear the same complaints:

  1. Fragmented developer experience: Developers must navigate multiple disconnected tools, platforms, and knowledge bases.
  2. Knowledge discovery challenges: Finding relevant documentation, code examples, and best practices is time-consuming and often frustrating.
  3. Limited self-service capabilities: Many operations require tickets or assistance from specialized teams, creating bottlenecks.
  4. Inconsistent standards enforcement: Ensuring compliance with organizational standards for security, quality, and architecture is difficult to automate and enforce.
  5. Cognitive overload: The increasing complexity of development environments places a heavy cognitive burden on developers, reducing productivity and satisfaction.
  6. Accountability: It’s unclear who owns what and who to call when something goes wrong. Site reliability engineers (SREs) are sometimes on call for services they don’t know anything about or who owns them. Similarly, when security or customer support needs to file a ticket, they don’t know who to assign it to.

When an IDP Falls Short

Internal Developer Portals (IDPs) are often hailed as the go-to solution for these pain points, and even the report highlights adopting an IDP as a must for improving the developer experience.

Developer portals are useful for org-wide visibility, but are difficult to maintain and require a lot of investment to get started. From our conversations with organizations, many have failed to adopt them for this reason. The ones that are successful have spent years building them.

Also, teams and tools change frequently, and AI is just accelerating that. Things end up orphaned or incorrectly owned. Eventually, teams are playing hot potato, trying to find the right person. This is a death spiral — the less useful the information, the less likely a portal would be used, reducing the incentives to maintain it.

A Self-Managed Teams Portal


That’s why we are building Aviator Teams, a central hub for all development activities within an organization. It combines the organizational benefits of traditional IDPs with the intelligence and contextual awareness provided by the AI.

Prince Shekhar Valluri, Principal Staff Software Engineer at LinkedIn, and one of the advisors for Aviator Teams, described the problem in his blog post:

For engineering organizations operating at scale, ownership quickly becomes complicated due to massive scale of assets, growth and shifting priorities, people movements and re-orgs, business complexity, and technology not always mirroring the org chart.

Without clear accountability, assets can become neglected or orphaned, causing operational headaches and hindering effective collaboration.

The goal of Aviator Teams is simple: to be the single source of truth for ownership, so that developers spend time building and shipping instead of finding information.

We’d love to hear your feedback on what we’re building. Request early access, share your workflow and ownership challenges, and help us build the features you actually need and design a better developer experience from the ground up.

This blog post was originally published on The New Stack.

Subscribe

Be the first to know once we publish a new blog post

Join our Discord

Learn best practices from modern engineering teams

Get a free 30-min consultation with the Aviator team to improve developer experience across your organization.

Powered by WordPress