In my daily work, I often wear two hats: a technical PM and a Solution Lead. My role involves earning trust and authorization from both my boss and the engineering leaders, discussing requirements with business units, collaborating with internal and external stakeholders, and guiding the team to deliver results over weeks or months of development.

I feel that MTa L2 is perfect for people like me. It gave me a chance to step back, take a higher-level view, and reexamine how teams actually operate.

Teams & Tasks

At work, it’s so easy to get used to a pattern: the business unit requests something, we allocate resources, and then build it. On the surface, it feels straightforward.

But is it really that simple?

The MTa challenge activities made me rethink what’s going on beneath this “business as usual” flow—and reminded me there are far more details to consider.

Before the Task Starts

  1. Digest the requirements and clarify constraints
  2. Think through implementation, outline division of roles, and identify the skills your team will need

1. Digesting Requirements & Clarifying Constraints

What exactly is the task? Why are we doing this? What problem are we solving, and what goal are we aiming for?

  • Is it tied to a key company strategy?
  • A small-scale proof of concept?
  • Or a training opportunity for the team?

And what are the constraints?

  • Is the budget tight?
  • Is it critical to deliver all features by the press conference in two weeks?
  • Are your senior developers unavailable because they’re on other projects, leaving mostly juniors on the team?
  • Or… all of the above?

2. Team Roles & Division of Work

Based on the task and its limits, think ahead about how work might be split:

For example, in the final MTa challenge, the first two tasks were relatively simple. It was enough for one person to gather requirements and divide work back to the team.

But the final “boss level” task was a big, complex deliverable within tight time constraints. Having just one person translate requirements wasn’t realistic. It needed much more upfront planning: defining roles, sequencing work, and setting up checkpoints to make sure we could actually pull it off.

Once the Task Starts

  1. Learn about your team members and how they can contribute
  2. Adjust how the team operates in real time

1. Understanding Your Team

Ideally, you’d know everyone on the team before the project starts. But in reality, you often only get to pick a few key roles, and other members are assigned by their managers.

So how do you figure out team dynamics early on?

As the project progresses, you gradually discover who’s good at spotting core problems, who quickly absorbs and processes information, who can manage task division, who keeps an eye on details, and who’s an all-rounder.

With this understanding, you can start aligning people to the right roles and adjust task assignments or review processes as needed.

2. Real-World Team Adjustments

Everyone brings different personalities and experiences, which naturally leads to different ideas. But a team is built from these differences. So how do you keep things running smoothly and deliver results together?

In our MTa team, we held quick debriefs after each task. These discussions helped us work out how to improve next time. Compared to the slightly awkward first hours of the morning when we were still strangers, our teamwork became much smoother later on—and our results reflected that.

For example, during the challenges we worked through questions like:

  • With so many voices in the team, which ones should we prioritize? Which can wait?
  • Should we always announce before passing on information, or are we so in-sync that teammates will naturally pick up and act?
  • How should we balance time allocation, division of work, and who’s responsible for execution vs. review?

Final Thoughts

We tackled so many challenges together. With every debrief, our team got better and better at collaborating. Each task had a different level of difficulty and constraints, testing our ability to adapt and work flexibly as a group.

Having taken MTa twice now, I can say this: the core design of the program remains consistent. It’s through these playful, game-like activities that participants get to reflect on how they collaborate at work—and spot areas for improvement.

What I really like about MTa is that it doesn’t force you into a specific “methodology box.” Instead, it gives you open-ended tasks and a feedback framework that highlights key factors to consider. This gives you space to observe, reflect, and uncover your own insights about how teams work.

Here’s my personal takeaway about the difference between L1 and L2:

  • MTa L1 helps you see yourself from a personal perspective—reflecting on how you show up in different team tasks.
  • MTa L2 helps you see things from a team perspective—analyzing how the team as a whole operates.