Kubi's Blog

I got fired. It felt sudden and completely unexpected, but in hindsight, the signs had been there for a while. In the past 72 hours, all those lingering signals finally clicked and now I can clearly see what I did wrong: I tried to please my director instead of doing the job … and it came back to haunt me.

In this nine-minute read, you will come across one of the most important lessons I have learned, and one that is not easy to find elsewhere. Over the past 10 years, five during my career and five during university, I have spent a great deal of time on LinkedIn, reading countless posts along with many blogs beyond it, yet I have never seen this lesson expressed quite like this. So grab your coffee and get ready for something honest, confessional, and genuinely instructive.

I’ve never quite learned how to sound confident.

There were things I could do in my life without hesitation such as playing football at a high level, walking into the nationwide exams and coming out first among a million students, setting off on unplanned adventures, hitchhiking, pitching a tent in the middle of nowhere. In those moments, I moved with certainty. But when it came to my voice, that certainty always slipped away.

When I first started this job where I worked as an AI Engineer, they handed me a small survey. Your strengths on one side, your areas to improve on the other. I didn’t pause, not even for a second. I knew exactly what to write under improvement: sounding confident. Don’t confuse it with being confident. My problem is even bigger: even when I was sure, I still sounded unsure.

That’s why, in one of my first meetings at the company, when we were deciding which tools to use and which paths to take for a major project, I couldn’t do more than gently suggest what I believed was the right choice. I knew the answer, or at least I trusted my understanding of it. Still, it came out as a suggestion, not a stance.

The next paragraph gets a little technical, but only just. You’ll find the main two reasons I was fired waiting at the end of it. But don’t jump there yet, I suggest you continue reading in order.

We were building a graph-based search system in which entities linked to one another through all kinds of relationships, so that at inference time, you could follow the threads: who connects to whom, and under what conditions. I knew Neo4j was the natural fit. It’s what you reach for when the world you’re modeling is made of nodes and edges. So I said something like, “I think Neo4j is a great choice because it’s a graph database.” Even now, I can hear how soft it sounded. Not a decision, just a suggestion. A few seconds later, our CTO brought up Google Spanner, a service I hadn’t even heard of at the time. Looking back, I realize this suggestion was likely influenced by the fact that nearly all the other services and frameworks used in the company were part of the Google ecosystem. I’m not entirely sure, but I assume there was some agreement in place that gave us access to Google services at a significant discount. Still, I was quite surprised that I had never come across such a tool before, despite having over five years of professional experience and another five years as a student. He said it is a good choice for graph problems, and he surely sounded more confident than I did. I admitted I didn’t know it, but I’d look into it. And I did.

Here’s the heart of it, without drowning in jargon:

Neo4j is graph-first. Every part of it is built for movement from one node to the next, directly, almost instinctively. It uses something called index-free adjacency: no searching, no detours, just following a pointer in memory like a straight line through a map. Google Spanner, on the other hand, is relational at its core. It’s a distributed system, built on key-value storage, and later it learned how to speak graph but that’s all it is: an added layer, a translation, not its native tongue. It doesn’t live and breathe graphs; it accommodates them. You cannot have a Spanner Graph without first defining the underlying table structures. In Google Spanner, a graph is not a separate storage silo; it is a logical view built on top of traditional relational tables. And that distinction matters more than it seems. Because the role I applied for explicitly spoke of graph search, GraphRAG, and similar ideas. The work itself was supposed to be rooted in graphs. However, in my final meeting, the one where they told me they would not move forward, I was criticized for my system being slow, which I will address later, and not being sufficiently ‘graph-based’.

It was the very same direction I had been nudged toward. The same voice that once said, “use Spanner”, now criticized me for building a system that was no longer graph-based and was too reliant on traditional queries and joins. Don’t get me wrong. I’m not innocent in this. I was the one who said the next day, “It looks like Spanner has graph support as well, and since we’re already using many tools in the Google ecosystem, so let’s try it.”

At the time, it felt reasonable to go along with my director rather than push back and try to convince him otherwise. How could I have known that this decision would come back to me later as one of the reasons I would be let go? I could not have known. But I could have listened more closely to myself, to the years I had spent learning, to the long hours of reading, and to the quiet confidence I had built over time.

Instead, I let it pass. I went along. Maybe I didn’t trust my voice enough to defend the other path. Maybe I didn’t want to be that person, the one who resists, who pushes back, who makes things uncomfortable. Maybe I was afraid that if I stood too firm, I’d be out even sooner. I did have one small experience where my initial attempt to push back during my first week was met with a negative response, which I’ll touch on later in the article. So that may have influenced me as well, though I can’t say for certain.

And that wasn’t a risk I felt I could take. There was a newborn at home, a life that depended on me to provide and to show up steady and reliable. A wife who had followed me across countries, leaving behind her own work, her own ground and now unable to continue her career here. The weight of it all sat quietly on my shoulders. So I chose the easier way out.

I became the one who agrees. I chose to please my director instead of doing the job. I became the “Yes Man”.

As I mentioned earlier, the system’s slowness came up too. What’s almost ironic is that I had seen it coming. In the early days, I sat down with the CTO and the Tech Lead and laid out a trade-off: speed versus accuracy. We were trying to ingest every characteristic of every product in the catalog. But some of those characteristics were ghosts. In one extreme case, there were 268 characteristics, and 150 of them appeared in just a single product. Once, across roughly 5,000. I remember suggesting we leave those out. Not out of laziness, but intention. They added weight, slowed everything down, and the chance of them ever being useful was almost negligible. One in ten thousand, maybe less. A risk you take, because no system is ever whole. Not even close. In this world dominated by AI, even 98% is often called perfection.

But then came the hesitation.

“What if,” the Tech Lead said, “during a demo, the customer asks about exactly that product and uses exactly that attribute? That one edge case?” He didn’t say the rest out loud, but it lingered in the room. *What if it fails? What if it returns nothing? What if that moment costs us the deal? And the CTO agreed. We couldn’t take that risk. So the decision tilted the other way. Bring everything in. No exceptions.

I should have pushed back. I should have said, So what? The likelihood of them even asking about that specific product and its rare attribute was less than one in ten thousand. And even if it did come up, so what? We could simply add that particular characteristic to the system later. You acknowledge that it has near-perfect accuracy, even if it is not 100%, and move forward. No system is flawless, and that is the reality anyway.

But I didn’t say that. I said, “Okay.”

And I carried it forward. All 268 characteristics, every edge case, every rare signal. And here’s the part that matters: the problem wasn’t just the database growing heavier. Databases can handle weight. That wasn’t the real strain. The real cost lived elsewhere. Each characteristic meant another LLM call (although concurrent, still slows the system), another request, another conversation with the model. One by one, they stacked quietly, invisibly until the system slowed under its own ambition. Again, without diving into the details, trust me on this: leaning on those extremely rare characteristics was a costly mistake, and it weighed the whole system down. I could see it working 60–75% faster with leaving out the rare (which had frequency under 0.1%) characteristics.

Okay, enough tech talk. I’ll mention one last signal that I missed and I’ll end this.

About four weeks before I was let go, I asked the CTO for a week off. My son needed critical checkups in Germany, where he was born. He also had heart issues. This was not a last-minute request, as I had asked for a week off three months in advance. I sent the email. A week passed. Silence. I followed up on our internal chat just to make sure he’d seen it. The next day, he replied: “Yes, I saw it. I’ll get back to you.” He never did.

Two more weeks went by, and something else began to shift. Subtle at first, then harder to ignore. In our morning standups, he’d engage with everyone else, ask questions, respond, stay present. But when it was my turn, his camera would go dark. Once, he even left the meeting the moment I started speaking. It felt deliberate. Like a quiet message, not spoken but performed: You’re already gone. Maybe it was his way of softening the blow before it arrived. Or maybe it was simpler than that: why listen to someone who won’t be here much longer? I don’t know. What I do know is how it felt: to be slowly erased in real time, as if I had already stopped existing in the room. And still, I didn’t piece it together. Not yet.

Two weeks later, I reached out to him once more via DM. This time, he said, “You can take it”. Just like that. As if the silence before it hadn’t meant anything, as if the question had simply been waiting somewhere out of sight. Looking back, it feels like he wanted it to fade into the background until something else arrived. All those small things, the delayed replies, the unanswered e-mails, the way I was quietly avoided in meetings… they were all pointing in the same direction. A pattern, soft but persistent.

And I missed it.

It all clicked late on a Thursday (Friday was the May 1st holiday), near the end of the workday, when he called for a meeting. There were three of us. The moment I saw the HR representative in the participant list, I understood what it was about. A realization that came all at once, just a little too late. I should’ve seen it coming from miles ago, but I didn’t. Ironically, that final meeting ended up being the longest interaction I had with him in the past month.

I made a lot of mistakes in that job, and I learned from almost all of them. The biggest lesson I took with me is this: Don’t try to please your director, just do the work well. If the product stands, everything else follows. But I made those mistakes out of fear. The fear that if I spoke too firmly, too clearly, I’d be shown the door. During the interviews, one of the company’s CEOs told me that I should speak up and warn others about potential system failures or share any strong ideas for improvement. The company’s culture document reinforced the same expectation. With that in mind, I tried to set aside my more hesitant side and acted accordingly during my first week. I took a close look at the codebase, occasionally leaning on Claude, and noticed several areas that could be improved. Some were not minor tweaks but more fundamental issues, such as the use of two languages where I believed one, Python, would have been sufficient. From what I could tell, the second language and its framework did not serve a clear purpose and seemed to be included simply for the sake of using it. Unsurprisingly, it was also part of the Google ecosystem. I suggested removing the unnecessary framework and simplifying things by relying on plain Python, along with five or six smaller improvements. I documented all of this and sent it in an email that first Friday to the CTO and both CEOs. The CEOs, who were not technical, responded positively, looped in the CTO, and encouraged further discussion. What came back, though, was something else entirely. A long reply. Dense, abstract, and, to me, unconvincing. He spoke in abstract terms, referring to things like hidden burdens and unseen costs. I never fully grasped what he meant. I read it, but very little of it actually made sense to me. I read it more than once, trying to make sense of it, but it never quite settled. Even now, I think some of those earlier decisions had been made in a rush. The kind of rush that says, “Google has a framework, we’re already in that ecosystem, why not use it?” Maybe there were credits involved, maybe just convenience.

But beneath all that, I heard a quieter message: Don’t dig too deep. Don’t question too much. Just move forward.

And something in me shifted after that email. I started to hold back. To soften. To stay quieter than I should have. As I said, I was already wired to speak softly and it’s just how I am. And when I finally tried to break out of that in a new place, I hit a wall. What I was reaching for slipped out of my hands, and I ended up continuing to be the uncertain man I’ve always been.

Looking back, that might have been the worst decision I made.

The funny thing is that my fear of losing the job was totally nonsense. After the first 72 hours of my exit, I already secured three job interviews. If only I could be braver and stand up and defend my opinions. The worst isn’t that bad at all, I see it now. “The fear of death is worse than death itself.”

Anyway, life goes on. As Mandela said, “I never lose. I either win or learn.”

I learned a big one.