--- title: Am I the problem? Interviewing another team to find out. description: A DevOps engineer interviews the infra team at ngrok to study how they handle technical disagreements, expecting to find conflict similar to his own... canonical: https://daily.dev/posts/am-i-the-problem-interviewing-another-team-to-find-out--gahma2skt twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Am I the problem? Interviewing another team to find out. | daily.dev og:description: A DevOps engineer interviews the infra team at ngrok to study how they handle technical disagreements, expecting to find conflict similar to his own... og:url: https://daily.dev/posts/am-i-the-problem-interviewing-another-team-to-find-out--gahma2skt og:image: https://api.daily.dev/og/posts/GAHma2skt.png og:image:alt: Am I the problem? Interviewing another team to find out. og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Am I the problem? Interviewing another team to find out. **[Lobsters](https://daily.dev/sources/lobsters)** · 18 min read · 0 upvotes · 0 comments ## Summary A DevOps engineer interviews the infra team at ngrok to study how they handle technical disagreements, expecting to find conflict similar to his own experiences. Instead, he finds a team that navigates disagreements calmly and reaches consensus without animosity. This contrast leads to a personal reckoning: he realizes he has been a primary source of conflict throughout his career. The post shares practical conflict-resolution tips drawn from the Gottman Method (5:1 positive-to-negative interaction ratio, paraphrasing), the book Crucial Conversations, and mutual aid organizing principles — including how burnout fuels conflict and how consensus-based decision making reduces it. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the Gottman ratio and how does it apply to workplace relationships? The Gottman ratio is a 5:1 rule: healthy relationships require five positive interactions for every negative one. Applied to the workplace, it means intentionally creating positive touchpoints — random 1:1s via tools like Donut, social meetings where work-talk is banned, and enforcing good pull request etiquette — so that neutral events read as neutral and negative ones as honest mistakes rather than attacks. _Engineers navigating remote team friction track practical relationship-building approaches like this on daily.dev._ ### What is the paraphrasing technique from the Gottman-Rapoport Intervention and how do I use it at work? Paraphrasing, drawn from the Gottman-Rapoport Intervention, requires each person in a disagreement to summarize what the other said to that person's satisfaction before responding. In practice, you don't need the full intervention — just applying the paraphrasing step in 1:1s or tense discussions sharpens listening skills and prevents people from talking past each other. _Developers working through team alignment challenges find field-tested communication techniques discussed on daily.dev._ ### How does burnout relate to workplace conflict on engineering teams? Burnout and conflict feed each other in a cycle. Burnout — defined as the combination of resentment, exhaustion, shame, and frustration — is worsened by feeling mistreated, misunderstood, or overburdened, all of which are also conflict triggers. Catching burnout signs early (gossiping, feeling disconnected, frustration) and addressing them with direct conversation can break the cycle before it causes lasting team damage. _Teams dealing with recurring conflict and burnout patterns find relevant perspectives from engineering practitioners on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 13 comments across lobsters (as of 2026-09-14). **TL;DR:** Commenters found the post genuinely resonant and thought-provoking, with most appreciating its honesty and practical framing; the main debate centers on whether individual humility in technical arguments is always warranted, or whether the stakes sometimes genuinely justify fighting harder. **Sentiment:** 70% positive · 20% mixed · 10% skeptical **The case for** - Reframing technical disagreements as discussions rather than battles — where 'losing' rarely worsens your life — resonated strongly with several readers. - The post's references to concrete frameworks (Gottman Method, Crucial Conversations) were appreciated, with at least one commenter ordering the source material. - Readers valued the author's willingness to do genuine self-reflection rather than blame others. **The pushback** - Some commenters pushed back that stakes can be real — e.g., being on-call for a system built on a bad decision, or watching a startup tank due to a catastrophic technical choice. - The claim that 99.9999% of technical disagreements have no company-level impact was challenged as an overstatement by people who've seen bad decisions sink products. - One commenter noted that broader management structures and burnout culture are systemic problems that individual conflict-resolution tips can't fully address. **By community** - lobsters (positive): Mostly warm reception with genuine engagement; the main friction was a side-thread debating whether technical argument stakes are ever truly high enough to justify strong advocacy. **Hottest debate:** Whether 'losing' a technical argument ever genuinely matters — i.e., whether humility is always appropriate or whether real on-call and business consequences sometimes justify fighting harder for your position. **Open questions** - How do these conflict-resolution approaches hold up when the decision-maker is a tech lead who can simply override team consensus? - Does individual humility help when the root cause of conflict is systemic burnout or dysfunctional org structure rather than personal behavior? **Highlights** > I think something that really helped with this was realizing that fundamentally it did not really matter if I won an argument, especially in a workplace. Because really I was just giving my opinion, and it's not like I was smarter than anyone else. There is no technical disagreement in basically any context that if were to "lose" that would result in my life getting worse. I'm sure other people may feel differently, but this reframes these arguments as what they should be - technical discussions, and if a person is particularly passionate I can use that as a sign to trust them. > — [mplant on lobsters · 4 points, 2 comments](https://lobste.rs/s/c30jsd/am_i_problem_interviewing_another_team#c_1ry1vs) > > Because really I was just giving my opinion, and it's not like I was smarter than anyone else. I think even in your proposed situation, "losing" an argument doesn't _actually_ mean that your being on the hook for overnight support of a system is a problem, or should make you feel differently about the stakes for that argument. Mostly because you may very well be wrong. Or because actually both sides of the argument are valid and the actual impact of the decision comes out in the wash. Or because this decision basically doesn't matter compared to the big chunk-o-tech-debt that actually causes all of your outages. Or, or, or... Lots of decisions in software engineering matter quite a lot. But that doesn't mean that winning an argument is in and of itself particularly important. If you lose, and you were right, and you can clearly see how your on call pages have gone up dramatically since that decision, then you have a remarkably clear case for reversing the decision. And if all of that happens without you appearing vindictive, because you didn't die on the original hill, then maybe in the future you'll end up having your opinion respected somewhat more. And if not, then maybe the problem is that your team doesn't respect your opinion — which is rather independent from whether you're losing all of your arguments. > — [smoores on lobsters · 1 points](https://lobste.rs/s/c30jsd/am_i_problem_interviewing_another_team#c_vje2sk) > Hmm, that doesn't really match what i've seen in this industry. I've worked on companies where bad technical decisions negatively affected products, sometimes even completely tanking them, and ending in the eventual downfall of the company. These were small-ish startups, yes. And there were other factors that contributed to the failure of the company, sure. But let's not dismiss the disastrous effect that a terrible technical decision can have. I mean a decision like "let's allocate most of our development efforts on a complete rewrite of our main web front-end [which is already working and generating revenue, btw] into a 'modern' stack using React and GraphQL because ". Given that i've seen these kind of problems first-hand more than once, i'd say your estimation of 99.9999% of technical disagreements having no effect on the success of a company is off. Otherwise, my experience would be an extreme outlier. > — [epidemian on lobsters · 3 points, 1 comments](https://lobste.rs/s/c30jsd/am_i_problem_interviewing_another_team#c_1vizqu) > I have a thought that I hope doesn't come across too rejective or something. But I have a feeling that present day management and company structures - also outside of our industry - are extremely flawed. I think that wrong ideas have been picked up at spread. Productivity should be high, everyone is burned out but nobody has actual solutions but grand speeches. And I get it it's all you can do, of the structure is a certain way but it has effects on how people work and eg make decisions. I think that's something that has to be accepted because just saying "others do the same" doesn't mean it's the approach is any good. It seems to work better or worse for some and all that but I think to a degree we drifted into a world where work and companies are semi religious things in that we do things cause they make sense or create benefit but kind of arbitrary numbers are their own goal which is pretty silly. And that I think includes the winners. Given how people spend money when they are rich I think few are genuinely happy. They might be addicted to some stuff and therefore might think so, but I doubt there is much fulfilling for many of them. I think it's time to reevaluate these things and I tbh the post does that, even when it might not be the primary goal. > — [reezer on lobsters · 1 points](https://lobste.rs/s/c30jsd/am_i_problem_interviewing_another_team#c_ca6geq) **Source threads** - [lobsters](https://lobste.rs/s/c30jsd/am_i_problem_interviewing_another_team) · 61 points · 13 comments ## Similar posts on daily.dev - [Designing For Healthy Conflict in An Engineering Team](https://daily.dev/posts/designing-for-healthy-conflict-in-an-engineering-team-rc0hxgbni) · Effective Software Leads · 7 upvotes · 2 comments - [Tools for founders to navigate and move past conflict](https://daily.dev/posts/tools-for-founders-to-navigate-and-move-past-conflict-fg1hnqyse) · TechCrunch · 1 upvotes · 0 comments --- Tags: [#devops](https://daily.dev/tags/devops), [#cicd](https://daily.dev/tags/cicd), [#leadership](https://daily.dev/tags/leadership) [View this post on daily.dev](https://daily.dev/posts/am-i-the-problem-interviewing-another-team-to-find-out--gahma2skt) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Am I the problem? Interviewing another team to find out.","url":"https://daily.dev/posts/am-i-the-problem-interviewing-another-team-to-find-out--gahma2skt","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/am-i-the-problem-interviewing-another-team-to-find-out--gahma2skt"},"datePublished":"2026-08-07T22:34:02.449Z","dateModified":"2026-09-14T09:00:45.393Z","description":"A DevOps engineer interviews the infra team at ngrok to study how they handle technical disagreements, expecting to find conflict similar to his own...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/c47b40475c887235dda9a276e8af5af2?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/c47b40475c887235dda9a276e8af5af2?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/am-i-the-problem-interviewing-another-team-to-find-out--gahma2skt","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"devops,cicd,leadership","timeRequired":"PT18M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Am I the problem? Interviewing another team to find out."}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/am-i-the-problem-interviewing-another-team-to-find-out--gahma2skt#faq","mainEntity":[{"@type":"Question","name":"What is the Gottman ratio and how does it apply to workplace relationships?","acceptedAnswer":{"@type":"Answer","text":"The Gottman ratio is a 5:1 rule: healthy relationships require five positive interactions for every negative one. Applied to the workplace, it means intentionally creating positive touchpoints — random 1:1s via tools like Donut, social meetings where work-talk is banned, and enforcing good pull request etiquette — so that neutral events read as neutral and negative ones as honest mistakes rather than attacks. Engineers navigating remote team friction track practical relationship-building approaches like this on daily.dev."}},{"@type":"Question","name":"What is the paraphrasing technique from the Gottman-Rapoport Intervention and how do I use it at work?","acceptedAnswer":{"@type":"Answer","text":"Paraphrasing, drawn from the Gottman-Rapoport Intervention, requires each person in a disagreement to summarize what the other said to that person's satisfaction before responding. In practice, you don't need the full intervention — just applying the paraphrasing step in 1:1s or tense discussions sharpens listening skills and prevents people from talking past each other. Developers working through team alignment challenges find field-tested communication techniques discussed on daily.dev."}},{"@type":"Question","name":"How does burnout relate to workplace conflict on engineering teams?","acceptedAnswer":{"@type":"Answer","text":"Burnout and conflict feed each other in a cycle. Burnout — defined as the combination of resentment, exhaustion, shame, and frustration — is worsened by feeling mistreated, misunderstood, or overburdened, all of which are also conflict triggers. Catching burnout signs early (gossiping, feeling disconnected, frustration) and addressing them with direct conversation can break the cycle before it causes lasting team damage. Teams dealing with recurring conflict and burnout patterns find relevant perspectives from engineering practitioners on daily.dev."}}]} ```