Am I the problem? Interviewing another team to find out.

Am I the problem? Interviewing another team to find out.

2026-08-07

I'd like to thank ngrok for supporting my "art" (weird ranty tech blog posts). They paid me to write this post, but the opinions and stories here are my own.

Many years ago, I was working in DevOps at Cisco. This was my first job out of college, so I had all the energy and wisdom of a sledgehammer. I fondly remember eating those Sysco burrito bowls from the Cisco cafeteria and getting flakes of fried tortilla all over my $3,000 laptop.

A good friend of mine referred me to that job, and it was great working with a friend, for a while at least. Unfortunately, we just argued about so much stuff: git branching strategy, fields on Jira tickets, the "definition of done", architecture, security, timelines, priorities, everything. After two years of this, I couldn't handle it anymore. I left that job, got a therapist, and lost contact with that friend.

Have you had your fair share of technical arguments? With software being so abstract, I feel like there are so many abstract hills to die on. But maybe that's just me? Or just the teams I'm on? There's one sure-fire way to find out: interviewing a similar team at another company. Surely this simple activity won't cause an existential crisis and recontextualize the last few years of my life or anything.

Soir Bleu (1914) by Edward Hopper.

I work on an infra team as my day job, but back in April, I got an opportunity to interview the infra team at ngrok. Y'know, the thing that lets you serve a website on localhost? Lately they've diversified into other developer networking tools. Anyway, my plan was to write about how other teams approach technical disagreements, since my past work experience has involved a lot of those. Once we sorted out conflicts with our respective on-call rotations, I met with all four of them and ended up with thirteen pages of notes.

Unless you're a consultant, it's pretty rare for us to meet people doing our same job in their natural habitat. You might meet some domesticated tech workers at a conference, showing off their tricks in fancy slide shows. Always presenting solved problems, while the unsolved problems remain, like worms under an unturned rock. So I was excited to enter a parallel dimension and talk to another infra team, which mirrored my own team in many ways.

NameFav emojiInterests<br>JamesGreen builds, DevEx, cats<br>StacksOwnership, standardization, infra<br>AlexPragmatism, Crucial Conversations, infra<br>SabrinaStandardization, CI/CD, tennis

My first interview was with James , who had been with the company for four years. He's into photography, cat fostering, and sushi, an extremely synergistic set of hobbies. He's fostered hundreds of cats, sometimes as many as seven at a time. His Slack display name right now is literally "Seven Cats in a Trenchcoat". To feed all those hungry mouths, he keeps the developers happy by working on pipelines and other developer tooling.

How was I supposed to get a guy who has room in his heart for hundreds of cats to spill the tea about workplace conflicts? I was up for the challenge. James brought up that the infra team recently had a discussion about whether to adopt Argo Rollouts or whether to build a custom in-house tool, augmenting their existing Buildkite CI/CD setup. This must be it! We found some conflict. In my notes, I created a subheading called "Argo-gate" and eagerly pressed James for more details.

The context is that ngrok has a tricky update rollout process. They have a golang service called Mux which runs in each region and is holding hundreds of thousands of TCP connections. Replacing this golang process with a new one requires waiting several hours for connections to drain. In the early days, this update process was controlled by a script running on a developer's laptop. If their wifi cut out, the update would fail. Anything was better than that, so they ended up with the foundations of their current Buildkite CI/CD system. But they aren't super happy with it now that the company has more products using that same system. The team agrees the CI/CD needs improving, but disagree on how to do it. More custom tooling around Buildkite would be easier to adopt, but using Argo would force a rewrite of those shaky foundations.

"Who is on each side?" I asked, like a bloodthirsty Roman Vestal asking about a gladiator bout. It's not so simple, according to James.

Pollice Verso (1872) by Jean-Léon Gérôme.

Stacks doesn't want to burn innovation tokens on custom tooling, so prefers Argo but understands there are other factors at play.

Alex , ever the pragmatist, thinks it'd be too difficult to gather buy-in for a rewrite, preferring to build on the existing system. Alex and Stacks have been friends since high school, so it's not like they are opposing factions.

Sabrina hasn't used Argo before, but usually sides with Stacks on the importance of standards. She's...