When I interviewed Jamie for a position at ZenTech, he seemed like an enthusiastic engineer. With solid tech skills, ideas for process and product improvement, and a great team attitude, he was the obvious choice.

But, two years later, Jamie was “that guy”. You know, the one who wants to code without being bothered.

I should have noticed the signs. He didn’t speak up in retrospectives, he didn’t contribute process or product ideas like I expected, and his “team-friendly” interactions were usually sarcastic. He often talked about technical debt, our lack of innovation, and the “stupid” decisions holding us back. An irritating “I told you so” sentiment plagued his comments and feedback.

Jamie may have thought about leaving the company. If he did, I couldn’t tell. Although, I certainly wish he would have. But we were shorthanded, and I needed all the help I could get.

The result?

Another cliché programmer who just wanted to code and be left alone.

People are shaped by environment

Too many managers believe the problem lies with Jamie. If he was a better employee, dedicated worker, or at least cared more, then this wouldn’t happen. Right?

Unfortunately, no.

The transition from enthusiastic programmer to polarized programmer doesn’t happen overnight. But it starts sooner than you think.

The first suggestions matter a lot

How you handle ideas from new programmers sends an important signal. Good or bad, it sets the stage for what they expect. This determines if they share more ideas in the future… or keep their mouth shut.

Sure, some ideas might not be feasible in your environment. Some might get put on the back burner to be discussed “when we’re not busy”. Some ideas seem great, but they run against unspoken cultural norms.

No matter what the reason, dismissing or devaluing your programmer’s ideas — especially in the first few months — is a bad move.

Damaged by all the naysaying, he’ll try a few more times to present his ideas differently, aiming for a successful outcome. If he continues to feel punished, though, he’ll realize that the only way to win is not to play.

Which is exactly what you don’t want your programmers learning.

He will stop presenting ideas, asking to meet customers, and genuinely trying to understand the business.

Ultimately, it’s a lose lose.

The bigger the idea, the bigger the risk

Remember that your programmer is taking a risk when they offer a new idea. The bigger the idea, the bigger the risk.

Why is it a risk? Because our ideas reflect ourselves, our views, and our passions. We don’t advance ideas we don’t care about, or that we think won’t work. We put forth our best ideas with the hope they will be received.

This requires vulnerability, which only happens if we’re fairly certain we won’t be humiliated. If we believe our ideas won’t be accepted, we stop offering them.

Feedback about ideas shapes behavior

It’s only natural, then, that your programmer is reduced to doing only what brings him success: coding.

His enthusiasm for creation, innovation, and development, sadly, are lost.

Perhaps it transforms into an unrealistic ideas about code quality or code metrics.

His concern for market share and business health is replaced with a concern for titles and pay scales. He becomes more worried about how much he earns, what his title is, and how he looks on LinkedIn.

His enthusiasm for changing the world is replaced with nit-picking the development process.

Worse of all, though, his concern that “We aren’t building the right thing” will be replaced with “We aren’t building the thing right.”

He’s learned to not give input on what is built, so he becomes obsessed with how it’s built.

Your culture, for him, has become survival of the fittest.

What’s your onboarding teaching?

While you would never say this directly, your onboarding and culture may be teaching:

“Our company doesn’t like big ideas from little people.”
“You just focus on building stuff. We’ll figure out what the customer needs.”
“You are just a code monkey.”
“Hmm… why are you asking so many questions. Don’t you have coding to do?”

What is your real culture?

Culture isn’t the slogan on your wall, or how you describe your mission during an interview. Culture is the way people actually act, and what they actually care about.

Texas A&M Professor Ifte Choudhury states,

“A culture is a way of life of a group of people — the behaviors, beliefs, values, and symbols that they accept, generally without thinking about them, and that are passed along by communication and imitation from one generation to the next.”

If you wonder what kind of culture you have, start watching how people behave.

If you don’t like what you see, change it. Culture isn’t dictated. It’s learned, modeled, and imitated.

As a leader, it’s your job to be worthy of imitation.

Because the culture isn’t Jamie’s fault. It’s ours — Team Leads, Software Managers and CTO’s.

So, stop blaming Jamie and start making the changes that your culture demands. The sooner, the better.

P.S. Part 2 of this article is here