Be Nice to Your Developers!

(and everybody else who works for you).

Some call it the reptilian brain. Some call it the primitive brain. Whatever it truly is, evolution has handed us down a form of genetic memory that has us hard wired to magnify and prioritize threats.

The nature of these threats changed. From situations like starvation or being eaten by a predator, we now face being yelled at by a boss or assaulted with 1000 types of olive oil in the condiment aisle, being overloaded by drug ads that list horrific side effects, our news feed, you get it.

When that change occurred, the imprint was not similarly modified. It isn’t just ‘decision fatigue’, it’s also limbic fatigue! Consequently, we are all finely attuned to seeing the negative and have to make special effort to root out and applaud the positive.

When building a product, a software engineer goes through a cycle of constantly being told by the machine that he is wrong <THREAT!> until he finally reaches a point where the machine can run the software correctly and he marks up that one positive. He might repeat the cycle hundreds of times before finally delivering that feature the business has asked for.

That is a lot of "threats" to assess and process! Further, one can only hope the business-ask was clearly made and understood. The art and science of software requirements gathering, presentation, and ultimately acceptance for implementation is mired in two (ok...many more) decades of idea evolution with no clear winners. Perhaps we should invent a principle similar to Conway's Law where we define "the structure of the software development process is akin to a fingerprint of the personalities involved and organizational structure"? Sorry, tangent! A touch of PTSD perhaps.

When the business receives the feature, it is very common for them to gloss over the 50 things that work right and highlight the one thing that didn't, sometimes making a much bigger deal out of it than it actually is in context.

We can't blame them for this. They are simply doing what comes absolutely naturally. What we are hardwired for!  This perceived “miss” can feel like a punch in the gut because from the primitive-brain perspective it’s a fresh threat.  

But what we can do is ask for business to also notice the 50 things that went right and give proper credit for all of that effort. Those represent effort, complexity, understanding, and a whole lot of primitive-brain threat-management. 

This is counter to how most of us behave. "If you see something, say something", right? To be clear, I am not advocating for rewarding failure, glossing over, 'the old hug-n-slap', or any other diminishment of calling out legitimate problems and failings.

Instead considering a re-characterization of software deliverables in a way that makes wins and losses at least equal in weight. Of course we can't call it done until all the things that we need to work, do so correctly. Still, we should count the wins.

Imagine the conversation where we point out the real-world things like we do button, font, color, or defect issues. In the normal course of a polite society conversation most of us wouldn't dare call out “misses” that we deride and disrupt our developers over.

“Hey Bill, I noticed your shirt is really a bit too big, and your shoes are a poor match for your belt - and hey is that really the right shade of beard dye for you?”   

“Pat, you said you were going to be done losing those 20 pounds by the end of the month - here it is a week late you only lost 16 pounds!  COME ON PAT!”

Probably not most of us.

But somehow and even quite reasonably, after having burned a lot of budget for something to be built, the things that are not quite right massively overbalance (in the receiver's perception) the things that are working as intended. I think a ratio of 50 working elements of software to one defect is not unusual, but is often seen as failure.

So how do we overcome our base nature in this regard?

To some extent, the Great Leap forward of mankind is to intercede that primitive-brain base nature reaction with a cognitive overlay. Training and indoctrination are used to build overlays, as well education, rehearsal, meditation ...etc.  

Could we use a reevaluation of our business processes to better account for our own innate reactiveness in these often emotional situations?

Most people want to be appreciated. Many become disengaged and produce poorly when unappreciated.  If we are going to use phrases like "human capital management", can we do more to treat that capital as human?

So when I say be nice to your developers, I am not talking about a Starbucks gift card, cash bonus, extra day off for weekends worked, any of that which should just be considered table stakes/decent treatment for good workers.  I'm talking about working a little harder to understand the efforts that were required to produce something and count the wins as wins, not just side effects of the perceived failures.

And here's the hard part - expressing appreciation even when we're upset that the thing we have been waiting for is not yet perfect. This isn't a pizza. This is upper echelon technology development built to order.