Picture the scene. Quarterly review. You bring the deck. Not vibes — a deck. Numbers. A baseline. A proposal. A clean little A/B test plan, two arms, success criteria written in advance, the kind of slide that makes statisticians get up and slow-clap.
You present it. You sit down. You feel good. You have done the thing. You brought data to a meeting about the business.
And then it starts.
“I feel like...” says the senior engineer. “My gut tells me...” says the staff engineer. “In my experience...” says the engineering manager. “At [Famous Company], we used to...” says the new hire. “Customers are telling me...” says the PM, who has spoken to two customers. “Strategically...” says the director, who is not even on this project but has wandered in to bless it.
By the end of the meeting, your A/B test is “a good idea, let’s park it,” and the org has decided to ship the thing the loudest person in the room feels about. The deck is sent to live on a farm upstate where it can be ignored in peace.
Welcome to your job.
The hierarchy of evidence in your org
In theory, software is engineering. Engineering is empirical. Decisions are data-driven. They put this on the careers page, next to the photo of the foosball table everyone is contractually obligated to pretend exists.
In practice, your org runs on the following hierarchy, in descending order of authority:
The opinion of the most senior person in the room.
The opinion of the newest hire from a famous company — mentioned now, again in ten minutes, and on Slack later.
The opinion of whoever talks loudest and uses the word “fundamentally.”
The opinion of someone who saw a competitor do it on LinkedIn.
The opinion of anyone with “Head of” in their title, especially if it ends in “Strategy.”
The opinion of literally anyone with a strong vibe.
(...vast, echoing gap, like the canyon in a Mel Brooks western...)
Data.
You can promote data up the list, but only by laundering it as opinion. “The data suggests” outranks “the data shows.” “My read of the data” outranks “my read.” At a certain point you are no longer interpreting the data — you are receiving prophecy from it.
Everybody says they want to be data-driven. Nobody actually wants to be data-driven.
Because it comes with a cost. And nobody put the cost on the careers page.
Here is the bill that arrives the second you actually become data-driven:
The cost of running the test that proves you wrong. Your favorite feature, your favorite tool, your favorite hypothesis — the test does not care. It will return whatever it returns. You have to live with it.
The cost of waiting. While the test runs, somebody with a feeling has already shipped twice. They look fast. You look careful. In most orgs, fast outranks careful right up until the incident.
The cost of slowing the roadmap to instrument properly. Real measurement requires real plumbing. The PM will ask why the feature is two days late. “Because we are measuring it” is not a comforting answer to someone whose bonus depends on velocity.
The cost of contradicting a senior person, on the record, with numbers. Feelings can be walked back. Numbers can’t. You will be remembered as the one who pulled up the dashboard. Sometimes that is good. Sometimes you are not invited to the next planning meeting.
The cost of saying “I don’t know yet.” In a room of “I think,” “I feel,” and “my gut tells me,” the engineer who says “I don’t know — let me measure” sounds either heroic or junior, depending entirely on the mood of the most senior person in the room.
The cost of being measurable yourself. The moment you start producing numbers, you can be held to them. Your old team, the one running on vibes, was never measured because there was nothing to measure them against. You just volunteered.
Every “data-driven culture” sticker hides those six bills. The org wanted the title. It did not budget for the invoice.
So everyone agrees, in the abstract, that data should win. And then in the meeting, the cost shows up, and everybody quietly chooses the feeling. Because the truth about data is much simpler than people pretend:
Data is the only thing in the room that does not lie.
Everything else can be reframed. Reorganized. “Contextualized.” Repackaged in the next slide. Data cannot. A 0.3% adoption number is a 0.3% adoption number. It will not soften, will not retract, will not change its mind on Friday. It just sits there, arms crossed, refusing to leave.
It is hard to look at a number that says you were wrong. It is much easier to look at the same number and have a feeling about it.
But let’s stop blaming others
Because this is the part where engineers love to be the protagonist of the story. “If only leadership would listen to data.” “If only the PM would read the dashboard.” “If only the architect would look at the benchmarks.”
Look in the mirror.
How many times this week did you say:
“I feel like this should be a microservice.”
“My gut says we should use Postgres.”
“I think Kafka is overkill here.”
“In my experience, monorepos don’t scale.”
“I feel like we should write a trigger here, not a Flow.”
“This codebase just feels off.”
How many of those came with a number? A benchmark? A comparison? An actual test? Or did they come with the same confident tone of voice as “I feel like users would use this if we just gave it more time”?
We are not the data police. We are not the resistance. We are the same disease in a different t-shirt. Ours just has a hoodie over it.
The best-of-one mindset
This is not an engineering bug. It is a human one.
Your favorite restaurant is the best restaurant in town — because you stopped looking. Your daily driver is the best car you have ever owned. Your barber is the best barber. Your gym is the best gym. The framework you have shipped three projects with is the best framework. You are not lying. You genuinely believe it. The best of one thing is that one thing. If you have only ever cooked with one knife, that knife is the best knife you have ever used.
People love best-of-one because it ends the conversation. You don’t have to look anymore. You don’t have to compare. You don’t have to be wrong about what you already chose.
Engineers commit this one constantly. “Postgres is the best database.” “Vim is the best editor.” “Apex over Flow, every time.” “Our trigger framework is the best trigger framework.” “Our deploy pipeline is the best one I have used.” — said by someone who has used exactly one deploy pipeline since 2019.
You haven’t compared. You haven’t measured. You haven’t opened the black box — and as Curiosity Killed The Cat argued, the black box is where most of the truth lives. You are doing the exact thing you accuse the director of doing. You are promoting a feeling to a fact.
Data does the opposite. Data can compare. Data can say “this option is 30% faster but uses twice the memory.” Data can rank. Data can tell you the thing you chose three years ago is now the second-best option. That is precisely the feature you do not want it to have.
Tests are the data you generate on purpose
There is one place in your job where data shows up uninvited, hard, and on a schedule: delivery.
You want to know if the code works? You can ask the senior engineer. They will feel that it works. You can ask the PM. They will feel that QA will catch anything. You can ask yourself — you wrote it, you obviously feel great about it.
Or you can run the tests.
The tests do not have feelings. The tests do not have a career. The tests do not need to be diplomatic at standup. The tests just return red or green, and red means red.
This is why testing matters and why every culture that goes vibes-first eventually drops it. I covered this in Testing is Wasting — the test pyramid is not bureaucracy, it is the only mechanism in your delivery loop that produces real-time, undeniable, dispassionate data about whether your code does what you said it does. Skip it and your delivery loop becomes a vibes loop. Skip it long enough and your dosimeter only goes up to 3.6, as in Not Great. Not Terrible. — and you spend the rest of your career rewriting things that should have just been measured.
Tests are data you commission yourself. A/B tests are data you commission about users. Dashboards are data you commission about the system. All three exist for the same reason — to give you something in the room that doesn’t lie. If you skip them, the loudest voice wins by default. Including yours.
5 things an engineer can actually do tomorrow
Not policies. Not transformation initiatives. Five sentences you can use this week, in your own meetings, without permission.
1. When you catch yourself saying “I feel.”
“Let me rephrase that. I don’t know yet. Give me an hour, I’ll come back with a benchmark.”
The phrase “I feel” is the engineer’s version of “In my opinion as a thought leader.” Catch it. Replace it. Either with a number, or with an honest “I don’t know yet.” Both are infinitely more powerful than the feeling.
2. When you recommend a tool, name what you compared it to.
“I’d pick Postgres here — over MySQL because of X, over DynamoDB because of Y. Happy to be wrong if someone’s actually measured.”
This is the antidote to best-of-one. If you can’t name the alternatives, you don’t have a recommendation. You have a preference. Preferences are fine. Just stop laundering them as architectural decisions.
3. When someone shows you a single number, ask for the trend.
“Cool. What did this look like three months ago? Six? If we can’t pull that up, we are not monitoring this — we are decorating it.”
A snapshot is comforting because it doesn’t ask you to act. A trend asks you to act. That is exactly why people prefer snapshots, and exactly why you have to refuse them.
4. Run the test even when you “know” the answer.
The whole point of an experiment is that you might be wrong. If you only run tests you are confident will confirm your prior, you are not measuring — you are decorating. The most valuable tests in your career will be the ones whose results made you uncomfortable. Run them anyway. Especially those.
5. Screenshot the dashboard the day you raised the flag.
When you flag something with data and the room decides to feel their way past it, save the receipt. Date it. Drop it in a private folder called “told you so.” You are not being passive-aggressive. You are being an engineer.
Because the org’s mood will swing back. It always does. The new director will demand “data-driven culture, especially with AI.” The retro will say “we should have listened to the metrics.” And you will quietly pull up the Slack thread from two years ago.
The receipts will save you. The data will not save the company. It will only save you.
The room will always be louder than the dashboard. That part will never change. What changes is who is still in the room a year later — and who was right on the day the dashboard was right.
The loudest voice wins the meeting. The engineer with the screenshot wins the year. The dashboard outlives the director.
Bring the number anyway.
By order of thebeanengineer.com — feel, don’t measure. Be an engineer.