Engineering Practice: Architecture Review Across Teams

At Tableau, the Tableau Mobile team has around 30 people across 3 scrum teams. We mainly work on code in Tableau Mobile itself, but some folks also work on code in Tableau Desktop and the front & back end of Tableau Server.

The Problem

Top-down communication was working fine, but we wanted to facilitate more engineer-to-engineer communication.

Our rough goals were to:

• Increase communication across teams
• Have a place for discussing code and code reviews in depth. Sometimes code reviews get frothy, so we wanted a place to discuss them in real-time like humans
• Prevent frothy code reviews in the first place by discussing significant changes before they’re coded up
• Increase awareness of technical changes affecting multiple teams
• Disseminate engineering best practices

It’s an old problem: how do you get information out of one person’s head and into everyone else’s? Ask a software engineer to give a one-hour brown bag presentation, scheduled weeks in advance? How does anyone even know what information would be useful?

Our Solution

The core of our solution has been a twice-weekly architecture meeting. “Architecture” isn’t quite the right term to use if we look at it deeply, but the term can cover a wide range of use cases, so we go with it.

We’ve iterated on this approach over time; here’s what has worked well for the past few years:

• Open Topics: Anybody can raise any engineering-related topic, of any length.
• Open to All: Everybody on every mobile team, regardless of role, is invited to attend. In practice, a dozen or so people regularly attend.
• Variable Topic Length: Topics can be quick notices or can fill the whole hour, as needed.
• Variable Formality: Topics do not need to include official slides: they could be discussion-only, screen-sharing an IDE, dissecting a log file, etc. Slides are great if the presenter feels they’ll help.
• Last-Minute Topics: Topics do not need to be declared ahead of time. Feel free to show up and say “I have a topic”.
• Scheduled Topics: Topics can be declared ahead of time if desired: post in the Mobile Slack channel with the topic and any pre-reading that you hope people will read ahead of time. This could be hours or days before the meeting. In practice, this is used for bigger topics and acts as an informal reservation system. Posting a topic ahead of time also increases meeting attendance.
• Cancel When Empty: We cancel the meeting if nobody has brought up any topics after a 5 minute grace period. Early on the meetings were rarely canceled because we had a backlog of topics to get through. These days, it’s canceled maybe ~40% of the time.
• Optional Attendance: It is openly OK to leave the meeting if the topic isn’t relevant to you.

Lots of Topics

Because anyone can present any topic, the variety of presentations has been fantastic. The topics wind up covering a lot of ground — examples include:

• Here’s a sticky situation I’d like to dig in to and for us to come to a decision on
• I just wrapped up a deep investigation and I’d like to disseminate this information
• We’re looking at changing this library that other teams use, here are the tradeoffs
• We’re looking at implementing some new functionality, does this approach look reasonable
• I have a big code review coming shortly, I’d like to walk people through the changes in person
• I found an interesting new debugging/IDE tool/feature, here’s how it works
• Here are some new UX designs that will affect multiple teams
• A guest speaker will present on non-mobile area X, because we’re going to need to integrate with X.

This is where the informality helps. If we required schedules and formal presentations, some of these topics would be lost. Not everyone enjoys putting slides together, and without this architecture meeting outlet, the information wouldn’t get disseminated. “I’d like to walk everyone through a big code review” feels like a lousy brown bag session, but works great for these architecture meetings.

Failed Experiments

We’ve tried several iterations on our formula over time, and some of our less successful experiments included:

• Limiting the attendance: Inviting everybody just makes for better decisions and outcomes. There was some concern early on that, say, PMs would infect the technical discussions with PM words like “deliverables” and “desirements”…but that never happened. PMs know the meeting might be a white-knuckle ride through IDE-land and log dissection, but they honor this and tough it out. Or they leave the meeting, which is totally OK too.
• Requiring declared topics: Requiring people to post topics ahead of time to Slack/email drastically reduced the number of presenters and topics.
• Reducing meeting frequency: Twice a week means there’s always an architecture meeting around the corner where you can present your topic.
• Separate “community” meetings: We tried this too, sort of like a brown bag approach, with topics and slides and some officialness. Participation waned, and it wasn’t clear what the “community” meeting provided beyond what the flexible architecture meeting did.

Benefits

This combination of openness and schedule flexibility has worked out really well. It’s worked so well over the past few years that we’ve basically stopped tweaking the concept. Some of the benefits we’ve seen:

• More Design Discussions: Most (all?) designs of even moderate complexity have been discussed by multiple people from different teams
• More Change Awareness: More people are aware of upcoming changes to design and code
• Information Spreads Faster: More people understand topics & concepts that were previously known by only one person
• Shared Best Practices: Tools & practices are shared more broadly & quickly throughout the teams
• Better Code Reviews: Code reviews are less contentious, contain fewer surprises, and are more efficient for everyone involved

Steal This Meeting

Hopefully some elements of this meeting concept are stealable for your teams!