When looking at a product like Swarmia, it can be hard to see how to put the theory into practice. In this post, I’ll share how we use Swarmia across our engineering organization to work better together — from the daily flow of individual engineers to company-wide visibility into strategic projects.
Since we first published this article in 2022, we’ve more than doubled our headcount, and our software engineers are now working across multiple product teams. That growth has changed how we work, but the fundamentals remain the same: we still focus on getting code through smoothly, understanding where our time goes, and continuously improving as a team.
One thing worth noting before we get into the details: not every team uses Swarmia in exactly the same way, and that’s how it should be. Different teams have different workflows and priorities, and Swarmia adapts to how each team wants to work rather than forcing everyone into the same process.
With that said, let’s get into how we use Swarmia at Swarmia.
The basic building block of any software company is getting your code smoothly through the code review process and into production. If this part doesn’t work, any other improvements you attempt will have limited impact.
At Swarmia, our average PR cycle time for the entire company at the time of writing (measured from the first commit to code deployed to production) is 29 hours. We’re still pretty happy with this number — especially as we’ve doubled in size since 2022.
Swarmia helps us achieve this speed in two ways: Slack notifications and the pull requests view.
The Slack notifications give you instant feedback when you need to take action on a PR, which greatly reduces waiting times. In addition to personal notifications, we also receive team-level notifications when a new PR is ready for review. We have a culture where anyone can review any PR within their team, which makes getting reviews faster and effectively avoids knowledge silos.
The pull requests view is another way for us to stay on top of our pull requests. It shows all PRs from our team members across all repositories, separated from noise like bot-created dependency upgrade PRs. The PRs are divided into sections based on where they are in the review process, which makes it easy to understand what needs attention right now.
We’re actively looking to help out with reviews, so whenever we have time between tasks, we just come to this bookmarked page and look at the Review section to find open PRs to review.
As we’ve grown to multiple product teams, cross-team collaboration has naturally become more important. When someone touches code owned by another team, that team automatically gets notified through our GitHub code owners setup working with Swarmia’s Slack integration.
For example, if I edit code in a file that concerns our Okta integration (which team Yoshi owns), GitHub automatically requests a review from team Yoshi, and they get a notification in their Slack channel. This removes the need to manually ping people — they’re always automatically in the loop. And while we don’t require that someone from the owning team must approve before merging, it is a good way of keeping teams informed about changes in their areas.
The investment balance view has been an extremely useful tool for the wider team. It’s a super simple and accurate way for the whole company to see where our engineering time is going.
We’ve always followed the balance framework approach, where work is divided into mandatory “keeping the lights on” work and elective investments (building new stuff, improving existing stuff, or increasing productivity). We’ve also expanded our use of investment balance to new breakdowns like planned vs. reactive work and product use cases.
In the past, our biggest challenge was maintaining enough focus on building new features. As engineers, we often gravitate toward making the code nicer to work with, and sometimes lose focus on customer-facing goals. This view helps us see when the balance is slipping and course-correct to ensure we’re also shipping new features to customers.
The way we think about investment balance has evolved as we’ve grown to multiple product teams. We can now see different investment patterns across teams, which helps leadership make better decisions about resource allocation without micromanaging individual teams.
As we’ve scaled, tracking cross-team strategic projects has become more important. Some of our teams use the initiatives view heavily for tracking project progress, while others still prefer the work log view — it depends on the type of work and how the team likes to operate.
Leadership uses initiatives differently, focusing on cross-team progress and whether strategic projects are on track. The view gives them visibility without requiring engineers to write status updates or sit through meetings.
We host bi-weekly retrospectives in the engineering teams. We usually follow different formats depending on what we want to focus on.
For regular retros, we look at the work we’ve done in the past two weeks using views like work log, initiatives, and investment balance. It’s surprisingly hard to remember what the team worked on in just two weeks, so having this data visible makes our discussions much more grounded.
We also go through our working agreements, though we’re usually pretty good at staying on track with them since we already get notified about exceptions in our daily digest.
Survey retros have become a regular practice since we launched developer experience surveys. Whenever we conduct a survey, teams hold a dedicated retro to go through the results. We look at categories where we’re doing well and discuss why, and we look at areas with lower scores to decide if we want to take action. This gives us qualitative insights that complement our system metrics.
Epic retros also happen when we complete bigger batches of work. We use the initiatives view to open all the sub-issues and look for patterns. If something took much longer than expected, we ask why and discuss how to avoid similar issues in the future.
I’ll be honest, we’re not actively tracking AI adoption metrics yet. Even though we build AI impact measurement capabilities for our customers, internally we’re very much in the experimentation phase.
What we do care about is how people feel about AI tools. In our developer experience surveys, we include survey questions about AI tools like “I use AI tools in most of my programming work” and “I rarely notice AI tools cause quality issues in our team.” This sentiment data is far more valuable for understanding whether the tools actually help — and these survey answers feed back into our retrospective discussions.
Overall, we have folks in both the AI ‘power user’ and the AI skeptic camp on the team, and that diversity of perspective is valuable as we experiment with where AI makes sense in our development process. When we’re ready to track AI impact more formally, we’ll be able to use Swarmia for that, too.
Running developer experience surveys has become a part of our rhythm. We use survey results to identify friction points and connect responses to system metrics throughout the app.
Surveys help us have better discussions, and make better decisions. Instead of assuming we know what’s frustrating people, we can see patterns across teams and dig into specific issues. For example, if one team scores lower on “Deploying code is simple,” we can investigate whether it’s a tooling problem, a process problem, or something else entirely.
Using our own survey feature as customer zero has been valuable, and it’s helped us understand what works well and where we need to improve the product.
Every Friday at Swarmia, we host demos for the whole company to show what we’ve been working on.
We use the work log and investment balance views to give everyone a quick understanding of what types of work have been happening and what different teams have been working on at a glance.
The work log shows the detailed view of recent work, while investment balance helps communicate the mix of new features, improvements, and maintenance work across teams.
This visibility helps everyone stay connected to what’s happening across the company, even as we’ve grown to multiple product teams working on different parts of the product.
It’s one of those practices that gets harder to maintain as you grow, but having Swarmia makes it easy — no one needs to prepare slides or write summaries.
Hopefully this post gave you some inspiration, ideas, and perhaps a starting point on how you could use Swarmia in your organization.
But remember: every team is different, and Swarmia is flexible. Take what resonates, adapt what doesn’t, and make it work for your team.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
