This one goes out to those of us who are always right.
Earlier in my career, I took a lot of pride in being the person who was the quickest to find potential flaws and match them with an immediate solution to a problem. In fact, I felt like I saw all the problems.
Before I arrived at Uncorked, I took my background in electrical engineering and computer science and used it to design and develop medical devices, which had a specific kind of gravitas—any decision you made could impact someone’s life.
So I was trained and conditioned to enumerate all the possibilities quickly in my head. And, given a healthy dose of professional ego, I thought that meant that my ideas were the best and that I was the best. As such, when my decision-making technique earned me a management role, and I started to delegate tasks, my folks would receive step-by-step instructions on how to accomplish any task Lee’s Way.
And guess what? That didn’t work. No one ever did it the way I told them to. And I didn’t get it. I was giving my people the solution! All they had to do was copy it.
But then, something unexpected happened. The tasks got done anyway. And they even worked. In fact, the less direction I gave, and the more trust I put in others to come up with a solution, the better the results were. Turns out, other people’s solutions could be better than mine. And, when you give engineers a challenge, part of the fun comes in figuring out how to solve it. I was literally sucking the fun out of people’s lives.
It seems really obvious, but at the time this was really counter-intuitive to me. And it brought on a major case of impostor syndrome. It felt like my intuition was flawed. My carefully honed deduction skills were
How I Busted My Ego and Opened Up
Along the way I’ve experienced a few things that have helped me overcome this anxiety, which I want to pass along to technical people who are realizing, for the first time, that there’s more than one right way to do things.
Questioning your intuition makes you slow down, approach the problem differently, and seek input from others with different experiences than you. Here are a few ways I’ve seen this come to life, from a more practical perspective, in my time at Uncorked…
Seek Input from Others
Once, after unveiling an internal product at a big conference, we decided to synthesize what we had learned from the experience in something we call a Semio Session. The first task in a Semio Session retrospective is to write down any questions we have about the topic as a whole. Writing down questions was the easy part. I wrote down my big worries, as did everyone else. But I couldn’t quite understand why some non-technical members of the studio were in the room. What did they have to contribute?
As others began to read out their questions, something struck me. Despite spending several months deep-diving into this product and its problems, the questions asked by others in the session, specifically the ones in non-technical roles, were way more interesting and insightful than my own. In fact, given a million years I probably would have never have come up with questions half as insightful. So I began to embrace these alternate points of view and see similar insights pop up all over the place, from all sorts of people at every level. This diversity of thought helped me bring back a broad set of insights to my work.
Approach the Problem Differently
I took the gulp.js tool I had seen in a web project and began to use it to autosave my firmware projects, ssh the binary to the destination and flash it. Archaic firmware paradigm, meet automation tool for the modern web. I know this line of thinking suggests mobile developers should learn web development and web devs should learn some firmware stuff and developers should learn some design principles. My point is that you never know what other paradigms are common practice in other fields that could be useful in your own work.
Break out of your mold and try something new. I had to put aside my ego to realize this, and embrace a different set of tools to solve a problem.
These learnings go beyond software development. We praise speed, and individual achievement, often at the expense of consideration and deep thought. Don’t work on your ideas in secret. Take that startup idea you have been ruminating about, share it with others. Let them challenge your preconceived notions. Get colleagues to test the app you’ve been designing in your off-hours. You can learn a lot just by watching how someone interacts with it. Not everyone swipes the same way or is drawn to the same part of the screen as you. They’ll give you invaluable data that you wouldn’t have come up with. Sharing something you’ve worked hard on will make you feel vulnerable, and can take extra time, but you will learn things you never would have alone. I’m always amazed when I give an app to someone how they use it in a way that’s different than what I’ve anticipated.
Like I said, this seems really obvious. But we get caught in the trap of not inviting different types of roles and different types of people into brainstorming sessions. We get locked into using specific toolsets or paradigms or systems to solve problems. We don’t slow down and gather feedback from broad groups.
So, before you come to a crisis of confidence, like I did, remember it takes all kinds of minds and perspectives to create an experience that people will find useful, thoughtful, and, will hopefully love.