Sync-ups

Sync-ups - efficient meetings for intense product building

How to run meetings effectively and at minimum.

Meetings can become seriously unproductive at any given point.

Ever had a meeting that stretched on? They went in circles? That had no tangible outcomes? That you and others didn’t actually need to be in?

I define the Time Cost of Meetings to help quantify and conceptualise the cost aspect,

the Time Cost of Meetings

Given a meeting with 5 people, if one person speaks for just 10 mins – they consume 50 minutes of potential working time from everyone.

That’s the cost of meeting. It’s a trade-off between meeting time vs work time.

I’ve refined and developed a “Sync-up”, a concise and effective way to do meetings in hackathons and product building.

Sync-up - key aspects

• the Runner: runs the sync-up, often the Product Manager
• Time capped to minimum: total duration 15 minutes or less for a 4 person team
• Focus on immediate tasks: the Runner should screen-share/display a Kanban board
• Chunk out time for updates and ensure participants are relevant: taking turns,
  • each teammate has about 3-4 minutes of speaking time to convey:
    • what they worked on since last sync-up
    • what they will work on next
    • any highlights/blockers/requests
  • after which, anyone else can chime in suggestions, queries, concerns…etc
  • ideally, the relevant updates Kanban board as they were working through their tasks
• Establish when to next sync-up on current trajectory: established at the end (usually hold one every 4 hours)
• Abolish low-level details and 1-1 discussions: no diving into details or using the group sync-up for 1-1’s, do that with only relevant parties afterwards

context - at my 7th hackathon, I hacked with 15 people

In my 7th hackathon, the National Innovation Games in Australia, I learnt the importance of sync-ups and developed a better way of having meetings. No other hackathon has drilled into me the potential extreme inefficiencies of meetings.

As always, note: disclaimer on sharing context while respecting privacy

The organisers had randomly assigned participants into teams of 15 people. Not joking, 15 people are 3 pizzas-worth of team – too many pizzas to have a cosy party.

It was sponsored by Creative Australia, known as the Australia Council for Arts at the time, the Australian Government’s principal arts investment and advisory body. They weren’t familiar with running a hackathon and had outsourced its organisation to a firm. The firm decided this team size was appropriate.

Check out Team Sizing.

🤯 Now, 15 people! Wow, remember Output Optimisation - Time? On paper, we could output 300 hours of productivity in a 40 hour hackathon at a chill pace.

That’s not the case. A 15 person team is exceedingly hard to orchestrate. Here’s the main factors that made it hard.

• unfamiliarity: we were all random strangers
• size: 15 voices, needs, skillsets and vibes – meshing in attempt to produce outcomes
• demographics:
  • age: 2/3 of the team were young uni students, remaining ranged up to late middle-aged
  • skewed backgrounds: I was the only technical person in that I was studying electrical engineering and knew how to code. Everyone else came from a non-technical arts/business background.
• accomodating people with different needs:
  • we had a Deaf person who used only sign-language that required an additional translator to be present (this was the closest I know how to refer to these people)
  • this Deaf person was one of the most vocal and dominant in the team
  • there was increased time and attention span required for: the Deaf person using sign-language > the translator interpreting with many micro-pauses > audience to digest it
• remote collaboration: pandemic time! fully remote with 15-ish camera feeds on screen
• dominant personalities and voices:
  • 2 middle-aged teammates were ladies with an arts related background/career, and from the get-go and throughout – they took the most talking time in the team during meetings, with one spamming the group chat
  • one was the Deaf person
  • this resulted in some rather skewed opinions in meetings
  • I’ll refer to them as the 2 dominant voices (2DV) from now on
• assigned facilitator: all teams were assigned one. However, their job was to facilitate rather than lead directly, so our team still had to storm and make our own decisions.

How did it play out?

The organisers and our facilitator advised us to operate in 3 phases. First, brainstorming for about ~3 hours, then ~4 hours to build the solution/MVP, then polish and prep presentation.

It started at about ~10am in the morning, and by 4pm, we still had not reached consensus on the idea to work on 🥲

Since commencement, we were essentially in one big and dragged on meeting within a massive group video call. The 2 dominant voices absolutely controlled the meetings. Both had a strong need to express their opinions on everything and they often just fed-off each other.

It’s actually fine if experienced or insightful voices hold the most sway in a group dynamic – I’d love to take a backseat and learn from working in a team with Levelsio for example. However, the opinions circulated by the 2DV were generally lacking in product-sense and feasibility. Additionally, there was no structure in the approach they took towards brainstorming and vetting ideas – which made it challenging for the rest of team to join the ride.

E.g. the deaf person championed the idea: to have a translator person in every cinema to translate for Deaf people (which would be extremely cost-inefficient if done, and does not remotely fit the hackathon theme of “Embedding Technology”).

A thought came to my mind. “Wow, when one person speaks 5 minutes in a meeting with 15 people, they’ve managed to consume 1 hour 15 min of possible work time.”

The 2DV managed to kill 45 hours of possible work time (3 hours x 15 members), way past the recommended brainstorming time without reaching consensus on an idea. I wasn’t sure if 2DV can even be counted into that possible work time, because after we finally managed to align on an idea – the 2DV evaporated into thin air and did not contribute to actually building a demo or prepping for the presentation 😛 It felt like all-talk, no-action.

In fact, about half the team dropped off as we entered the actually doing work phase. Understandable, as 2DV managed to consume the main daylight hours with painful discussion, and such a large team has various different commitments and expectations of work.

However, I believe that any leading or dominant voice in a meeting and should also bear a greater weight of responsibility in leading in action as well. Walk your talk.

How did we even get out of that meeting mess?

A few hours in, I realised this wasn’t going to work out. It was just painful to be in the meeting. I paid attention throughout to other teammates, and had identified two (Julia and Daniel) who gave good vibes and provided better opinions whenever they had a chance to speak. They were also uni students, and I thought we might spark some fresh ideas together.

I privately messaged each of them, and the facilitator for a green-light – asking if us three could jump into a seperate huddle call to brainstorm independently. We did so, and each of us came out ~20 minutes later with an idea.

I then reached out and invited two others who had industry experience. And who I had observed giving infrequent, but thoughtful input in the big meeting. I invited them to join our trio-call one-by-one, and we went around pitching our ideas for a quick-sense check.

Then I pulled us all back into the big group call, and asked if we could pitch our ideas and take a vote on the idea we wanted to work on since we’re running overtime.

My idea was an old idea I had watching Star Wars with my hard-of-hearing Granddad. We put it to a group vote with all the other ideas we had so far, and my idea captured 50% of the team’s votes 🔥

Okay, cool - now we can start the work right?

Unfortunately not – I’ll continue this story in another article. seed (on Buy-in, and Empathy)

Takeaways

Main point:, a 20 minute huddle with 3 people produced desired outcomes more efficiently than 7 hours with 15 people.

What made my meetings work:

• Keep it short: those constraints are good. The task at hand will always compress or expands to fill the time given to it
• Keep it small: relevant and necessary for the minimum people attending
• Expand/compress scope as needed: add/remove the right people for specific input at the right time
• Return to wider team with outcomes: at each layer, once outcomes are achieved from the meeting, those takeaways can be brought back to wider team

This became the basis of a sync-up for me, and seriously taught me the potential pain otherwise.