jonoropeza.com

Making software and software development teams. Mostly the people parts.


Intentional vs Happenstantial

One of my favorite concepts I've dug in on this decade is first principles thinking, and one of the best principles I've been learning is the importance of being intentional whenever possible.

I tend to be an incrementalist by nature, and to live and reason in de facto realms as opposed to de jure. This puts me in opposition to many of my peers in the software engineering profession, who tend to reason policy-first and gloss over or even ignore the second and third order effects of the policies and rules they write as happenstance.

Neither one is "right", and I don't think my way is better. But it does give me a unique vantage point of many situations I face, and I've come to see the power of this in a few different ways.

One is simply being able to empathize with those around me who feel those second and third order effects of well-intentioned policy.

Another is to understand how to nudge and influence peers and leaders who see things through mre de jure lenses. You have to appeal to their sense of policy-first, and work to change the policy rather than appealing to common sense or feelings or other ways that more de facto thinkers tend to act.

A third power is the ability to pull out of these loose realms and set reality-based intentions. In the derogatory sense, this would be known as Paving The Cow Paths, but in the martial arts we would describe flowing instead of opposing in loftier terms.

What does all this mean practically? It means that when I see positive change one a team I'm working on or managing - let's say a group that was having a sev0 every month, but has only had 1 in the last six months - I'm more prone to digging in, teasing out what the inputs have been that have led to this, and encoding as many as I can into policy.

A simpler way of saying it: This kind of making things that were occurring through happenstance or second order effect into first class citizens in a team's framework is akin to bottling up luck, understanding it, and learning what inputs to apply to maximize the chance of it being a repeated outcome.

posted in Engineering Leadership