Bit of a shower-thought today, a continuation of something that’s been rattling around in my brain for a minute.

I think there’s a helpful way of thinking about what I consider to be a core belief spectrum in engineering (and indeed, other fields, but let’s set that to the side for the moment), and that by naming and describing it we can come up with a lens that helps us operate more happily and effectively in our lives and careers.

The setup

For the sake of argument, let’s take the following spectrum (somewhat adapted from political science):

• Reactionary
• Conservative
• Progressive
• Radical

Let us then flesh it out, assigning objectives that are mutually exclusive but not exactly complements of each other:

• The reactionary must not take any action that foreseeably makes things worse.
• The conservative prefers not to take any action that foreseeably makes things worse.
• The progressive prefers to take every action that foreseeably makes things better.
• The radical must take every action that foreseeably makes things better.

We can further refine this–and drop the intermediate steps as uninteresting–and squint at it as:

• The reactionary is compelled to minimize foreseeable costs, regardless of potential gains.
• The radical is compelled to maximize foreseeable gains, regardless of potential costs.

This makes some intuitive sense based on experience, right?

If you’re making pacemakers, every change could kill at least one person if you get it wrong, so you make choices to avoid incurring that risk/cost. If you’re making a hobbyist programming language, major design churn is fine because you’re pretty sure there’s a more elegant solution/implementation/whatever out there.

Why this matters

All of us engineers have a natural comfort zone in this spectrum, informed by our own neuroses and experience and skills. Some of us are very good at thinking through failure modes, bounding them, and optimizing for potential costs of creating and operating a system. Some of us are very good at exploring new ideas, trying out really transgressive approaches to things, and searching for nuggets of value in largely fruitless outcome manifolds. Some of us switch between these as circumstance demands, some of us settle into a happy medium of exploration that trades effectiveness in either direction for generality–all sorts of presentations.

We are forced to interact or join organizations that display some aggregate point on this spectrum, and the degree to which we are near or far from that point is–I contend–a good warning for how much we’ll enjoy that time spent together.

If you join an org that’s very conservative in its engineering but you like moving fast and breaking things, you’ll be unhappy. If you join an org that’s continually trying to build and test out things but you prefer to slow down to optimize costs and reliability, you’ll be unhappy.

So, try to find an org that matches where you are on this spectrum.

Another way of looking at it

So, we’ve got this lens for looking at this engineering culture, and I think it’s doing alright. But, as I kept mulling it over, I think I spotted a place for refinement.

I’d previously framed this as two mutually exclusive goals: cost minimization and gain maximization (arguably, you could maybe go frame it as the explore-exploit problem, but I won’t do so here).

The problem with that framing is that it doesn’t feel particularly actionable: an agent has preference for either one or the other, and we all just kinda have to accept that preference. The best we can do is avoid finding ourselves in orgs that do not align with our preference. This is not satisfactory.

So, instead, let’s give a teensy bit extra framing to the extremes:

• The reactionary is compelled to minimize foreseeable costs because gains are illegible.
• The radical is compelled to maximize foreseeable gains because costs are illegible.

This minor trick says, in effect, that two extremes exist because of an information gap. Our reactionary doesn’t say as a rational actor “I don’t care about gains” any more than our radical says “Costs are irrelevant”–instead, each one is unable to assess and plan around the thing that is illegible to them, and so they disregard it in their calculus.

This seems like a small tweak, but it suggests that if we want to change where an engineer or org is on the spectrum, we can do so by changing the insight and information they have available to them.

A reactionary engineer provided a reasonably full exploration of gains will (in my experience) grudgingly go along with a change in course. A radical engineer provided a reasonably full accounting of costs will (in my experience) reluctantly pull back on new initiatives or churn.

Engineering culture and hierarchy

Given the aforementioned legibility modification to the framing, we can also see a basis for an observed behavior in engineering orgs: as you go up and down the hierarchy, you may see shifts in location along the spectrum, and this tends to result in tension and upset.

In some orgs we see that the people at the top have a viewpoint of market opportunities and not the daily costs of operations and maintenance, and that people closer to IC roles see first-hand groans and cracks in the software and aren’t privy to business and market information. In such cases, the leadership may be more radical and the rank-and-file more reactionary.

In other orgs we may see that the ICs are closer to customers or to new techniques and technology and opportunities, while leadership is aware of fiscal realities (quite literally the costs of the business) and market challenges. In such cases, it is leadership that is more reactionary while the ICs are more radical.

If we want to improve the health of an organization then and limit this source of friction, we need to ensure that information flows in both directions: the people that are unaware of the costs need to be informed and so too the people that are unaware of the opportunities. This leads to the (admittedly obvious) implication that vertical communication in an org must be aided and information thermoclines aggressively removed.

One of the easiest wins (and annoyingly common tasks) one faces as engineering leadership at a company is supporting the host org’s proprioception around things like costs and gains–making things like dashboards for sales, marketing, and ops spend available and ensuring that the people serving in the role of business analysts have everything they need to perform that function.

Engineering culture and ambient conditions

It’s also critically important that things entirely outside the actual area of operations of an engineering org can cause the legibility of costs and gains to wax and wane, and this in turn can cause a huge change in the culture without deliberate choice.

Let’s say that the operating regime of an org is such that any notion of cost is hidden: for example, the ZIRP regime that meant lots of capital from family offices and investors looking for a home resulted in a glut of funding, and in such cases engineering practices tended towards the radical. Companies had no real cost understanding driving against things like large distributed systems and microservices, and engineers felt no particular pressure to optimize, streamline, and simplify their work–after all, many would jump to the next job and get a raise regardless of the mess they’d left behind.

In another org, let’s assume that there is very little insight into the customers and market opportunities (say, because leadership was unable to maintain a meaningful and successful sales cadre). This org will instead tend to focus on minimizing the costs and bring increased scrutiny over every single little engineering initiative out of fear of accidentally spending more than is absolutely needed.

In neither case did the orgs or engineers or even engineering leadership purposefully choose to adopt a more reactionary or radical culture, but external factors in the business and world instead tilted the entire field one way or the other.

Of particular interest to us, I suppose, is that with the post-COVID era starting austerity in tech and recent Trump administration policy choices the payoffs have become vague but the costs incredibly real. I expect that this will continue to dominate the engineering culture meta for the next several years, and so I expect that we’ll all have to figure out how to get along in workplaces that are increasingly reactionary in how they do their engineering.

---