Creating an Ego-Free Environment

For years I've been talking to my teams about "ego-less development".  I don't remember where or when I heard about the concept, but I thought I'd take a couple minutes to talk about what that means to me.

For me, ego-less development starts with the recognition that not everything is about me.  All of this code we write daily is code written by us on behalf of and for the organization that employs us, and for which we are paid a (hopefully) fair wage.  When we are done writing it, we do not own it.  It is not who we are.  The idea behind an ego-free environment is that you check your ego at the door, and do your best to produce the best software for the company the best way you know how.

You can think of software as commissioned art.  Not every piece is perfect, but when the project is over, the piece sits in the living room of the commissioning person to be enjoyed by that person, not taken home.

When you take the perspective that the code that you write is not yours, it becomes a lot easier to decouple yourself from the code you write.  Many people take criticism of their code as a criticism of their own person.  While criticism on your code can include a criticism of your skill set, it's should not be intended to suggest anything wrong with you as a person, even though your mind might translate the criticism.

The translation works like this:  What's said is "Well, I see something wrong in this code here." What is heard is "You wrote this code.  Something is wrong with it.  So something is wrong with YOU! STUPID!"

If you're a team lead, you need to make sure that the culture changes so the message comes across correctly.  Here's a couple things I've found really helpful in cultures I've been part of:

Freely admit your own mistakes:  Everyone makes them.  It's no fun to make them, and worse to have things blow up because of something you did.  When things do explode, fess up.  No excuses. "I did that. I'm really sorry."  You're looking to demonstrate the correct approach that you're looking for. Lead by example.

Let people know it's okay to screw up:  While habitual bad performance has to be addressed, not every little failure is something team members should feel like they have to fret over.  Be honest. Don't gloss over it by saying it's okay.  "Yes, you screwed up.  We've all been there.  We'll do what we need to fix it."

Don't map ownership of specific code to people:  If there's a bug found in the system, there's a tendency to say something like, "Oh, looks like a bug in your code.  Guess you better get in there and fix it." Once the code is integrated, it's company code.  You don't own that code.  Anyone can go fix it.  Throw the bug in the backlog and let the next available dev snag it.

Use positive language, even when disagreeing:  Yes, this is software, and at some point you've got to ship.  Sometimes there are differences of opinion, but you lose the instant you say something like "Well, the smart thing to do is..."  That's another way of calling someone stupid, if they legitimately disagree with you.  Language and communication sets the tone.  Make sure that you phrase the argument in terms of risks, rewards, costs, or benefits.  "The problem I see with approach A is that X, whereas this other approach [note: not "my approach"] avoids that problem."

Let's say you even get to Nerdvana and have an ego-free environment.  Never forget that there are scores of cognitive biases out there and that at any point, you may be falling prey to them.  Keep an eye on your own communication to ensure that you're truly communicating the way you would like. Even in an ego-free environment, people still can be defensive.

Not many environments work as one-person bands.  Great work takes great teams.  Great teams are formed by trust.  Check your egos at the door, and build that trust in your environment today!