How we might operate Tuist

You might have seen me talking about Atlas, the operations platform we’re building at Tuist. I have this engineer’s obsession with optimizing things, and not just builds and test runs. I also keep thinking about how we operate the company itself.

Recently I started using Amp and got hooked. There are a lot of good ideas in it. I’ve also been playing with Grokbot, and I’ve been picking up patterns from each of these apps. On the side we added one more primitive to Atlas, compute, which felt necessary for the way we want to work. Now that the pieces are in place, we’re starting to see where this could go.

I’ve been following the conversation around software factories, where you simulate a team and bots take tickets. The more I think about it, the less it clicks with how we work. I like how Shopify approaches this kind of thing. Instead of jumping on the factory idea and automating everything possible, you look at how you actually want to work and build from there. When I do that, I land somewhere different.

The model I think we’ll end up with has no tickets, no tasks, no Linear. Just signals, things that need to be acted on. A signal can be an alert from observability, a spike in errors, a request from a customer, or an idea from one of us sitting in a queue that people can join. Ticket systems existed because execution was the bottleneck. I don’t think that’s true anymore.

Each signal becomes a thread, scoped to that one piece of work. Threads can be created automatically or by hand, and people join them alongside agents that have all the context of the company. Think of how we run incidents. There’s a channel scoped to the incident, some people jump in, and the system gets back to normal. I want that for every kind of work. When a thread finishes, it ends with a summary and artifacts, like a pull request or a postmortem, and then we move on. Something sorts the threads by priority, but there’s no ticket system behind it.

Here’s an example. We detect a spike in errors, and the agent sees that an enterprise account is affected. It classifies how important that account is, which decides how high this goes. It starts the investigation and invites the right people into the thread. It could go all the way to an open PR, or stop at an initial investigation. It doesn’t need to be critical either. Say every day we pull data on our prospects and leads, and a customer stops using a feature they need in order to renew. A thread opens, a couple of us get pulled in, and we work it to some kind of result.

For this to work, it has to use what’s native to each platform. Notifications are the obvious one, which is why I started building a mobile version of Atlas. I want a ping when something needs me, and then I want to jump in from a phone, a desktop app, or by voice. Some of my best thinking happens on the metro to work, talking through accounts and things that need attention. Those conversations mix finances, sales, product, and engineering, and they should all live in the same place.

This is also why I think Slack mostly goes away for us, or stays only for customers. We’d keep one team channel, something like a WhatsApp group, and everything else happens in threads. I honestly think the way we operate could run entirely on Atlas, and some of these ideas could eventually make it into Tuist.

One more thing I love about Amp is how they use feature flags. They give agents live telemetry and let them attribute errors to accounts, projects, and flags, so an agent can tell when something is probably caused by a flag being turned on. I think that’s beautiful, and we’re moving in a similar direction. We do fewer peer reviews. We trust each other, we trust the system, and we keep iterating on it so we can move faster.

I’m proud of what we’ve come up with. Investing in Atlas, and soon in a mobile app for Tuist, feels like going back to our roots. We’re strong on mobile and we love it. I think we’ll bring something cool to our customers, our users, and the industry.