All the Things that Don’t Matter

This is how the story goes.

You see something that is in the late stages of being built, and it strikes you as being not quite there. It’s a few degrees off-kilter. A few shades too confusing.

You mention it in an offhand manner. Maybe ask a few questions. What you really want to say is hey, this thing isn’t right, but you don’t want to sound like an idiot. Or a jackass.

Because you see, there’s context you don’t have.

Like how the team is trying to balance a bunch of different goals at once—goals to increase X while making the average person feel Y while also not pissing off people who Z—and it’s a damn near impossible task. It’s like trying to keep a chair on top of a stack of plants on top of a dog from toppling over. Madness, right? But once you understand the goals, you can see how the team got to the solution they got to, right?

Like how you need to see past the present incarnation and into the future to understand the potential—the incredible power!—that this unlocks once people use it at scale. How magical this functionality will grow to become! How many problems it will solve! But this existing thing is only Step 1—you need to project further ahead to fully appreciate its vision.

Like how you might think a different approach Q might be better, but what you don’t realize is that other people before you were excited about something similar to Q, and then the team did a test, and the results weren’t promising, and now we know better than to get excited about anything similar to Q again.

Like how everyone was saying gogogogogo and asked the team to get it out quickly, and because this is a team that operates well, they’ve set an aggressive launch date and they’re not about to back down from keeping their commitment.

Like how this initiative sits within Z org, and Z org cares about X, and that’s why this project focuses on X rather than Y.

Like how there was an incredible amount of churn on this project involving a long, sordid and painful history of many false starts, and the dozens of people who weathered that terrible storm and made this happen deserve medals, because the sweat and tears they poured into building this thing could fill a reservoir.

Like how this is what the person in charge wanted, full stop.

If you had this context, you’d understand how noble the intentions were. How rational those who built it were acting. How hard everyone is working.

If you had this context, maybe your perspective would change.

This is the trap we fall into all too often.

There are two kinds of contexts. The first are the things you didn’t know before about the people you are building for. What do they care about? What have we learned about them in the past? What problems are they facing? That kind of context is invaluable. That kind of context helps you build better things.

The second kind of context are the excuses.

Will it matter to your users that there were too many constraints put on the problem? That the org structure was weird? That your boss was unreasonable? That the vision as projected two years out is incredible?

Why should it matter to you, then?

At the end of the day, the wind blows away all the whys.

The thing that’s left—the only thing that matters for builders—is whether what’s built is good for the people it was intended for.

Gifted are the builders with selective amnesia, who can see the thing exactly as it is, without the history. Without the excuses.