Temp Squads: How to Organize Ephemeral and Mixed Teams for Hyper-Performance with AI.

Introduction

The rapid adoption of AI is changing how organizations build software faster than most teams can adapt. We are still learning how to organize people and AI around complex, fast-moving development work.

This post proposes a framework for mixed human-AI teams that can hold people of different skills and knowledge area and take advance of this misc. to build fast. Its goal is to improve delivery while helping people develop new skills across the organization. The approach combines ideas from open-source communities and agile management, adapted for large companies.

The framework is intended for developers, designers, managers, and leaders working across dozens of teams, hundreds of repositories, and products serving millions or billions of users. For smaller organizations, use only the practices that fit your context.

The Problem

Well... let me introduce myself: I am a web developer with more than 15 years of experience and currently working as lead developer for a DevEx initiative within the fintech ecosystem of the biggest Latin American company. Our environment includes hundreds of distributed services, repositories, and databases handling millions to billions of requests each day.

As the company shifted toward an AI-first model, technical contribution was no longer expected to come only from developers. Designers, managers, and other roles should also be able to track, implement and maintain features with AI assistance.

Two major barriers emerged. First, software development depends on extensive hidden knowledge: internal pipelines, architecture, Git, semantic versioning, testing, linting, deployment, and company-specific processes. AI lowers the coding barrier, but it does not automatically provide this organizational context.

Second, we were trying to fit AI into processes designed for a pre-AI environment. Backlog management, planning, reporting, maintenance, bureaucracy, and rigid role definitions could not keep pace with AI-assisted development. Code production became faster, but the surrounding organization did not, leaving an issue: developers still as the only people able to contribute directly to codebases.

The Momentum

We first recognized that the main obstacle was organizational, not technical. Adopting AI effectively requires teams to reconsider processes, roles, and assumptions established long before AI became part of the workflow.

Fortunately, my organization and manager were open to personal experimentation. This support created the momentum needed to test a new way of working rather than forcing AI into existing processes. What you will see here does not represent my company views and are part of a personal research. So...

These changes must be collective. Without support from teammates and leadership, attempting a major transformation can become costly and exhausting. In that situation, the best first step may be to introduce the ideas, build alignment, and wait until the organization is ready to experiment.

What we changed

So, we started to change things and move our development pipeline to be something more like this:

1. Business Plan

The business still holds the product, so the goals still come from them. But here we expect exactly this. we dont want tasks breakdown, pre-technical analysis - we want a business goal in format of feature request or RFC (request for change). we also expect business reasons, risk analysis, acceptance criteria, etc.

2. Goals Definition

Once the goals are accepted and well defined, and they were negociated between the business and the IT management team, and everything is clear, we move to document the milestones.

3. Milestones Documentation

For each milestone, create a single card in the organization’s project management tool. This card should not contain a task breakdown, design files, implementation details, or individual action items.

Its purpose is to document the milestone at a business level and serve as a bridge between business and technology teams. Each card should represent one goal, feature, or RFC and provide a concise, high-level view of the initiative.

The card should include only essential information, such as the business rationale, risks, intended outcomes, relevant metrics, requirements, and links to the related code repository or repositories where implementation issues will be tracked.

Keep the card objective and focused. It should define the goal and provide the context needed to align stakeholders, not become a detailed specification or technical plan.

4. Workforce Definition

Once a goal is defined and documented as a milestone, the next step is to identify the people and teams required to deliver it.

This is a staffing decision: assess the goal’s scope, complexity, dependencies, and delivery timeframe, then define the minimum group of capabilities needed to complete the work.

For example, a backend-focused goal may require backend engineering, data platform support, database modeling, and validation from teams that own shared services. A frontend goal may require UI/UX, frontend engineering, and product support. A full-cycle goal may require a complete cross-functional squad.

The objective is not to assign the work to the team that first receives the request. It is to identify the most appropriate people, expertise, and supporting teams across the organization to deliver the business goal effectively. And from the formalization of this analysis a Temp Squad will rise.

5. The Temp Squad Emerges

This is one of the most significant changes in the process. In a traditional model, a goal is passed between separate teams, often creating handoffs, dependencies, and delays. For a full-cycle initiative, the work would typically move through multiple teams according to a predefined timeline.

Instead, the workforce definition is used to create an independent Temporary Squad. Each member continues to report to their original team lead while also contributing to a temporary, cross-functional team responsible for delivering the goal.

The model is illustrated below:

Click here to view the diagram in full size

As shown in the diagram, temporary squads emerge from the existing team structure. They bring together the required capabilities for a specific goal while preserving the organization’s permanent reporting structure.

Temp Squads

A Temporary Squad is created for a specific goal and remains active only for the duration of that goal. The responsibilities required to deliver the initiative are assigned to the squad, allowing other team members and managers to remain focused on their primary responsibilities.

Instead of moving tasks between teams, the Temporary Squad keeps the work within a cross-functional group that has the necessary context, skills, and AI-enabled support to deliver the outcome.

The flow is as follows:

Goal definition
  -> Temporary Squad creation
  -> Build and communication loop
  -> Release
  -> Temporary Squad closure

Work does not move repeatedly between teams or owners. The Temporary Squad maintains responsibility for the goal until it is completed, canceled, or otherwise concluded.

This model follows a few core principles:

• The Temporary Squad exists only for the duration of its goal.
• If the goal is completed, canceled, or blocked, the squad is dissolved.
• The squad should remain minimal, practical, and focused on delivery.
• The squad should avoid unnecessary rituals, lengthy planning cycles, and unproductive discussions.
• The squad should be autonomous and self-sufficient enough to define the practices required to achieve its goal.

Once goals and Temporary Squads are defined, the next step is to establish how the squad will coordinate its work.

The Squad Coordinator Role

Each Temporary Squad should designate a Squad Coordinator. This person is responsible for tracking progress, consolidating relevant information, coordinating operational activities, and addressing the squad’s day-to-day needs.

The Squad Coordinator does not need to be the most senior member of the team. The role should be assigned to someone with sufficient availability and the ability to keep the work aligned with the goal. It can also provide a development opportunity for semi-senior professionals to build mentoring, coordination, and leadership skills.

Communication Channel

Each Temporary Squad should have a dedicated communication channel using the organization’s standard collaboration platform, such as Slack or Microsoft Teams.

The channel should include all squad members and provide a visible, centralized record of progress, decisions, questions, and relevant updates. This enables managers and stakeholders outside the squad to stay informed without creating unnecessary meetings or reporting overhead.

A shared channel also supports direct, goal-focused collaboration. Team members can quickly access the expertise they need: designers can consult developers about deployment considerations, developers can request UI/UX input, and all members can exchange knowledge about effective AI-assisted practices quickly.

This structure reduces isolated work, knowledge gaps between teams, and long coordination chains. It creates a practical learning environment in which people collaborate across disciplines while maintaining focus on the squad’s delivery goal.

Defining Tasks

The Temporary Squad operates as a focused delivery unit: it is accountable for results while managing its internal tasks independently. Goals, milestones, and outcomes remain visible to the organization, while the squad defines and executes the work required to achieve them.

All Temporary Squads should track work in a consistent location and format. The specific tool may vary, but the model should provide a shared, transparent, and practical view of the work.

A useful approach is the community open-source model, which is widely used to coordinate large software ecosystems with many contributors. The process is straightforward:

1. The Squad Coordinator meets with squad members to develop a shared understanding of the goal or problem.

2. The squad breaks the goal into small, actionable units of work.

3. Each unit of work is created as an issue in the relevant code repository, such as GitHub or GitLab.

Important: During task definition, the squad should focus on what must be done to achieve the goal, not on who will execute each task. Assignment happens after the work has been clearly defined.

The Issues

Each Temporary Squad task should be represented by an issue in the relevant code repository. The related goal or milestone card should link to the repository and its issues.

Every issue should include a clear title, a detailed description, and labels that make the backlog easy to filter and manage. Recommended labels include:

• Goal or initiative: A single label applied to every issue related to the Temporary Squad’s goal.
• Expected effort: Labels such as 2d, 4d, or 6d to indicate the expected duration (d = days). Ideally, an issue should not exceed this range.
• Expectation or context: Labels such as hard, good for beginners, or blocked to provide additional context.

Pro Tip

After creating the squad’s issues, use AI to provide an initial assessment. Provide the repository and initiative label, then use a prompt such as:

Go to this repository: <repository link>.

Collect all issues with the label <label>.

Read each issue carefully and review the relevant repository code and documentation.

For each issue:
- Define a possible implementation plan.
- Assess the intended outcome.
- Identify implementation considerations, risks, dependencies, and other useful observations.
- Add the analysis as a comment on the issue.

Make it explicit that the comment was generated by AI and must be reviewed by a human.

Not every issue requires an AI assessment. Use it where additional context, planning support, or risk identification adds value. The repository provides a single source of information for the goal, issues, code, and AI-assisted analysis.

The Technical Backlog

Once all issues have been defined, they form the technical backlog for the goal. Executing this backlog represents the delivery of the initiative.

Using an open-source-inspired model does not require making company information public. The same practices can be applied within private repositories and internal platforms. Public projects can still be useful references for understanding how large contributor communities organize work. For example, see the React issue tracker.

Task Assignment

Once the backlog is ready, Temporary Squad members should filter issues by the initiative label, review the briefing and any AI analysis, and select the work they can execute.

After planning, every active issue should have a visible assignee. This creates clear ownership while allowing squad members to participate in task selection.

The Squad Coordinator aligns the backlog and definition of done with stakeholders, communicates the agreed expectations to the squad, and helps remove blockers during execution.

The AI

Temporary Squads create a practical environment for AI-assisted delivery because they work on a limited, well-defined goal. The squad can provide AI with a focused set of inputs: the business goal, acceptance criteria, relevant repositories, issues, dependencies, and definition of done, where EVERYBODY is aware of whats happening and can contribute with AI.

This reduces unnecessary context and makes AI output easier to validate. Instead of asking AI to understand an entire organization or backlog, the squad asks it to support a specific initiative. Smaller and more objective scopes reduce ambiguity, improve planning quality, and make errors easier to identify before they affect production.

AI can support the Temporary Squad throughout the delivery process:

• During goal definition, it can help identify unclear requirements, missing acceptance criteria, risks, and possible metrics.
• During workforce definition, it can help map affected systems, dependencies, and required capabilities. Staffing decisions remain the responsibility of managers and technical leaders.
• During task definition, it can help break down the goal into issues, suggest implementation plans, identify risks, and prepare initial technical assessments.
• During execution, it can support code exploration, implementation, testing, documentation, pull request descriptions, and release notes.
• During completion, it can summarize the delivered work, document lessons learned, and identify knowledge that should remain available to project maintainers.

Different squad members should use AI according to their responsibilities and experience levels. The main advantage is that they can learn from and support one another.

Because different technical roles work closely within the same focused scope, communication barriers are reduced. Team members can ask questions, validate decisions and definitions, request help, and share AI-assisted practices directly with the people who have the relevant expertise.

AI should be treated as a shared capability, not as an autonomous owner. Its output must be reviewed, tested, and approved by accountable people, and this people is now a multi-skill set of people.

By reducing context switching, shortening feedback loops, improving access to knowledge, and helping a small cross-functional team move from a clear goal to a validated delivery with less coordination overhead, AI becomes more than an individual support tool. It becomes a scalable execution capability that helps teams improve performance and deliver outcomes faster. AI is about communication, at the we removed the communication boundaries.

Who Is the Owner?

Project ownership does not transfer to a Temporary Squad. The squad is responsible for delivering a specific goal within a project, such as a refactor, feature, or improvement.

Once the Temporary Squad merges its changes, the project maintainers resume responsibility for maintaining the codebase. Work should follow the established engineering workflow:

1. Create a branch.
2. Implement the changes.
3. Open a pull request.
4. Include project maintainers in the review when their context or approval is required.

This model allows the Temporary Squad to deliver a defined outcome without changing the long-term ownership or maintenance responsibilities of the project.

The Management Perspective

From a management perspective, the focus shifts from assigning individual tasks to understanding how people are allocated across goal-oriented Temporary Squads.

Managers should avoid micromanaging squads. The purpose of the model is to reduce coordination overhead and give squads the autonomy needed to deliver their goals. Managers should focus on the following:

• Which Temporary Squads each team member is currently supporting.
• Whether team members have sufficient capacity for their assigned squads.
• Whether a team member is assigned to too many squads at the same time.
• Whether each squad is progressing as expected.
• Whether intervention is needed because a squad is blocked, delayed, or operating outside its agreed scope.

Completion

When a Temporary Squad completes its goal, the squad is dissolved. Its issues should be closed, canceled, or documented with their final status.

The project maintainers retain responsibility for the delivered code, and the participating members return their focus to their permanent teams or future Temporary Squads. This closes the delivery cycle and creates capacity for the next initiative.

Conclusion

Temporary squads are not a replacement for permanent teams, managers, or product ownership. They are a delivery model for turning a clear business goal into a focused, cross-functional unit with the skills, authority, and context needed to complete it.

AI can make implementation faster, but speed alone does not create business value. The real advantage comes from reducing handoffs, shortening decision cycles, and allowing the people closest to a goal to collaborate directly. Instead of moving work through several isolated teams, a temporary squad holds the responsibility for a defined outcome from discovery through release.

For the business, this model can improve time to market, make ownership more visible, reduce coordination overhead, and help teams use specialized knowledge where it has the highest impact. It also creates a practical learning environment: people work alongside different disciplines, share context in real time, and build stronger AI-assisted delivery habits while producing results.

The model needs clear guardrails to remain effective:

• Every squad needs one measurable goal, a limited scope, and a clear end condition.
• Squad membership must be intentionally sized and time-bound.
• A temporary manager should coordinate progress and unblock work without becoming a new layer of bureaucracy.
• Permanent product maintainers retain long-term ownership of the codebase.
• Managers must protect capacity by limiting how many temporary squads a person joins at the same time.

The best way to adopt this approach is through a small pilot. Choose a meaningful but contained initiative, define the expected business result, and compare its lead time, quality, rework, stakeholder satisfaction, and delivery predictability against the current model. Scale only after the organization has evidence that the new structure improves outcomes. When goals are clear, ownership is explicit, and AI is supported by shared organizational context, teams can move faster without sacrificing quality, accountability, or long-term maintainability till you have finally achieve: Hyper-Performance.

[!WARNING]
This framework is experimental. It is based on practical observations and early experimentation, not a proven universal model.

Its effectiveness depends on the organization’s culture, leadership support, product complexity, technical maturity, and ability to protect team capacity. Start with small, measurable pilots, collect feedback, and adapt the model before applying it at scale.

Temporary squads should complement—not replace—clear ownership, sustainable workloads, security practices, quality standards, and long-term product maintenance.

Acknowledgements

Special thanks to Edson Silvestre Bento, Mariana Moreira, Heitor Galdino Da Silva, Pilar Canosa, and Catharina de Araujo.

They are managers, colleagues, and teammates who have contributed directly to these experiments. Many of the ideas discussed in this article were developed, tested, and refined alongside them.

Together, we are exploring better ways to organize teams and deliver software in an industry increasingly shaped by AI. I am grateful to work with such open-minded and talented people.

Cover image by: https://unsplash.com/@imaginebuddy.