Only Debate The Non-Linear

Daniel Golant - Feb 19 '23 - - Dev Community

I sometimes feel like the course of my career has been one long vacillation1 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

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 research2 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 confident3 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. 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, 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 important4! 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. 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 Shave5

When I was reflecting on a recent moment in which I decided to stay mum, 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 valued6, and therefore most rewarded, for non-linear impacts.

a graph of Big O growth rates

“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) to θ(6n). Instead, non-linear impacts eliminate whole swaths of work, thereby increasing the output of every individual in the organization as well7. 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
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”, 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 surface8. 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
  3. Engineers receive outsized rewards for the non-linear impacts they create9

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.”

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, I found that their value 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 the community considers always important 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.
  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
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player