Wikipedia describes an ivory tower as “a metaphorical place—or an atmosphere—where people are happily cut off from the rest of the world in favor of their own pursuits.” As an engineer, I use the term ivory tower to describe a stereotypical coder or architect who cannot or will not accept criticism.
If the guy has become an ivory tower due to a cult of personality, you might hear people excuse his behavior with comments like, “He’s so smart he never has to write down any design decisions. He just keeps them all in his head.”
There are multiple reasons why we don’t keep design decisions in our heads including, but not limited to:
- designs of any complexity should be reviewed by others, which is impossible if it’s not documented somewhere;
- documentation provides the ability to look back, years later, to decide if the design decision still applies;
- and the most common usage, design documents exist so that others can understand it during implementation and maintenance.
Ivory towers are often groups of individuals who have final say on critical decisions, decisions that have ripple effects for years, that don’t seek out or listen to other people’s input. They are the corporate-appointed monarchs of development.
Ivory towers house the echo chamber for the good ol’ boys club and are usually led by the one guy who, with a smile on his face, will tell you to sit down, because the adults have made the decision. Or he’ll sneer and offer a satisfied smirk afterward.
An ivory tower might just be one toxic person that can’t take feedback and can’t believe you would have the audacity to give it. In fact, toxicity in teams is usually driven by a single individual. Most people strive to do good work, be kind to their peers and go home at the end of the day, but ivory towers are narcissists who feed on ego. They only want to hear praise.
This is the reality in the vast majority of dev shops. Usually it’s just one person or one group that behaves this way, but it puts strain on other teams. Why? If it’s the corporate-appointed monarch ivory tower making decisions without input, devs get irritated and angry. They want input into what they will be doing for the next year of their lives at work. They may have experience relevant to the technology decision and can give an honest answer about the trade-offs involved. They might know of a better tool. Nobody wants to repeat past mistakes.
I am always awed when I discover the depth of knowledge embedded in coworkers all around me, and the more I see, the more I accept how much I need their input to be successful. For every person who is willing to blog about the cool things they learn, there are a thousand others who have deeper knowledge that never write a single word, and sometimes, they can be found sitting right next to you.
Since ivory towers can be categorized under toxic work culture, they should be dismantled, but how?
Well, if I had the silver bullet to remedy the situation, I’d be in a different place in my life, but I have learned some effective tools to shift work dynamics. All ivory towers share the common trait of being incapable of taking feedback, and to be honest, I get it. Criticism is terrifying. Being told you haven’t made the best decision is hard to hear. If your self-esteem is tied to work, learning you might not be as good as you think you are can have ripple effects in other parts of your life.
I’m an author, and after writing my first novel, I had several people (who love me) fawn over the novel. In my ivory tower of self-congratulation, I shared my masterpiece far and wide until one friend read it and articulated its flaws. I was devastated and hurt. How could someone tell me my first novel wasn’t perfect? But . . . but . . . my mom loved it! After a bit of reflection, of course, I quieted my bruised pride and accepted the truth. She was right. I realized that accepting feedback was a crucial path I needed to take in order to get better. I forced myself to disconnect from my writing and accepted there was a lot about writing I didn’t know. Years later, after completing several publishable novels, I circled back to that friend and thanked her profusely for her honesty.
Accepting feedback gracefully can be hard, but it gets easier with practice. A lot easier. If you accept that your efforts cannot and will not ever be perfect, but the quality of your efforts can be improved by learning from others, the ego quiets down.
And therein lies the answer. Foster a culture of accountability, and divorce yourself from your work product. Ask your peers to go hard on your pull requests. If you’re early in your career, seek out mentors. Don’t encourage or participate in a culture of rubber stamping other people’s code. If you don’t have any suggestions for a pull request, ask questions. Show that you’re teachable. When you make a design decision, document it and ask for feedback, even if you only do it on a whiteboard. Be willing to be criticized.
Some of us haven’t figured out how to accept feedback, and there is no shame in that. I was one of those people, and I learned the embarrassing way, so I will share my methodology in the hope that it will help someone else avoid defensiveness and temper tantrums.
First I assume the person giving me feedback is correct, and I immediately attempt a paradigm shift in my head to see the situation from that person’s perspective. When I do this, questions bubble up. Can I get more detail? Since all decisions have trade-offs, what’s to be gained by changing the decision and what might be lost? Why did I think it was a good idea to do it that way? Is this a hole in my knowledge? Where can I learn more about this so I don’t make the mistake again?
Sometimes, I can’t force myself down the road to agreement, and when that happens, I request time to chew on it. While I’m processing, I dig for the good in what I’ve been told. Almost all of the time, I beeline to google to see what the rest of the world says about the problem. How have other people solved it? What pitfalls lie down the two roads?
Sometimes the person giving me feedback is correct, and when that happens, I’m grateful I wasn’t defensive. I usually shoot the person a note to thank them for teaching me something.
Sometimes the person is wrong, and I may send them the results of my research and ask for more discussion, or I may ignore it, depending on the other person's personality. Most of the time, however, we’re both partially right and partially wrong. The world of engineering and design is rife with trade-offs and few things are all one way or all the other. What may be right in one architecture might not be the best choice for a different architecture. What may have been right a couple of years ago might not be considered correct today. Give yourself and other people grace to make mistakes.
If someone has the courage to provide you real feedback, recognize what a Herculean emotional feat they made on your behalf. Since the inability to take feedback is so common, they know they risk upsetting you. Remember they are subconsciously making a decision about whether they’re going to go out of their way to help prevent your faceplant in the future.
Finally, when someone is correct, acknowledge them. It doesn’t have to be cheesy. It can be, “Thanks! I learned something new today.”
Funny things happen when you have the courage to be vulnerable. Stronger bonds form between teammates, and a culture of trust and excellence begins. Everyone gets better at everything which becomes a multiplier for productivity.
Do I expect an ivory tower to come tumbling down because I sought feedback on work products? No. That’s not how narcissism work, but actively requesting critiques changes the way other people think about feedback. Vulnerability gets normalized and more people jump into the fire asking for feedback, which results in all around better collaboration and an increase in the quality of your code. Meanwhile you grow together and rack up wins.
Later, as you glide past the ivory tower on your road to success, take a moment to look back and reflect on how far you’ve come and why not? If you’re so inclined, let your dog take a leak.
Top comments (2)
Thank you, Tami, for this!
Thanks for reading, Tyler! You're awesome.