Most companies want their teams to collaborate more. Most also struggle to find a format that does it without a dreadful team-building day everyone wishes to avoid. At AAI Labs, people from different teams don't always share a project, so we tried something other than an event: giving small mixed teams a real problem with a strict time limit.
How mini-projects work
Mini-projects are monthly sprints. About 50 people take part, split into teams of three or four. Teams are assigned randomly, following the requirement that every team has at least one engineer or data scientist. Teams are reshuffled every sprint, so each round you work with different colleagues.
Each team gets a brief: a client-relevant business or technical problem, an approach to explore and at least one alternative to compare it against. The brief suggests a strategy and an outcome, but the teams are free to choose how to approach the challenge.
The biggest constraint is time. Teams meet for two one-hour sessions a week, for four weeks. No work is allowed in between the meetings, meaning each person dedicates 8 hours of their month. When the meeting ends, you forget about it until the next session.
This restriction doesn't just keep everyone productive, it also encourages focusing on outcomes rather than doing busywork. By the end of week two, all teams have to have something that works end to end, however rough. This ensures troubleshooting begins in the middle rather than the end of the initiative – problems surface and can be addressed much faster.
Why one working day a month is worth it
A full day a month away from client work looks like a cost. However, in July our 14 teams tested 14 ideas, each with a working result and a comparison against an alternative. Among them:
- a comparison of 13 open-weight language models ranked by cost per successful agent task
- a fine-tuned model that flags risky AI agent actions for human review
- a predictive maintenance demo for CNC machines that recommends whether to replace a tool, inspect it or keep running
- an interactive guide to CNC process planning
- simulation tools for truck routing, supply chain design and manufacturing yield
Some of the most useful results were negative. One team built an exact supply chain optimizer and found that better routing could save at most 0.84% on that network, because most orders could legally go to only one plant. Another tested whether AI agents get worse after many tool calls and did not find the expected drop on their task. Findings like these change how we scope similar client projects, and each cost a few dozen person-hours rather than a client project built on the wrong assumption.
Teams also come back with tools they had not used before: OR-Tools for routing, PatchCore for visual defect detection, Streamlit for fast demos and context-pruning plugins for coding agents.
Voting for the best results
On the final Friday, each team posts its work in a shared Slack channel. Colleagues comment in the thread, and everyone votes for their 3 favorite projects.
Projects lower in the ranking are not criticized. A team that reports "it didn't work as well as we hoped, and here is why" has done the job. Our own guidelines rate that above a polished demo of something obvious. It is a friendly competition: we celebrate the projects people liked most, take a month's break, and come back for the next round.
Clear improvements by the second sprint
The first sprint felt confusing to some teams. Working with people you barely know on a problem outside your field, especially with a clear time restriction, can be uncomfortable. Finding the best way to communicate within the team, understanding how the deliverables should look – all teams were working in an unfamiliar format for the first time.
By the second round, the teams were noticeably stronger. People knew the format, so sessions went on the problem rather than the process, and they were quicker to pitch an idea before it was fully formed. The initial awkwardness in July became playful and exploratory, with team members suggesting additional features just because they were interested in testing their ideas.
Trying it with your teams
The format matters more than the topic:
- Assign teams, mix them and change them every round.
- Cap the time and protect it: short fixed sessions, nothing in between.
- Require a working result by the halfway point.
- Ask for a comparison against an alternative, so results are evidence, not opinion.
- Treat honest negative results as a success.
Eight hours a month is enough for a team to test an idea properly. It is also enough for people from different parts of the company to learn how the others work. At worst, the initiative gets canceled after an unsuccessful attempt. At best, a project may turn into a valuable product.