The most popular article I’ve written is called Why your programmer just wants to code. To date it has received over 62,000 reads.
(The third part of this series, how programmers can change their environment, is here)
The article tells the story of Jamie, a programmer who joins a new company full of enthusiasm and ideas. Fast-forward a couple years, and Jamie is one of those programmers “who just wants to code.” A programmer who doesn’t contribute new ideas, doesn’t offer new ways of doing things, and just wants to be left alone to write code.
Sadly, I received almost no response from managers or leaders about this story.
It appears some of you missed the point, so let me be blunt.
Tech managers, these situations are your fault.
You must accept responsibility for unmotivated programmers who “only want to code” or who appear to be concerned only with flashy, new tech.
As the leader, you are responsible for creating an environment where everyone can contribute to solving the problems at hand.
Instead it appears many programmers are treated like idiot savants; brilliant children capable only of coding.
Stop it. Seriously.
The massive response to this article should scare the hell out of you. The market is hot, giving them the power to resign and replace YOU with a better leader.
I get the sense that they are mad as hell, and aren’t going to take it anymore.
Don’t believe me? Read on…
I wrote the article in hopes that leaders would recognize that programmers want to bring their whole brain to work, but too often the environment prevents them from doing so.
Instead, I received thousands of responses (claps, comments or message) from programmers who wish their managers paid attention. Who wish their culture welcomed, discussed and debated ideas.
Some of the comments which stood out are…
“Omg preach! ???????????????????????? This “idea/feedback negging” phenomenon is the deadliest innovation killer of all the land, and it hurts every department (not just a coder problem). “
“I came in to the workforce guns blazing, ready to make a difference. Now, I struggle to suppress my true thoughts everyday and just deal with how things are… I REALLY hope leaders start figuring this out soon.”
“I went through something similar, I even stopped working on my pet projects because coding at work was sucks and demanding, glad I just left them after 5 months!”
“It’s sad that actually the coding culture in my current environment is that programmers are merely interested in finishing a task instead of thinking of sharing ideas.”
Hasen takes a slightly different view.
“What we need is not “acceptance” of ideas. We need to see our ideas discussed and debated, and then see that the decision is based on the merit of the idea, not our position.
If I present an idea and it gets discussed and then dismissed, that’s ok.
If I present an idea and just get told that I should not do that and just focus on my current assignment, well then that is a clear signal that I’m not allowed to do anything but comply with orders like a grunt.
When that happens I’ll basically be looking for the next job.”
That last one sums it up. Create an environment where your programmers can fully contribute, or else the best ones will leave.
Let’s get real. If you see this problem on your team, it’s not going to fix itself overnight. BUT, you can take huge steps toward reversing this problem.
Let’s change things.
Start Listening and Stop Telling
If you’ve got developers who just want to be left alone, today is a great day to turn things around.
Start in your next 1:1 with them. (Don’t have 1:1s? Use my guide to start today.)
Step 1: Be humble.
Have a reset conversation with each team member, where you honestly ask if you’ve been deaf to their ideas, treating them like “resources”, and frustrating them.
Regardless of what they say, tell them you don’t want to be that sort of boss, and that you’re sorry. (Yes, it is good to apologize to people you may have hurt. Yes, even if you’re the boss.)
Next, tell them you need their help. You rely on their feedback to improve. Give them permission to stop you the next time you do it, and to give you feedback in private about your behavior.
Finally, thank them for being there, and all their hard work. Thank them for listening, and helping you grow into the kind of manager they need.
Step 2: Listen more, tell less.
In all your interactions with the team, talk half as much. Then, half as much again.
This will probably catch them off guard, especially if you’ve been “leading from the front” and telling them what to do.
Instead, listen to how they talk to each other. How they talk about customers, bosses or other teams. Who controls the flow? Who’s still trying to put ideas out there. Who seems completely shut down?
See if you can get everyone to participate through open ended questions. Consider using a “talking stick” if some people suck all the air out of the room. Gently set expectations that you want to hear everyone’s contribution to solving problems.
Step 3: Ask more often than tell
Most engineering managers take the default approach to telling engineers how something should be done. This is probably because they used to be engineers, and they “see the answer clearly.”
Yet, telling doesn’t build the team up, it shuts them down.
So, start asking more questions. Lots of WHY? questions. Of course, you have to tap into your curiosity and lean in to hear the answer.
Truth be told, you depend on them to get the work done, and you depend on them to make a million small decisions. You should be very interested in what they think, and bringing their ideas to light.
The book Humble Inquiry by Ed Schein is a wonderful resource for learning to ask better questions.
Tech leaders, you’ve got work to do. You’d better start pulling all-nighters to fix things, before it’s too late.
-Marcus Blankenship, Hacker, Problem Solver, Calvinist, Geek. Author of Habits That Harm Your Technical Team.
This post was originally featured on Hacker Noon.
Interested in reading more?
Check out Why your programmer just wants to code and Interjecting in meetings.