Six months ago I introduced Swarmia into our engineering ecosystem—not out of curiosity alone, but out of need. As I reflected in The CTO Playbook, when a tech team grows, when its output becomes a mix of many intertwined signals, what separates the effective from the overloaded isn’t just more processes—it’s clarity. It’s the ability to see trends, to link effort to outcome, to make leadership about enabling rather than inspecting.
In our case the challenge was clear: our teams were shipping features, yes, but I sensed that the cost, the context, the collaborative friction, and the throughput were not optimally aligned. The manual dashboards I kept maintained the status quo but did nothing for insight, nothing that the teams could lean into. Enter Swarmia—through a recommendation from ChatGPT and Google searches—which promised a different approach.
What I discovered
Swarmia has become indispensable in three areas:
Team-level visibility, not individual surveillance.
This matters deeply because in The CTO Playbook I emphasise that leadership must shift from controlling individuals to shaping team dynamics and capability. Swarmia’s metrics do exactly that: pull request lead times, trend direction, tool adoption (for instance seeing how Cursor is picked up), FTE time spent on tasks. These insights allowed me to ask better questions—“Are we collaborating in the right way?” “Is our throughput going where the business needs?”—rather than “Who is slacking?” That subtle shift transforms culture.
Alignment of capacity and business outcomes.
The release of Swarmia’s FTE-tracking feature was, for me, a leap. I could retrospectively view how much time was being spent on certain tasks, how it mapped back to business goals, and surface where we were misallocating effort. This echoes Build’s triad: business outcomes, developer productivity, developer experience. With Swarmia I finally had a tool that didn’t just track tickets—it surfaced story about capacity, direction, and team effort.
Tool integration that supports the reality of engineering.
Because we use GitHub, we could onboard reasonably straightforwardly (for someone with GitHub experience). The value came quickly: I could report back to product leadership with meaningful metrics at the team level, show trends rather than raw numbers, and avoid drowning in data. The shift is from “tickets closed” to “teams moving in the right direction”.
What wasn’t perfect
No system is flawless, and Swarmia revealed some practical frictions which offered leadership lessons:
- Onboarding new developers (especially external or less-GitHub-savvy) is weak. The tool assumes a certain fluency and GitHub org membership. So when we added external contributors or new joiners who weren’t deeply familiar with our GitHub organisation, the friction was real: invites that confused them, login failure when not part of the org, initial lack of clarity about “what am I signing up for?”.
- The invitation and access model required each contributor to join our main GitHub org—a constraint that in our context (many external contributors, branch-specific work) became unnecessarily heavy.
From a leadership perspective, these are not just UX issues—they reveal a truth: even the best metrics won’t matter if your team can’t engage easily. In The CTO Playbook, I write about onboarding not as access, but as alignment: “Onboarding is not about rights—it’s about understanding purpose and place.” So here the tool and process need to reflect that.
How this aligns with the leadership model I advocate
In The CTO Playbook, I argue that a CTO’s key task is not to build all the code, but to create a tech team environment where people do great work together. That means:
- Ensuring visibility (but not micromanagement)
- Connecting engineering work to business results
- Designing systems and processes that enable—not entangle
- Measuring the right things (and enabling the right conversation)
Swarmia supports all of these. It gives visibility; it connects team effort to outcome; it allows us to avoid focusing on “how many commits” and instead ask “how much value is flowing and where is friction?”.
And from Build, the authors reinforce this mindset: effectiveness is not only about speed or metrics in isolation—it’s about business outcomes, developer productivity, and developer experience. By applying Swarmia in this way, I feel I’m executing that trifecta: enabling my teams to deliver business value, track productivity meaningfully, and stay engaged by focusing on team-based insight, not individual ranking.
What I’ve learned and would recommend to other CTOs (or anyone leading Tech-teams)
If you’re in a similar situation—leading a growing engineering org, needing insight without falling into command-and-control—I’d share a few practical lessons:
- Don’t deploy the tool then forget the culture. Because metrics only support conversations. Use them to ask “What is slowing us down?” “What collaboration patterns are emerging?” not “Why is person X slower?”
- Think onboarding from the contributor’s viewpoint. If you invite external developers or new joiners who don’t touch the full org—you’ll need clear language, clear purpose, and simple steps to get started. We had to build short “why we use this” intro docs to get them engaged.
- Set expectations for insight, not oversight. Frame the tool as helping teams improve—not as a management dashboard to check boxes. That changes the tone and preserves trust.
- Use the FTE and trend features to bridge the gap between engineering work and business discussion. When you can say “We spent X days on feature A, here is how that aligned to business goal Y”, you do more than report—you lead strategically.
- Recognise the interplay between developer experience and productivity. If onboarding is clunky, you burden the experience, and productivity follows. Fixing friction is leadership work, not just vendor tuning.
Final thoughts
My score for Swarmia is 10/10, and it’s not a marketing blur. It’s because the tool lives up to what I believe: leadership in tech is about enabling teams, creating clarity, and linking work to outcomes. It’s about the space between people, process and purpose—and any tool that supports that is valuable.
If you are a CTO, Head of Engineering, or tech leader wrestling with how to monitor and lead your organisation without losing heart or culture—Swarmia is one of the few tools I’ve found that truly scales at the team-level, not just task-level. And when you combine it with the mindset in The CTO Playbook, and the frameworks in Build, you get more than metrics: you get leverage.
If you want to explore how to integrate such tooling into your leadership framework, how to surface the right questions for your teams, or how to drive culture alongside measurement—feel free to reach out to me or visit ctotmc.com. I’m happy to exchange ideas and talk through how to lead with clarity, strategy and shared ownership.
— Robert Mejlerö, author of The CTO Playbook, CTO & tech leader developing high-impact engineering teams.
Switzerland.