I was 24 years old, a programmer at my first job, sitting in a meeting with a bunch of colleagues I admired working on a tricky problem. I thought I saw a way out of it. Yet I was terrified to speak.
I rarely spoke in these meetings. These were all people I looked up to. They had taught me much of what I knew about programming. They were all, whether they knew it or not, my mentors. I desperately wanted to feel I belonged with them. And yet I thought they were on the wrong path.
The most exciting moment in programming is not when you finish the code, when the solution first comes into view; a heady, shallow-focus moment when you get close enough to believe you can solve something that once seemed impossible. Surroundings dissolve. Adrenaline bubbles like soda in the veins until it burns the nose and excites the blood.
Thump. Thump. Thump. My heart was pounding. And yet I was paralyzed. The solution I was about to propose was different from the path my mentors were currently pursuing. What if I was wrong? It would prove to everyone that I wasn’t one of them.
Thump. Thump. Thump. I felt my breath draw in almost by accident, and then I heard my own voice. The words came out in a free fall. “Ithinkinallcasesthedecidingfactoristherecordstatus.”
My boss looked at me. Everyone, in fact, looked at me.
Thump.
Thump.
Thump.
“She’s—-she’s true.” The guy leading the meeting was so surprised he tripped over the words.
Within seconds, the team took that little nugget and ran with it. Within a few minutes we had assigned roles and figured out what to do to get past the problem. I barely noticed. I should have been excited, but I was mostly just glad I wasn’t wrong in front of all of these people I admired.
I’ve remembered that moment over the years. Although I now have years of practice of speaking my mind, I can still feel that aching need to be aligned with the people I admired. There is safety in sameness, a promise that we won’t be ridiculed. I can still smell that reckless and thrilling feeling of saying something my mentors might disagree with. But mostly what I remember is the saccharine taste of relief that was less about the fact that the problem was on its way to being solved, and more about not having to face separation from those I longed to be like. They accepted my idea, and by extension, me. I was safe.
A few years after that heart-pounding meeting, I founded a tech company to build custom apps and software for people who had ideas but didn’t have the skills to execute themselves. Since then, I’ve sat around a lot of tables with passionate people who wanted to solve challenging problems for themselves and those around them. Our team has taken on issues as diverse as getting air ambulances where they need to be when seconds count, to replacing the traditional wedding guestbook with something more memorable and fun. Thought it all, I’ve found that people are hard-wired for the drive to make an impact, but often our egos and insecurities hold us back.
As we begin our careers, many of us have people we look up to. We draw inspiration from them, even ideas, quotes, and mantras. We absorb their ideas like sponges, hoping the magic will rub off on us.
In today’s climate, we constantly acquire even more people to look up to. Our accelerated hype cycle means there’s a steady flow of standards and rules that the current flavor of the week has ordained. Wear this, say this, do this, think this. The best result that can ever come from this is a convincing forgery of someone else’s art.
In order to create our own magic we must take in those norms and then eventually come up with our own ideas which differ from those that have gone before us. And there’s the catch: to truly contribute, most of us will eventually have to disagree with our mentors. That means risking feeling alone.
Most of us know that a preoccupation with imitation will never lead to a breakthrough. No one films breathless biopics of people who did exactly as they were told. This leads us to a fundamental truth.
It has to be different to make a difference.
Yet that can lead to another problem. We, as a society, are oddly fascinated by the first doer of things. At times, we become paralyzed by the idea that we must be the first and only one to ever do something or it has no meaning.
“First” stories are mesmerizing. The first airplane flight. The first use of an antibiotic. The first computer. We long to know that new ground has been broken.
For all of the celebration of newness, for that “first” to matter, the story cannot end there. There must be a second attempt, and a third, and probably dozens more after that until the discovery is refined enough to have value in everyday life. Many of the things we rely on today were not the first of their kind. MySpace came before Facebook. Those Nokia brick phones came out years before the first smartphones. Laser discs preceded DVDs, which have gone nearly obsolete in favor of streaming media.
Those firsts mattered because they changed the collective vector of thinking, but it’s often the subsequent efforts that get us to where we need to be to truly change how we live. The fact that others are working on the same thing doesn’t mean we’re irrelevant — it’s evidence that we’re working on a problem that matters. And that leads us to the second truth.
You don’t have the be the first or only to matter. Competition is validation.
Turned around, these point us to two limiting constructs that pervade our culture. Many of us have one or both of them lurking in our thought patterns. They are:
I must be like those I admire to matter.
I must be the first and only to matter.
We have to kill these limiting beliefs to progress, and it has to be a systemic choice. That means not only modeling but actively cultivating an environment that nurtures budding ideas and the people behind them.
Since as all things, there’s more to it when it comes to the implementation, I’ve put together some tips that have helped our teams through this process over the years.
The Practical Stuff
Once we’ve stripped out the limiting beliefs that hold us back, we’re ready to get down to work. Here are three specific principles that help.
Intentionally Involve Multiple Diverging Perspectives
We might expect forward motion to be the result of a single idea moving forward cleanly in a straight line, led by its original creator. But that’s rarely is sustained progress the sole work of one creator or team. I think of it more like a braided tree trunk, with various threads crossing each other and coming together for a moment before diverging.
In fact, we often seem to do better when we have a little competition. For some of us, this is the pure drive to win. In many cases, though, I think there’s something more fundamental at work. Have you ever been stuck on a problem for hours, and then ask a co-worker, and they immediately see the problem and point it out? Why do we miss things that are right in front of us?
A concept called cognitive dissonance makes us value things more highly the more we’ve invested in them. We can’t handle the idea that we might have shown poor judgment in that investment, and so we are likely to continue committed to the same rut, I mean, path. This persistence sometimes pays off. But often there is a limit to how far one idea can run.
This is why our co-worker can so easily see what we miss. That person hasn’t made the same investment in idea 1.0 and so they don’t have the same attachment. They’re willing to see it tossed aside. And that’s how idea 1.1 comes to be. Idea 1.1 is often far superior to idea 1.0. We’ve taken the proof of concept and refined it into something more useful. In our office, we’re often at idea 1.4 to 1.9 before we really feel we have a home run. It’s interesting that we as a society place so much emphasis on 1.0 and take the upgrades that make it work for granted.
I watch this happen in companies attempting to push the envelope all the time. One person suggests something, and that suggestion threatens an idea that we are attached to, so we try to cut it off at the knees. It’s hard to move the conversation forward this way, yet most of us do it all the time. I am guilty of it myself on many occasions, especially if I feel like the other answer means I have to rethink something I had settled in my mind or will cause more work I don’t feel I have time to do. I remember a time when we were talking about how to do something a bit tricky related to securing data across multiple tables. I had learned a pattern for doing this years ago, and had assumed the team would stick to that pattern. When it came time to review the implementation, I found they had gone in a different direction that was different from what I had been taught. My immediate reaction was to see red. Here I was, responsible for the security of this data and they had defied the way I’d told them to do it? I could just see the ramifications. We’d fail an audit. We’d lose trust. It would be all my fault. There was no way this new way could be correct.
The team pushed back. They’d researched the method. It was touted by respected sources. It was the right way to do it today, even though there had been a different script years ago. The industry had advanced.
Something was buzzing around in my mind, wanting attention. Something telling me that maybe my issue here was not that I actually knew the answer and what they were saying was factually incorrect, but that this was about fear. And it was. When I followed the feeling to its root, I found I was upset because I had invested my feeling of safety in the pattern I had memorized years ago. I was worried that I wouldn’t be able to get to the same level of confidence with a new solution. It threatened my feeling of security, so my instinct was to fight it.
For what it’s worth, my team was right, technology was allowed to progress, and all is well. But if they hadn’t felt comfortable hitting back, we might have stayed stuck in an outdated solution.
Take, by contrast, a more useful discussion. One person says something. The next person takes the time to understand it, and uses that as a building block and adds something meaningful that enhances the discussion. The third person builds off of that, and so it goes on and progress is made.
This means that to solve problems that matter, we can’t rely solely on a singular visionary, team or idea. We have to have parallel and sometimes competing visions in order to keep advancing.
What’s interesting is that this entire ideate - implement - refine process can only work if you feel safe to offer an opinion that differs from the conventional wisdom — or your boss’ wisdom. That is, it only works if we’ve already cast out the first limiting belief, “I must be like those I admire to matter.” Once we are working from a healthy mindset, here are some strategies to cultivate varying viewpoints:
Include all relevant perspectives up front. The typical argument I hear against this is efficiency. What’s the efficiency gain in having an extra person in two hours worth of meetings vs. having to redo weeks or months worth of work when that person is finally asked their opinion at the 11th hour? If they’re a stakeholder, they need to be a part of it from the beginning, not brought in at the end to rubber-stamp a flawed project. Also, look at the list of people objectively and with fresh eyes to be sure that you don’t reinforce any previous exclusionary practices. If the last effort on this topic failed, consider if some faces might be missing from the table.
Seek out naysayers. A related tip that warrants being specifically called out is to avoid the echo chamber. Make an intentional choice to include those with relevant but different viewpoints. This may not be easy. It takes a lot of confidence to volunteer for a project where you know you’ll be outnumbered. The people with the viewpoints you need may self-select out initially. Make a specific effort to recruit and include those who know why your idea could fail.
Build dissent into the process. Everyone should be involved in both giving and receiving feedback, so it becomes a natural part of the process instead of a tool of power where one person’s opinion must always be right. It’s also important that the feedback is visible to all and is followed up on. At Entrepreneurial Technologies, one way we do this is through putting each piece of code through a peer review before it’s incorporated into the project. This also means we make it okay to tell someone you disagree and okay to admit your idea is flawed. For those in a leadership position, one of the best ways to do this is to model it. If we as leaders are okay with admitting we don’t know something, with having our ideas challenged, and with getting excited for others when they have a new idea, that puts everyone in the right headspace to grow. I’m not saying this is easy (see cringe-worthy moment above).
Have at least three viewpoints. There is a seemingly arbitrary rule of thumb that seems to get things unstuck: having not just two, but at least three perspectives. With two, you tend to get locked into a battle of one person’s will against another. With three, there is a recognition that each person must listen to the others to find a way forward.
Understand first, solve second.
Once you have your viewpoints assembled, we want to squeeze every ounce of information from them that we can. They are our most valuable asset. And yet we tend to skip over this step.
I remember in high school English, we spent time memorizing what seemed like a million grammatical rules, especially the rules of comma usage. When a student pointed out that great authors such as James Joyce and Gertrude Stein often broke these rules, the teacher said, “If you know the rules, you can decide when to break them.”
You might be tempted to dismiss this as a witty comeback for a beleaguered English teacher trying to convince his students to give attention to something pretty tedious. Yet there’s a hidden truth in this, that in order to make a better version we must first comprehend why the traditional way is the way it is.
In order to innovate, we must first seek to understand that which we want to improve upon.
Early in my career I noticed that if I kept learning more and more about the problem, eventually the solution became obvious. Each piece of information eliminates or reinforces a direction, until it’s clear to everyone in the room which way things need to go next. It may not feel as thrilling as pulling an idea out of thin air, but it’s much more effective. Until we deeply understand the problem, we’re not qualified to offer a solution. Yet we rush in to try to solve it with minimal information.
Again, this is most often about ego. Our ego wants to convince others that we are geniuses who magically create solutions that no one else could possibly have thought of. Rarely does this actually work. People often take the Henry Ford quote “If I would have asked people what they wanted, they would have said faster horses” to imply that visionaries pull incredible ideas out of a vacuum. But the hidden nugget here is this: Ford understood the needs of his audience. He knew they wanted faster transportation. That was the key to his invention. He didn’t ask them how to solve it, because that was his job. But he deeply understood what they yearned for, and that was the problem he solved.
We can do this in our own teams too, by making a conscious choice to let go of ego-based desires to make ourselves the stars, and immerse ourselves in learning before solving.
Here are some practical tips to do this:
Kill the magician mentality. We are not here to be all-knowing experts. We’re here to learn and apply. Replace a desire to look smart with a desire to be of use. It’s less stressful for everyone, but that’s not the main benefit. It allows people to set aside the insecurity that makes us rush to be right, and instead focus on making things better. If you feel like someone is expecting you to wow them with magic, communicate the need to learn first to adjust their expectations.
Use time wisely. There’s a tendency to waste face-to-face time with relevant parties (users, clients, etc) getting their buy-in on solutions before we have truly understood the problem. Try flipping that perspective to understand that first and foremost, these people are your eyewitnesses. They understand the problem intimately. We try not to ask leading, solution-focused questions like “would you like a button here?” which rarely produces useful answers (users don’t know if they want a button there or not until they try it — what they know is that they want their problem solved). Instead, try open-ended, problem-focused questions like “tell me how this process works in real life.” or “What is the hardest part of the order entry step for you?”
Protect dissenting opinions. In the previous step we covered the need for people who disagree. Now we have to make sure they are heard. If you are trying to solve a problem, you may at times find that you don’t have the resources to solve it completely and so you have to settle for a solution that solves part of the problem. That is sometimes a rational choice at the problem solving stage. What tends to happen though is that we cut off discussion during discovery and rush to get to consensus, steamrolling anyone who doesn’t fall in line. Make sure if there is a dissenting voice that you take extra care to champion that message. Get all of the facts out. Sometimes that dissenting viewpoint reveals a critical truth that others are too afraid to voice. Understanding that point of view can make your solution that much stronger. Bonus: people who feel heard are more willing to collaborate, even when they know it will involve compromise.
When in Doubt, Focus on Your Purpose
Some problems are interesting to solve for their own sake. If you’ve ever lost 20 minutes of your life to messing with a Rubik’s cube, you know how this happens. I’d suggest though that there is an ego component to this. Sometimes we want to solve something to prove that we can, not because it advances an overall goal.
In technology, you have a collection of people who have chosen to spend their lives tackling problems. That means that the people who self-select into these fields tend to be those who see this as a thrilling challenge rather than a scary unknown. And for many, there’s a portion of the thrill of problem solving that is about me vs. the problem. Can I conquer it? Am I smart enough, creative enough, or tenacious enough to figure it out? That craving is what allows us to keep trying. But when it goes too far, it becomes a terrible place from which to solve a meaningful problem.
History gives us a tragic example of this in Sir Douglas Haig. The British WWI general came to his post with few successful previous campaigns and a wealth of unearned self-confidence. Despite the evidence that the face of war was evolving through the use of machine guns and tanks, he persisted in his belief that the cavalry would save the day. He decided to mount a campaign of attrition at Somme, France over his colleagues’ objections. He lost 60,000 men on the first day, and still refused to believe the evidence that marching in slow, straight lines was suicide in the face of machine gunners. Ultimately, he lost 400,000 men at Somme. And still he remained committed to his failed tactics. What was the problem? Why couldn’t Haig see what was plainly in front of him?
His ego had become attached to his original plan. He couldn’t back down his ego was wrapped up in the idea that he was the genius and his plan was the best. And that brings us to another important lesson.
To accomplish things that matter, you must be more attached to your purpose than to your plan.
Plans are enticing. They’re concrete. They make us feel smart and secure. But we can easily fall into the trap of mistaking our plan for our goal.
How do we combat this?
Connect to the story behind your purpose. Meet the clients. Visit the job site. Interview the users. Allow your team to do the same. If they can call the user(s) by name, talk to them, understand their personalities and goals and dreams, they’re going to feel a much stronger connection that purpose. It’s why fundraisers for awful diseases feature stories of particular people, not grim statistics — it’s the story that moves us to act.
Ignore sunk costs. Whatever is spent in terms of time and effort, is spent. It has no bearing on the right course forward. Imagine you were starting from zero, today, balancing the costs and benefits of the plan moving forward. Does it still make sense in that light? If not, it’s your ego holding on, not your purpose.
Create a “No I Told You So” culture. Our ego wants it to be about one idea (aka person) winning and another losing. On the other hand, changing course with new information is a trait of successful businesses and individuals. We need to allow this as a normal part of our operations. When we feel that “I told you so” culture creeping in, we know we’ve strayed from our purpose and it’s time to re-align.
These are all nice ways of saying we have to get over ourselves the need to prove how smart we are to get down to the business of solving problems. It feels good to shed that useless pressure. And it’s the best way to do things that matter.
***
Erin Rollenhagen is the founder of Entrepreneurial Technologies, Inc. and the author of Soul Uprising: It’s Never Just Business. You can connect with her on LinkedIn, Facebook, Instagram or email, or take your chances on her sporadically-monitored Twitter account.