Am I the problem? Interviewing another team to find out
Am I the problem? Interviewing another team to find out
我是那个问题所在吗？通过采访另一个团队来寻找答案
2026-08-07 2026年8月7日
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. 我要感谢 ngrok 对我“艺术创作”（那些古怪且充满抱怨的技术博客文章）的支持。他们付费让我撰写这篇文章，但文中的观点和故事均属我个人所有。
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. 多年前，我在思科（Cisco）从事 DevOps 工作。这是我大学毕业后的第一份工作，当时我拥有大锤般的精力和智慧。我至今仍怀念在思科食堂吃那些 Sysco 墨西哥卷饼碗的日子，当时我总是把炸玉米饼的碎屑弄得我那台 3000 美元的笔记本电脑上到处都是。
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. 我的一位好友推荐我去了那份工作，能和朋友一起工作感觉很棒，至少起初是这样。不幸的是，我们对太多事情争论不休：Git 分支策略、Jira 工单字段、“完成的定义”、架构、安全、时间表、优先级，几乎所有事情。两年后，我实在无法忍受了。我辞职了，找了心理咨询师，也和那位朋友断了联系。
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. 爱德华·霍普的《蓝色之夜》（1914）。
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. 我的本职工作是在一个基础设施团队，但在四月份，我有机会采访了 ngrok 的基础设施团队。你知道的，就是那个让你能在本地主机（localhost）上运行网站的服务？最近他们已经多元化发展，推出了其他开发者网络工具。总之，我的计划是写写其他团队是如何处理技术分歧的，因为我过去的工作经历中涉及了太多此类冲突。在协调好我们各自的轮班时间后，我与他们四个人见了面，最终整理出了十三页的笔记。
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. 除非你是顾问，否则我们很少有机会在自然工作环境中见到从事相同工作的人。你可能会在会议上遇到一些“被驯化”的技术人员，他们在精美的幻灯片中炫耀自己的技巧。他们总是展示已解决的问题，而未解决的问题则像未翻开的石头下的虫子一样潜伏着。因此，我很兴奋能进入一个平行维度，与另一个在许多方面与我自己的团队如出一辙的基础设施团队交流。
| Name | Fav emoji | Interests |
|---|---|---|
| James | 🐈 | Green builds, DevEx, cats |
| Stacks | 🏗️ | Ownership, standardization, infra |
| Alex | ⚖️ | Pragmatism, Crucial Conversations, infra |
| Sabrina | 🎾 | Standardization, CI/CD, tennis |
| 姓名 | 最爱表情 | 兴趣 |
|---|---|---|
| James | 🐈 | 构建成功、开发者体验 (DevEx)、猫 |
| Stacks | 🏗️ | 所有权、标准化、基础设施 |
| Alex | ⚖️ | 实用主义、关键对话、基础设施 |
| Sabrina | 🎾 | 标准化、CI/CD、网球 |
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，他在公司工作了四年。他喜欢摄影、寄养猫咪和吃寿司，这是一组极其协调的爱好。他寄养过数百只猫，有时一次多达七只。他现在的 Slack 显示名称简直就是“风衣里的七只猫”。为了喂饱那些饥肠辘辘的小家伙，他通过开发流水线和其他开发者工具来让开发人员保持快乐。我该如何让一个心里装着数百只猫的人吐露职场冲突的内幕呢？我准备好迎接挑战了。
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. James 提到，基础设施团队最近讨论了是采用 Argo Rollouts，还是构建一个内部定制工具来增强现有的 Buildkite CI/CD 设置。就是这个！我们找到了冲突点。在笔记中，我创建了一个名为“Argo 门事件”的子标题，并急切地追问 James 更多细节。
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. 背景是 ngrok 有一个棘手的更新发布流程。他们有一个名为 Mux 的 Golang 服务，运行在每个区域，承载着数十万个 TCP 连接。用新进程替换这个 Golang 进程需要等待数小时以排空连接。早期，这个更新过程是由运行在开发人员笔记本电脑上的脚本控制的。如果 Wi-Fi 断开，更新就会失败。任何方案都比这强，所以他们最终建立了当前 Buildkite CI/CD 系统的基础。但现在公司有更多产品使用该系统，他们对现状并不十分满意。团队一致认为 CI/CD 需要改进，但在如何改进上存在分歧。围绕 Buildkite 开发更多定制工具更容易采用，但使用 Argo 则会迫使他们重写那些不稳固的基础设施。
“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. “谁支持哪一方？”我问道，就像一个嗜血的罗马维斯塔贞女在询问角斗士比赛一样。据 James 说，事情没那么简单。
Pollice Verso (1872) by Jean-Léon Gérôme. 让-莱昂·热罗姆的《决定性的投票》（1872）。
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 prepared for either outcome. James often sides with Alex when it comes to developer happiness (like avoiding a rewrite), but he also sees the pros and cons and would be happy with either decision too. Maybe these people are just genuinely okay with either outcome? Surely not, right? Stacks 不想在定制工具上浪费“创新代币”，所以倾向于 Argo，但也理解还有其他因素在起作用。Alex 一如既往地务实，认为要获得重写的支持太难了，更倾向于在现有系统上进行构建。Alex 和 Stacks 从高中起就是朋友，所以他们并不是对立的派系。Sabrina 以前没用过 Argo，但在标准的重要性上通常支持 Stacks。她对任何结果都做好了准备。James 在开发者幸福感（比如避免重写）方面经常支持 Alex，但他也能看到利弊，对任何决定也都乐于接受。也许这些人真的对任何结果都无所谓？肯定不是这样，对吧？
At this point I was worried I wasn’t getting the full story, since it was so unlike my own experiences of workplace conflict. I had no evidence, but my brain just couldn’t imagine that a topic like this wouldn’t lead to some arguing and hurt feelings. I figured he must have been over-simplifying or straw-manning them, or downplaying the level of disagreement. The next interview was Stacks. Maybe he would spill the beans I’m looking for? Apparently not, he corroberated James’ account of the situation and we had a lovely conversation about team boundaries and ownership. How frustrating! Next was Alex. Alex opened up and even recounted big-picture topics discussed in his most recent meeting with his manager, which was super interesting but it wasn’t conflict like I was looking for. And fi… 此时我担心自己没有得到完整的故事，因为它与我自己的职场冲突经历太不一样了。我没有证据，但我的大脑无法想象这样一个话题竟然不会导致争吵和伤害感情。我猜他一定是过度简化了，或者是在进行稻草人谬误，又或者是淡化了分歧的程度。接下来的采访对象是 Stacks。也许他会吐露我想要的内幕？显然没有，他证实了 James 对情况的描述，我们还就团队边界和所有权进行了一次愉快的交谈。真令人沮丧！接下来是 Alex。Alex 很坦诚，甚至讲述了他最近与经理会议中讨论的大局话题，这非常有趣，但并不是我所寻找的那种冲突。而且……