The forbidden word

Early in my time at an early-stage LLM startup, my skip-level gave me the following nudge (paraphrased):

Don't use the word "impossible". We are making computers talk.

It honestly caught me a bit off guard. I've always been one to question everything and challenge assumptions. In fact, I was expelled from religious school in junior kindergarten for that same reason.

It's true, the word "impossible" should not have been in my vocabulary. It was sobering to realise that I was being close-minded, or at least imprecise. I resolved never to do so again.

I grabbed a permanent marker and a sticky note. I attached the note to the interior of my laptop, next to the trackpad. Here's what I wrote:

NOTHING IS IMPOSSIBLE

Nothing?

Before you "well actually" me, I'm also not saying that everything is possible. What I actually believe is that nothing is impossible in the absolute; things are only impossible if we accept some priors or constraints.

Now, it's not realistic to re-evaluate every prior every time. I'm not suggesting we litigate whether the formula for water is dihydrogen monoxide. The important part, in my view, is to reframe our thinking to consider that there is a hidden "because" clause here.

For example, it is impossible for parallel lines to meet because they remain a fixed distance apart. This is true under Euclidean geometry, but in projective geometry, these lines meet at infinity. Even this apparently basic fact of mathematics rests on priors.

Unspoken constraints

By dropping the "because" and neglecting to mention the priors, I was engaging in a form of laziness. I had considered the problem and decided that it wasn't feasible under the current constraints, but stating them explicitly felt like a waste of time. I know this was a learned behaviour formed through my desire to create focus and cut through the noise, but it was still lazy.

Consider an example. Let's say someone tells us "Alice needs to ship Feature X within two days". We know that this request as stated is unrealistic. Simply saying "that's impossible" doesn't give us a path forward. Instead, we should consider how to make it possible.

What are the constraints that make the situation supposedly impossible, and can we change them? Perhaps we can adjust the expected timelines, the priority of Feature X or other work, or how work is being allocated across the team. By flagging the constraints, we reframe the situation into a solvable problem.

Unexamined possibilities

At my next job, a publicly traded biotech company, I encountered a much more frustrating use of the word "impossible". When I questioned decisions or suggested alternatives, I was sometimes told that my proposal was impossible. In this case, "impossible" was an assumption, not a conclusion.

Often, the proposals were both possible and fairly ordinary. The people rejecting them may not have understood the path forward, or had the space to explore it. I empathise: it's more comfortable to call something impossible than to admit that we don't know how to do it. Challenging our thinking is tough, but necessary for growth.

Unfortunately, this tendency was cultural, and I couldn't change it on my own. Of course, culture is greater than any one individual! I also worked with a lot of wonderful, curious, intelligent people, some of whom I still keep in touch with. As I proved my expertise over time, I earned more trust, which turned into influence.

Sharing the lesson

My current workplace, another early-stage startup but in the telematics industry, has a very different culture. Despite listening for it, I never heard the word "impossible". Instead, we constantly say "what if" and "how about". Difficulties are something to explore, not a reason to shut down.

The brief exception came when an intern joined our team and was struggling with writing code. They sometimes became frustrated when they encountered tasks they felt were "impossible", despite clear instructions and patient guidance. Not understanding the next step would lead to a mental block.

A representative example was a small task to filter a list. Our product integrates with upstream APIs, and one upstream endpoint was returning all users, while we wanted to filter for only the users who were drivers. The task required a one-line addition to the transform function.

Here's some pseudocode:

const users = [
  { name: "alice", role: "admin" },
  { name: "bob", role: "driver" },
  { name: "carol", role: "driver" }
];

const drivers = users
  .filter(user => user.role === "driver") // "impossible"
  .map(buildDriver);

What gave me hope was that this intern was a very curious person outside of software engineering. They asked plenty of questions about the business and about us as people. It was a 12-month internship, so there was plenty of time to extend that curiosity to work tasks.

So I sat them down and passed on the same lesson — that instead of calling something impossible, they should consider how to make it possible. It made a significant difference. They began approaching their work with more curiosity, asked questions when they had gaps in their knowledge, and gained more confidence.

This is real life, so I won't lie and say that they magically became a 10x engineer. However, they have become a valuable member of the team. They found their strength where software meets customers, and are making improvements to our documentation, product demos, and integration coverage. This work still requires them to confront the unfamiliar, and they're doing a great job.

Fin

I sent a message to my former skip-level, thanking them for the perspective a few years ago. Reframing my thinking in this way made me much better at what I do, and now it's helped someone else do the same. I hope that reading this article helps others too!