How a Group Becomes a Team

When I joined the SPAR program, I was expecting to learn about robotics and share some benchmark experiences with others at my level; but I was surprised with a leadership lesson that was about neither robotics nor benchmarks.

We had a program-wide kickoff two weeks ago, but didn’t hear much from the program lead for almost a week even though we tagged him in slack. We shared a group slack channel, so I assumed the worst, and thought that the mentees were left for dead. I showed mild initiative by proposing a meeting time at an arbitrary time with one day notice.

Two days after the unofficial meeting, our mentor Tzu dropped a lettucemeet link with all our availabilities. Tzu’s availability was wide open for us. The meeting was confirmed 5 days out.

Lesson learned: you only get as much commitment as you give

One of the conditions of working for one of Robocurve’s initiatives was to sign an NDA, standard practice. I signed it an hour after the link was posted in slack, but Tzu sent out 3 reminders in Slack before the meeting. How unusual, I thought.

Then when we started the meeting, the NDA requirement was mentioned again, mentioning that somebody didn’t sign the NDA without calling them out by name. Whenever I form a group, I infer anybody’s unresponsiveness to be a sign of disinterest. But seeing that all the mentees had to apply to volunteer for this program, I was wrong. Most people have more than one report above them, be it family, sports, work, or other commitments.

Lesson learned: Being busy or lacking attention for being responsive itself is weak signal for disinterest.

During the meeting, Tzu mentioned having led more than 80 teams before. Big number, but I had no idea what that meant. But as he kept on going over his mental agenda, it clicked. He had standardized his group formation meetings to turn them into teams.

- Greetings leadership and company introduction
- Personal intros with 1 'fun fact about myself'
- Describing past experiences for each
- Project goals and scope discussion
- Timeline and budget discussion
- Task assignments
- Logistics and coordination discussion
- Future repeating meetings confirmation
- Team values pep talk
- Action item commitments confirmation

I never knew I was a bad project leader until I witnessed a good one in action.

I had a flashback to all the group projects I had during my 6 years of university and years of working at startups. Never have I ever made commitments feel so personal by making everyone pause for 30 seconds for a chance to raise objections about why they cannot commit to meeting every week at that same time. Then another 20 seconds of deliberate silence for allowing time to formulate questions about scope and team identity. At startups, I thought I was ahead just because I put an agenda together and following up once for each commitment made at the meeting.

The efficiency of the meeting was somewhat impressive, but the remarkable part of the meeting was the pep talk. Instead of assuming what it means to be a good teammate and worker, Tzu stated four personal values.

• Take ownership: if something can be better, make it your problem to fix, don’t assume someone else will do it.
• Action bias: prefer to do something than nothing
• Be Follow-up Maxxing™: chase down todos after every meeting, as many reminders as it takes to get it done.
• Do work you’ll be proud of in a year, don’t put out useless work.

The way that these were mentioned raised the expectations for myself and for everyone else in the team. If someone(me, probably) is not following up or putting out AI slop, that’s a signal that they’re not meeting expectations. And it gave me permission to annoy the shit out of whoever’s not doing what they said they would. This was against my previous status quo of follow-up once then never again. Project rules are different from dating rules. Or could it be that I didn’t follow up with my dates enough times in the past? I’ll never know.

For each action item assigned, the direction was voluntary then the timeline was suggested. This allowed variable scope, which is the best kind of autonomy. I wanted to prove myself and make a great impression of my contributions. Shorter, more frequent timelines establish a culture for accountability and quality.

It makes great sense to standardize such a team formation for running many projects involving people who have other obligations. Even in a corporate setting, if I ever wanted to get ahead, asking for permission to put together a prototype is going to be too slow. If I want to show initiative, I can’t wait for resource allocation to be justified at management level. I should be scoping, eliciting, and following up with ad-hoc project members who owe me nothing. Great leadership in organizations is de-risking, expediting, and motivating.

I didn’t actually deliver anything useful yet, but I’m learning what I can along the way. The journey to an automated future will need more leaders.