During the journey to design, build, and release our Customer Experience platform, one of the pillars of TrustYou Hospitality AI solution, we have transformed our entire Product & Engineering organisation and way of working to align with a fast-paced and innovative approach.
Today, I’d like to introduce one of our most impactful changes of the last few years: the “Temporary Team”—or TTeam—concept.
What Is a Temporary Team?
A TTeam is a limited-lifetime team designed to foster the collaboration among the individuals needed to accomplish a specific goal. This is achieved by bringing engineers together to work full time with a clear purpose.
We create TTeams with a well-defined scope that can be delivered in no more than a few weeks. The TTeams disband once the scope is released, or canceled due to new findings after some initial work, or redefined to fit within the budget.
A TTeam is a cross-functional and cross-team setup with engineers with different skill sets as well as other roles like product managers or product designers—even colleagues from other departments if their knowledge or skills are required. Each TTeam has a product lead and a technical lead. These roles don’t necessarily imply a leadership position outside of the TTeam, offering engineers an opportunity to grow their leadership skills in a well-defined context.
Long-lived Teams vs. Temporary Teams for Product development
We maintain a structure of long-lived teams to handle local changes, long term technology strategy and operations for each subsystem, with clear ownership. The long-lived teams are the anchor for the knowledge of the subsystems. Meanwhile, temporary teams enable us to boost focus and flow when designing and implementing the most complex features.
While a TTeam is active, its members step away from their day-to-day responsibilities within their long-lived teams. Each TTeam chooses how they work. Typically, it’s very pragmatic and lean: a dedicated Slack channel, a Miro board for capturing and discussing ideas, a simple Kanban board for the tasks, and a bias for pair programming sessions and workshops over formal, recurring meetings.
Once the TTeam disbands, each member returns to their long-lived team, bringing back valuable knowledge and insights gained out of their regular work environment.
A Real-Life Example of Focus and Flow
To illustrate, let’s look at how we built and released one of our features: Mark a Survey review as inappropriate.
This feature is triggered from the Inbox of the CXP platform. Once a survey review is marked as inappropriate, it goes through an approval flow and notifications. Upon approval, the review is excluded from KPI calculations across dashboards and labeled with a specific status in the Inbox.
Implementing this functionality has required changes in several platform components owned by different teams.
In a typical engineering setup with long-lived teams, the tasks to implement this feature are distributed across multiple team backlogs. Coordinating the work requires additional planning meetings on top of each team’s regular schedule, as well as aligning in advance on interfaces, test data, and other dependencies. The very much needed touchpoints between the people collaborating on the feature are both an “overhead” and exceptions to their day-to-day workflow within their long-lived teams. As a result, different priorities, misaligned timelines, and overlooked dependencies often lead to delays and frustration.
In our case, we created a temporary team to build and release this feature. The TTeam included four engineers with different skills from the teams owning the impacted subsystems. The team lead of one of those teams and the product manager of other of those teams took on the leadership roles, as a part time assignment.
Over three weeks, the temporary team worked together to design, implement, test, and release the feature. With a single priority, regular syncs, and on-demand pair programming and grooming sessions. Blockers were identified and addressed immediately and any misunderstandings were uncovered and fixed at early stages. Everyone pulled in the same direction, leading to a successful and timely release.
Highlights and Lessons Learned
The concept of temporary teams has been a game-changer for us, especially when tackling:
- Cross-Team Features: When features require expertise from engineers across multiple long-lived teams, TTeams eliminate dependencies, reducing idle time and blockers. Instead of splitting tasks across backlogs, TTeams align everyone toward a shared goal.
- High-Uncertainty or High-Risk Tasks: When uncertainty or risk is high, a TTeam enables flexible ways of working with fewer formalities. This focus helps the team to tackle complex problems without distractions.
Of course, not everything has been perfect. The main challenges we faced include:
- Too Many TTeams: After discovering the potential of TTeams, we initially launched too many at once. Managing scope, kickoff, and disbanding properly takes time and effort. Excessive TTeams created chaos until we established some controls to prioritise and limit the number of active TTeams.
- Poor Planning: Early on, we rushed to kick off TTeams without considering the impact on long-lived teams. Now, we plan weeks in advance, and for unexpected needs, we carefully evaluate timing to minimize disruptions.
Test & Learn!
TTeams have become a crucial asset in increasing the focus and flow of our Product & Engineering department.
However, Test & Learn is one of our core values at TrustYou, and we continue to apply it to our temporary teams concept. We regularly reflect, learn, and refine how we leverage them.
If you find yourself in a situation similar to the one I described with long-lived teams in the example, it might be worth considering whether some form of temporary team could work for you.
I love technology and people, so I became an engineering lead. Curious and restless learner. Geek and still hands-on when time allows, I contribute to building the future of hospitality with AI solutions as the VP of Engineering @TrustYou.
