Brilliant, But Stuck
You’re one of them — one of those 10x developers. The cream of the crop. You know how to build things, and build them well. Technical challenges don’t scare you — you got a track record of getting them done. People like working with you, because they know they will learn from you. In fact, people join whichever company you work for, just_ to be able to work with you. Recruitment loves you.
Yet, not all is perfect.
Your company doesn’t appreciate you fully. Sure, they like the stuff you build. But you know you don’t live in a vacuum. You work with other teams from time to time, with management, product management, sometimes even top management. Whenever you have a significant idea, or point out problems outside the realm of your own code base, somehow things don’t happen.
You feel slightly ignored. Initially, they listen, but somehow any initiative you take dies out. Somehow achieving something bigger in the company doesn’t happen. You’re stuck. Stuck in the group of people you hand picked to work with you.
Why?
Well, obviously because other people don’t see how good your ideas are, or they’re afraid of change, or just don’t care. Or perhaps it’s their culture. Also, other people are incompetent and probably simply stupid.
Yet, reflecting back on your career thus far, this has been a recurring issue.
You worked for many companies, and every time you and your team were the only competent ones. The powers that be, and other teams, didn’t get you, didn’t listen, didn’t do anything with your suggestions.
Hmm…
Maybe… just maybe, is it not them? Perhaps, possibly, is there any chance this may have to do something with you?
If so — _hypothetically — _what could the problem be? Intimidation through brilliance?
Let me ask you this: are you somebody who tells it like it is? Are you a “truth teller”, if you will? If so, looking back at all the time you “gave feedback” or made suggestions outside your direct realm of influence (your team) — did things die out practically immediately after telling people what you thought?
If so, your problem may be communication.
No, sorry, let me rephrase that: your problem for sure, without a doubt, is communication.
Shudder
Communication — that’s what managers do, right? Meetings and shit? You’re an engineer, your job is to write the codez.
You may think that, and continue living with that assumption, but here’s what I found:
You can be the smartest person the world, have the best ideas in the world, make the best observations in the world — if you cannot share them in a nonviolent way, they’re worthless._You may as well not have them_.
If you cannot share good ideas or changes to make in a constructive, nonviolent way, the only way to make any of them happen is within the small group within your direct control, which self-selected (that’s a fancy way of saying: people left when they couldn’t take it anymore, or only joined after accepting a job after you berated them). You cannot “scale” if you cannot communicate nonviolently.
What do I mean when I say “violent”?
Some examples:
- “The way use your editor is pretty stupid, use split views and keyboard shortcuts dude.”
- “Your code quality is pretty bad.”
- “Your code reviews are a joke.”
- “You’re doing ‘hero programming,’ not real software development.”
- “You’re wasting our time with your meetings.”
- “You’re doing it all wrong.”
This is language that judges (unfavorably).
Here’s a quick way to detect such language — think about how you would feel (shudder) when somebody says this to you (not the awesome you that you are, but a slightly less superior you). Would you feel good or bad? If bad — it’s probably violent communication.
You may say — “I’m just telling people the truth, they should be able to handle that. And if they can’t — tough cookies. Grow a pair.”
Of course, you may be right. But reality is this: this is the belief that brought you where you are today. How’s it working out for you?
Of course, the world should work differently, attitude shouldn’t matter, just skills and ideas, and_sure, you can wait for this to change. Any day now!_ Maybe in your next job things will be different.
You may find, however, that the group of people that respond well to violent communication is shockingly small. Some may accept it, but most people will just consider you an arrogant dick, and ignore you as much as possible.
So what’s the alternative? Keep your mouth shut? No, of course not.
Nonviolent Communication
I’ve written about nonviolent communication before, but the essence to me is this:
Stop mixing observation with judgement, in fact, stop judging altogether. Focus on constructive ways to move ahead.
Which raises the question: what’s the difference between observation and judgement? Observations are objective(nobody can disagree with them), judgments are subjective (some people may disagree, most likely: your audience).
Let me give some examples (most important phrases are marked in italics):
Judgement: The way use your editor is pretty stupid, use split views and keyboard shortcuts, dude.
Observation with constructive feedback: I noticed that you keep switching between windows in your editor with your mouse, have you considered using split views and keyboard shortcuts to switch between them?
Side-note: fluffing up judgmental terms like “stupid” with adjectives like “a little”, or “pretty” doesn’t change the fact that you’re judging.
Judgement: Your code quality is pretty bad.
Observation with constructive feedback: I noticed you have a lot of uninitialized variables. The risk of those is that it may lead to undefined behavior. Have you considered using tool X that can mark those and help you to quickly get rid of them?
Judgement: Your code reviews are a joke.
Observation with constructive feedback: I’ve noticed that the focus of code reviews is a lot on indentation and variable naming. I think there may be more value in focusing on architectural issues. Perhaps we can come up with a way to work those into the code review process?
Side-note #1: something being “a joke” is not an observation — we all have different senses of humor, and what your team does during a code review may differ from others, and that’s not necessarily bad (“bad” — look at me using judgmental words).
Side-note #2: “there may be more value” sounds like overly soft language, but it opens up the chance that, at the end of a constructive conversation, you may be proven wrong. Even though you think you’re infallible, there’s a chance (however small) that you’re not, and there may be other valid points of view. Being careful with definite statements like “there is more value” is sensitive to that.
Judgement: You’re doing “_hero programming_,” not real software development.
Observation with constructive feedback: Whereas the number of features you finish is impressive, I also see that many of them don’t have any unit or functional tests associated with them. This makes me worried about future maintenance, and edge cases not being handled. Have you considered requiring some sort automated testing for all new features?
Judgement: You’re wasting our time with your meetings.
Observation with constructive feedback: We have a daily meeting every day, but it _appears_we are sharing things that everybody already knows. Is there anything we can do to make this meeting either more valuable, and if not, at least reduce its frequency or remove the meeting altogether?
When you use judgmental language, people will only hear the judgment and nothing else — any valuable advice or idea around it becomes white noise.
When you judge, you piss people off — whether or not they tell you, or show it. Pissed off people are remarkably uncooperative. For sure, they’re not going to help you, or take your ideas seriously.
And there you have it.
Communication, it really matters — we all wish it were different, but that’s life. Consider giving it some serious thought. As a starting point, read my previous article on NVC.