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 constraint 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 missing "because" here.

For example, if a distributed log produces messages out of order, it is impossible to restore order merely by adding a downstream message queue, because we cannot recreate ordering from disorder without another source of ordering information. Even this basic fact of distributed systems rests on priors.

Lazy speaking

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 Foo Feature 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? Perhaps we can change the expected timelines, change the priority of Foo Feature or other work, or adjust how work is being allocated across the team. By flagging the constraints, we reframe the situation into a solvable problem.

Lazy thinking

At my next job, a 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. Even worse, I was told that I had too many ideas and made too many improvements — apparently making "more senior" developers look bad by comparison.

In this case, "impossible" was not a result of compressed reasoning, but a lack thereof. Often, the proposals were not only possible, but also fairly ordinary. The people rejecting them just didn't immediately see their merits, and had no interest in finding out. It was easier to say something can't be done than to admit that they didn't know how.

Unfortunately, this tendency was cultural, and I couldn't change it on my own. Of course, not everyone there was like this! 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, and things got better for me.

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 asked "what if?" and "how about?". Difficulties were something to explore, not a reason to shut down.

Things changed when an intern joined our team and was struggling with writing code. They quickly became frustrated and gave up when they encountered tasks that were "impossible", despite clear instructions and patient guidance. Really, they just didn't know what to do, leading 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 only a one-line addition to the transform function.

Here's some pseudocode:

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

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

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. This was a 12-month internship, so it was critical to make corrections early.

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 became a more confident developer.

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 skip-level today, 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!