Mike Tria on the Un-SDLC

I asked Mike Tria what was working at Gusto now that AI had spread past engineering into product and design. He started with a product Gusto had just launched, Gusto Cofounder, an AI teammate for small business owners. “The fascinating thing about it, in addition to what it does, is how it was built. It was built by a very small team, four to five people.” He added: “Just four or five builders, we call them.” Then he answered the question I would have asked next: “I would have been extremely skeptical of an approach like this last year.”

Mike has been in technology for 23 years, most of them “between an engineer and a manager.” In the early or mid 2010s he ran his own startup selling back-office automation to bookkeeping firms and benefits brokers (”I just love that gnarly space”), and along the way he wrote his own tax software and double-entry accounting system. “I still use it to this day.”

After about eight years at Atlassian, where he ran the cloud platform underneath products like Jira, he missed small business: “I missed the hard, complicated space of compliance and regulation and all that kind of stuff. I found it fascinating.” He’s been Gusto’s CTO for three years. Gusto runs payroll, benefits, and health insurance enrollment for small businesses. “We are a highly regulated organization for very good reason,” he said. “In a lot of ways, small businesses trust us with helping them run their business.” Most of our conversation was about how people at a company like that are learning to work across roles, and the rest was about the bill.

Four or five builders

A year ago, Mike said, nobody would point a coding agent at a multi-million-line legacy codebase and expect it to refactor anything. That changed fast. Like a lot of companies, Gusto now has most of its engineers using agentic development every day, which he dates to about December. “We’ve instrumented the entire software development life cycle with AI, trying to eliminate situations where we would have handovers or just waiting on people.”

The Cofounder team built it “in a matter of weeks together.” What had changed since last year came in three parts: “We have a lot of context in our code base that the agents can pick up on, we have better controls and guardrails, and there’s more knowledge on how to do this correctly.” The models have improved too, but his answer focused on Gusto’s side of it: its codebase, its controls, and what its engineers have learned.

He called it “almost the un-SDLC”: “It’s sometimes faster to build the thing than to have a meeting to talk about the thing.” The way I heard it, the un-SDLC is about cutting out the handoffs, the “waiting on people” he’d mentioned earlier. When the same few people can design, build, and talk to customers, less of the work sits waiting for someone else. Getting there takes a lot of work on the SDLC itself, and Gusto has a whole team doing it. “They’re the SDLC team,” he said, “and they’re curating a set of golden skills, not just in engineering, product design, data.”

Blurring the roles

Cutting handoffs only works if people can cover more ground themselves, and that’s the other change Mike sees at Gusto. Gusto has people with the titles product manager, designer, and engineer, “but I wouldn’t take too much of that in terms of rigid lines of responsibility.” He described designs built by engineers and product managers “prototyping and vibe coding some stuff that works, too.”

He brought up a discussion that had been going around the industry. Engineers are getting so much more productive, the argument goes, that the old ratio of engineers to product and design, “call it seven to one or eight to one,” should move toward “three to one or two to one,” because now you need a lot more PMs and designers to keep up. His read, “at least from what we’ve seen,” runs the other way. “Engineers honestly can do a lot more. The tooling doesn’t just make it such that engineers can do engineering faster. It takes the hats off of the people in the software development life cycle and lets individuals do more.” A PM does product work faster and also steps “a bit into engineering, into data, into design.”

That was the second time he’d used the image. Back when he was describing what Gusto does for its customers, he said: “A small business owner wears a lot of hats. We prefer to at least take a few of those hats off of the customer such that they can focus on growing their business.”

It changes who he hires, too. “I absolutely see asking for more breadth in anyone in R&D over time.” Twenty-five years ago, hiring an engineer meant asking about compilers, because “they needed to make their own tools.” Tools now, “I don’t wanna say they’re free, but they have reduced in cost tremendously,” and “they don’t have to build the workshop anymore.” What’s left to hire for is “how much do they actually understand the business need?”

A high-speed train to the desert

That point about building the workshop runs against something I’ve heard a lot on this show, so I pushed on the opposite position. Other guests on the show have told me that if you’re serious about AI you have to build the factory, and spend something like 30 to 50 percent of your time on how your team uses the models. What did he make of that?

“I am all sorts of contrarian, aren’t I?” Then: “What is the purpose of a company, right? We exist for our customers.” He agreed that speed matters, and went further: “Speed ultimately becomes the greatest moat for an organization.” But “if you put all of it though into engineering, you’re going to run into issues, and I’m being specific here. You’re gonna run into problems around haste. You’re gonna run into, are we actually shipping the right thing? You might be shipping a lot of things. Are you shipping the right things?” User research, market understanding, and customer feedback need just as much energy. “Otherwise, you can end up with vanity stats and token maxing where things look really good on paper if you’re a CTO and you’re representing to your board, ‘Look, numbers go up.’ But if you’re not manifesting that as shipping value to your customers, you have built a quite an expensive but potentially wasteful machine.”

He wasn’t arguing for slowing down. “I’m not saying do it at the expense of trying to get more speed out of engineering. Certainly, absolutely do that. But I think more energy needs to go into the entire product life cycle.”

I offered him an image: a high-speed train to the middle of the desert doesn’t do you much good. “Yeah, you got it.” He added: “This is an area where we are still learning and still evolving... I would not claim to be an expert on it.” What he did feel comfortable saying was that the other crafts at Gusto weren’t waiting on engineering: “This isn’t just engineering pulling other crafts lagging along. They’re all pushing in different ways.”

Sufficient guardrails

Moving fast inside a regulated company takes what Mike called “sufficient guardrails in place to unlock that kind of speed.” Some guardrails at Gusto haven’t changed. For production code, one engineer’s work is still reviewed by another, “from a security and compliance perspective.” What changed was how much code there was to review. Gusto’s response was to support the reviewers, with “tooling to help make the job of human code reviews easier.”

The other problem at Gusto’s size is making sure everyone knows how things work. With “hundreds of engineers,” he said, “the problem starts to become different folks have different levels of information about what your developer tool chain looks like.” Tenured people know how things work; newer people might not. “So our promise has been less docs, less meetings, put it in the actual tool chain itself.”

One example is risk tiers, which engineers helped define through a survey. The part he wanted to geek out about was how an engineer finds out which tier a change falls in. “The way you would’ve done this in the past is a very large Google Doc. Someone reads the Google Doc, goes to a meeting, says, ‘I am tier three.’ Someone else says, ‘I disagree, you are tier two.’ Nowadays we really don’t ship Google Docs.” Instead, the AI tooling can “interview the engineer and inspect the repo to figure out what the right tier is.” The engineer gets the answer without waiting on anyone.

Spreading AI fluency

Tools only get people part of the way. Mike draws a line between using AI and being good at it. “There’s I think a big difference between adopting AI tools and being fluent at them.” You can learn the first from a training video. “Fluency, from what I’ve seen, can only really be developed at scale through pairing and peer work from others that are fluent.”

So in March, Gusto found its most AI-fluent engineers and sent them into other parts of R&D for a few days at a time, “kind of like forward deployed engineers.” They’d sit down with someone working a ticket from the backlog and say: “Let me show you how I would do this.” Of everything Gusto tried, he said, “that I would say has paid more dividends for us than anything else.” It built, he said, a base of people “that now wanted to share with others.”

The rest depends on the individual. “You have to be curious, as in you’re seeking out the information. You can’t expect that it will always be pushed to you because there is too much.” He doesn’t exempt himself: “I even fall into this trap sometimes myself, where I have to reset my expectations of how I build something.”

Avoiding token maxing

When I asked about cost, he started with an understatement: “We spend more than a dollar on this, I can tell you that.” At first the push was simply to get people using AI, because of “how much low-hanging fruit is out there.” Then came the industry debate about token maxing, people pushing up a usage number because it’s the number being watched. “I didn’t see this really at Gusto, which I’m very happy about.”

He doesn’t start by setting limits. “If you just show somebody how much they’re spending and what they’re spending it on, I have found engineers and just honestly most employees just do the right thing.” It’s a habit from reliability work: show a team its alerts, its postmortem action items, what its service costs, and engineers will fix things in their own sprints without being told to. “The first step should always be just show people. Just show them.”

Rules come later. Until then, he treats spending as a signal. “Sometimes tokens are a signal that you have inefficiency in how you’re building something.” If one engineer gets some amount of output at some token cost, and “another engineer is producing a similar amount of output at five times the token cost, that’s worth you digging into and understanding why that is the case. In some sense, it’s learning.” What he wants is to get past counting tokens, and past counting PRs, to measuring impact.

He’s also wary of going too far the other way. “No one’s gonna wanna work at a company where you’re really limited in which models you’re allowed to use or hard limits on the number of tokens because the company is trying to be, let’s say, penny-wise and pound-foolish.”

Pods built around customers

At the end I asked him to look a year out. “It’s hard for me to look more than three weeks ahead, but I will try and do my best at a year.” He pointed back to Cofounder. Over the next one or two years, he could see “highly autonomous teams with high agency and an ability to ship and experiment and learn with customers in a much faster way than perhaps the rigid software development life cycle most of us have been using for 20, 30 years” becoming a much larger share of how work gets done. “I think that can feel really empowering, honestly, for not just engineers, but anyone in those crafts, any builder there.” As for the models: “I don’t see them as replacing engineers at all. I see them as incredible tools that could augment an organization to be faster than it already is.”

Engineering teams have usually been organized around a piece of technology, the mobile team or the identity team. “I think a lot of those barriers are being broken down.” At Gusto, engineers who used to be front-end engineers are already full stack. What he sees are “more flexible and adaptable pods that are just focused on a customer problem.” His example: “Our job is customer logins. We focus on that. Whatever it takes.” To him, that’s “more empowering. It’s more thrilling. It’s kind of what engineering should have been all along.”

His last words were “Thanks for letting me be contrarian.” Going back over it, what he said about speed and what he said about customers fit together. The handoffs are shrinking. An engineer can design, a PM can prototype, and a team of four or five can carry a product from idea to customers. What hasn’t changed is the question of whether it’s the right thing to build. When the people on your team can work across roles like that, is the work pointed at a customer, or at a chart where the numbers go up?

High Output is brought to you by Maestro AI. Mike’s first move on token spend is to show people the data, then dig in when one engineer’s output costs five times as much as another’s. Maestro analyzes your org’s coding agent sessions to show where tokens go, how your teams work with agents, and what to improve. It works with Claude Code, Codex, and Cursor, and traces estimated cost to teams, initiatives, and linked PRs.

Visit https://getmaestro.ai to see inside your software factory.

Thank you for subscribing. Share this episode.