Only Debate The Non-Linear
Tags: culture, organizations, teams, architecture
Published: 2023-02-19 23:08:56

---
title: Only Debate The Non-Linear
published: true
date: 2023-02-17 21:46:04 UTC
tags: culture, organizations, teams, architecture
cover_image: https://lh4.googleusercontent.com/5VNgKcfNRpR9X5_o3rvSFr-C8ZRWNwyDIFMJRVGicG-GrnQ8y4fi_tQjTEx0XBexdwgVuAXwXRqTCCkw_k6KrjeU8ZpFGu-zTJ4o-mviw7Agt8k2iXt9ex3eMd9tQv7e9bxYxG2WbhVIpTtfc5pBEMM
canonical_url: https://thelog.farm/2023/02/17/only-debate-the-non-linear/
---

I sometimes feel like the course of my career has been one long vacillation<sup><a href="#footnotes">1</a></sup> between being too argumentative and too deferential.

I’ve often struggled _specifically_ in work contexts to discern when a debate was worth having. In the moment, it has often been difficult to suss out whether my disagreements were rooted in real merit, or simply personal preference, and more importantly whether those disagreements were worth airing.

In fairness to myself, I’ve also come into contact with many _other people_ who struggle with this. I can’t count how many people I’ve worked with who casually made requests for _significant changes_ to other peoples’ work, often for _spurious benefit_ and with _horribly_ _inopportune timing_. Funnily enough, those are the exact people who I’ve historically avoided debating with, either due to a (often mistaken) belief that they simply knew better, or due to an (often correct) understanding that these people are just _not worth debating_. I hope that someday my career rewards me for at least _thinking_ _about_ whether it’s worth having certain debates, because it would break my heart to find out that what society really values are those sorts of inconsiderate boor. 

> nit: hey could you rewrite this entire pull request
> 
> — jordan (@jdan) [January 27, 2023](https://twitter.com/jdan/status/1619033066068148224?ref_src=twsrc%5Etfw)

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

### Do We Really Have To Fight?

That being said, I’ve just as frequently seen _unthinking accession_ to other peoples’ decisions go just as poorly. I’ve seen this referred to as “false harmony” in management articles, and it can mean that teams fall into bad patterns just for the sake of collegiality. After all, we would still be deploying once a week if someone hadn’t decided to rock the boat a bit.

We know from years of [organizational psychology research](https://hbr.org/2005/03/want-collaboration-accept-and-actively-manage-conflict)<sup><a href="#footnotes">2</a></sup> that some amount of conflict  between people is healthy and desirable. What that “some amount” looks like, and how to attenuate levels of disagreement towards that magic number, is of course the golden question. 

Reflecting on my own swings between needless belligerence and deleterious avoidance, I’ve come to the conclusion that whether conflict in a group is at “healthy” levels is, internally to one person, mostly rooted in confidence. People who try to present as supremely confident<sup><a href="#footnotes">3</a></sup> will often seek conflict (or at least domination) in trivial matters. People who outwardly present as _low_ in confidence will often _avoid_ open disagreement, even when they have meritorious doubts about an issue. This can, over time, destabilize organizations.

Not all disagreements are equal, and moreover, not all people react to one disagreement in the same way. Their impact on the morale of both organizations _and_ individuals doesn’t even have any sort of logical progression. Periodic debates over things that are perceived as low in importance can often outweigh the occasional knock-down, drag-out fight over matters that participants feel are critical to long term success. If you re-read the previous sentence, you’ll notice that I didn’t mention the _direction_ of the aforementioned impact on morale. Some people –whose existence perpetually amazes me- actually _enjoy_ discussing [linting rules](https://en.wikipedia.org/wiki/Lint_(software)). Like I said, the impact of conflict is highly individual.

### You Gotta Fight, When It’s Right

We’ve established that there’s some equilibrium level of conflict, and that some conflict can actually _increase_ the efficiency and morale of a team. This is not some groundbreaking insight by any means. That being said, how do we find that equilibrium? It’s easy to say “pick your battles” or “only argue about the important things,” but what does that _mean_? “Important” is a completely arbitrary standard! As I mentioned, not only have I had colleagues who have _enjoyed_ arguing about lint rules, [commit style](https://stackoverflow.com/questions/3580013/should-i-use-past-or-present-tense-in-git-commit-messages), or whether to deploy on Fridays, but I imagine those same people also find those debates to be _quite_ important. Hell, at times I’ve even been convinced that I was wrong, and come to believe that their topics _were_ important[<sup>4</sup>](#footnotes)! That still doesn’t give me a tool that tells me whether I am _generally correct_ in judging importance. What we need, and what I have been looking for some time, is **a** [**_razor_**](https://en.wikipedia.org/wiki/Philosophical_razor#:~:text=In%20philosophy%2C%20a%20razor%20is,avoid%20unnecessary%20or%20improbable%20assumptions.). Telling people to only argue about important things is actually good advice, **if** you give them a toolkit to decide what is important!

### My Kingdom For A Shave<sup><a href="#footnotes">5</a></sup>

When I was reflecting on a recent moment in which I decided to [stay mum](https://dev.to/dangolant/stop-checking-where-you-are-43p7-temp-slug-4482129), I managed to distill just such a personal principle: **Only Debate The Non-Linear**.

At some point in their careers, most engineers come to a realization: **we _are not rewarded for linear outputs_.** Most engineers will tell you that the transition from a junior engineer to a senior engineer, or the truly transformational work in our careers, does _not_ come from just crushing tickets non-stop for extended periods of time. Similarly, these transitions don’t come from implementing some n+1 product feature that you’re told is very important. Instead, engineers are most valued[<sup>6</sup>](#footnotes), and therefore most _rewarded_, for **non-linear impacts**. 

![a graph of Big O growth rates](https://lh4.googleusercontent.com/5VNgKcfNRpR9X5_o3rvSFr-C8ZRWNwyDIFMJRVGicG-GrnQ8y4fi_tQjTEx0XBexdwgVuAXwXRqTCCkw_k6KrjeU8ZpFGu-zTJ4o-mviw7Agt8k2iXt9ex3eMd9tQv7e9bxYxG2WbhVIpTtfc5pBEMM)

“Non-linear impacts” are impacts that don’t just add some incremental value to the company, and they’re not even impacts that, say, accelerate feature output from [θ(2n)](https://stackoverflow.com/questions/10376740/what-exactly-does-big-%D3%A8-notation-represent) to θ(6n). Instead, non-linear impacts _eliminate whole swaths of work_, thereby increasing the output of every individual in the organization as well<sup><a href="#footnotes">7</a></sup>. As a concrete example, I would rather implement a self-service e-commerce _platform_ for a company’s merchandising team, rather than make it easier for engineers to service a ticket to build a `/products/hat/:id` endpoint every 6 weeks. I wish I was joking that companies like this exist, but I am sure you know someone who has worked in a job like that.

![A gif of a drag queen tripping and falling](https://lh6.googleusercontent.com/4MoQ3rH917I6HgfJXa1fSF__cjN-6ecHf85NrDw0TvggUeasj0K1JMQ2IDZTmC7SYB3h-sVvg1hYASKie6L3OjKhWf13PfPIOhZvgxHrLtlyKZgmaZ0bHYgeo_yH_mugctfMx0Om5bktY-MyWUKmfg)
_Non-linear drag, despite what you might expect, is not what we call a RuPaul contestant who can’t walk in a straight line._

“Non-linear impact” has an inverse, which I have named “ **non-linear drag** ”. Non-linear Drag is a term I use to describe factors that lead to **_exponentially_**  **decaying**  **productivity** over time. Most folks would probably lump this in with “[tech debt](https://en.wikipedia.org/wiki/Technical_debt)”, a term I doubt ever really had a lucid definition. I think precision matters when you’re offering people a razor, so I want to differentiate _this_ form of tech debt, which generally involves bad architecture or fundamental technology mismatches, versus things like an increasing support surface[<sup>8</sup>](#footnotes). All growing organizations experience increasing drag, even if they dedicate massive resources to minimizing that drag, but certain choices can set the **growth rate** of that drag on a _very_ bad path.

### Putting It All Together

Engineers love to argue over examples while missing a broader point, so if the examples above don’t please you, hopefully I have _at least_ convinced you of the crazy idea that certain decisions can be critical. They can lead to wild success, but they can also cause you to _screw up really badly_. If you’re unconvinced of this concept, then I don’t know, maybe you should go juggle some chainsaws. After all, what’s the worst that could happen?

Alright, getting back to our point, at this point we have three premises:

1. Linear impacts and drags exist, and they’re generally the majority of what we encounter
2. Non-linear impacts and drags exist, and the opportunity to create them is [definitionally rare](https://en.wikipedia.org/wiki/Pareto_principle)
3. Engineers receive outsized rewards for the non-linear impacts they create<sup><a href="#footnotes">9</a></sup>

Coming back to the start of this post, where I was trying to figure out a razor I could apply that was better than “pick your battles,” I think we now have a strong argument for a good rule of thumb: **Only debate the non-linear**. If there is a **strong** case to be made that a proposal will create some non-linear impact, then it is worth debating at some length. In cases where there’s really no chance that an outcome will create this sort of massive impact, then I don’t see much point in wasting too many cycles or emotions on a subject. I see this razor  as an organizational analog to, or perhaps even a lever towards, the principle of choosing “[boring technologies](https://mcfunley.com/choose-boring-technology).”  
  
Of course, not all non-linear outcomes are equal, such as choosing a data model versus choosing a linting standard, but overall I think this rule has given me a solid starting point when deciding whether something is worth a lengthy debate. During my recent stint at [Carta](https://carta.com/), I found that their [value](https://carta.com/blog/cartas-operating-principles-and-identity-traits/) of “optimizing for the first derivative” played well with this approach. I think if you apply this test _strenuously_ you’ll find that even [subjects](https://www.monocubed.com/blog/best-front-end-frameworks/) the community considers [_always_ important](https://en.wikipedia.org/wiki/Cargo_cult#:~:text=A%20cargo%20cult%20is%20an,advanced%20society%20to%20deliver%20goods.) really can’t generate an excessive return in business value.  
  
I’m curious to hear how other people “pick their battles”, and I hope at least one person finds a more-rigorous-than-average process useful. What do you think, am I tackling this all wrong? Is this obvious to a normal, well-adjusted person?

#### Footnotes

1. More realistically, my life
2. Not to mention millions of dollars in self-help book sales
3.  We say “present as” rather than “are” because, as we all know, often people presenting as confident are doing it to hide insecurity. 
4.  I’ve gone back and forth on some things multiple times, like commit messages, and on others (deploying on Fridays) I’ve come to a synthetic point. 
5.  Listen, everyone tells me I need to have headings, you can’t force me to make them _coherent_
6.  Or at least, should be. I have definitely seen my share of feature farms that pay people lots of money to generate negligible outcomes. 
7.   I mention increased output rather than “improved efficiency” because they are different outcomes, in a growing business _output beats efficiency._ This is a critical distinction passed to me by my old boss [Dave Hauenstein](https://www.linkedin.com/in/davehauenstein).
8.  One thing I love is comparing terms I made up with other terms I made up and never explaining one of them. I could have sworn I published something about this years ago, but I guess I have some more writing to do.
9.  It’s worth mentioning: _engineers_ don’t get fired for creating non-linear drag, the company generally sacks the whole team for that