This is Part IV in a series on how Automated Insights revamped its internal organizational structure and processes. Start at the beginning with Part I.
In Part III, I went into some detail about how we structured Squads for the whole company. In this article I’m going to talk about our Agile-inspired workflow.
As a guiding principle, we used the Scientific Method to provide a base to build from. Our version goes like this:
- Identify a problem using data
- Propose a way to improve a Squad metric related to the problem (hypothesis)
- Build a quick solution (experiment)
- Check the metric to evaluate impact
- Iterate and improve
A Culture of Experimentation is Key
The Scientific Method is based on the idea of using experiments to tests hypotheses. Finding answers through experimentation is something I’ve pushed at Automated Insights from the very beginning. I often talk about how Automated Insights is one big experiment. Because of my pessimism about traditional corporate culture, we experiment with virtually everything we do. If it works, we’ll keep it. If it doesn’t, we move on to the next experiment. When we adopted the Spotify Squad model for our engineering organization, it was an experiment. It turned out to be a successful one.
We stressed with our Squads that experiments are the most important aspect of what we do. Build quick solutions to validate a hypothesis, then iterate, rebuild, or move on based on the results.
A related concept that I’ve stressed with the Squads is “small over big.” I’d rather have small teams over big teams. Small meetings over big meetings. Small processes over big processes. Small solutions over big solutions. It’s a simple, almost trivial, heuristic, but it’s one that I find works well most of the time. Especially when you are trying to scale, small over big is almost always a better answer.
Our Sprint Cycle
We chose two weeks for the length of our sprints. Why two weeks? It was long enough to split up work and make good progress, but short enough to allow Squads to stay agile and iterate.
Some organizations use longer or shorter sprint cycles. Two weeks has worked for us. I can’t imagine having it any shorter because that means the planning/demo meetings are taking a larger percentage of the sprint (one out of five days instead of one out of ten days). We’ve discussed the possibility of extending it to three weeks, which would make for a good experiment at some point.
For our team members that were not previously familiar with Agile (especially those in non-engineering groups like HR, Finance, etc.) we had to stress that not everything has to be completed in two weeks. A “project” could take two months and that’s totally acceptable, but you’d be hard pressed to convince me that a two month project can’t be broken up into several one or two week chunks of work. And if it can’t, then how can we possibly track progress and estimate with any certainty?
It’s important to understand that two weeks is simply a progress measure for the work, it’s not a rigid timeframe that we must make every project or feature timeline conform to. That said, I often hear someone quoting that it will take “two more sprints worth of work” or “a sprint and a half”. It’s pretty natural to think of how long something will take in terms of the sprint duration. However, it is an imprecise measure (as is often the case with software development), which is why I’m less keen on having longer sprint cycles. Two sprints could mean 4 weeks or maybe it means 3.75 weeks or even 3.5 weeks. If we had three week sprints, it would be even more imprecise to say something is a “sprint” worth of work.
With a two week sprint duration, that means we get (re)organized every two weeks. Our big planning day is on Monday (i.e., every other Monday). On those Mondays we have two key activities: company-wide demo meeting and individual Squad planning sessions.
Company-wide Demo Meeting
Prior to implementing Squads, I scheduled one-on-ones with everyone in the company. That meant roughly fifty, thirty minute one-on-ones over a couple weeks. This was just a one time event so I could get a quick pulse on the company. The most consistent issue I heard was that as we got bigger, it was harder to keep track of what everyone was working on. And eventually they’d see something new going live and was surprised because they didn’t know someone was working on it.
Our bi-weekly demo meeting solves that issue. Now, every other Monday, I require everyone get up and spend up to two minutes either showing off something they worked on over the last sprint (i.e. demoing) or giving an update on the things they did. It’s the most important meeting we have at the company.
Initially, we scheduled this meeting for three hours. With 50 people giving two minute updates each plus setup time, we thought it could go three hours. Fortunately, they’ve gone two hours consistently, especially as we gotten better at the hand-offs between each person. We’ve also moved from everyone having presentations on their computer, to a central repository (intranet) of slides and docs that we can show from a single computer. Instead of developers having a terminal window open to show off their work, we use animated gifs that highlight the key code or features they want to talk about.
There are a few things to mention about the Demo meeting. I’m not a fan of meetings in general, so it’s a little ironic that I condone and even advocate everyone attending the bi-weekly Demo meeting. I do not require everyone attend the Demo meeting, but I encourage it. We record the full meeting so it can be watched later if you can’t attend the whole thing. I do require that everyone be present to do their demo. Feel free to pop in and out, but just don’t miss your demo slot.
Why do I want everyone to demo? There are a bunch of good reasons and virtually no bad ones. First, at a company like Automated Insights, we need everyone to be able to communicate their ideas and thoughts clearly. If you can’t get up in front of your friends and colleagues for two minutes and talk about what you did for the last two weeks, you are likely not going to be a very effective employee. I’m not saying it will be easy for everyone due to fears of public speaking, but we have a round of applause after each demo presentation and are cutting jokes throughout the two hours, so it’s a pretty low stress environment.
It also provides a little extra incentive to put your best foot forward during each sprint. You don’t want to get up in front of the whole company and try to bluff your way through your update. It’s much easier if you can show something interesting. Early on some people would come to me and say “But I don’t have anything to show”. That’s fine, just give a quick summary on the key features, bugs, processes, servers, meetings, interactions, discussions, trips, whatever that you were involved with. Two weeks is long enough that everyone should have done something that is worth mentioning even if that was “refactored the users page” or “evaluated our HRMS options.” I much prefer employees show us something they worked on, but it’s ok to simply tell us if it is not possible to show it. But I strongly encourage showing it.
An unexpected side affect of the Demo meeting is it has turned into a forum for employees to show photos from vacations or fun excursions they’ve gone on. It’s not uncommon for someone to take a minute to show pictures from a recent trip or something funny their kid did over the weekend or sharing news about a new wedding engagement.
In summary, our Demo meeting is a 2 hour all-hands meeting that’s optional but strongly encouraged where each employee spends up to 2 minutes updating the company on their recent work and personal events. Not a single person has come to me in the last year to say they feel disconnected from other parts of the company.
Sprint Planning Meetings
After the Demo meeting, the Squads are encouraged to get together to start planning out the next sprint. The sprint planning meetings can last anywhere from 30–60 minutes. Early on when we were just starting, some needed 90 minutes.
We aren’t rigid about how Sprint Planning meetings are run. Autonomy is a key feature of the Squad model, so we stay away from dictating much about how Squads do their thing. We give them what we consider are best practices, but leave it up to them to implement.
The goal for the planning meetings is to leave with a plan for the next two weeks. The Tribe Leader for the Squad generally attends so she can stay in the loop with the Squad and nudge a Squad in a particular direction if needed.
The basic template agenda for a Sprint Planning meeting goes like this:
- Metrics: review the Squad’s metrics and general trends
- Experiment review: discuss in-progress or completed experiments and any impact on the metrics
- Problem ranking: prioritize next problems to work on
- Feature planning: as a group, develop solutions to those problems
- Retro: discuss roadblocks and ways to improve the sprint process
Most Squads use Trello to keep track of their work. Here again, we have a basic template we use for each Squad’s Trello board, but they can deviate from it if needed.
Sample Squad Trello Board
Other Squad Meetings
We recommend that Squads have one or two Standup meetings a week to check-in on progress. These are quick meetings that can help ensure everyone stays in sync and is knowledgeable about any roadblocks. Some Squad Standups are in-person and some are done virtually via Slack. We’ve seen a lot of experimentation with different formats. In my experience, Standups rarely last without tweaking periodically. They can get a little mundane (“I have nothing to update since last Standup”) so often Squads are trying to tweak the format to make them more effective.
Another type of Squad meeting that is pretty common is a design session for the Engineering-oriented Squads or just general brainstorming meetings for non-engineering Squads. These are necessary when you’ve decided to build a new feature or implement a new “thing” during the Sprint Planning meeting, but need to spend more time specing it out. Sometimes the results of a design session will require a second, briefer Squad Planning meeting once additional details are known about how much effort a certain feature will take to implement.
Squad Leader Meeting
From the beginning, we had an hour long Squad Leader meeting the Tuesday following the Demo meeting (so every other Tuesday). Initially, the purpose of the meeting was to answer questions Squad Leaders had about the new Squad model as well as get their feedback about what was working or not working.
Once everyone was comfortable with the Squad model, the agenda for the meeting settled into this:
- Update on metrics: changes and trends; issues and difficulties in moving the numbers
- Impact on the System: changes in how the squad is impacting the system; potential changes to metrics or measurement
- Intra-Squad communication: this sprint’s activities that may impact other squads; future activities that may impact or require collaboration from other squads
- Proposed process/squad changes: discuss any resource gaps or surpluses within Squads as well as any upcoming Squad resource changes
- Special topics: how to have hard conversations; best practices for managing performance; etc.
As we’ve reached a stasis, the Squad Leader meeting has turned into more of a status meeting (which isn’t necessarily a good thing), so we’ve discussed the possibility of moving the meeting to a wiki on the intranet that can be done virtually instead of in-person.
Tribe Leader Meeting
Similar to the Squad Leader meeting, the Tribe Leader meeting has been a forum for the five Tribe leaders to get together every couple weeks. Unlike the Squad Leader meeting, this meeting has been more sporadic in nature and we went several months without having it at all. Our Tribe Leaders are already pretty connected with each other so a separate meeting isn’t usually necessarily. Occasionally, if we start to feel disconnected or if there are particular issues we need the Tribe Leaders to discuss, we’ll schedule an ad-hoc meeting.
Guild Meetings
As I described in Part III, we have cross-Squad interest groups called Guilds. There is a Developer Guild, a Designers Guild, etc. Each Guild holds a meeting periodically to get the Guild members together to discuss relevant topics. We haven’t put in place any guidelines for how Guild meetings should work. They are self-organizing and self-governing.
The Developer Guild has been our most successful Guild to date. They meet every two weeks and keep a running list of prioritized topics to discuss. Also, they have one or more people do quick Lightning Talks where they show something cool they’ve been working on or a new product/API/tool they’ve been using. The Developer Guild Leader has been great about sending out notes from the meeting to the other Squad Leaders to keep them in the loop.
Uniformity, but with Autonomy
As the CEO with a traditional organization model, keeping track of how all the different groups in the company operated was challenging, especially as we grew. It was also difficult to know how everyone was performing and contributing to the company goals. By having everyone adopt the same basic operating model and cadence, it makes it a lot easier to understand what any one person or group is working on and when work is expected to be done.
While we have uniformity in terms of the basic structure and operating model, within each Tribe and Squad there is autonomy to tweak the day-to-day processes as needed. This has provided the structure the leadership teams needs to run the company, but the freedom our employees need to work the way that best suits their team.
Next up in Part V, I’m going to talk about how the traditional role of “manager” is broken and how we split it apart inside of Ai.
If you like this article, please let me know by clicking the ❤️ button below!