The engineer problem, part 2
by Matt May
In my last newsletter, I outlined a problem I see in a lot of tech spaces, to wit: efforts in the DEI space tend to work around companies’ engineering organizations, where those organizations are not explicitly standing in the way. I promised that I’d share my advice on how to deal with that.
First, I’m going to let you in on a little secret.
You know how the stereotypical alpha engineer works weird hours? Has hobbies that are out of the ordinary, or perhaps none at all? Likes working at home, or in the dark, or in drab or messy offices or cubes? Tends to go deep down individual rabbit holes? Avoids significant face-to-face interactions? Has trouble with social norms, like speaking in turn, wearing business-casual attire, or possibly personal hygiene?
Surprise! Lots and lots of engineers are neurodivergent. ADHD (*wave*), autism, and by extension their love child, AuDHD—whether diagnosed or not, suspected or not, treated and/or medicated or not—are common among software engineers. Which, when you think about job descriptions that require mastery of all manner of arcane languages, a broad working knowledge of one or more codebases, and the ability and willingness to work outrageous hours under immense pressure, kinda makes sense, no?
I want to emphasize that this is a stereotype, and try to steer you away from trying to clock your coworkers as neurodivergent. Neurodiversity also encompasses many more identities, though I’m singling out ADHD and autism because I have by far the most first- and second-hand experience with them. It’s been my experience across at least the first couple decades of my career that companies never really asked if a technical resource needed accommodations to do their job unless it was to increase their rate of production. It’s not a thing we’re conditioned to wear on our sleeve, because the nail that sticks out is the one who gets hammered down.
Account for neurodiversity
Okay. With this in mind, let’s start rewinding some of the interactions you’ve had with an engineer. Were they stuck on a single conclusion and closed off to other perspectives? Do they have trouble keeping their opinions to the boundaries of their own role? Is it hard dealing with one-offs or other exception cases, even when they’re important to the overall business objective? Then it’s entirely possible that a difference in neurotypes is at work. It’s even possible that two people with similar forms of neurodivergence (that is, two or more autistic or ADHD folks working together) don’t manifest the traits of those identities in similar or compatible ways.
An example: autistic and ADHD folks have a tendency to place a strong emphasis on equality and fairness. (Fun fact: my Buddhist name, Byōdō, means “equality” in Japanese.) However, we are not all identically fixed on an ideological true north. When an issue like this comes up, if someone is bringing up functional instances of inequality, whatever they may be, it may not be “playing devil’s advocate” to them, but an actual mental block. It may benefit everyone involved to recognize this difference before reacting.
Determine intent
Here’s a very important thing to know: being neurodivergent is not a hall pass for unacceptable behavior. It is not license to be an asshole. Nor are you in a position to determine your coworkers’ neurological statuses. So tread very carefully here. But some care should be taken to see if what you are encountering as opposition is simply a cognitive block, or a contrarian political position. Or some combination of the two.
Sometimes we can hear a criticism and immediately take a defensive stance. For example, someone might say that an equity and inclusion initiative is excluding someone. And atomically, that’s usually true in a sense: equity efforts do privilege certain groups to compensate for inequities that have come before. If that’s all that needs to be exposed to fill in the gaps in someone’s understanding of the problem set, that’s fine. It’s when this is meant to express a political opposition to the entire concept of equity work that this changes from an exchange of ideas to a fundamental disagreement.
Re-center “truth”
Truth in a software engineering sense is exceedingly simple. True is 1, and false is 0. That’s literally all there is to Boolean logic.
When Boolean logic is applied to anything with nuance, we have a big problem—for example, when there is my truth, which is to say my own observed reality, and it may collide with that of others. A Boolean, black-and-white approach to this kind of collision may satisfy none of the actual stakeholders involved but for the Boolean thinker. Consider Solomon and his approach to shared custody.
In Part 1, I classified one type of engineer as the “Master of Logic and Reason.” This is what I mean. One can be very good at marshaling ones and zeroes around in a precise order, and wholly incapable of resolving differences of opinion.
The only truth that matters in a lot of workplaces is that if you don’t look like you’re making the organization more effective or profitable, your position is not stable. Systems thinkers are always aware of this fact. Many say no to non-revenue-generating work because they are trained to believe that’s the only measure that will save them from the next layoff. If you’re in a peer relationship with a coworker that’s actively obstructing your work, you or someone else need to cause them to understand that the business goals include your role and portfolio, or you wouldn’t be there either.
An example: I’ve had any number of engineering leads try to derail accessibility work on their products (knowing they’d be the ones who’d have to implement it) by calling out how small they perceive the market for those fixes to be, relative to their feature work. “How many people are we talking about, really?” is the common refrain. But here’s the thing: that’s not an engineering lead’s job. If your job is to improve your company’s accessibility, your value to the company is usually in protecting or expanding sales, especially in government and education.
Do you know whose job is not to analyze how to do that? The engineer’s. If you have a mandate from the company, then the decision is made. My life got a lot easier when I learned not to argue the why with engineers, and go straight to the business managers when we were not in alignment. You lose autonomy in your role the moment you acquiesce to an engineer stating their opinions and biases as facts.
Get help
Finally, it’s usually worthwhile to ask your friends and colleagues if they’re experiencing the same kinds of pushback that you are. Organizational dysfunction is a slow burn, where over time people determine that their job is easier if they can bully the other stakeholders around to get what they want. If you’re being sidelined by an engineer (or anyone, really), it’s unlikely that it’s only happening to you. In which case, you may need to rally the rest of the team together and say, hey, are we working as a team, or aren’t we?
We are conditioned to believe that if something isn’t going right at work, it must have been something that we did wrong. But sometimes, it really isn’t in your head. Coordinating with others can help you determine if there is a problem with how roles are defined and reinforced, and if so, how to rebalance the reward systems so that everyone is pulling together. It’s also a way to see if maybe the reward system is working exactly as intended, which can help you decide to move on to work that’s more aligned to your own goals.