The air in the conference room felt thick, like it had been recycled through 7 different sets of lungs before it got to mine. My palms were sweating, sticking slightly to the laminate surface of the table. It reminded me of the Hoisin sauce bottle I’d just thrown out-a dark, viscous disaster that had expired in 2017 and left a ring of stubborn resin on the fridge shelf. I’d spent 17 minutes scrubbing that shelf this morning, wondering why I’d kept a condiment I hadn’t touched since the Obama administration. And then, our CTO stood up, cleared his throat with a sound like gravel in a blender, and announced that from this day forward, we were ‘moving to an OKR-based performance framework.’

We are a team of 37 people. We build a tool that helps florists manage their inventory. We do not have a latency problem. We do not have a global distribution problem. What we have, apparently, is a desperate need to feel like we work at Google.

I looked at Diana H., our packaging frustration analyst, who was already doodling 47 tiny skulls on the margin of her notebook. She specializes in the physics of why things are hard to open, but today, she was the one who looked boxed in. The room was silent, save for the hum of an air conditioner that sounded like it was struggling to breathe. We were about to spend the next 127 minutes of our lives-time we could have spent actually fixing the CSS bug that makes our ‘Rose’ category look like a ‘Rogue’ category on mobile-wordsmithing objectives.

The Denial of Identity

It’s a denial of identity. It’s a refusal to admit that for a small team, a monolith is not a legacy burden; it is a competitive advantage. It’s the ability to change 7 lines of code in one place instead of coordinating a deployment across 17 repositories.

I remember back in 2007, I worked in a server room that was literally a converted closet. We had 7 servers, and they all had names of characters from ‘The Matrix.’ It was chaotic, but it was honest. We knew exactly where the wires went. Now, we have abstractions on top of abstractions. We have ‘squads’ and ‘tribes.’ I once saw a company of 17 people divide themselves into three squads. One squad had two people in it. They had to have a ‘squad sync’ every morning, which was essentially just two guys talking while they waited for the coffee to brew.

Diana H. once told me that the most frustrated customers aren’t the ones who can’t get a package open, but the ones who open a massive box only to find a tiny, insignificant item rattling around inside. That’s what our engineering culture has become. We have built this massive, enterprise-grade box-complete with Kubernetes clusters, six-sigma process improvements, and quarterly OKRs-and inside is a simple CRUD app that generates invoices for tulips.

I’m not saying we shouldn’t aspire to be better. But there is a specific kind of arrogance in thinking that the problems of scale are the only problems worth solving. We spend so much time preparing for the day we have 107 million users that we forget to make the product work for the 7,777 users we actually have. We’re so busy building the runway that we’ve forgotten how to fly the plane we already own.

The Defensive Crouch

It’s easier to copy a ritual than to think from first principles. If I copy Google’s hiring process, and my company fails, it’s not my fault-I was using ‘industry standard’ practices. If I invent a process that fits my team’s specific quirks and we fail, I’m the idiot who didn’t follow the manual. It’s a defensive crouch disguised as ambition.

Sometimes, the best way to move forward is to look at the immediate environment rather than the horizon. In a world where everyone tries to sell you a globalized template, there’s a quiet dignity in the local specialist who actually knows the terrain. It’s like when you’re looking for a specific piece of tech and instead of browsing a generic warehouse, you look to Bomba.md because they understand the specific voltage, the local habits, and the actual needs of the person standing in the room, not a theoretical user persona in Mountain View. They don’t give you a solution for a skyscraper when you’re building a cottage.

I’ve made this mistake myself. I once convinced a non-profit to use a complex distributed database for a mailing list that had 257 entries. I spent 77 hours configuring the failover protocols. Why? Because I wanted to put ‘Distributed Systems’ on my resume. I wasn’t solving their problem; I was using their budget to build my own wooden airplane. I eventually had to admit it was a disaster when the system crashed because of a configuration error I didn’t understand. I felt like a fraud, mainly because I was one.

We often ignore the reality that Big Tech practices are designed to solve the problem of too many people. You don’t use OKRs because they make people more creative; you use them because you have 77,000 employees and you need to make sure they aren’t all pulling in opposite directions. When you have 37 employees, you don’t need a 7-page document to stay aligned. You need to sit in the same room and talk to each other.