AI-driven software teams need more decision-making authority

Software companies are producing code faster, working with smaller engineering teams, and removing management layers. Yet many still rely on centralized approvals that slow the journey from completed engineering work to customer delivery. AI has accelerated execution, while the decisions governing that work often follow processes built for a slower organization.

Over the past two years, software companies have changed their engineering structures, hiring priorities, and workflows faster than in previous shifts. These changes have expanded what individual employees and small teams can accomplish. But faster execution creates a problem when teams must wait for other parts of the business to approve what happens next.

For CTOs and engineering leaders, the challenge is to turn execution speed into business results. That means examining decision rights, the authority to approve actions and commit resources, alongside team structures, engineering practices, and employee capabilities.

AI has already changed the software organization

The scale of this change is clear in Bain’s research on software organizations. Bain, a management consultancy that advises companies on organizational transformation and has a commercial interest in this work, reports substantial changes in engineering hierarchies, hiring priorities, and how responsibilities are divided.

Its findings show companies moving toward smaller teams, broader individual roles, and greater use of AI agents. These agents are software systems that can carry out tasks, such as generating code or running workflows, with limited human direction at each step. As agents handle more execution work, engineers spend more time defining tasks, evaluating results, and deciding what should happen next.

This shift changes the skills companies need from employees. It also creates opportunities to reorganize work that previously depended on several specialists and management layers.

Yet the transition is uneven. Companies have made substantial progress in changing who performs engineering work, while authority over business decisions remains concentrated in many organizations.

Teams are getting smaller, flatter, and more AI-dependent

Bain’s 2026 AI Org Assessment Survey, involving 155 respondents, shows how quickly engineering organizations are changing. Traditional pyramid structures have become much less common, while companies increasingly expect engineers to work with AI agents and handle activities previously assigned to other specialists.

Hiring priorities are changing too. Fluency with AI tools has become a leading engineering capability, while judgment and problem-solving remain important as employees spend more time evaluating agent-generated work.

The survey’s main findings show several connected changes:

The figures show how engineering work is changing. As agents handle more implementation tasks, developers must become better at specifying requirements, checking outputs, resolving uncertainty, and deciding whether results are ready for use. Technical expertise remains essential because engineers need enough understanding to recognize incomplete or incorrect output.

Bain illustrates this shift in Figure 1, “Developers are spending less time coding, more time directing agents,” from the 2026 AI Org Assessment Survey. The figure shows developers moving away from direct implementation toward supervising execution and evaluating results.

The change extends beyond how developers work with agents. Responsibilities once assigned to separate specialists are also moving closer together, allowing employees to contribute to more stages of software delivery.

Bain’s Figure 2, “Developers are absorbing the most adjacent work,” documents this expansion. Both figures draw on the Bain AI Org Assessment Survey, 2026 (n=155).

The changes span several functions:

• Developers increasingly handle testing and deployment alongside implementation.
• Product managers build prototypes and contribute directly to marketing activities.
• Designers produce front-end code, taking on implementation work.

These broader roles allow smaller groups to complete more of the work needed to build and deliver software. Tasks that once required coordination across several functions can increasingly be handled within one team.

Companies are also placing greater emphasis on experienced employees who can supervise agents and make technical decisions. Engineering pods of three to five people are emerging as one possible configuration. These pods are small, closely coordinated teams that combine human expertise with substantial execution by AI agents.

Bain’s earlier brief, “How Will AI Change Software Organizations?”, anticipated smaller teams, flatter hierarchies, more agent supervision, and decisions moving closer to execution. Its subsequent findings show the first three developments clearly underway.

Moving decisions closer to execution has proved harder.

That difference matters because team size, reporting relationships, and individual productivity determine how work gets done. Decision authority determines whether the people doing that work can take the next step.

The organizational chart is changing faster than decision-making

The clearest sign of the remaining challenge is how much authority stays at the center. Although traditional engineering pyramids have become substantially less common, 70% of organizations still make decisions centrally.

Bain highlights this finding in its brief “Redesigning Tech Company Operating Models for an AI-Accelerated World.” The firm reports that centralized decision-making persists across organizations at different levels of AI maturity.

The structural and decision-making figures measure related organizational characteristics rather than a matched before-and-after change in authority. They show that flatter reporting structures can coexist with centralized decisions.

Removing a management layer reduces the number of people between engineers and senior executives. But a company may still require central approval for product launches, resource allocations, or other consequential decisions.

Teams can therefore gain responsibility for execution while retaining limited control over delivery. AI makes that separation more costly because work reaches decision points sooner.

Faster engineering exposes slower handoffs

Consider a development team using AI-assisted workflows to complete a feature. Engineers may finish implementation, testing, and release preparation much faster than before. Yet the feature must still pass through the company’s established release, marketing, and business approval processes.

When those processes depend on sequential decisions by separate departments, faster development causes completed work to pile up at the next approval point. The delay has moved from engineering execution to coordination.

This creates a gap between local productivity and end-to-end delivery performance. A company can produce more features or resolve technical issues faster while seeing much smaller improvements in the time it takes to make changes available to customers.

For technology executives, this changes how AI investments should be evaluated. Engineering productivity matters commercially when additional capacity produces delivered features, better customer experiences, or other business outcomes.

Bain identifies decision-making as the most neglected part of organizational redesign. That finding stands out because companies have already shown a willingness to remove management layers, change hiring priorities, and redefine professional roles.

Changing decision rights reaches deeper into the organization. It determines who can authorize action, allocate resources, and accept responsibility for the consequences.

Those choices determine how authority is distributed across a company. Revising them can require more substantial changes to management responsibilities than introducing AI tools or combining technical roles.

Engineer-led marketing shows how ownership can expand

One AI-native company’s approach to feature marketing shows what happens when teams gain authority over more of the delivery process. AI-native companies build their workflows and organizational structures around AI from the outset.

At this company, engineers who develop a feature can also launch its marketing. The people who build the functionality take responsibility for bringing it to market, rather than handing the finished feature to a centralized marketing organization.

In a conventional arrangement, engineers complete development and transfer the feature to marketing. Marketers then need to understand how it works, decide how to communicate its value, and coordinate the launch with other teams.

Each handoff adds work because another group must learn the context, align priorities, and make decisions. When engineers also participate in launching the feature, development and commercial release become parts of a more connected workflow.

The important change is how responsibility and authority fit together. Engineers own more of the outcome and can make decisions about activities previously controlled by another function.

Assigning extra tasks alone would produce a different result. If engineers prepared marketing materials but still needed central approval for every decision, much of the coordination would remain.

Engineer-led feature marketing shows how companies can reduce these dependencies. The model does not require every engineering team to run marketing or every centralized marketing organization to disappear.

Specialized functions still provide expertise, coordinate company-wide priorities, and handle decisions affecting multiple teams. The design question is which activities need that broader perspective and which can be managed by people closest to the work.

Decision rights need explicit boundaries

The same question applies to product launches, deployments, resource commitments, and cross-functional priorities. Each involves different risks, dependencies, and consequences.

Some decisions need centralized oversight because they affect shared resources or create risks beyond a team’s immediate responsibilities. Others can stay within the team when its members have the necessary information and expertise.

Authority therefore needs to be assigned deliberately. When routine decisions require escalation, executives and central functions spend time reviewing matters the responsible team may already understand well enough to resolve.

Moving those decisions closer to execution reduces coordination. But teams also need to know which commitments they can make independently and when they must involve someone else.

Clear decision rights establish these boundaries. They tell employees where their authority begins and ends while allowing leaders to oversee decisions with wider consequences.

For established software companies, changing these arrangements can be difficult. Approval processes, functional boundaries, and management responsibilities often reflect practices developed before AI substantially accelerated engineering work.

Agents change how quickly teams can produce results, while established processes may still determine when those results reach customers.

Leaders therefore need to examine the path from completed engineering work to customer delivery. Counting management layers or employees using AI agents shows how execution is changing. Tracking where work waits for approval reveals which decisions limit the benefit.

There is no single AI-era organization chart

Once companies identify the decisions slowing delivery, they still need to decide how to organize their teams. Bain’s research identifies several approaches to AI, each suited to a different objective.

Some companies use agents to increase capacity while largely preserving existing team sizes and responsibilities. Others remove management layers to simplify coordination and shorten decision cycles.

A third approach makes engineering pods substantially smaller as agents absorb implementation work. These groups depend on a higher concentration of senior employees to direct agents and make technical decisions.

Another approach builds multidisciplinary teams around generalists who can manage broader workflows with AI assistance. These employees combine skills previously spread across separate functions, allowing teams to complete more work internally.

Each approach involves trade-offs. Preserving specialized teams can increase capacity while maintaining established expertise. Removing management layers can simplify coordination, particularly when companies also change approval authority.

Smaller, senior-heavy pods concentrate technical judgment around agent execution. Multidisciplinary teams can shorten the path from development to delivery by reducing dependencies between functions.

Three-to-five-person engineering pods illustrate one way to combine these characteristics. Whether they work depends on the tasks involved, the expertise available, and the authority given to the team.

A compact team managing a narrow technical function has different needs from one responsible for a feature throughout development, release, and operation. Team size should therefore follow the responsibilities and decisions the company wants the group to handle.

AI-native marketing organizations offer another model

Bain reports that some AI-native marketing organizations generate several times the revenue per employee of traditional software companies. These businesses organize work around small multidisciplinary pods that include an embedded engineer.

Agents handle activities that previously required much larger departments. The embedded engineer brings technical capability into the marketing pod, helping the team connect implementation with marketing execution.

This arrangement reduces the need to spread every activity across separate departments. Marketing specialists and engineers can coordinate directly, while agents provide additional execution capacity.

The revenue-per-employee comparison shows the performance some organizations have achieved with this model. However, differences between AI-native and established businesses also affect their economics, so the comparison needs that wider context.

AI-native businesses have another advantage: they can design workflows around agents from the beginning. They can establish team responsibilities, reporting relationships, and decision processes without first changing an existing organization.

Established software companies face a different task. They must introduce agent-supported workflows while revising responsibilities and processes employees already use.

Copying the visible structure of an AI-native business therefore solves only part of the problem. Companies also need the decision authority and operational capabilities that make the structure work.

For one business, the goal may be increasing delivery capacity while preserving specialized teams. For another, it may be giving multidisciplinary groups responsibility from initial development through customer release.

Both can use AI extensively. Their organizational designs should follow the outcomes they want to achieve and the decisions employees need to make.

Autonomy requires stronger engineering discipline and a new talent pipeline

Giving teams more authority creates another operational requirement. They must be able to exercise that authority reliably, especially when agents produce a growing share of the work.

Bain identifies several practices that support autonomy in AI-native companies: strong automated testing, well-defined requirements, disciplined site reliability practices, and teams responsible for operating the systems they build.

These practices help organizations maintain quality and reliability while reducing the supervision needed from other departments.

Engineering foundations make autonomy practical

Automated testing checks whether software behaves as expected. Clear requirements describe the intended result, giving engineers and agents a shared basis for completing and evaluating tasks.

Site reliability practices help teams keep software dependable in production. They include monitoring systems, responding to failures, and improving availability.

When teams also operate the systems they build, their responsibility continues after deployment. They must consider how implementation decisions affect customers, system performance, and ongoing maintenance.

These foundations become more important as companies adopt agentic AI, meaning AI systems that can plan and execute sequences of work with limited human intervention.

An agent may complete implementation tasks quickly, but the organization still needs to determine whether the result meets its requirements. Weak testing or unclear specifications can allow errors to accumulate as execution accelerates.

Bain describes AI-native companies establishing strong engineering practices before introducing agents. The sequence matters because agents extend an organization’s existing ability to produce, evaluate, and operate software.

For established companies, improving these practices can make agent adoption more dependable. Automated checks reduce manual review, while clear requirements help engineers recognize when generated work falls short.

Operational discipline also supports broader decision authority. A team with reliable testing, clear requirements, and responsibility for operating its software has more of the information needed to make deployment and maintenance decisions.

Leaders can then assign authority within defined boundaries while retaining oversight of decisions that affect people or systems beyond the team.

Human judgment remains accountable for agent work

As agents perform more execution tasks, companies must establish who is responsible for their outputs. People need to decide which activities agents can handle independently, which decisions require human involvement, and who is accountable when results affect customers or operations.

This becomes important when several agents contribute to work supervised by a small team. One agent might implement a change, another might generate tests, and a third might prepare deployment activities.

A person or team must still evaluate the combined result and decide whether it can proceed.

That responsibility makes technical judgment increasingly valuable. Engineers must understand requirements, recognize errors, evaluate trade-offs, and identify risks that automated checks may miss.

These capabilities become especially important as companies place more execution work under the supervision of experienced employees.

Yet the move toward senior-heavy teams creates another challenge: developing the engineers who will exercise that judgment in the future.

Senior-heavy teams are changing the engineering career path

Bain reports a substantial change in engineering workforce composition. Junior engineers previously represented approximately one-third of engineering teams on average. Their share has now fallen below one-fifth, while the proportion of senior engineers has increased.

This shift is linked to the automation of routine implementation work. Companies can increasingly assign tasks traditionally handled by junior developers to agents supervised by experienced engineers.

The immediate benefit is greater execution capacity per employee. A smaller group of senior engineers can direct substantial amounts of agent-generated work, allowing companies to operate with leaner teams.

But routine work has also helped engineers develop expertise. Junior employees traditionally learn by implementing features, fixing errors, receiving feedback, and gradually taking responsibility for more complex technical decisions.

These activities expose engineers to production requirements and the consequences of different design choices. As agents take on more of this work, opportunities to learn through direct implementation change.

Companies therefore face a tension between short-term efficiency and long-term capability development.

A senior-heavy team may perform well today while relying on expertise that took years to develop. If fewer junior engineers gain comparable experience, companies may struggle to find enough employees capable of directing agents and making complex decisions in the future.

This matters because operating an AI tool and exercising engineering judgment require different skills. Engineers supervising agents need to recognize incomplete requirements, questionable implementations, and risks that routine checks may miss.

Developing that expertise requires experience with real problems and the consequences of decisions.

Hiring and development must adapt to agent-directed work

Companies are beginning to experiment with new ways to recruit and develop junior engineers. Some place greater emphasis on candidates’ ability to communicate with customers, solve unfamiliar problems, and build working solutions.

These approaches give demonstrated judgment and practical capability more weight than formal credentials or traditional hiring signals.

The ability to direct agents is also becoming part of the expected skill set. A junior engineer may need to understand a customer’s problem, define tasks for agents, evaluate their outputs, and improve the resulting solution.

This changes how employees learn. Instead of spending most of their time implementing each step directly, they can help define and review a larger volume of work.

The ambition is to accelerate the development of judgment that previously took years to acquire, potentially compressing that learning into a fraction of the time.

Reaching that goal requires deliberate development practices. Agent-directed work exposes junior engineers to more tasks and outputs, but experience comes from understanding why decisions succeed or fail.

Companies can develop that understanding by giving junior employees meaningful responsibility for requirements, evaluation, testing, and operational outcomes, with support from experienced engineers.

This approach also connects talent development with the engineering practices needed for autonomy. Clear requirements and automated tests provide feedback, while responsibility for production systems exposes employees to the longer-term consequences of technical decisions.

Hiring experienced engineers can meet immediate supervision needs. Sustaining senior-heavy teams requires a way to develop the next generation of employees who can make those decisions.

Evaluate autonomy through delivered outcomes

These workforce changes add another dimension to evaluating an AI operating model. Leaders need to understand what teams can deliver today and whether the organization is developing the expertise needed to sustain that capacity.

A useful assessment starts with the work a team can complete and the decisions it can make without escalation. It then examines how agents contribute, how their outputs are checked, and who is accountable for the result.

Delivery performance should be measured across the full process, from starting work to making it available to customers. This reveals whether delays occur during implementation, testing, approval, release coordination, or another stage.

The assessment should also examine whether teams have the technical practices and human capabilities their authority requires. A group may be able to approve its own deployment, for example, but doing so reliably depends on testing, operational knowledge, and clear responsibility for failures.

As companies expand team autonomy, these measures become more closely connected. Faster execution increases the volume of work requiring evaluation, while broader decision rights raise the consequences of human judgment.

For engineering leaders, the practical task is to determine where authority can safely move closer to execution and what capabilities teams need before that happens. Those boundaries should evolve as teams strengthen their engineering practices, gain experience, and demonstrate that they can deliver and operate their work reliably.

In conclusion

AI is changing how software companies operate, but faster engineering execution does not automatically translate into better business performance. Smaller teams, flatter hierarchies, and AI agents can increase productivity, yet those gains remain limited when decisions still depend on centralized approvals and lengthy coordination processes.

For CEOs, CTOs, and engineering leaders, the priority is to align decision-making authority with the capabilities of AI-enabled teams. This means identifying where approvals slow delivery, determining which decisions can move closer to execution, and ensuring employees have the skills and engineering practices needed to take greater responsibility.

Organizational redesign must also account for long-term talent development. As agents absorb more routine engineering work, companies need new ways to develop the technical judgment and operational experience that future leaders will require.

The most effective operating model will depend on each company’s structure, capabilities, and business objectives. The common challenge is ensuring that changes to team size, roles, and AI adoption are matched by changes to how decisions are made.

The next stage of AI-driven organizational change will depend less on how quickly teams can produce work and more on how effectively companies turn that work into business outcomes.